Openremote with Heyu
Openremote is installed on my Beaglebone Black. I wanted to control my CM11 X10 device with Openremote. Openremote can control the CM11 device directly. But this gives us one way only control over the devices. And I wanted to see the status of the X10 devices. Since I used Heyu in the past which gives device status feedback, I wanted to reuse this setup for Openremote.
Openremote is an opensource remote control application for mobile devices. I contains a server, a cloud based development tool and a number
of apps for Apple and Android devices. Although Openremote can control X10 devices connected on the local USB port directly, I only provides
on-way control over the X10 devices. Not all commands are supported, most importantly the all-off command does not work in this setup.
However Openremote can also execute commandline scripts. This is our entrance to controlling X10 devices via Heyu.
Heyu is a program that listens and controls the CM11 interface connected via serial or USB. It is a daemon that listens to all activity that happens on the X10 network. So the X10 network status is knows by Heyu and can be viewed. We can also send almost any X10 command with this tool. I have used Heyu for a couple of years now using a self made web interface using PHP. But now I want to integrate the X10 network in my home automation system which is controlled by Openremote.
The first thing we need is a couple of scripts for every remote control command that we want to use in Openremote. For some unkown reason I was not able to call Heyu directly from Openremote. So I made a one-line shell script for every on and off command.
The script looks like this:
/usr/local/bin/heyu on A1
This script turn the X10 device on address A1 on. So I made another 15 scripts for all other devices (A1 - A16) to turn them on and off. I could have made a more intelligent script, but this also works fine.
To control a device, Openremote uses commands. There must be an on and an off command for every device.
The protocol will be 'Shell execution protocol' which will call our 'a1 on' script. The same must be done for every device for both the on and off commands.
Reading device status
Reading the device status is more complex. We could call every individual X10 device to get the status and report this to Openremote. But the X10 protocol is very slow. A status update could take a couple of seconds. And we can only send 1 command at the time. To be reliable we want Openremote to get the status of all devices every couple of seconds. So calling X10 devices will not work. However Heyu caches the status of all devices. Heyu constantly listens to the X10 network and records all commands passed on this network. So Heyu knows the status of the network, this is not 100% secure. But for normal use the Heyu cache status is accurate enough. And getting the info from Heyu takes just a fraction of a second, which is what we need.
Openremote has a nice feature to populate multiple sensors (which hold the device status) in just one call. So we can call Heyu to give back the status of all devices in one call. The command 'heyu info' gives us the on/off status of the devices. It will not give us the dim status, but for now it's fine. Maybe I will add functionality for dim status in the future.
Again we need a script to call Heyu. This script is a little more advanced since we need to convert the output of the Heyu command to something Openremote can understand. I used the following script:
/usr/local/bin/heyu info | tail -2 | head -1 | cut -c 39-54 | sed 's/0/off /g' | sed 's/1/on /g'
The script takes the 2nd last line of the output and converts the 0's and 1's between the brackets to 'on' and 'off'. This is the output Openremote can handle.
Now we can create a command in Openremote to execute this script.
To get the status we need the 'Shell execution' protocol to call our status script. The polling interval tells Openremote on what frequency the script must be called to get the status. The Regular expression tells Openremote how to get the status values. In our case the values 'on' or 'off'. All values are read in a single call, but we need to populate multiple sensors. A sensor contains the status of a device in Openremote. All sensors must be entered separated by a semi-column.
For every sensor name listed in the command we need to create a sensor. The name of the sensor must match. The sensor calls the status command and is of type 'switch'.
Now we can create a switch for the X10 devices that actually tells the current status.
The switch uses the sensor to get the current status of the device. The on command and off command are used to turn the device on and off.
Now a new switch can be added to a screen. We can choose an image for on and for off. Depending on the status of the X10 device the correct image and command will be displayed.
Using this setup we can use X10 devices bidirectional, so we can control them and get the actual status back. The X10 protocol is very slow. This is reflected in the remote. Pressing a button will take a second or more to activate and give the correct status back. So when you press the switch, it will take some time to actually switch to the other position.
Debugging these setups can be very tricky. But both Heyu and Openremote can give us a lot of debugging information. As long as you know were to look. First start by configuring Heyu correctly. Make sure Heyu works fine, also check with the user running Openremote.
Next try the scripts. Are they running correctly and do they give the right output?
Last look at Openremote. By default Openremote doesn't give debug information on shell scripts. To enable shell script logging add the following lines to the configuration file '$openremotehome/webapps/controller/WEB-INF/classes/log4j.properties'.
log4j.logger.OpenRemote.Controller.protocol.SHELLEXE = ALL, shell-file log4j.appender.shell-file = org.apache.log4j.RollingFileAppender log4j.appender.shell-file.File = ../logs/shell.log log4j.appender.shell-file.Threshold = DEBUG log4j.appender.shell-file.MaxFileSize = 500KB log4j.appender.shell-file.MaxBackupIndex = 1 log4j.appender.shell-file.layout = org.apache.log4j.PatternLayout log4j.appender.shell-file.layout.ConversionPattern = %p %d (Shell): %m%n
The log file shell.log provides debug information on executed shell commands.