X10 Controller Binding [;


The X10 Binding supports the CM11A serial and via the Mochad server the CM15A/CM19A usb interfaces.

The binding can control switches and dimmers connected via X10 and also captures the messages to keep track of the current state.

  • The CM11A is a serial interface that allows a computer to control attached X10 modules via power line.
  • The CM15A is a usb interface that allows a computer to control attached X10 modules via power line or RF.
  • The CM19A is a usb interface that allows a computer to control attached X10 modules via RF.


The binding has been tested with a CM15A controller. CM11A and CM19A support is currently not tested.

Hardware - CM11A

The CM11A is a device that communicates over a serial interface.
Most people connect it to a computer using a serial to USB adapter.

Use of serial port

The binding opens the serial port when it starts and keeps it open until the binding is terminated.
If the serial port is disconnected a reconnect will be attempted the next time it is needed.
Therefore, other applications should not attempt to use the port when OpenHAB is running.
However, another program could load macros into the CM11A before openHAB starts.

CM11A macros

The CM11A is also able to store a schedule and control modules based on that schedule.
That functionality in not currently supported by or used by this binding.
This binding doesn’t clear macros from the CM11A so other programs could load macros before openHAB is started.
If you want to do scheduling using openHAB you should be sure there are no macros in the CM11A.
The heyu clear command can be used for this purpose.

Hardware - CM15A/CM19A

The CM15A/CM19A are device that communicates over the USB interface.

To connect to these devices you need to use the Mochad server: https://sourceforge.net/projects/mochad/.

The Mochad server can also be run in a docker container: https://hub.docker.com/r/jshridha/mochad/dockerfile

Use of serial port

The binding opens a connection to the Mochad server when it starts and keeps it open until the binding is terminated. If the connection is lost a reconnect will be attempted every 5 seconds.

Other programs can connect to the Mochad server simultaneously, but the state of Things will not be properly updated.


The CM15A/CM19A are also able to store a schedule and control modules based on that schedule.

CM15A macros and timers are NOT supported. For best results, use AHP

(ActiveHome Pro) to clear interface memory and disable the internal RF to PL

repeater. This ensures the CM15A behaves like a transceiver.

Supported things

The binding currently supports the following thing types:

  • switch - which supports on and off states
  • dimmer - which can be dimmed in addition to turned on or off


Discovery is not supported because that kind of information is not available in the X10 specification.


The CM11A/CM15A/CM19A act as a Bridge to the controlled modules, which are represented as Things.

Bridge Configuration

The CM11A bridge requires the parameter serialPort which identifies the serial port the cm11a is connected to.

The CM15A/CM19A bridge requires the parameter host which identifies the host name or IP address of the Mochad server

and the parameter port whcih identifies the TCP port of the Mochad server.

Thing Configuration

Each attached thing must specify the houseUnitCode set in the device (i.e. A1).

Optionally the extendedDimming option can be set to true to use extended dimming code. Not all x10 devices might support this.

This allows setting absolute values for dimming directly. If set to false only allows relative changes in dimming value (supoprted by all X10 dimmer devices).

Optionally set the viaRF option to send the X10 commands via the RF interface of the CM15A/CM19A.


Thing Channel Type ID Item Type Description
switch switchState Switch An On/Off switch
dimmer lightDimmer Dimmer A dimmable device



Bridge x10:cm15a:MyCm15a  [ host="mochad.local" ] {
    Thing switch SwitchA1 [ houseUnitCode="A1", viaRF=true ]
    Thing dimmer DimmerA2 [ houseUnitCode="A2", extendedDimming=false ]

Bridge x10:cm11a:MyCm11a  [ serialPort="COM3" ] {
    Thing switch SwitchB1 [ houseUnitCode="B1" ]
    Thing dimmer DimmerB2 [ houseUnitCode="B2" ]


SwitchA1  "Kitchen Plug"   <light>  (someGroup)  { channel="x10:switch:MyCm15a:SwitchA1:switchstatus" }
DimmerA2  "Porch lights"   <slider> (someGroup)  { channel="x10:dimmer:MyCm15a:DimmerA2:lightlevel" }
SwitchB1  "Garage Plug"    <light>  (someGroup)  { channel="x10:switch:MyCm11a:SwitchB1:switchstatus" }
DimmerB2  "Garden lights"  <slider> (someGroup)  { channel="x10:dimmer:MyCm11a:DimmerB2:lightlevel" }

Known issues

  1. When openHAB starts up it doesn’t restore the last state of each module. And, the X10 protocol does not provide a discovery service. Therefore it assumes everything off.

  2. The dimmer slider can get out of sync with the actual light because of the way X10 works. On some switches if you turn them on they will go to full bright and some switches will return to the previous dim level.


  1. CM11A (X10) Protocol Document
  2. Heyu - control software for the CM11A
  3. Mochad source forge project


Version 0.1

  • initial release


jar: org.openhab.binding.x10-3.3.0-SNAPSHOT.jar
sources: x10_binding_v0.1.zip

1 Like


Is this binding supposed to support Openhab 3? I get errors when trying to use it.
After I add the add-on I create a thing for a cm15a. It adds successfully and shows as a bridge.
I checked and it is connected to my mochad address and port. Before I even create a thing for an x10 item. I see errors in the openhab log when an x10 string comes in from mochad. The error is:
2022-10-06 16:51:25.615 [WARN ] [ternal.handler.AbstractBridgeHandler] - Bridge is not set

Can you help with this or is this not supported for OH3?


I made it specifically for OH3. Not sure where it goes wrong for you (and I have no time to dive into it currently). I use textual configuration myself, shouldn’t make a difference, but who knows. Like:

Bridge x10:cm15a:interface "X10 Interface" @ "Meterkast" [ host="nas.fritz.box", port="1099"]
    Thing dimmer woonkamer "Licht Woonkamer" @ "Woonkamer" [ houseUnitCode="M1" ]

I did try textual config as well. But I will try again. What version of Openhab 3 did you test on?
I’m running 3.3.0. Also is this binding bi-directional? Can I send commands to mochad as well?
I’m currently trying to use the binding to received x10 events from the cm15a via mochad.

I’m still on 3.3.0.M3.
The binding is bidrectional. You can send commands (that is my main use case).

The problem seems to be in receiving x10 events. Which is my case. I have a lot of x10 motion sensors and they send events back to openhab. With this binding I get those errors about bridge not set everytime an x10 motion sensor sends back an event. Any ideas?


Curious if you found a solution.

I have a similar problem using OpenHAB 4.03. Things are working fairly well, but If I send a command to turn on a light with an X10 handheld remote, I get:

2023-10-13 18:03:06.458 [WARN ] [ternal.handler.AbstractBridgeHandler] - Bridge is not set
2023-10-13 18:03:07.289 [WARN ] [ternal.handler.AbstractBridgeHandler] - Bridge is not set
2023-10-13 18:03:08.161 [WARN ] [ternal.handler.AbstractBridgeHandler] - Bridge is not set

If I send the same command from within ActiveHomePro I get:

2023-10-13 18:13:30.389 [WARN ] [ternal.handler.AbstractBridgeHandler] - Bridge is not set
2023-10-13 18:13:33.742 [WARN ] [.binding.x10.internal.CM15AInterface] - CM15A/CM19A received a command but no address and no previous address is available.

The addresses are defined in OpenHAB (e.g. E5, E1). I’ve “disabled” the RF transponder using AHP: