But lately I notice lately that EventGhost has been putting out some strange error messages when I'm using the XTB. Most times after sending an X10 command, EG would issue a "Powerfail" message (generated in the code by an "/xA5"). In fact, if I unplug the unit then reconnect to AC it issues a "Powerfail" message too. Also, yesterday there were a string of "EEPROM" messages (generated by an "/x5B") at one per second for about 32 minutes straight. The CM11A does not perform in the same manner. I contacted Jeff Volp, creator of the XTB and he was not familiar with EG unfortunately.
He replied to my email with the following response, which means almost nothing to me since I am not that technical. Can anyone take a look at it and figure out if there is something that can be done to ensure compatibility with the XTB-232, since overall it works a LOT better than my CM11A. Thanks!
The CM11A issues a Power Fail Poll once a second when there is a power interruption. Even though the the XTB-232 does not need the clock information, it duplicates that poll to be compatible with the applications that expect it following a power interruption. The automation software is expected to respond with a clock update to cancel the request. From the CM11A protocol spec:
5.1. Power-fail Macro Download Poll Code.
NOTE: I beleive that this is mainly for the CP10. The battery
backed CM11 does send this poll after a power failure, but it
responds to a setclock directive rather than the macro download.
It waits till the resumption of power before it starts sending this byte.
DBS, Jan 1, 1997
In order to poll the PC, the interface will continually send:
Poll: 7 6 5 4 3 2 1 0
Value: 1 0 1 0 0 1 0 1 (0xa5)
This signal will be repeated once every second until the PC responds with
a clock update ( 0x9b see section 8 ).
5.2. PC Response to Macro Download Poll Code.
To stop the polling, the PC must respond with:
PC Response: 7 6 5 4 3 2 1 0
Value : 1 1 1 1 1 0 1 1 (0xfb)
Once this has been transmitted, the macro must be immediately
downloaded. At this stage, the interface will wait until the 42 byte
macro has been received before any X-10 transmissions can occur.
8. Set Interface Clock.
This command is purely intended for the CM11 and CP10.
The PC can set the interface clock with an unsolicited transmission at
any time. In addition, once the interface detects the absence of power,
it will request the current time from the PC when the PC is available as
For a CM11, the time request from the interface is: 0xa5.
The PC must then respond with the following transmission
Note: The bit range is backwards from what you'd expect in serial
communications. Bit 55-48 is actually the first byte transmitted,
etc. To make matters worse, the bit orientation is correct within
the bit range, IE bits 4-7 of byte 6 _IS_ the monitored house code.
Further, bits 0 and 1 of byte 6 appear to be flipped. I get a
"monitor status clear" if bit 0 is set.
The original docs had bit 23 as part of current hours AND day.
DBS Jan 1, 1997
Descriptions of bits 0-3 are now correct as shown below.
CWS Sep 1, 2002
Bit range Description
55 to 48 timer download header (0x9b) (byte 0)
47 to 40 Current time (seconds) (byte 1)
39 to 32 Current time (minutes ranging from 0 to 119) (byte 2)
31 to 24 Current time (hours/2, ranging from 0 to 11) (byte 3)
23 to 15 Current year day (MSB is bit 15) (byte 4+.1)
14 to 8 Day mask (SMTWTFS) (byte 5-.1)
7 to 4 Monitored house code (byte 6...)
2 Timer purge flag
1 Battery timer clear flag
0 Monitored status clear flag
The CM11a will not respond to any other transmission until its time
request is satisfied. Per Buzz Burrowes, sending just the header (0x9b)
followed by some indeterminate delay of the order of 10 milliseconds
is sufficient to satisfy the time request without having to modify the
clock setting. (CWS May 19, 2003)
The full CM11A protocol document can be downloaded from the XTB-232 page on our website http://jvde.us/
I don't know why your CM11A does not perform similarly because the one I used during XTB-232 firmware development certainly sends out the power-fail poll a power interruption. The fact that the XTB-232 keeps sending it means your EventGhost software is not responding properly to that request. Neither the XTB-232 nor the CM11A will respond to actual commands until the clock update is received.