Not too long ago, I discussed adding the ActiveEye Motion Sensor (outdoor model MS16A) to my home automation system. At the time, the sensor communicated with a CM19A computer interface and the Mochad gateway relayed messages to the Domoticz server. This time around, the sensor will communicate with a RR501 Transceiver Module which will translate the radio frequency messages from the sensor to power line messages that will be picked up by the CM11A computer interface. The Heyu gateway relays these messages to the Domoticz server.
Previous post: Motion sensor using CM19A computer interface
This post: Motion sensor using CM11A computer interface
- X10 ActiveEye Motion and Dusk Sensor.
- CM19A USB PC Transceiver.
- ActiveHome Computer Interface. No longer available from the manufacturer, but still found in retail channels.
- RF Based Transceiver Module. Should work with the TM751 Wireless Transceiver Module which I believe works with a single house code.
- Raspberry Pi:
- Single board computer. Both configurations were tested with the shown Raspberry Pi 3 Model B (latest version of the board), a Raspberry Pi Model B+ (2014) and a Raspberry Pi 1 Model B (2011).
- Wired connection using a Universal Serial Bus cable (version 2.0 for all Raspberry Pi)
- Wireless radio frequency link.
- Power line link over household wiring.
- Wired serial connection compatible with RS-232 (Recommended Standard 232). A proprietary cable is used, with a standard DE-9 (DB-9) female connector at the computer end and a telephone type male RJ-11 connector at the CM11A interface.
Table of Contents
- What the Sensor Does
- What the Sensor Does Not Do
The sensor is meant to operate as follows. While the sensor detects motion, it sends wireless "on" messages. The house and device code sent with these messages is programmable. The first of these messages switches the light on, the following do nothing (except clutter the airwave and power line) because the switch is already on. Once the sensor no longer detects motion, it waits for a programmable period of time and then sends a wireless "off" message.
Presumably, there is a lamp or appliance with the same house and device code that will turn on and off in response to these messages. Since the sensor uses radio frequencies to transmit its messages, there has to be a transceiver such as the RR501 or TM751 to convert them to power line messages.
The sensor is also a dusk sensor. If enabled, it will send an "on" message when it gets dark at the next house and device code to the one programmed. It will send an "off" message when it gets light. It is also possible to disable the motion messages during daylight.
The mode of operation described above may not be appropriate. For example,
- it is not possible to light two or more lamps when motion is detected if they are connected to X10 modules with different addresses.
- If a light were already on before the sensor detects someone outside then it must not be turned off after motion is no longer detected because, presumably, that light was serving a purpose.
Of course, Domoticz can resolve this mess by acting as go between. It will read the incoming message from the sensor via the transceiver and Heyu bridge and it will send out the appropriate power line commands via the Heyu bridge to any number of connected lamps. Since Domoticz knows the state of these lamps when it receives sensor data, it can work out if any should not be turned off after the prescribed delay.
It turns out that when you change the batteries, the sensor will return to the default address: A1. After loosing the settings a few times because of this, I gave up and decided to accept the default. This probably need to be changed, as there is greater likelyhood that neighbours are using X10 hardware with the default address.
I setup my sensor to report movements day and night and to report dusk and dawn explicitly. By default the latter is done with an on and off message to an address with the same house code as the motion sensor but with a unit code equal to the successor of the motion sensor. This means the sensor will be sending "A2 on" messages to report on that dusk has arrived and and "A2 off" to denote dawn.
I did not change the default behaviour for the off message. I can use the adjustment screw on the sensor itself to dial in the delay. But it does not really matter, the off message will be almost ignored; the software will take care of turning off the lights.
Summarizing, I have setup the MS16A so that it looks like two sensors:
- "A1 on" : motion has been detected and
- "A1 off" : no motion detected in the last xx minutes (not used)
- "A2 on" : it is dark
- "A2 off" : is is light outside.
Adding the motion sensor is as simple as adding a switch to virtual hardware. However, it is not possible to find the appropriate sensor type among those available for virtual sensors. Instead I added a manual switch in the way I suggested was not appropriate a while back:
- Click on the Switches tab.
- Click on the at the top left of the page.
- Fill in the correct information in the Add Manual
Light/Switch Device window.
- Select the hardware; in this case, only Heyu is available.
- Give the device a name. Showing unbridled imagination, I called it
- Select the switch type:
- It may be necessary to change the House Code and Unit Code if that X10 is already assigned to a virtual device. This address does not have to reflect the physical address of the real sensor.
- Finally, click on the
Adding the dusk sensor is more of the same. Do change the device
name and switch type to reflect the nature of the sensor.
It will also be necessary to set a different X10 address.
The default A1 could be changed to A2 for example.
As Domoticz does not interact directly with X10 hardware, it will be necessary to write scripts to handle the two sensors.
The scripts that I created a few weeks ago for using the ActiveEye Motion Sensor with the Mochad gateway, will work with the Heyu gateway.
First, a user variable needs to be added to the Domoticz database.
- Click on the Setup tab.
- Click on More Options in the drop-down menu.
- Click on User variables is the second-level drop-down menu.
- Complete the
- Set the name to
- Set the variable type to
- And set the variable value to
- Set the name to
Second, add a hidden virtual switch, called
to the Domoticz database.
- Click on the Setup tab.
- Click on Hardware in the drop-down menu.
- Click on the
- Name the sensor
$SensorStateand change its type to switch. Starting the name with a dollar sign '$' hides that switch which will be visible only in the devices list
- Click on the OK button.
Save the following script as a file named
script_device_heyu_active_eye.lua in the
lua scripts directory
All 'Off' messages from the motion sensor are ignored at all times. Motion sensor messages 'On' messages are also ignored unless
- the dusk sensor indicates that it is dark, and
- the hidden $SensorState switch is off.
Sensor_Delaycontains the specified number of minutes that lights should be turned on when motion is detected. It is a simple matter to edit this delay in the Domoticz web site.
The hidden virtual switch
$SensorState is being used as a
timer. Once it is turned on for the specified number of minutes all other
motion sensor messages are ignored. Since this is the only script that modifies
the state of this switch
The script to be performed by Heyu must be added
Note how the lua script ignored
A1 off messages but the
Heyu script does not. It responds to them by
turning the virtual motion detection sensor off in the Domoticz database. How long it takes for this to happen can
be controlled by the adjustement screw on the top of the sensor.
While testing this new setup on the older Raspberry Pi, I had my other home automation system running on the newest single board computer. The CM19A connected to that system was picking up the wireless messages from the motion sensor. I was surprised at the number of garbled messages that the Mochad gateway was unable to decipher. I ended up turning off email notifications of errors, because my mailbox was getting too many messages.
In the previous post on this subject, I discussed the long time needed for the script to perform its actions. This delay will be longer here because of the extra step done by the RR501 transceiver. Placement of the sensor may be even more critical. It remains to be seen how that will work out in the new home for my old the X10 hardware.