Basically they indicate that there are some communication errors with the switch when the switch is off.
It's as if it responds to a status request too quickly for the CM11a to process.
The above post was output on the command line. Here is a log entry:
10/30 18:42:27 sndc addr unit 4 : hu C4 (kitchen_dining_light)
10/30 18:42:28 sndc func StatusReq : hc C
10/30 18:42:28 Poll received unknown value (1 bytes), leading byte = 2
10/30 18:42:28 Poll received unknown value (1 bytes), leading byte = 0
10/30 18:42:28 Poll received unknown value (1 bytes), leading byte = 2a
10/30 18:42:29 rcvi func StatusOff : hc C
Please note that the three bytes, 0x02 0x00 0x2a, together with an initial 0x5a poll request that can be/supposed to get eaten with the failed status request send operation, these four bytes form a complete, correct transmission from the interface, with the 0x2a byte evidently representing an X10 'address C4' signal, received from the queried module obviously, then followed by the correctly decoded StatusOff.
Here is what the current Heyu maintainer is asking:
Me having much less experience with X10 hardware than C programming, please let me know what do you, experienced X10/CM11A users, think about it. Should we assume a module is broken if it responds to a status request so prompltly that we have problems with correct handling of this response? Or should we tend to not interprete the CM11A returned 0x5a (poll request) replacing awaited 0x55 (ready) as a send failure indication, thus being more prone to real transmission failures caused by unsolicited incoming signals?
Thanks,
Janusz
