md
Domespic [3] Gateways
December 13, 2016
Previous: Part 2 - Raspbian Next: Part 4 – Domoticz

Install Mochad

Do not install the "latest" mochad package available from Sourceforge as it has problems in Raspian Jessie. For some reason Sourceforge currently serves mochad version 0.1.16 (as of 1 Nov 2016) even though version 0.1.17 is available. The following shows how to install the later version. However you should check for a newer version here: https://sourceforge.net/projects/mochad/files/ and adjust the wget commands accordingly.

pi@rpi2b:~ $ sudo apt-get install libusb-1.0-0-dev pi@rpi2b:~ $ mkdir mochad pi@rpi2b:~ $ cd mochad pi@rpi2b:~/mochad $ wget -O mochad.tgz https://sourceforge.net/projects/mochad/files/mochad-0.1.17.tar.gz/download pi@rpi2b:~/mochad $ tar xf mochad.tgz pi@rpi2b:~.mochad $ cd mochad* pi@rpi2b:~/mochad/mochad-0.1.17 $ ./configure pi@rpi2b:~/mochad/mochad-0.1.17 $ make pi@rpi2b:~/mochad/mochad-0.1.17 $sudo make install

We will check that the Mochad daemon is not running, plug in the CM19A or CM15A into the USB and check that the daemon is then active and issue an 'on' and 'off' commands to an TM751 Wireless Transceiver module at address D1.

pi@rpi2b:~/mochad/mochad-0.1.17 $cd $home pi@rpi2b:~ $ sudo systemctl status mochad ● mochad.service - Start mochad service Loaded: loaded (/lib/systemd/system/mochad.service; disabled) Active: inactive (dead) Plug in the CM19A or CM15A and wait a little while... pi@rpi2b:~ $ sudo systemctl status mochad ● mochad.service - Start mochad service Loaded: loaded (/lib/systemd/system/mochad.service; disabled) Active: active (running) since Tue 2016-11-01 01:37:38 ADT; 10s ago Process: 1296 ExecStart=/usr/local/bin/mochad (code=exited, status=0/SUCCESS) Main PiD: 1301 (mochad) CGroup: /system.slice/mochad.service └─1301 /usr/local/bin/mochad Nov 01 01:37:38 pib2 mochad[1296]: starting Nov 01 01:37:38 pib2 systemd[1]: Started Start mochad service. Nov 01 01:37:38 pib2 mochad[1301]: Found CM19A Nov 01 01:37:38 pib2 mochad[1301]: In endpoint 0x83, Out endpoint 0x04 Now test the gateway... pi@rpi2b:~ $ echo "rf d1 on" | nc localhost 1099 11/01 01:39:46 Tx RF HouseUnit: D1 Func: On pi@rpi2b:~ $ echo "rf d1 off" | nc localhost 1099 11/01 01:39:58 Tx RF HouseUnit: D1 Func: Off

Debugging

If something does not work, there are a few things that can be done to pinpoint the cause. This is probably not an exhaustive list.

  1. The Mochad service is not running,
    Verify its status and then restart it.
    pi@rpi2b:~ $ sudo systemctl status mochad ● mochad.service - Start mochad service ... Nov 26 11:43:43 rpi2b systemd[1]: Unit mochad.service entered failed state. pi@rpi2b:~ $ sudo systemctl start mochad pi@rpi2b:~ $ sudo systemctl status mochad ● mochad.service - Start mochad service ... Nov 26 11:49:56 rpi2b mochad[6669]: starting Nov 26 11:49:56 rpi2b systemd[1]: Started Start mochad service. Nov 26 11:49:56 rpi2b mochad[6670]: Found CM19A Nov 26 11:49:56 rpi2b mochad[6670]: In endpoint 0x83, Out endpoint 0x04
  2. The X10 transceiver (TM751 or RR501) relay clicks but the lamp does not turn on.
    • the lamp is not plugged in the transceiver,
    • the lamp is turned off,
    • the bulb is burned out.
  3. The X10 transceiver (TM751 or RR501) relay does not click.
    • the house code of the transceiver is not 'D',
    • the unit code of the RR501 is not '1',
    • the CM15A is too far from the X10 transceiver
    • if using power line commands with a CM19A then there could be a phase problem. There is lots of information on the Web about this vexing problem. I wasted a lot of time because of this, I was sending rf through a CM19A which also repeated them to the power line. At the time, the 220 volt baseboard was on which bridged the two power phases. The RR501 responded to the power line commands so that I did not figure out that the rf on the CM19A was broken!

Install Heyu

Just as there is no direct support for the CM15A/CM19A interfaces in Domoticz, there is none for the CM11A. A "gateway" called heyu can be installed. It is actually a home automation program of its own but limited to the X10 protocol via the CM11A interface.

Installation of Heyu is quite similar to that of Mochad: get the source code, compile it and install the resulting binary.

pi@rpi2b:~ $ mkdir heyu pi@rpi2b:~ $ cd heyu pi@rpi2b:~/heyu $ wget -O heyu.tgz https://github.com/HeyuX10Automation/heyu/archive/v2.10.tar.gz pi@rpi2b:~/heyu $ tar xf heyu.tgz pi@rpi2b:~/heyu $ cd heyu* pi@rpi2b:~/heyu/heyu-2.10 $ ./Configure pi@rpi2b:~/heyu/heyu-2.10 $ make ... plenty of time to do something else! ... ** Now become root and run 'make install' ** pi@rpi2b:~/heyu/heyu-2.10 $ sudo make install mkdir -p -m 755 /usr/local/bin cp heyu /usr/local/bin chgrp root /usr/local/bin/heyu chmod 755 /usr/local/bin/heyu chown root /usr/local/bin/heyu ./install.sh I did not find a Heyu configuration file. Where would you like the sample Heyu configuration file installed? 1. In directory /home/pi/.heyu/ 2. In subdirectory .heyu/ under a different user home directory 3. In directory /etc/heyu (for system-wide access) 4. No thanks, I'll take care of it myself Choice [1, 2, 3, 4] ? 1 Creating directory /home/pi/.heyu The sample configuration file will be installed as /home/pi/.heyu/x10config I will add the TTY port for your CM11 to the config file Specify /dev/ttyS0, /dev/ttyS1, etc., or the word dummy To which port is the CM11 attached? tty tty ./install.sh: 198: [: tty: unexpected operator I could not find the device you specified. Please try again. Specify /dev/ttyS0, /dev/ttyS1, etc., or the word dummy To which port is the CM11 attached? /dev/ttyUSB0 Setting uid:gid = 1000:1000 for /home/pi/.heyu/x10config Changing TTY permissions to 777 The directory /var/tmp/heyu was created with the permissions 777. The permissions for the SPOOL directory (/var/tmp/heyu) are OK The permissions for the directory /var/lock were set to 1777 cat install.sh >install chmod a+x install pi@rpi2b:~/heyu/heyu-2.10 $

Hopefully, Heyu is installed correctly. Check by invoking the application's information command and then try to turn a device on and off

pi@rpi2b:~/heyu/heyu-2.10 $ cd $home pi@rpi2b:~ $heyu info starting heyu_relay Heyu version 2.10 Configuration at /home/pi/.heyu/x10config Powerline interface on /dev/ttyUSB0 Firmware revision Level = 7 Interface battery usage = Unknown Raw interface clock: Wed, Day 327, 00:03:28 (--> Civil Time: Wed 23 Nov 2016 00:03:28 AST) No schedule has been uploaded by Heyu. Housecode = A 0 = off, 1 = on, unit 16.......8...4..1 Last addressed device = 0x0000 (0000000000000000) Status of monitored devices = 0x0000 (0000000000000000) Status of dimmed devices = 0x0000 (0000000000000000) pi@rpi2b:~ $ heyu on b1 pi@rpi2b:~ $ heyu off b1
Note the first line about starting the relay. We'll come back to it.

Of course X10 commands take some time to travel along the power line. So don't expect instant responses. However what I actually got was something like a three second delay between invoking Heyu and the device reacting. However the program provides an explanation for the excessive delay:

pi@rpi2b:~ $ heyu on b1 RI serial line may be stuck. RI serial line may be stuck. pi@rpi2b:~ $ heyu off b1 RI serial line may be stuck. RI serial line may be stuck.
It turns out that the culprit is the serial <--> USB cable I used. It was cheap for a reason. The question is addresses in the Heyu FAQ:
If getting a long delay when switching lights on and off and report of 
Q: I get the message "RI serial line may be stuck"
   after a long delay.

A: This is a problem with some adapters using an older Prolific chip.
   The workaround is to put the directive 'CHECK_RI_LINE  NO' in your
   Heyu configuration file.

The proposed solution works. Both the installation script and the information command say where the configuration file is located.

pi@rpi2b:~ $ nano /home/pi/.heyu/x10config
... # HOUSECODE A # A B C D E F G H I J K L M N O P # Workaround for "RI serial line may be stuck" problem with older Prolific chip # based USB-serial adapter: CHECK_RI_LINE NO ...

Note how the first invocation of Heyu started the relay, a service (daemon) that communicates with the CM11A. Whenever a Heyu command is issued, the program starts the relay if it is not already running. It takes a few seconds to start this service. Thus when a first "on" or "off" command is issued after a reboot, there will be a considerable delay before it is executed. It would be better to start the relay during the boot process. This can be done following the advice in X10 with CM11a wiki:

To restart Heyu at 10 minutes before the end of every hour (because it sometimes fails) and whenever the Rasberry Pi is rebooted, edit the crontab file as follows:

pi@rpi2b:~ $ crontab -e ... select the editor you want to use, the default is nano which has been used throught this guide.
# For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command 50 * * * * /home/pi/heyu-2.10/heyu start @reboot /home/pi/heyu-2.10/heyu start

I have not found Heyu particularly flaky, but the above advice means that a problem could resolve itself after an hour. This could be very useful when away for an extended period.

A final pointer: remove all timers and macros that could still be stored in the CM11A. I did not do this and for a while I was wondering what was turning on and off some of the living room lights at seemingly random times. It had been a couple of years since I had used the CM11A but still it contained some timers.

pi@rpi2b:~ $ heyu erase Erasing all blocks of data on the eeprom ................................................................ pi@rpi2b:~ $

Backup

If your gateway is (or gateways are) working, it may be a good idea to backup the SD card. That means copying the content of the SD card to a file image on your desktop computer. In fact, it amounts to performing the initial Debian image installation process in the opposite direction.

The specific instructions for installing the Debian image to an SD card with a Linux desktop also explain how to do the reverse. If you have a Windows or Mac OSX machine, you can hopefully figure out how to reverse the direction of the copy operation. Here are the series of commands used on Linux:

michel@hp:~$ df -h ... identify the physical device containing the boot partition (fat) ... and the operating system (ext) partition. In my case it was sde. michel@hp:~$ sudo umount /dev/sde1 michel@hp:~$ sudo umount /dev/sde2 michel@hp:~$ cd Downloads/raspberrypi michel@hp:~/Downloads/raspberrypi$ sudo dd bs=4M if=/dev/sde of=backup.img

Previous: Part 2 - Raspbian Next: Part 4 – Domoticz