X10 Flip-Flop Problem.

[Nathan]

I recently added a couple of action items to a rule. They looked like this.

Turn ON Device One
Turn OFF Device Two

Both devices were on the same housecode, one on F10 and one on F16. The order of action is important, the first must be turned on before the second is turned off.

When running the rule, I would see the first device turn off, and immediately turn on again (it was already on), followed by the second device turning ON. Not always, but often enough to be frustrating. Couldn't figure out what was wrong until I monitored the events using another PC and an X10 logging program.

What I saw in my log was the following:

F10 <== First half of the F10 Fon sequence
F16 <== Then the F16 Foff Sequence
FOFF
FON <== Then second half of the F10 Fon sequence turns on BOTH devices by mistake.

Since X10 commands are split across two messages, any message is subject to becoming split by another. I don't know that this is HAL's problem exactly, but HAL is getting a bit too enthusiastic about sending commands and interrupting his own command with a following command. I don't know exactly how this works at the low level, but it may be beyond HAL's control.

Changing my actions resolved the problem. My rule actions now read..

Turn ON Device One
in 2 seconds Turn OFF Device Two

The tiny extra delay makes sure the first command completes before the second is queued.

Just thought I'd post the experience in case someone else is running into this kind of flakey behavior.

Cheers,
Nathan

[kstamper]

Nathan,
Knowing that you have an Ocelot, but not knowing the purpose of your logic and weather or not it needs to be in HAL, but couldn't you do this in the Ocelot since it kepps track of what is on and what is off?

IF Device_One IS Off
THEN Device_One, Turn On

IF Device_Two IS On
AND Device_One IS On
THEN Device_Two, Turn Off

I know that you are the one of the few people here that doesn't need any logic schooling, but thought I would mention it in case someone else might be seeing the same thing. Since I got my Ocelot, I find my self doing all of my normal logic there, and using HAL for the things that only HAL can do. So far I am up to about 700 lines of code in the Ocelot and still going.

Kelly

[Nathan]

Certainly. This is not a problem with CMAX code. But this particular logic must be in HAL.

The point was not so much as to find alternative ways to do it but rather to warn others that HAL can do this (I really consider it an X10 bug, not a HAL bug, but think HAL should do a little defensive programming to protect us from X10's flaws) and thus give them a chance to avoid problems.

I have tested this quite a bit, and HAL will often interleave X10 commands. If they are for different housecodes, no harm is done. If they are the same command for two different devices on the same housecode, no harm is done. But is they are opposite commands for different devices on the same housecode, BAM! You have strange behavior. A little enforced delay prevents problems.

Cheers,
Nathan

[VincentB]

funny you mention this problem..i too saw this occur and i resolved it the same way :wink:
Although it is an X10 flaw, it wouldn't be hard for HAL to add a bit of logic that checks any other X10 actions in the same macro/rule and applies its own delay to compensate, as opposed to use having to do it.