Light Control – two questions (variable evaluates incorrectly; “switch physically”?


#1

1) Give a description of the problem
This piston is intended to turn on a light with motion, then turn it off, after a Wait, if it had become inactive. Also, if the switch was manually turned on prevent it from being turned off after the motion becomes inactive (i.e. the switch overrides the motion control).

2) What is the expected behaviour?
The top two IF statements supervise the motion. The last two set or clear a flag based on the physical interaction with the wall switch. This flag is to lock out the turning off when the motion becomes inactive.

3) What is happening/not happening?
The logic of the motion and the logic of setting and clearing the flag work correctly when tested independently. However, when together two things happen that I can’t explain:

-1- the flag when set TRUE is evaluated as FALSE. This causes the light to turn off with motion=inactive. There is no other SetVariable instruction in the trace data to have changed it.

-2- the turning off the light triggers an IF clause that is constructed with: “switch physically changes to off”. This should only react to a physical change to the light switch and not a programmatic change - correct?

I have annotated the trace data for the areas noted above.

Thanks in advance.

4) Post a Green Snapshot of the pistonimage

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)
8/29/2019, 10:45:06 AM +180ms
+0ms ╔Received event [Home].time = 1567089907859 with a delay of -1680ms
+332ms ║RunTime Analysis CS > 118ms > PS > 195ms > PE > 20ms > CE
+335ms ║Runtime (41236 bytes) successfully initialized in 195ms (v0.3.10e.20190628) (334ms)
+336ms ║╔Execution stage started
+337ms ║╚Execution stage complete. (1ms)
+338ms ╚Event processed successfully (338ms)
8/29/2019, 10:44:56 AM +362ms
+2ms ╔Received event [Hall Light].switch = off with a delay of 102ms
+106ms ║RunTime Analysis CS > 33ms > PS > 53ms > PE > 20ms > CE
+109ms ║Runtime (41231 bytes) successfully initialized in 53ms (v0.3.10e.20190628) (106ms)
+110ms ║╔Execution stage started
+123ms ║║Condition #2 evaluated false (7ms)
+124ms ║║Condition group #1 evaluated false (state did not change) (10ms)
+133ms ║║Cancelling condition #9’s schedules…
+134ms ║║Condition #9 evaluated false (6ms)
+135ms ║║Cancelling condition #8’s schedules…
+136ms ║║Condition group #8 evaluated false (state changed) (9ms)
+143ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+145ms ║║Condition #14 evaluated false (5ms)
+146ms ║║Condition group #13 evaluated false (state did not change) (6ms)
+153ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+155ms ║║Cancelling condition #16’s schedules…
+156ms ║║Condition #16 evaluated true (7ms) Why did this evaluate true when the switch was NOT physically changed to off?
+157ms ║║Cancelling condition #15’s schedules…
+158ms ║║Condition group #15 evaluated true (state changed) (9ms)
+160ms ║║Cancelling statement #17’s schedules…
+164ms ║║Executed virtual command setVariable (1ms) Set Flag = False
+166ms ║╚Execution stage complete. (56ms)
+167ms ╚Event processed successfully (167ms)
8/29/2019, 10:44:52 AM +407ms
+1ms ╔Received event [Kitchen Motion Sensor].motion = inactive with a delay of 92ms
+78ms ║RunTime Analysis CS > 18ms > PS > 43ms > PE > 17ms > CE
+80ms ║Runtime (41238 bytes) successfully initialized in 43ms (v0.3.10e.20190628) (78ms)
+81ms ║╔Execution stage started
+87ms ║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+89ms ║║Cancelling condition #2’s schedules…
+89ms ║║Condition #2 evaluated false (4ms)
+90ms ║║Cancelling condition #1’s schedules…
+91ms ║║Condition group #1 evaluated false (state changed) (7ms)
+96ms ║║Comparison (enum) inactive changes_to (string) inactive = true (1ms)
+97ms ║║Cancelling condition #9’s schedules…
+98ms ║║Condition #9 evaluated true (5ms) This should evaluate True as the motion is inactive
+103ms ║║Comparison (boolean) false is (boolean) false = true (1ms)
+104ms ║║Condition #45 evaluated true (5ms) This, however,should NOT evaluate as true (which is finding the flag set false)as the flag was set true and no other SetVariable commands have occurred?
+105ms ║║Cancelling condition #8’s schedules…
+106ms ║║Condition group #8 evaluated true (state changed) (13ms) Why does this group evaluate as true since the flag was set true.
+108ms ║║Cancelling statement #11’s schedules…
+124ms ║║Executed physical command [Hall Light].off() (10ms)
+124ms ║║Executed [Hall Light].off (12ms)
+133ms ║║Cancelling condition #14’s schedules…
+134ms ║║Condition #14 evaluated false (7ms)
+135ms ║║Cancelling condition #13’s schedules…
+135ms ║║Condition group #13 evaluated false (state changed) (8ms)
+144ms ║║Condition #16 evaluated false (6ms)
+145ms ║║Condition group #15 evaluated false (state did not change) (8ms)
+147ms ║╚Execution stage complete. (67ms)
+148ms ╚Event processed successfully (148ms)
8/29/2019, 10:44:37 AM +711ms
+2ms ╔Received event [Kitchen Motion Sensor].motion = active with a delay of 97ms
+94ms ║RunTime Analysis CS > 23ms > PS > 50ms > PE > 21ms > CE
+97ms ║Runtime (41243 bytes) successfully initialized in 50ms (v0.3.10e.20190628) (94ms)
+99ms ║╔Execution stage started
+107ms ║║Comparison (enum) active changes_to (string) active = true (0ms)
+108ms ║║Cancelling condition #2’s schedules…
+109ms ║║Condition #2 evaluated true (6ms)
+121ms ║║Comparison (time) 38677822 is_between (time) 21600000 … (time) 79200000 = true (8ms)
+122ms ║║Time restriction check passed
+124ms ║║Condition #3 evaluated true (14ms)
+126ms ║║Cancelling condition #1’s schedules…
+127ms ║║Condition group #1 evaluated true (state changed) (24ms)
+130ms ║║Cancelling statement #5’s schedules…
+141ms ║║Skipped execution of physical command [Hall Light].on([]) because it would make no change to the device. (4ms)
+142ms ║║Executed [Hall Light].on (7ms)
+146ms ║║Executed virtual command [Hall Light].wait (0ms)
+147ms ║║Requesting a wake up for Thu, Aug 29 2019 @ 10:45:07 AM EDT (in 30.0s)
+151ms ║╚Execution stage complete. (53ms)
+153ms ║Setting up scheduled job for Thu, Aug 29 2019 @ 10:45:07 AM EDT (in 29.996s)
+162ms ╚Event processed successfully (162ms)
8/29/2019, 10:44:34 AM +666ms
+2ms ╔Received event [Hall Light].switch = on with a delay of 96ms
+104ms ║RunTime Analysis CS > 30ms > PS > 52ms > PE > 22ms > CE
+107ms ║Runtime (41232 bytes) successfully initialized in 52ms (v0.3.10e.20190628) (104ms)
+109ms ║╔Execution stage started
+122ms ║║Condition #2 evaluated false (7ms)
+124ms ║║Condition group #1 evaluated false (state did not change) (10ms)
+135ms ║║Condition #9 evaluated false (7ms)
+137ms ║║Condition group #8 evaluated false (state did not change) (10ms)
+148ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+151ms ║║Cancelling condition #14’s schedules…
+153ms ║║Condition #14 evaluated true (11ms)
+155ms ║║Cancelling condition #13’s schedules…
+157ms ║║Condition group #13 evaluated true (state changed) (15ms)
+161ms ║║Cancelling statement #19’s schedules…
+167ms ║║Executed virtual command setVariable (2ms) Set Flag = True
+181ms ║║Comparison (enum) on changes_to (string) off = false (1ms)
+183ms ║║Condition #16 evaluated false (10ms)
+186ms ║║Condition group #15 evaluated false (state did not change) (13ms)
+189ms ║╚Execution stage complete. (81ms)
+192ms ╚Event processed successfully (191ms)
Clear
Full

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.


#2

This question has come up many times. I believe the physical vs programmatic interaction is not always reported correctly to ST. You might want to look at this thread:


#3

Sorry to be ill-informed. What is “have a DHT that recognizes manual switch interactions”?

The Honeywell Z-Wave, SmartThings Compatible switch that I have does respond to the IF statements below, however, it also responds to a programmatic change to the switch.

I am happy to use what is in the example piston but I am not sure that I completely understand it (yet)

Thanks in advance


#4

Device Type Handler


#5

there should be a fix coming for physical vs. digital changes…


#6

Just to clarify a bit:
WebCoRE has had the capability of distinguishing the difference between Physical and Programatic changes to a switch for quite a while now… The catch is that webCoRE can only see the differences when the Device Handler reports a difference.

So any updates have to come from the Device Handler, not webCoRE. This also means an updated DH will only be helpful to devices that are using that DH, not your entire house.


While waiting for an update to your Device Handler, the link that @guxdude shared is a great method to use .

  • The first piston there works with a dumb switch / smart bulb combo
  • The second piston there works with a smart switch / dumb bulb combo

#7

Works as advertised. Thanks for the help…


#8

There is a webcore bug in this if the check for state includes the matches digital or physical. I agree the devices need to report correctly, and webcore has an issue also.

See pistons like for an example of the failure. I have shared information on the fix (and it exists now in the HE version of webcore)