This page last changed on Jul 21, 2009 by barf.
I would like to join this community, of which I became aware of just recently. I hope to be able both to contribute (also as a developer) as well as profit (in whatever sense!) from it in the future.
The last 3 years I have more or less secretly worked on infrared signals, file formats (XML), java classes and XML transformations, in the context of (infrared) remote control and home automation. I use "Harc" as project name. Instead of trying to reach a "finished" state, I wrote a rudimentary documentation, and put the stuff on my web server, and thisis the outcome. Download link at the end of the article. There is much stuff that I hope this community will find interesting and usable. All GPL-3, except for file formats (DTDs etc), which are in the public domain.
I have some more concrete ideas on "synergies", to be discussed later.
Looking forward to hear from you, and to work with you.
Thanks for getting in touch. It definitely looks like an interesting project. At the moment of particular interest is any available code related to translating across different IR code formats.
Let us know your further thoughts,
Posted by juha at Jul 22, 2009 19:02
These are my (immediate) thoughts:
In the short time span, it should be very easy for the controller to support the Harc server as additional protocol. There are two ways to achieve this: either through the socket interface (using a Harc server on either the same or a remote machine), or by calling the Java classes directly (as jar-files). This would already have large advantages over the present Lirc-solution. See alsothe absence of IR routing for one. Actually, I hope to have my own
home-setup run like this shortly.
In the slightly longer time span, here are some (not yet very developed) suggestions: The device configuration format should be very interesting for Beehive. Beehive presently supports data in LIRC format. The LIRC format has many shortcomings, which I have dealt with on my web-site. It was made for a particular purpose, using it in Beehive seems to take it far outside of that domain. My device configuration format is intended as a machine readable description of all the interfaces of a device(-class), without instance specific information like remote control buttons, IP-address. It can also contain several IR command sets (for example, many Philips TVs can be controlled both by RC5 and RC6 IR commands), as well as command sets for bidirectional communication (TCP sockets, serial,...). As far as I am aware of,
there is nothing similar at the moment, at least not non-proprietary. When vendors publish commands for their devices, it
is in general as pdf- or Excel-files, i.e. nothing machine readable. Also note for example the Eventghost project: the approach is to write a plugin (in the Python language) for each device to be supported. My proposed device format is certainly not well tested and mature, but I hope (and think!) that it is fairly usable starting point. By the way, my code is GPL-3, while I have decided to make file formats including DTDs public domain. (Yes, migrating to schemes would
be desirable...) So this format, (with redundant CCF information), should be a good alternative for Beehive. (Strictly speaking, exchange format for import and export). I plan a "translator" from LIRC files, should not be too hard (basically writing a LIRC "IRDevice" that writes files instead of sending IR light).
Reading your article on UIComposer 2.0 it strikes me that your concept of "Building modeling" is quite close to a GUI for my "home file", although the emphasis is different.
Posted by barf at Jul 23, 2009 19:40
Protocol integration is what we do, so that seems a viable route. There are a few people here visiting the site regularly who went through the exercise of integrating their own favorite protocol, and at least according to them, the process is not too painful. Let us know if you need help with that, the documentation is still a bit lacking. We will integrate additional protocols into mainline to be released as priorities permit.
Translator from LIRC files is another thing that interests us at the moment, coming from other priorities. If you don't mind, let me know the status of this effort and lets discuss it directly over email: juha (at) openremote dot org.
Posted by juha at Jul 27, 2009 09:08
Interesting... so it seems CCF import might be in the works?
any thoughts on the direction...
Bengt.. Sounds interesting... Like to hear more.
Posted by avdorks at Nov 06, 2010 00:57
I can import CCF files of the first generation Prontos http://www.pronto.philips.com/Products/Archive/ using the API of the Tontoproject. However, only the IR-codes are taken into account. Also ccf-exports are possible. Just download; it is there. I intend to write some more in the Pronto thread.
I have written a fair amount more stuff, which are presently not released...
Posted by barf at Nov 07, 2010 13:29
Bengt.. I have users Tonto a few time for gathering codes.. See you on the pronto side..
I think bringinf in the devices would be the best bang for the buck on this one... just my 2cents.
Posted by avdorks at Nov 12, 2010 14:12
Just a short update: I have changed the project name to Harctoolbox and registered the domain harctoolbox.org. Correspondingly, the package name (in the sense of Java) was changed to org.harctoolbox -- makes integration easier. I also uploaded a new release called 0.6.0 -- although the word "release" is a bit of a misnormer; it is rather a snapshot of my code etc.
Posted by barf at Jan 13, 2011 17:58