When does Status get set relative to the associated Control event?

[rleidy]

Forgive me if this has been asked before - I could not find the answer with a search.

 

I've seen some posts suggesting that you can define a program condition such that you can detect an OFF when the device is already OFF or detect ON when it's already ON.  Essentially, detect a slow double tap.  The code snippets I've seen look like:

if control x is switched off
and status x is off

then ...

Suppose the light is ON and I switch it OFF.  The control condition will be true.  But, the only way the entire condition can evaluate to false on the first OFF tap is that the device status must not be set to OFF yet.  It must still be in its ON state.

 

Does the ISY process status changes after it has run all programs triggered by control events?

 

If so, what prevents this program from being run a second time once the status has been updated to OFF? 

 

Obviously, the technique works for detecting the double-OFF.  I would like to get an understanding of why it works.

[stusviews]

Control requires that the device itself send the signal. If the device is off and the device is turned off, the control condition will be true. Neither a direct command nor a scene will cause the control condition to be true.

 

Status requires that the state of the device be changed. If the device is off and a scene or direct command issues an off, status will not be true.

 

The ISY processes commands immediately. I haven't seen conditions exactly as you wrote them. Also, there is no such action as a "slow double tap."

[rleidy]

Let me take another stab at my question.  I am describing a scenario where the OFF button press triggers a program.  The purpose of the program is to check to see if the OFF was pressed while the device was already OFF and then perform some action.  (something similar was discussed here recently:  http://forum.universal-devices.com/topic/16937-bathroom-fan-with-timer/?do=findComment&comment=150121).  So, suppose the switch is currently ON and I press OFF.  The OFF press triggers the program.  If it was the case that the device status had already been updated to OFF by the time the program executes, then the program condition would always be true and it would never be detect "switch is OFF and OFF is pressed".  Since that condition *can* be detected, it seems to me that the update of the device status must lag the processing of the control event.  So, when the switch is ON and I press OFF, the program must see the previous state (status of ON) after the first OFF press. 

 

If that is accurate, then what happens when the lagging status is finally updated from ON to OFF.  Does that trigger the program a second time?  If not, why not?

[LeeG]

SwitchLincControlStatus - [iD 0088][Parent 0001]

 

If

        Control '33.95.41.1' is switched Off

    And Status  '33.95.41.1' is Off

 

Then

        Set 'SwitchLinc Relay' On

 

Else

        Set 'SwitchLinc Relay' Off

 

First press of Off paddle.  If is false so Else runs.  (If Control is True but Status is On so IF Status False)

 

"If that is accurate, then what happens when the lagging status is finally updated from ON to OFF.  Does that trigger the program a second time?  If not, why not?"

 

The eventual change of Status to Off does trigger Program again.  If is still False so Else runs again..

 

Wed 11/18/2015 09:33:14 AM : [iNST-SRX    ] 02 50 33.95.41 00.00.01 CB 13 00    LTOFFRR(00)

Wed 11/18/2015 09:33:14 AM : [std-Group   ] 33.95.41-->Group=1, Max Hops=3, Hops Left=2

Wed 11/18/2015 09:33:14 AM : [D2D EVENT   ] Event [33 95 41 1] [DOF] [0] uom=0 prec=-1

Wed 11/18/2015 09:33:14 AM : [  33 95 41 1]      DOF   0

Wed 11/18/2015 09:33:14 AM : [D2D-CMP 009A] CTL [33 95 41 1] DOF op=6 Event(val=0 uom=0 prec=-1) != Condition(val=0 uom=0 prec=-1) --> false

Wed 11/18/2015 09:33:14 AM : [D2D-CMP 0094] CTL [33 95 41 1] DOF op=6 Event(val=0 uom=0 prec=-1) != Condition(val=0 uom=0 prec=-1) --> false

Wed 11/18/2015 09:33:14 AM : [D2D-CMP 0088] CTL [33 95 41 1] DOF op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true

Wed 11/18/2015 09:33:14 AM : [iNST-SRX    ] 02 50 33.95.41 22.80.0B 40 13 01    LTOFFRR(01)

Wed 11/18/2015 09:33:14 AM : [std-Cleanup ] 33.95.41-->ISY/PLM Group=1, Max Hops=0, Hops Left=0

Wed 11/18/2015 09:33:14 AM : [iNST-DUP    ] Previous message ignored.

Wed 11/18/2015 09:33:14 AM : [iNST-SRX    ] 02 50 33.95.41 13.01.01 CB 06 00           (00)

Wed 11/18/2015 09:33:14 AM : [std-Group   ] 33.95.41-->13.01.01, Max Hops=3, Hops Left=2

Wed 11/18/2015 09:33:14 AM : [iNST-INFO   ] Previous message ignored.

Wed 11/18/2015 09:33:15 AM : [iNST-TX-I1  ] 02 62 16 90 AB 0F 13 00

Wed 11/18/2015 09:33:15 AM : [D2D EVENT   ] Event [33 95 41 1] [sT] [0] uom=0 prec=-1

Wed 11/18/2015 09:33:15 AM : [  33 95 41 1]       ST   0

Wed 11/18/2015 09:33:15 AM : [iNST-ACK    ] 02 62 16.90.AB 0F 13 00 06          LTOFFRR(00)

Wed 11/18/2015 09:33:15 AM : [D2D-CMP 0088] STS [33 95 41 1] ST op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true

Wed 11/18/2015 09:33:15 AM : [iNST-SRX    ] 02 50 16.90.AB 22.80.0B 2B 13 00    LTOFFRR(00)

Wed 11/18/2015 09:33:15 AM : [std-Direct Ack] 16.90.AB-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 11/18/2015 09:33:15 AM : [iNST-TX-I1  ] 02 62 16 90 AB 0F 13 00

Wed 11/18/2015 09:33:15 AM : [iNST-ACK    ] 02 62 16.90.AB 0F 13 00 06          LTOFFRR(00)

Wed 11/18/2015 09:33:16 AM : [iNST-SRX    ] 02 50 16.90.AB 22.80.0B 2B 13 00    LTOFFRR(00)

Wed 11/18/2015 09:33:16 AM : [std-Direct Ack] 16.90.AB-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

Second press of Off paddle.   If is True so Then runs.

 

Wed 11/18/2015 09:36:13 AM : [iNST-SRX    ] 02 50 33.95.41 00.00.01 CB 13 00    LTOFFRR(00)

Wed 11/18/2015 09:36:13 AM : [std-Group   ] 33.95.41-->Group=1, Max Hops=3, Hops Left=2

Wed 11/18/2015 09:36:14 AM : [D2D EVENT   ] Event [33 95 41 1] [DOF] [0] uom=0 prec=-1

Wed 11/18/2015 09:36:14 AM : [  33 95 41 1]      DOF   0

Wed 11/18/2015 09:36:14 AM : [D2D-CMP 009A] CTL [33 95 41 1] DOF op=6 Event(val=0 uom=0 prec=-1) != Condition(val=0 uom=0 prec=-1) --> false

Wed 11/18/2015 09:36:14 AM : [D2D-CMP 0094] CTL [33 95 41 1] DOF op=6 Event(val=0 uom=0 prec=-1) != Condition(val=0 uom=0 prec=-1) --> false

Wed 11/18/2015 09:36:14 AM : [D2D-CMP 0088] CTL [33 95 41 1] DOF op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true

Wed 11/18/2015 09:36:14 AM : [iNST-SRX    ] 02 50 33.95.41 13.01.01 CB 06 00           (00)

Wed 11/18/2015 09:36:14 AM : [std-Group   ] 33.95.41-->13.01.01, Max Hops=3, Hops Left=2

Wed 11/18/2015 09:36:14 AM : [iNST-INFO   ] Previous message ignored.

Wed 11/18/2015 09:36:14 AM : [iNST-TX-I1  ] 02 62 16 90 AB 0F 11 FF

Wed 11/18/2015 09:36:14 AM : [iNST-ACK    ] 02 62 16.90.AB 0F 11 FF 06          LTONRR (FF)

Wed 11/18/2015 09:36:15 AM : [iNST-SRX    ] 02 50 16.90.AB 22.80.0B 2B 11 FF    LTONRR (FF)

Wed 11/18/2015 09:36:15 AM : [std-Direct Ack] 16.90.AB-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 11/18/2015 09:36:15 AM : [D2D EVENT   ] Event [16 90 AB 1] [sT] [255] uom=0 prec=-1

Wed 11/18/2015 09:36:15 AM : [  16 90 AB 1]       ST 255

Wed 11/18/2015 09:36:15 AM : [D2D-CMP 0066] STS [16 90 AB 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true

Wed 11/18/2015 09:36:15 AM : [D2D-CMP 0065] STS [16 90 AB 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false

Wed 11/18/2015 09:36:15 AM : [D2D-CMP 002C] STS [16 90 AB 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true

[rleidy]

There's nothing like empirical data - thanks for the confirmation LeeG.  

[LeeG]

rleidy

 

Hope that was helpful.  .The Event Trace is usually good at showing actual activity.   Please post back if additional questions.

[larryllix]

Forgive me if this has been asked before - I could not find the answer with a search.

 

I've seen some posts suggesting that you can define a program condition such that you can detect an OFF when the device is already OFF or detect ON when it's already ON.  Essentially, detect a slow double tap.  The code snippets I've seen look like:

if control x is switched off
and status x is off

then ...

Suppose the light is ON and I switch it OFF.  The control condition will be true.  But, the only way the entire condition can evaluate to false on the first OFF tap is that the device status must not be set to OFF yet.  It must still be in its ON state.

 

Does the ISY process status changes after it has run all programs triggered by control events?

 

If so, what prevents this program from being run a second time once the status has been updated to OFF? 

 

Obviously, the technique works for detecting the double-OFF.  I would like to get an understanding of why it works.

 

 

You need the status change condition protected from  triggering the program whatsoever with a second program that is disabled.

 

if control x is switched off

then run (if) program2

else --

 

Program2  (disabled)

if status x is off              <-------cannot trigger program lines

then do anything to status X device

else do anything to status x device.

[apostolakisl]

You need the status change condition protected from  triggering the program whatsoever with a second program that is disabled.

 

if control x is switched off

then run (if) program2

else --

 

Program2  (disabled)

if status x is off              <-------cannot trigger program lines

then do anything to status X device

else do anything to status x device.

 

Only if you have an Else clause.  But I don't think you would ever have an Else clause for this program, at least not the way I use them.

 

I have lots of these programs.  I use them as in bedrooms and bathrooms with a then statement to turn the light on to 15%.  This is really nice when you get up at night to go to the bathroom it is an easy way to turn the light on just a little when you want to keep your brain as nearly asleep as possible.  

 

Anyway, I can tell you that these programs had issues after some previous firmware updates where they would execute a Then statement when you turned the light off from an on state (the light would first turn off, then a split second later come back up to 15%).  I posted that as a bug and it was corrected.  So,the "order of operations" is apparently just barely the way it is and modifications to the firmware can tip it the other way if missed.

[Xathros]

Anyway, I can tell you that these programs had issues after some previous firmware updates where they would execute a Then statement when you turned the light off from an on state (the light would first turn off, then a split second later come back up to 15%).  I posted that as a bug and it was corrected.  So,the "order of operations" is apparently just barely the way it is and modifications to the firmware can tip it the other way if missed.

 

I still see this on occasion but have chalked it up to multiple paths of communication resulting in duplicate messages received by the ISY/PLM.  An Off received over the power line that turns off my bedroom light then the same Off received moments later via RF after making a few hops and crossing the phase bridge triggering my "Off when Off" trap.

 

Only solution would be for the ISY to wait longer (continue to reject duplicates for a longer period) but then we might miss real commands in higher frequency applications (have to wait longer between paddle presses to use the double off or double on as opposed to fast off/on).

 

-Xathros

[paulbates]

Interesting. Don't wireless devices send 2 on's and 2 off's sequentially? I'm pretty sure my MS does.

 

I still see this on occasion but have chalked it up to multiple paths of communication resulting in duplicate messages received by the ISY/PLM.  An Off received over the power line that turns off my bedroom light then the same Off received moments later via RF after making a few hops and crossing the phase bridge triggering my "Off when Off" trap.

 

-Xathros

[Xathros]

Interesting. Don't wireless devices send 2 on's and 2 off's sequentially? I'm pretty sure my MS does.

I believe so but the timing may be such that the ISY is capable of detecting the dupes. As apostolakisl mentioned above, there have been some releases where the ISY would see and act on both receives.  My motion counters would double up in these instances.

 

What  I am referring to above is single broadcast messages from a device like a dual band switchlinc dimmer taking different paths and arriving at the PLM spaced far enough apart for them to appear as separate messages rather than duplicates to be ignored.

 

-Xathros

[LeeG]

The RF devices do send 2 Group Broadcast On messages.  The second message is ignored by ISY.

 

Wed 11/18/2015 03:32:53 PM : Setting Time From NTP

Wed 11/18/2015 03:32:58 PM : [iNST-SRX    ] 02 50 14.C1.C7 00.00.01 CB 11 01    LTONRR (01) - first Group Broadcast message

Wed 11/18/2015 03:32:58 PM : [std-Group   ] 14.C1.C7-->Group=1, Max Hops=3, Hops Left=2

Wed 11/18/2015 03:32:58 PM : [D2D EVENT   ] Event [14 C1 C7 1] [DON] [1] uom=0 prec=-1

Wed 11/18/2015 03:32:58 PM : [  14 C1 C7 1]      DON   1

Wed 11/18/2015 03:32:58 PM : [D2D-CMP 0075] CTL [14 C1 C7 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true

Wed 11/18/2015 03:32:58 PM : [D2D EVENT   ] Event [14 C1 C7 1] [sT] [255] uom=0 prec=-1

Wed 11/18/2015 03:32:58 PM : [  14 C1 C7 1]       ST 255

Wed 11/18/2015 03:32:58 PM : [iNST-SRX    ] 02 50 14.C1.C7 00.00.01 CB 11 01    LTONRR (01) - second Group Broadcast message - ignored

Wed 11/18/2015 03:32:58 PM : [std-Group   ] 14.C1.C7-->Group=1, Max Hops=3, Hops Left=2

Wed 11/18/2015 03:32:58 PM : [INST-DUP    ] Previous message ignored.

[larryllix]

Only if you have an Else clause.  But I don't think you would ever have an Else clause for this program, at least not the way I use them.

 

I have lots of these programs.  I use them as in bedrooms and bathrooms with a then statement to turn the light on to 15%.  This is really nice when you get up at night to go to the bathroom it is an easy way to turn the light on just a little when you want to keep your brain as nearly asleep as possible.  

 

Anyway, I can tell you that these programs had issues after some previous firmware updates where they would execute a Then statement when you turned the light off from an on state (the light would first turn off, then a split second later come back up to 15%).  I posted that as a bug and it was corrected.  So,the "order of operations" is apparently just barely the way it is and modifications to the firmware can tip it the other way if missed.

Yeah I typically use a variable or other mechanism to know the state is already in that state being sent ('slow double tap off') but I think I failed to pick up on the actual subject of the matter here...the sequence of ISY processing signals vs status changes.

 

If people are using this technique, testing status of a point, triggered by the control signal that changes the status and sometime down the road UDI changes the internal processing order all these programs may stop working.

 

This also brings me to wonder that devices send out status updates when their status changes.

 

Since a SwitchLinc is really two devices, do we not get a control signal from the switch, when tapped,,as a trigger,  and then a second status change signal from the light control device circuitry?

 

If so ISY does seem to ignore the status changes sent but can manually invoke one with a Query. Proof of that is operating a device that does not send confirmation ie. 2441ZTH. After a setpoint change or mode change ISY pauses(may be admin console update time) and then displays the requested setpoint number or mode.   After a query ISY changes setpoint and mode indicators back to the originally displayed settings, proving that current status was assumed at that point.  If ISY was displaying actual status the admin console displayed setting would have never changed,

 

LeeG may know more about this. Is it possible some of the [message ignored] lines from the devices updating the latest  status change and ISY doesn't use them?

[apostolakisl]

I still see this on occasion but have chalked it up to multiple paths of communication resulting in duplicate messages received by the ISY/PLM.  An Off received over the power line that turns off my bedroom light then the same Off received moments later via RF after making a few hops and crossing the phase bridge triggering my "Off when Off" trap.

 

Only solution would be for the ISY to wait longer (continue to reject duplicates for a longer period) but then we might miss real commands in higher frequency applications (have to wait longer between paddle presses to use the double off or double on as opposed to fast off/on).

 

-Xathros

 

I have also seen it on occasion.  I really don't know what causes the rare and seemingly random incorrect execution of this type of program.  I would speculate that it is related to the issues you mentioned.  Perhaps a second instance of the "control off" makes its way around the network and hits the ISY after it has updated the status to off.  It could also be that the ISY missed the last event on the device and has the device incorrectly labeled as off even though it is on.

[LeeG]

larryllix

 

See post #4.  The Program is triggered when the Off paddle is tapped (by If Control).  The Program is triggered again when Status changes (by If Status).

 

Certainly should ISY change how Programs are triggered it could break existing Programs.   I think the idea of ISY changing any existing functional characteristic of most anything would break something. 

[larryllix]

Thanks Lee!  When I read your post I had something else in mind and missed the point I was getting at.

 

So this could be dangerous

If

        Control '33.95.41.1' is switched Off

    And Status  '33.95.41.1' is Off

 

Then

        variable -=1

        more lines

Else

        variable += 1

        more lines

 

If processing gets past the first arithmetic line and a second trigger hits and restarts it we could see a double dec/increment.

 

Even though we think we are dealing with one device we need to treat it like two devices, a controller that can send control signals, and a responder that can send status signals, that can do the same things in ISY.

 

I don't think ISY is going to maintain two statuses. "Where I think it is" and "Where it says it is", statuses.

 

Interesting stuff dissecting UDI's early brain.

[LeeG]

Once a Program is triggered and a clause selected the clause will execute from beginning to end without interruption, unless there is a Wait or Repeat in the executing clause.   The example will double count in the Else clause when moving from On to Off Status when the Off paddle is tapped.  That is why use of the Else clause is not a good idea in this case except for some general Action that is not bothered by entering the Else clause multiple times.   

 

So this could be dangerous

If

        Control '33.95.41.1' is switched Off

    And Status  '33.95.41.1' is Off

 

Then

        variable -=1

        more lines

Else

        variable += 1

        more lines

[fitzpatri8]

This also brings me to wonder that devices send out status updates when their status changes.

 

No, device status is only transmitted to the scene controller in response to a status request message. Error correction is in response to a binary yes/no to the 'did you hear me' message from between controller and individual responders only.

 

Under normal usage, when you control a scene with a switch, as the scene responders are adjusting their load settings, the switch will then send clean-up messages, asking each responder if it heard the scene message. The responder provides only a short ACKnowledgement to the controller that the message was received and processed, no load information is exchanged. The process is quick and efficient to support large, house-wide scenes.

 

The ISY displays its understanding of a device status based on its copy of the controller and responder link tables. (It is linked to the switch, so it'll see the switch turn on; and it knows modules a and c are linked as responders to the switch. When the switch says 'on', the ISY logically computes that modules a and c are now in whatever state they were linked.).

 

That's why it is necessary to use the ISY's Asministrative Console for all scene building and link table maintenance. If you start linking or adjusting devices manually, the ISY has no way to discern their correct state until the 3 A.M. maintenance program runs and the ISY specifically queries each device for its current status.

[ScottAvery]

I'm very happy to find this thread.  I use fast on and fast off as triggers in a number of places, but this method seems more natural, particularly for bathroom lights at night.  This makes more sense than rewriting the scene on levels every night/morning.