Restrictions not working for a DO EVERY?

#1

1) Give a description of the problem
I have a restriction on a DO EVERY. Even though the restrictions are not true, it is still running the code in the DO EVERY.

2) What is the expected behaviour?
I would expect the DO EVERY not work if the restriction code is not valid

3) What is happening/not happening?
The code inside the DO EVERY is running

**4) Post a Green Snapshot of the piston!

image
image.png1178×1103 67.8 KB

Currently the house is AWAY and no one is home. Yet the code is running.

5) Attach logs after turning logging level to Full
2/18/2020, 11:44:18 AM +123ms
+0ms ╔Received event [Home].time = 1582044258812 with a delay of -689ms
+133ms ║RunTime Analysis CS > 29ms > PS > 44ms > PE > 60ms > CE
+136ms ║Runtime (44738 bytes) successfully initialized in 44ms (v0.3.110.20191009) (134ms)
+137ms ║╔Execution stage started
+146ms ║║Cancelling statement #104’s schedules…
+151ms ║║true
+152ms ║║Executed virtual command log (1ms)
+157ms ║║false
+158ms ║║Executed virtual command log (1ms)
+163ms ║║false
+164ms ║║Executed virtual command log (1ms)
+168ms ║║false
+169ms ║║Executed virtual command log (1ms)
+175ms ║║Comparison (boolean) false is (boolean) false = true (1ms)
+176ms ║║Condition #74 evaluated true (4ms)
+180ms ║║Comparison (boolean) false is (boolean) false = true (1ms)
+182ms ║║Condition #75 evaluated true (4ms)
+186ms ║║Comparison (boolean) false is (boolean) false = true (2ms)
+187ms ║║Condition #89 evaluated true (5ms)
+191ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+192ms ║║Condition #79 evaluated true (4ms)
+193ms ║║Condition group #73 evaluated true (state did not change) (22ms)
+195ms ║║Cancelling statement #103’s schedules…
+198ms ║║Executed virtual command setVariable (1ms)
+221ms ║║Executed virtual command sendPushNotification (19ms)
+224ms ║║Cancelling statement #90’s schedules…
+316ms ║║Executed physical command [House Speakers].playTextAndRestore([Please Switch Washing Machine]) (85ms)
+317ms ║║Executed [House Speakers].playTextAndRestore (87ms)
+324ms ║║Comparison (boolean) false is (boolean) false = true (2ms)
+325ms ║║Condition #80 evaluated true (5ms)
+329ms ║║Comparison (boolean) true is (boolean) false = false (1ms)
+330ms ║║Condition #93 evaluated false (4ms)
+331ms ║║Condition group #78 evaluated false (state did not change) (11ms)
+334ms ║╚Execution stage complete. (197ms)
+335ms ║Setting up scheduled job for Tue, Feb 18 2020 @ 11:59:18 AM EST (in 900.355s)
+343ms ╚Event processed successfully (343ms)

#2

If you pause and resume it while you are away, do you find it never executes your tasks even when you are at home? If so that’ll explain what is going on.

#3

How does it explain it? It seems like it doesn’t update the logic. If I edit the piston while I’m away, it does not run the code inside when I’m home. Why is this happening?

#4

The timer (‘every’) runs asychronously outside the normal flow of the piston. It would appear the restriction is applied when the timer is started.

#5

Personally, I would convert the ONLY WHEN into a nested IF… Something like:

Every 15 minutes, but only during X hours.....  <-- Trigger
Do
    IF Location mode is Home
       and
       Any of Sensor 1, 2, 3, 5's presence is present
    Then
        Log x4
        IF @global is false
        etc etc etc

With this method, the location mode and presence are not checked until after the trigger fires.

#6

What other limitations are there with restrictions I should know about? Should I really be converting all of them to nested IF?

#7

There may be a use for it occasionally, but it is very rare that I use “ONLY WHEN” because of it’s pre-emptive check… (Although I would only convert pistons that are not behaving)

It is usually noticed on scheduled (or timed) events. If you stick one on a sensor’s motion, then webCoRE has no idea when it will trigger, so the ONLY WHEN is not checked until after motion activates.

#8

OK. I’l convert.