Openremote with Heyu

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

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

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.

Controlling devices

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:

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'.

X10 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

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'.