This page last changed on Jan 12, 2011 by barf.

The present, LIRC-based, controller IR-command has several shortcomings. I have managed fairly easily to overcome these, as described in this article. This is achieved by linking to my pet,  Harctoolbox, see also this. A new "command" (in the sense of this article (thanx Juha; it was understandable)) for the controller, called "newir" is constructed. This can not only send devicename/commandname pair to a LIRC server (as the present "ir" command) but also invoke GlobalCache and Irtrans IR gateways directly. IR-Codes in CCF format can be sent directly to GlobalCaches and Irtranses, also LIRC if applying a non-official patch. To IRtrans  (the ethernet model with "database") and LIRC-servers also devicename/commandname pairs can be sent (assuming that the server knows them of courses). More interestingly, a number of IR protocols are known (can be extended), and it is possible to send protocol/devicenumber(/subdevicenumber)/commandnumber type of commands, see this article. These are transformed to CCF-codes before sent to an IR-Gateway. Even more high-level: given appropriate device descriptions, devicename/commandname pairs can be given, which are transformed to CCF-form and sent to the appropriate gateway.

This article can be considered as a practical follow-up to the more theoretical article. It should be considered as a proof-of-concept,  intended for discussion and feedback, not for end user deployment.

This is a patch against https://openremote.svn.sourceforge.net/svnroot/openremote/branches/OpenRemote_Boss_2_0_DeveloperReleases/Controller_2_0_0_Alpha11  revision 3186.

Create a directory src/org/openremote/controller/protocol/newinfrared and put GatewayType.java, NewIRCommand.java, and NewIRCommandBuilder.java therein. Patch build.xml with  build.xml.diff and config/applicationContext.xml with applicationContext.xml.diff. Get the binary Harctoolbox, unpack, and put harctoolbox.jar in the new directory lib/harctoolbox. Put the dtds, protocol-, and devices subdirectories in the root directory of the used tomcat server. The controller should now build and be deployed by "ant war" and "ant deploy". (The upnp-stuff had some issues; so I just deleted it from my working copy.)

Since this patch only considers the controller, it is necessary to custom hack controller.xml with, e.g. a  standard text/XML editor, and repack the openremote.zip, and uploading...

The command element in the hacked controller.xml should now have "newir" as the value of the protocol attribute. There are now a number of new properties of the command:

  • gateway_type: one of globalcache, irtrans, lirc_client
  • ip_address: obvious. For LIRC, there should be a LIRC network server.
  • connector: IR connector of IRtrans or GlobalCache. AFAIK  not supported for LIRC, Typically "1".
  • module. Only for GlobalCache, see its API-documentation. Typically "2" on a "small" GC, "4" on a "large".
  • count: obvious
  • ccf: CCF format of signal. Leave empty if using protocol or devicename, see below.
  • interface: only for IRTrans, one of tcp_ascii, udp, http. Denotes interface used to communicate with the IRTrans. CCF-form of IR-signals requires UDP. "tcp" not supported.
  • devicename: either devicename for a LIRC server or a preprogrammed ("database") IRTrans, or used with the device evaluation, see below.
  • commandname: analog to devicename.
  • protocol: name of IR protocol, like RC5 or NEC1. Used together with devicenumber, possibly subdevicenumber, and commandnumber to compute CCF.
  • devicenumber: see protocol
  • subdevicenumber: see protocol
  • commandnumber: see protocoll

Be sure to get the difference between, e.g. devicenumber and device name: The first is, e.g. 'denon_avr_a100', the latter a small, nonnegative number to be used by the protocol.

We have now essentially four different use cases, dependent on the properties:

  1. a commandname/devicename pair is sent to the ir gateway (LIRC, IRTrans/tcp_ascii (with "data base"))
  2. User enters a CCF that is sent to the IR gateway (GC, IRTrans/UDP, patched LIRC)
  3. User enters protocol, devicenumber (possibly subdevicenumber), and command number. This is used to compute a CCF signal, sent as in usecase 2. For example, protocol="rc5", devicenumber=0, commandnumber=12 power cycles most Philips TVs.
  4. User enters device name and device number, using a device description file, CCF is computed and sent to the IR gateway as in usecase 2.

It should be pointed out that in a more final version, it may be better to eliminate usecases 3 and 4 in the sense of letting the designer/beehive compute the corresponging CCF instead of the controller, as above.

BTW, here is a controller.xml that can be used as an example.

Ohh, most likely I got at least something wrong. Please bear with me if everything does not compile and work exactly like described...

Document generated by Confluence on Jun 05, 2016 09:29