Away lighting simulator not triggering automatically

[freddyq]

Below is the first entry in the log after the time and presence conditions were true. I’m not an expert in reading the logs but from what I can see it looks ok, the only issue is why it waited so long to execute because the conditions would have been true over an hour before this entry…

24/09/2017, 20:24:22 +812ms
+1ms ╔Received event [Home].execute = 82.132.223.192 with a delay of 301ms
+258ms ║RunTime Analysis CS > 17ms > PS > 50ms > PE > 191ms > CE
+548ms ║Runtime (45328 bytes) successfully initialized in 50ms (v0.2.0e9.20170921) (546ms)
+549ms ║╔Execution stage started
+571ms ║║Comparison (enum) not present is (string) not present = true (3ms)
+574ms ║║Comparison (enum) not present is (string) not present = true (2ms)
+577ms ║║Condition #20 evaluated true (18ms)
+578ms ║║Condition group #17 evaluated true (state did not change) (19ms)
+588ms ║║Comparison (string) away is (string) away = true (3ms)
+590ms ║║Cancelling condition #5’s schedules…
+591ms ║║Condition #5 evaluated true (10ms)
+659ms ║║Comparison (time) 73463405 is_between (time) 1506275820000 … (time) 7200000 = true (9ms)
+660ms ║║Time restriction check passed
+662ms ║║Cancelling condition #19’s schedules…
+663ms ║║Condition #19 evaluated true (71ms)
+664ms ║║Cancelling condition #18’s schedules…
+665ms ║║Condition group #18 evaluated true (state changed) (84ms)
+669ms ║║Cancelling statement #7’s schedules…
+699ms ║║Calculating (integer) 6 - (integer) 1 >> (integer) 5
+713ms ║║Calculating (integer) 5 + (integer) 5 >> (integer) 10
+720ms ║║Calculating (string) Turned a random light on for + (string) 10 >> (string) Turned a random light on for 10
+723ms ║║Calculating (string) Turned a random light on for 10 + (string) minutes >> (string) Turned a random light on for 10 minutes
+755ms ║║Executed virtual command [3rd Bed Lights].sendPushNotification (26ms)
+843ms ║║Executed physical command [3rd Bed Lights].on() (85ms)
+844ms ║║Executed [3rd Bed Lights].on (87ms)
+881ms ║║Executed physical command [3rd Bed Lights].setLevel([25]) (32ms)
+882ms ║║Executed [3rd Bed Lights].setLevel (33ms)
+891ms ║║Calculating (integer) 5 + (integer) 16 >> (integer) 21
+895ms ║║Executed virtual command [3rd Bed Lights].wait (1ms)
+897ms ║║Requesting a wake up for Sun, Sep 24 2017 @ 8:45:23 PM BST (in 1260.0s)
+905ms ║╚Execution stage complete. (356ms)
+907ms ║Setting up scheduled job for Sun, Sep 24 2017 @ 8:45:23 PM BST (in 1259.991s)
+1415ms ╚Event processed successfully (1415ms)

[c1arkbar]

Was there something before that late execution that had scheduled it to be so late? Even though it didnt happen the hour before was everything still true when it did execute?

I dont see anything in the logs

[freddyq]

This is the entry immediately preceding that late execution. It is basically the last presence sensor leaving. Doesn’t look like anything that would delay execution in there…

And yes, when it did execute everything was still true - the time condition was true, the presence sensors were not present and SHM was set to ‘Away’.

How can I test this being triggered more closely? Do I just keep the trace on and watch closely as the piston stage approaches true?

24/09/2017, 12:16:08 +855ms
+1ms ╔Received event [Presence 1].presence = not present with a delay of 1152ms
+237ms ║RunTime Analysis CS > 21ms > PS > 43ms > PE > 173ms > CE
+248ms ║Runtime (45328 bytes) successfully initialized in 43ms (v0.2.0e9.20170921) (245ms)
+249ms ║╔Execution stage started
+286ms ║║Comparison (enum) not present is (string) not present = true (2ms)
+289ms ║║Comparison (enum) not present is (string) not present = true (2ms)
+291ms ║║Cancelling condition #20’s schedules…
+292ms ║║Condition #20 evaluated true (34ms)
+293ms ║║Cancelling condition #17’s schedules…
+294ms ║║Condition group #17 evaluated true (state changed) (37ms)
+305ms ║║Comparison (string) off is (string) away = false (2ms)
+307ms ║║Condition #5 evaluated false (8ms)
+308ms ║║Condition group #18 evaluated false (state did not change) (10ms)
+328ms ║║Comparison (enum) not present changes_to (string) present = false (0ms)
+330ms ║║Condition #15 evaluated false (17ms)
+331ms ║║Condition group #12 evaluated false (state did not change) (19ms)
+335ms ║╚Execution stage complete. (86ms)
+342ms ╚Event processed successfully (342ms)

[c1arkbar]

When the trace is on it will show you how things executed at the last run. So you won’t need to be watching it as it happens. It will display until the next run.

Ok so I missed this before. You don’t have a subscription on the first if statement. Click on that if and force a subscription for the condition of all presence being away. The subscription was removed when the trigger for the second if was added. Give that a try and see how it goes.

[freddyq]

OK, I will check the trace specifically next time.

Where can I read more about if conditions and subscriptions? I thought for this piston the ‘if’ condition was subscribed to the presence status of the 3 presence sensors so not sure exactly what I’m doing by forcing the subscription. Also, just to clarify I clicked on the condition specifying the three presence sensors and selected ‘Always subscribe’ under the subscription method drop down so I now see a ‘+’ symbol next to line 26 in my last screenshot above. I’m guessing that’s what you meant?

[c1arkbar]

Conditions and Triggers: The difference?

as new users join the community, we expect that at some point many new users will ask this question. so, heres a quick note. conditions: if there are NO triggers in a piston, webcore checks the conditions to decide which events that piston should be subscribed to. if there are triggers in that piston, webcore does NOT subscribe to the events the conditions refer to. triggers: if there are triggers in a piston webcore ONLY checks the triggers to …

This doesn’t exactly cover your question. But it’s good info.

The if was subscribed to the presence sensors up until you added a trigger to your piston. Then the subscription was only on the trigger.

By forcing this subscription your piston will now listen for events from those presence sensors and when the last one is not present your statement will be true and process the actions.

[freddyq]

Ahh I get you! But I will also read that post you link to. Certainly seems like there is less chance of the piston not executing as soon as it should with the condition now forced to subscribe to those presence sensors - I will keep an eye on that.

While I’ve got you, I also noticed a slight issue with the second if in this piston. The use-case I’m trying to code is that as soon as one of us gets home I want all the random lighting logic in the first if to be suspended, and then whichever light is on should be switched off unless it’s the landing light because I just want that to be turned on when we get home. So questions are:

1. In terms of that ‘suspend random logic’ point, do I need to code any particular logic or will that happen automatically when the conditions for the second if become true?

2. The logic isn’t actually working, i.e. I noticed a bedroom light still on when I got inside and the landing light hadn’t been turned on. When I looked through the logs it seemed like that second if was being executed three times, once for each presence sensor arriving so I thought maybe that’s screwing with it. So I added a boolean variable which would be set to true the first time that second if logic tests true and the if logic requires that variable to be false, in effect preventing the logic from running more than once. But that hasn’t resolved the issue.

3. I thought the reason the second if wasn’t running properly was because it needed to be configured to run asynchronously and not wait for the first if logic to complete, so I made that asynchronous but again, hasn’t resolved the issue.

Latest version of the piston is below. Any tips would be appreciated!

[c1arkbar]

Ok so all the subscription to a device means is that this piston will react to any event from those devices.

If this change doesn’t help then try adding a cancel all pending tasks into the actions of the second if. Insert that above your turn off command

[freddyq]

Cool, thanks. Think I get subscription now and also the difference between conditions and triggers.

I’ll see how this version of the Piston works before adding the cancel action. Thanks for help!

[c1arkbar]

Sure thing

[freddyq]

@c1arkbar Argh! Still no luck…the Piston didn’t trigger automatically again…here is a screenshot with the trace on and showing that the first if condition is evaluating true and also the logs. At the point the screenshot and logs were taken, the Piston still hadn’t run automatically.

Logs

9/29/2017, 5:35:50 PM +639ms+1ms╔Received event [Presence 2].presence = not present with a delay of 123ms+191ms║RunTime Analysis CS > 20ms > PS > 51ms > PE > 121ms > CE+209ms║Runtime (45327 bytes) successfully initialized in 51ms (v0.2.0ec.20170927) (208ms)+210ms║╔Execution stage started+228ms║║Comparison (enum) not present is (string) not present = true (1ms)+230ms║║Comparison (enum) not present is (string) not present = true (2ms)+232ms║║Cancelling condition #20’s schedules…+233ms║║Condition #20 evaluated true (16ms)+234ms║║Cancelling condition #17’s schedules…+235ms║║Condition group #17 evaluated true (state changed) (17ms)+243ms║║Comparison (string) off is (string) away = false (2ms)+245ms║║Condition #5 evaluated false (8ms)+246ms║║Condition group #18 evaluated false (state did not change) (9ms)+265ms║║Comparison (enum) not present changes_to (string) present = false (1ms)+267ms║║Condition #15 evaluated false (17ms)+268ms║║Condition group #12 evaluated false (state did not change) (19ms)+271ms║╚Execution stage complete. (62ms)+364ms╚Event processed successfully (364ms)9/29/2017, 5:34:32 PM +576ms+1ms╔Received event [Presence 1].presence = not present with a delay of 505ms+295ms║RunTime Analysis CS > 18ms > PS > 177ms > PE > 99ms > CE+303ms║Runtime (45325 bytes) successfully initialized in 177ms (v0.2.0ec.20170927) (300ms)+303ms║╔Execution stage started+318ms║║Comparison (enum) present is (string) not present = false (1ms)+320ms║║Condition #20 evaluated false (10ms)+321ms║║Condition group #17 evaluated false (state did not change) (12ms)+337ms║║Comparison (enum) not present changes_to (string) present = false (1ms)+339ms║║Cancelling condition #15’s schedules…+340ms║║Condition #15 evaluated false (16ms)+341ms║║Condition group #12 evaluated false (state did not change) (16ms)+343ms║╚Execution stage complete. (40ms)+350ms╚Event processed successfully (350ms)

[c1arkbar]

Try taking the time out of the while loop and instead add it as a restriction

[freddyq]

As a restriction?

[c1arkbar]

Click the funnel looking icon in the top left. Then you will see “only when” appear above all statements. Use the same logic for time you have in the while statement for that restriction instead.

[freddyq]

Ah ok, I’ll make that change and see what happens. Will need to read about restrictions because I’ve not used them before and not sure how they differ from other conditions.

[c1arkbar]

They are basically the same thing. But i think it might be the time meeting this up so going to move from condition to restriction

[freddyq]

So should the restriction go at the very highest level of the piston so that it covers all the logic or only so that it restricts the first if logic?

[c1arkbar]

Just so it restricts the while loop

[freddyq]

Like this? Note I’ve also added the ‘Cancel all pending tasks’ action as the return to home logic still wasn’t working like I want it to. Haven’t tested after adding that action yet.

[c1arkbar]

Yea like that