CM11A plugin issues with XTB-232

Questions and comments specific to a particular plugin should go here.
Post Reply
wysocki
Experienced User
Posts: 56
Joined: Mon Nov 23, 2015 9:23 pm
Location: Los Angeles area

CM11A plugin issues with XTB-232

Post by wysocki » Tue Apr 02, 2019 2:16 am

I replaced my CM11A with the XTB-232 a few weeks ago primarily because the CM11A was hanging on commands every now and then. The XTB-232 has rave reviews for being a better alternative to the CM11A and is available at http://jvde.us/xtb-232.htm It has been a solid replacement and has more signal strength than the CM11A, reducing errors in communication to my devices.

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
follows:

CM11:

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...)
3 Reserved
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.

Jeff

User avatar
kgschlosser
Site Admin
Posts: 4756
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: CM11A plugin issues with XTB-232

Post by kgschlosser » Tue Apr 02, 2019 7:49 am

it is getting sent.

Code: Select all

                        elif b == "\xA5":
                # power failure event; set the clock to clear
                ###print "xA5 received. Setting clock."
                self.TriggerEvent("PowerFail")
                serial.Write("\xFB")
                clockmsg = "\x9B"
                now = time.localtime()
                secs = now[5]
                mins = now[4]
                hrs = now[3]>>1
                if (hrs<<1) != now[3]:
                    mins += 60
                yday = now[7]&0xFF
                wday = now[6]+1
                if wday == 7:
                    wday = 0
                if yday != now[7]:
                    wday += 128
                clockmsg += chr(secs)
                clockmsg += chr(mins)
                clockmsg += chr(hrs)
                clockmsg += chr(yday)
                clockmsg += chr(wday)
                clockmsg += "\x00"
                serial.Write(clockmsg)
                serial.Read(1, 5)

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)
You can see the testing for the data that is incoming here

Code: Select all

 elif b == "\xA5":
 

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)
which you can see is being written to the serial port here

Code: Select all

serial.Write("\xFB")
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...)
3 Reserved
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)
and this is being done as well

Code: Select all

                clockmsg = "\x9B"
                now = time.localtime()
                secs = now[5]
                mins = now[4]
                hrs = now[3] >> 1
                if (hrs << 1) != now[3]:
                    mins += 60
                yday = now[7] & 0xFF
                wday = now[6] + 1
                if wday == 7:
                    wday = 0
                if yday != now[7]:
                    wday += 128
                clockmsg += chr(secs)
                clockmsg += chr(mins)
                clockmsg += chr(hrs)
                clockmsg += chr(yday)
                clockmsg += chr(wday)
                clockmsg += "\x00"
                serial.Write(clockmsg)
 
I think there may be an error in the logic of that last bit. It looks goofy.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 4756
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: CM11A plugin issues with XTB-232

Post by kgschlosser » Tue Apr 02, 2019 8:12 am

here you can give this a shot and see if it solves the problem.

he states here that this is something that is in fact not used and is only done for compatibility reasons.
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.
and in the actual API specs it states
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)
specifically the part about only sending the header and then waiting a small delay. and this should make everything work fine. and since the module you are using only does this for compatibility reasons and does not actually use the data that is being sent to it I see no issue with just sending the header all the time and not updating the clock.


so that is what I have done in the code.
Attachments
__init__.py
(14.37 KiB) Downloaded 8 times
If you like the work I have been doing then feel free to Image

Post Reply