This page last changed on Nov 19, 2010 by ebariaux.

I have started work on adding support for the Lutron HomeWorks system to OpenRemote and will use this thread to document the implementation and design decisions as well as ask any questions to help me move forward and integrate correctly in OR.

I've created 2 branches in the SVN repository for this implementation, you can find them at:

https://openremote.svn.sourceforge.net/svnroot/openremote/branches/feature/Designer_2_0_0_Alpha7-LutronHomeWorks-ebariaux for modifications made to the modeler

and

https://openremote.svn.sourceforge.net/svnroot/openremote/branches/feature/Controller_2_0_0_Alpha9-LutronHomeWorks-ebariaux for modifications made to the controller

All feedback and suggestions are welcomed.

Eric

Let's start with a quick description of the system.
Lutron is a company making high end Lighting control systems. It has been in the business for quite some time (> 50 years) and has several products on the market addressing needs from single load to whole house.
The product I'm integrating into OR is the HomeWorks system (current version, not the coming QS version), which is a whole house system.
In a nutshell, the system is composed of a central processor (or up to 16 for big installations) and a bunch of devices for input (keypad, contact closure) and output (relays, dimmers, blind controllers) sitting on the processor bus. Each device (or element in a device e.g. one of the loads of a dimmer) has a specific address on the bus.

OR will connect to the central processor through an IP connection and will provide command and feedback.

The different types of command that will be implemented are roughly as follows:

  • dimmer (raise, lower, stop or fade) : this addresses a specific load, having a unique address. Raise/lower will start raising or lowering the level until the stop command is sent. Fade will move to a specified level (taking a specified amount of time to do so). Note that blinds are also included in this category.
  • scene select : one of the device setting on the bus can be a GrafikEye. This is typically used to control 1 room that has several loads. In addition the centralized control as above, it offers local control of each load and definition of local scenes. This command recalls those local scenes from the central controller.
  • keypad "emulation" (push, release, hold, double tap) : this emulates the user action on a keypad device (either a physical keypad or a virtual one).

Some other less used or system wide commands are available in addition to those ones but I'll start with that, this will cover 80% of the needs and 95% of the design decision required.

I'll go into more details on how this is implemented as I cover my changes made to the modeler and controller.

Posted by ebariaux at Nov 19, 2010 11:19

Modifications made to the Modeler.

The main modification is adding the protocols/protocols/lutron_homeworks.xml file.
This adds another protocol type to the modeler interface to enter Lutron specific information.

So when adding a command to a device, you can now choose the "Lutron HomeWorks" protocol.
Doing this will display 4 additional fields to enter information:

  • address : address of the device on the bus, required for all the currently implemented command. This will be relaxed later for system wide commands. Also, regular expression used for validation will be improved in future.
  • command : one of the possible action : RAISE, LOWER, STOP, SCENE, PUSH, RELEASE, HOLD, DOUBLE_TAP. FADE has been left out at this stage, I'll take care of it later. Also, it would be nice if this could be a drop down menu instead of requiring the user to type in the command but this requires changes to the modeler code and protocol XML schema.
  • scene : only used by the scene command. Again, making this appear/disappear or disable based on the command entered above would be nice but not supported without code modification at this stage.
  • key : only used by the keypad commands. Some comment as scene.

The other modification to the modeler is adding a custom configuration section for the login information.
For an external device to connect to the HomeWorks processor, a username and password must be configured on Link 9 of the HomeWorks system (using the Lutron software). This username/password must be provided by the client upon connection (i.e. by OR controller in this case).
Communication with the HomeWorks is basically a telnet session. So OR needs IP/name of processor and port to use (default telnet port of 23 can be changed). For the sake of completeness, Lutron also broadcasts an AMX DDDP beacon that can be used for auto-discovery, so IP and port are optional.

All this configuration information should normally be associated with 1 HomeWorks processor, thus 1 device in OR.
As it is not possible to define this at this stage, I did create a system wide custom configuration. This is done in the file config/controller-config-2.0-M7.xml and appears in the modeler under "Config for Controller".

Posted by ebariaux at Nov 19, 2010 11:38

Related to this, I have a question on the implementation to do in the controller.

What is the correct way to access to this custom configuration section? Looking at the existing code, I see that there is a specific class for roundrobin configuration but that everything else is packed in 1 class.
I would tend to think that adding a LutronHomeWorksConfig class under org.openremote.controller would be the most appropriate. Still I'm a bit puzzled by the way this class is instantiated and accessed as there are several methods in ConfigFactory for getting it. Can you shed some lights on that?

Posted by ebariaux at Nov 19, 2010 11:42

Given the above described command, I'd like to have one button the raise a level or blind that will behave so that when I press on the button, the RAISE command is send and when I release the button, the STOP command is send. Is this possible with the current system? I haven't found a way to do this.

Basically a similar but even more complex scenario is the one of the keypad commands above, as based on the interaction of the user with the button potentially 4 different commands could be sent. Already having push and release (so same scenario as above) would be good. I believe hold and double tap might be left out of the protocol implementation.

Posted by ebariaux at Nov 19, 2010 12:37

Right now I've no idea – anything that works is good enough for me for the time being.

It looks like getCustomBasicConfigFromDefaultControllerXML() is what you're looking for.

It needs to be cleaned up. It's a proper mess.

Posted by juha at Nov 19, 2010 12:50

he he, we were commenting on this with juha this morning. China... Essentially tell yourself it is the same in parts of the android codebase. Sometimes we "refactor" is one way of putting it. Feel free to leave little "refactor me!" nuggets' with your comments if feasible.

it is not "you", horror stories around a beer sometime...

Posted by marcf at Nov 19, 2010 14:02

Given the above described command, I'd like to have one button the raise a level or blind that will behave so that when I press on the button, the RAISE command is send and when I release the button, the STOP command is send. Is this possible with the current system? I haven't found a way to do this.

The current 'repeat' for a button repeats the command (repeated send, like infrared) until released, but press and release are not handled as two distinct events – can only bind one command to a button (or macro set of commands).

Properly done would need to be addressed with an updated XML schema, something we can add to TODO for next iteration.

I am trying to think of if we can hack together something intermediate by setting properties on designer (lutron specific) and handling them in the protocol implementation... need to think about it.

Posted by juha at Nov 19, 2010 19:55
Document generated by Confluence on Jun 05, 2016 09:31