Away lighting simulator not triggering automatically

triggers
#21

OK I’ll put the trace on and then take the screenshot. But you might be onto something there because I’ve been having issues with ‘Away’ mode not setting because the Mrs doesn’t always have her GPS on and that happened yesterday as well so I ended up having to turn it on and then open the ST app to update her presence status. I believe i did that after the time condition in this Piston would have been met so maybe that screwed with logic.

I have a feeling I will need to get the Mrs to use a proper presence sensor rather than mobile which I was thinking of anyway. My mobile presence works fine because I always have the app running in the background and GPS on.

#22

Yea just check those things. The trace being on will visually help a lot!

#23

With the presence now triggering away mode properly, the piston triggered automatically which was progress however, it triggered about an hour after the time condition I’ve put in the logic. Looking at the logs, the first event I see after sunset + 15 minutes (which would be around 19:10) was this:

24/09/2017, 20:24:22 +812ms
+1ms ╔Received event [Home].execute = <I’ve removed the ip address> with a delay of 301ms

I’m not sure why it waited until an hour later to realise it could start executing the piston.

I had the trace on but didn’t really get a chance to check the piston around the sunset+15 minutes time to see what was going on…

#24

@c1arkbar any ideas?

#25

I don’t know. What do all the logs look like?

#26

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)

#27

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

#28

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)

#29

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.

#30

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?

#31

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.

#32

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!

image
image.png1178×1145 66.3 KB

#33

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

#34

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!

#35

Sure thing

#36

@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.

2017-09-29-20-46-03-
2017-09-29-20-46-03-.png1178×1141 273 KB

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)

#37

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

#38

As a restriction?

#39

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.

#40

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.