Known Issues with ActiveHome Pro

From X10Wiki
Revision as of 18:41, 28 May 2014 by X10douglas (talk | contribs)
Jump to navigation Jump to search

A macro sends an extra command that is not in the macro

The CM15A seems to have a bug where if you send a command immediately after dimming a light, an extra command gets sent (or the last dim command gets mangled). This command could turn the module on or off or may even turn all lights on or off. If you check in the activity monitor, the extra command is not listed but the modules respond to it. Reordering the macro to do the dimming last or inserting a short delay after the dim command should solve the problem.

After working for a short while, the powerline gets flooded with "Status Request" signals

There is a quite rare but known incompatibility between the CM15A and certain brands of coupler repeaters. SmartHome and Leviton coupler repeaters are known to be incompatible (I suspect the X10 Pro C/R is also incompatible since X10 designed the Leviton C/R. If anyone can confirm or deny this, please let me know). Users have claimed that ACT's coupler/repeaters don't have this problem (though I haven't tried them myself). If you know of any others please let me know.

If you run into this problem you have three options:

  1. Use a passive coupler,
  2. Use a coupler/repeater that is known not to exhibit this problem, or
  3. Use a controller other than the CM15A.

I have a theory as to what is causing the problem. To understand this you have to know that X10 dimmer receivers (lamp modules and light switches) will interpret any command immediately following a bright or dim command (with no pause) as another bright or dim command regardless of what the command actually is. When X10 designed the Leviton coupler/repeater, they took advantage of this and made it transmit (“repeat”) just enough data when multiple dim commands are received for the receiver to think that it was receiving another dim command.

I am guessing that the CM15A is interpreting this “repeated dim” as a J-Status Request (1111 1111) and figures a collision has occurred. When a collision occurs the transmitter is to abort the command and retry when the line is free. When the CM15A retries to transmit the DIM command the cycle starts all over again.

Since ACT coupler/repeaters handle multiple dim commands differently, they don’t exhibit this behaviour.

This is only a guess on my part, but I haven’t heard any other theories.