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.
Testing
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.
macros
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
Discovery is not supported because that kind of information is not available in the X10 specification.
Configuration
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.
Channels
| Thing | Channel Type ID | Item Type | Description |
|---|---|---|---|
| switch | switchState | Switch | An On/Off switch |
| dimmer | lightDimmer | Dimmer | A dimmable device |
Example
Things
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" ]
}
Items
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
-
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.
-
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.
References
Changelog
Version 0.1
- initial release
Resources
jar: org.openhab.binding.x10-3.3.0-SNAPSHOT.jar
sources: x10_binding_v0.1.zip
