Difference between revisions of "CM11A"

From LinuxMCE
Jump to: navigation, search
 
(18 intermediate revisions by 10 users not shown)
Line 1: Line 1:
<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>[[Category:Pluto_Devices]]
+
[[Category: Hardware]]
 +
{{Versioninfo}}
 +
[[Category: Power Line Control]]
 +
[[Category: X10]]
  
 +
== Reference Info ==
 +
Just for reference:
 +
 +
''[[CM11A]]'' is pc interface to powerline only
 +
 +
''[[CM15A]]'' is pc interface to powerline PLUS wireless signals (RF)
 +
 +
''[[CM19A]]'' is wireless signals (RF) only (you'll need a 751 or other to convert to powerline signals)
 +
 +
[http://forum.linuxmce.org/index.php?topic=10417.msg73261;topicseen#msg73261 Forum discussion]
 +
 +
 +
''For setup information see [[CM11]]
 
== Description ==
 
== Description ==
CM11A is a device that uses [http://hypermetrics.com/rubyhacker/x10proto.html X10] protocol to control lights (and may be other stuff) around the house by injecting data into powerline.
+
CM11A is a device that uses the [http://hypermetrics.com/rubyhacker/x10proto.html X10] protocol to control lights (and maybe other stuff) around the house by transmitting data over powerlines.
  
Each X10 device has an address formed as ''housecode''[A..P]+''unitcode''[1..16]. As powerlines are usually shared between near houses/apartments it's a good idea to choose other housecode than your neighbor, or purchase and properly install a filter.
+
Each X10 device has an address formed as ''housecode''[A..P]+''unitcode''[1..16]. Becuse powerlines are often shared by neighboring houses and apartments, it's a good idea to choose a housecode different from your neighbor's. Otherwise, purchase and properly install a filter.
  
To control those devices you need a small box which is connected to computer (this one is CM11A), whith it you can send commands to the devices.
+
To control those devices you will need a small interface box which is connected to computer (the CM11A)). With it you can send commands from the computer to the devices.
  
The command usually consist of few bytes (command itself and unit to control) and an exchange of checksums needed because the line may be noisy and commands weren't received corectly. In this case the retransmition is required by protocol.
+
The command usually consist of a few bytes (the command itself and the address of the unit to control). An exchange of checksums is needed because the lines are often noisy and commands may not be received correctly. In noisy conditions, retransmission is required by protocol.
  
There are several commands the pluto's CM11A implements:
+
There are several commands that LinuxMCE's CM11A wrapper implements:
 
* '''CMD_Generic_On''' will send x10 ON
 
* '''CMD_Generic_On''' will send x10 ON
 
* '''CMD_Generic_Off''' will send x10 OFF
 
* '''CMD_Generic_Off''' will send x10 OFF
* '''CMD_Set_Level''' depending on the existing level versus requested level will send DIM or BRIGHT
+
* '''CMD_Set_Level''' depending on the existing level. The requested levels will send DIM or BRIGHT.
  
Some devices may send commands to CM11A device (mostly motion detectors or some other bidirectional devices). We don't have any in the office so even if the code exists, it wasn't tested properly, but it should send SensorTripped event.
+
Some devices may send commands to CM11A device (mostly motion detectors or some other bidirectional devices). We don't have any in our office, so even if the code exists, we were not able to test it properly. It should be able to send a SensorTripped event.
  
 
== Implementation notes ==
 
== Implementation notes ==
* ''CM11A'' is responsable for getting commands from pluto and transform them in X10 commands
+
* ''CM11A'' is responsible for sending commands from LinuxMCE and transforming them into X10 commands
* ''DevicePoll'' will doo all the communication with device (sending commands, checking checksum, etc) and also will treat any ''InterfacePool'' requests comming from bidirectional devices.
+
* ''DevicePoll'' will perform the communication with peripheral devices (sending commands, checking checksum, etc). It will also process any ''InterfacePool'' requests coming from bidirectional devices.
* ''Message'' will transform unit code from for example 'A9' into internal X10 code '67'. Don't ask why, that translation is required by protocol.
+
* ''Message'' will transform the unit code. For example 'A9' will be converted into the internal X10 code '67'. Don't ask why -- the translation is required by the protocol.

Latest revision as of 11:47, 20 December 2010

Version Status Date Updated Updated By
710 Unknown N/A N/A
810 Unknown N/A N/A
1004 Unknown N/A N/A
1204 Unknown N/A N/A
1404 Unknown N/A N/A
Usage Information

Reference Info

Just for reference:

CM11A is pc interface to powerline only

CM15A is pc interface to powerline PLUS wireless signals (RF)

CM19A is wireless signals (RF) only (you'll need a 751 or other to convert to powerline signals)

Forum discussion


For setup information see CM11

Description

CM11A is a device that uses the X10 protocol to control lights (and maybe other stuff) around the house by transmitting data over powerlines.

Each X10 device has an address formed as housecode[A..P]+unitcode[1..16]. Becuse powerlines are often shared by neighboring houses and apartments, it's a good idea to choose a housecode different from your neighbor's. Otherwise, purchase and properly install a filter.

To control those devices you will need a small interface box which is connected to computer (the CM11A)). With it you can send commands from the computer to the devices.

The command usually consist of a few bytes (the command itself and the address of the unit to control). An exchange of checksums is needed because the lines are often noisy and commands may not be received correctly. In noisy conditions, retransmission is required by protocol.

There are several commands that LinuxMCE's CM11A wrapper implements:

  • CMD_Generic_On will send x10 ON
  • CMD_Generic_Off will send x10 OFF
  • CMD_Set_Level depending on the existing level. The requested levels will send DIM or BRIGHT.

Some devices may send commands to CM11A device (mostly motion detectors or some other bidirectional devices). We don't have any in our office, so even if the code exists, we were not able to test it properly. It should be able to send a SensorTripped event.

Implementation notes

  • CM11A is responsible for sending commands from LinuxMCE and transforming them into X10 commands
  • DevicePoll will perform the communication with peripheral devices (sending commands, checking checksum, etc). It will also process any InterfacePool requests coming from bidirectional devices.
  • Message will transform the unit code. For example 'A9' will be converted into the internal X10 code '67'. Don't ask why -- the translation is required by the protocol.