Programs Run Randomly

[Xathros]

... and how do duplicated control and status messages bouncing between all the dual band devices affect this as well? I know I am seeing duplicate messages with ever increasing frequency as I add more dual band devices, 3 of my 8 motion sensors now report twice each time they sense motion. I know they are only sending once but due to multiple routes back to the PLM likely on opposite phases, the message is received twice.

 

-Xathros

[oberkc]

OK...I did a little testing. I created a program. To ensure I am not missing the point, my understanding is that I am trying to better understand the reaction of a program when a "status" and "control" for the same device are in the same program, and what happens under various combinations of off->on, and on->on.

 

The program:

 

If
       Status  'Kitchen / SW KTS Kitchen Sink' is On
   And Control 'Kitchen / SW KTS Kitchen Sink' is switched On

Then
       Set 'X-10 Controls / Battery Chargers (A1)' On

Else
       Set 'X-10 Controls / Battery Chargers (A1)' Off

 

When the 'Kitchen / SW KTS Kitchen Sink' is switched from off->on, the status was false. When the 'Kitchen / SW KTS Kitchen Sink' is switched from on-> on, the status went true.

 

For those interested, the event log is below:

 

• 02 50 12.C9.76 00.00.01 CB 11 00 LTONRR (00)
   
  Mon 03/04/2013 10:02:07 PM : [std-Group ] 12.C9.76-->Group=1, Max Hops=3, Hops Left=2
   
  Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] DON 0
   
  Mon 03/04/2013 10:02:07 PM : [iNST-SRX ] 02 50 12.C9.76 0D.FE.30 41 11 01 LTONRR (01)
   
  Mon 03/04/2013 10:02:07 PM : [std-Cleanup ] 12.C9.76-->ISY/PLM Group=1, Max Hops=1, Hops Left=0
   
  Mon 03/04/2013 10:02:07 PM : [iNST-DUP ] Previous message ignored.
   
  Mon 03/04/2013 10:02:07 PM : [X10-RSP ] 02 63 66 00 06
   
  Mon 03/04/2013 10:02:07 PM : [ E EF 55 1] ST 255
   
  Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] ST 255
   
  Mon 03/04/2013 10:02:08 PM : [ 17 89 51 1] ST 255
   
  Mon 03/04/2013 10:02:08 PM : [ X10] A1
   
  Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11)
   
  Mon 03/04/2013 10:02:08 PM : [ FF 01 01 1] DOF 0
   
  Mon 03/04/2013 10:02:08 PM : [ FF 01 01 2] DOF 0
   
  Mon 03/04/2013 10:02:08 PM : [ X10] A1
   
  Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11)
   
  Mon 03/04/2013 10:02:08 PM : [ FF 01 01 1] DOF 0
   
  Mon 03/04/2013 10:02:08 PM : [ FF 01 01 2] DOF 0
   
  Mon 03/04/2013 10:02:08 PM : [X10-RSP ] 02 63 63 80 06
   
  Mon 03/04/2013 10:02:09 PM : [X10-RSP ] 02 63 66 00 06
   
  Mon 03/04/2013 10:02:10 PM : [X10-RSP ] 02 63 63 80 06
   
  Mon 03/04/2013 10:03:09 PM : [iNST-SRX ] 02 50 12.C9.76 00.00.01 CB 11 00 LTONRR (00)
   
  Mon 03/04/2013 10:03:09 PM : [std-Group ] 12.C9.76-->Group=1, Max Hops=3, Hops Left=2
   
  Mon 03/04/2013 10:03:09 PM : [ 12 C9 76 1] DON 0
   
  Mon 03/04/2013 10:03:09 PM : [iNST-SRX ] 02 50 12.C9.76 0D.FE.30 41 11 01 LTONRR (01)
   
  Mon 03/04/2013 10:03:09 PM : [std-Cleanup ] 12.C9.76-->ISY/PLM Group=1, Max Hops=1, Hops Left=0
   
  Mon 03/04/2013 10:03:09 PM : [iNST-DUP ] Previous message ignored.
   
  Mon 03/04/2013 10:03:09 PM : [X10-RSP ] 02 63 66 00 06
   
  Mon 03/04/2013 10:03:09 PM : [ X10] A1
   
  Mon 03/04/2013 10:03:09 PM : [ X10] A1/On (3)
   
  Mon 03/04/2013 10:03:09 PM : [ FF 01 01 1] ST 255
   
  Mon 03/04/2013 10:03:09 PM : [ FF 01 01 1] DON 255
   
  Mon 03/04/2013 10:03:09 PM : [ FF 01 01 2] ST 255
   
  Mon 03/04/2013 10:03:09 PM : [ FF 01 01 2] DON 255
   
  Mon 03/04/2013 10:03:10 PM : [X10-RSP ] 02 63 62 80 06
  

 

I was unable to observe the program in action, due to the location of switch not being in proximity to the event viewer.

 

I had performed another experiment, with another switch (keypad button) as trigger where I could observe the program in action.

 

If
       Status  'Office / KP OFC Desk Lamp' is Off
   And Control 'Office / KP OFC Desk Lamp' is switched On

Then
       Set 'X-10 Controls / Battery Chargers (A1)' On

Else
       Set 'X-10 Controls / Battery Chargers (A1)' Off

 

Interestingly, I found that this one, when a toggling a button from OFF->ON, first evaluated as TRUE, then quickly back to false. I can only assume that the control triggered an evaluation prior to a status change (TRUE), and the status change quickly triggered a second evaluation (FALSE).

 

the log from this example:

 

• 02 50 0A.D7.5F 00.00.01 CB 11 00 LTONRR (00)
   
  Mon 03/04/2013 09:43:20 PM : [std-Group ] 0A.D7.5F-->Group=1, Max Hops=3, Hops Left=2
   
  Mon 03/04/2013 09:43:20 PM : [ A D7 5F 1] DON 0
   
  Mon 03/04/2013 09:43:20 PM : [iNST-SRX ] 02 50 0A.D7.5F 0D.FE.30 41 11 01 LTONRR (01)
   
  Mon 03/04/2013 09:43:20 PM : [std-Cleanup ] 0A.D7.5F-->ISY/PLM Group=1, Max Hops=1, Hops Left=0
   
  Mon 03/04/2013 09:43:20 PM : [iNST-DUP ] Previous message ignored.
   
  Mon 03/04/2013 09:43:21 PM : [ A D7 5F 1] ST 255
   
  Mon 03/04/2013 09:43:21 PM : [X10-RSP ] 02 63 66 00 06
   
  Mon 03/04/2013 09:43:21 PM : [ X10] A1
   
  Mon 03/04/2013 09:43:21 PM : [ X10] A1/On (3)
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] ST 255
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] DON 255
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] ST 255
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] DON 255
   
  Mon 03/04/2013 09:43:21 PM : [ X10] A1
   
  Mon 03/04/2013 09:43:21 PM : [ X10] A1/Off (11)
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] ST 0
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 1] DOF 0
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] ST 0
   
  Mon 03/04/2013 09:43:21 PM : [ FF 01 01 2] DOF 0
   
  Mon 03/04/2013 09:43:22 PM : [X10-RSP ] 02 63 62 80 06
   
  Mon 03/04/2013 09:43:23 PM : [X10-RSP ] 02 63 66 00 06
   
  Mon 03/04/2013 09:43:24 PM : [X10-RSP ] 02 63 63 80 06

 

What remains a mystery (at least until I return home from a ski trip or someone else cares to explain) is why this second example appeared to trigger two evaluations and the first program never did this.

 

It is getting late, and I leave early tomorrow.

 

I hope this helps.

[LeeG]

"What remains a mystery is why this second example appeared to trigger two evaluations and the first program never did this."

 

The first Program was triggered twice during the off->on test. When the On command is received the Program is initially triggered due to the If Control On. The If evaluation is False because at first trigger time the current Status is Off and the Program is checking If Status On. That accounts for the first X10 A1 Off in the trace.

 

When the current Status changes from Off to On the Program is triggered again. The If evaluates to False because at second trigger time the If Control On part of the If is False. At the Status change trigger the On command is not being processed. The second trigger resulting from the Off->On test is False so a second X10 A1 Off is issued and traced.

 

Mon 03/04/2013 10:02:07 PM : [iNST-SRX ] 02 50 12.C9.76 00.00.01 CB 11 00 LTONRR (00) ON COMMAND RECEIVED

 

Mon 03/04/2013 10:02:07 PM : [std-Group ] 12.C9.76-->Group=1, Max Hops=3, Hops Left=2

 

Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] DON 0

 

Mon 03/04/2013 10:02:07 PM : [iNST-SRX ] 02 50 12.C9.76 0D.FE.30 41 11 01 LTONRR (01)

 

Mon 03/04/2013 10:02:07 PM : [std-Cleanup ] 12.C9.76-->ISY/PLM Group=1, Max Hops=1, Hops Left=0

 

Mon 03/04/2013 10:02:07 PM : [iNST-DUP ] Previous message ignored.

 

Mon 03/04/2013 10:02:07 PM : [X10-RSP ] 02 63 66 00 06

 

Mon 03/04/2013 10:02:07 PM : [ E EF 55 1] ST 255

 

Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] ST 255

 

Mon 03/04/2013 10:02:08 PM : [ 17 89 51 1] ST 255

 

Mon 03/04/2013 10:02:08 PM : [ X10] A1 - FIRST TRIGGER FROM IF CONTROL ON is FALSE

 

Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11)

 

Mon 03/04/2013 10:02:08 PM : [ FF 01 01 1] DOF 0

 

Mon 03/04/2013 10:02:08 PM : [ FF 01 01 2] DOF 0

 

Mon 03/04/2013 10:02:08 PM : [ X10] A1 – SECOND TRIGGER FROM CHANGE IN STATUS is FALSE

 

Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11)

 

EDIT: the On->On part of the first test triggered once because there was no change in Status (On to On) to cause a second trigger.

[oberkc]

EDIT: the On->On part of the first test triggered once because there was no change in Status (On to On) to cause a second trigger.

 

Except that I tried two cases...off>on and on>on. In neither case did it trigger twice, even though there WAS a change in status.

[LeeG]

The trace shows the off->on triggered twice as there are two X10 A1 Off messages sent for the single On message.

 

The On->On triggered once because there was no change in Status during this test.

[oberkc]

That is consistent with my current working theory: condions with status and control of the same device will always trigger twice when there is a change of status. First because of the control. Second because of the status change. They will always return FALSE the second time, regardless of final state and input condition.

I don't think I will be using this construct any time soon. Until I better understand it.

[Xathros]

I use this all the time. If switch is On and I turn it On again, then run a program that turns on other lights in the vicinity. Same with Off if already Off.

 

-Xathros

[oberkc]

Xathros,

 

You are not the only one who has posted that they use this construct. Based on my limited testing and subsequent theory, this looks to work for when the status and control conditions are the same and no change of state is initiated. Off-to-off. On-to-on.

 

I am concerned that this onstruct starts to fall apart umder certain cases where status changes, such as

 

If status xxx is off

And control xxx is switched on

 

When the switch xxx is switched from off to on, I believe this will return a quick TRUE and a subsequent false.

 

I am also suspicious that this might act funny when a dimmer is used and conditions other than full on/off are introduced.

[jwagner010]

Installed a new PLM this morning and so far so good. Comms issues seemed to have improved and not one miss fire of the program today so far. Appears my 5 year old PLM needed to be retired.

[Xathros]

Xathros,

 

You are not the only one who has posted that they use this construct. Based on my limited testing and subsequent theory, this looks to work for when the status and control conditions are the same and no change of state is initiated. Off-to-off. On-to-on.

 

I am concerned that this onstruct starts to fall apart umder certain cases where status changes, such as

 

If status xxx is off

And control xxx is switched on

 

When the switch xxx is switched from off to on, I believe this will return a quick TRUE and a subsequent false.

 

I am also suspicious that this might act funny when a dimmer is used and conditions other than full on/off are introduced.

 

oberkc-

 

I agree with your assessment of the above and that is the behavior I would expect.

 

I only use this for the situation where the device is switched on when it is already on or off when already off so the quick true before false is not a problem in either of those cases.

 

-Xathros

[oberkc]

I agree with your assessment of the above and that is the behavior I would expect.

Good. I was starting to wonder if I was missing something.

 

I only use this for the situation where the device is switched on when it is already on or off when already off so the quick true before false is not a problem in either of those cases.

 

Also good. I was concerned that the OP appeared to have had a much broader set of conditions, including some where the device was changing state. Fortunately, it appears that jwagner010 has gotten things working again. It is certainly difficult to diagnose problems when there are intermittent device failures thrown into the mix.