Hybrid Setup?

Started by Brandt, October 25, 2010, 06:04:19 PM

Previous topic - Next topic

Brian H

Interesting log entries.
Not sure exactly what they indicate.

Brandt

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:

QuoteMe 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

Brian H

Test with an early 2876DB Icon Dimmer Switch.
C4 was assigned address.
Smarthome 1132CU with Smarthome Manager Essentials sending and receiving the commands.

You may notice a Status Request returns two messages.
If not On or Off the second message is a %Dim value.

I have no idea if this has any bearing on what you are seeing.

T: C4 - 6:58:46 PM 11/3/2010
T: COn - 6:58:48 PM 11/3/2010
T: C4 - 6:58:53 PM 11/3/2010
T: CStatus Request - 6:58:55 PM 11/3/2010
R: C4 - 6:58:56 PM 11/3/2010
R: CStatus=On - 6:58:56 PM 11/3/2010
R: C4 - 6:58:57 PM 11/3/2010
R: COn - 6:58:57 PM 11/3/2010
T: C4 - 6:59:05 PM 11/3/2010
T: COff - 6:59:07 PM 11/3/2010
T: C4 - 6:59:11 PM 11/3/2010
T: CStatus Request - 6:59:14 PM 11/3/2010
R: C4 - 6:59:15 PM 11/3/2010
R: CStatus=Off - 6:59:15 PM 11/3/2010
R: C4 - 6:59:16 PM 11/3/2010
R: COff - 6:59:16 PM 11/3/2010
T: C4 - 6:59:27 PM 11/3/2010
T:  23% Preset Dim 6:59:30 PM 11/3/2010
T: C4 - 6:59:34 PM 11/3/2010
T: CStatus Request - 6:59:36 PM 11/3/2010
R: C4 - 6:59:37 PM 11/3/2010
R: CStatus=On - 6:59:38 PM 11/3/2010
R: C4 - 6:59:38 PM 11/3/2010
R: 23% Preset Dim 6:59:39 PM 11/3/2010

Brandt

I am trying to figure out i why I get this error only when requesting status from the switch when it is off.

Brian H

#19
I don't have any ideas why the off is messed up.
I do know that revisions >5.0 have changes in them as there are manuals for above and below 5.0.

This is what I got when I turned it on; off; brightened and dimmed. Using the local paddles.

R: C4 - 7:18:38 PM 11/3/2010
R: COff - 7:18:39 PM 11/3/2010
R: C4 - 7:18:41 PM 11/3/2010
R: COn - 7:18:41 PM 11/3/2010
R: C4 - 7:18:46 PM 11/3/2010
R: 23% Preset Dim 7:18:47 PM 11/3/2010
R: C4 - 7:18:50 PM 11/3/2010
R: 35% Preset Dim 7:18:50 PM 11/3/2010

SMF spam blocked by CleanTalk