Lights on getting home after sunset

huge101 · 2020-05-10 04:24:18 UTC

1) Give a description of the problem
For testing purposes, I’m using the “is home” condition instead of the trigger “changes to” and the wait will be 5 mins.

When I only have the outside light parts in the scripts, it works perfect. When I add the 2 indoors light, only the outside lights turn on. Go easy on me, i’m just starting with ST and WebCore as I just transitioned from Wink.

2) What is the expected behaviour?
I want to have the outside light turn on after sunset, always. I want the 2 lights inside the house to turn on after sunset, only if no one is home.

3) What is happening/not happening?
The outside lights turn on but nothing on the inside.

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

5) Attach logs after turning logging level to Full
5/10/2020, 12:22:20 AM +494ms
+0ms ╔Received event [My home].time = 1589084541669 with a delay of -1175ms
+44ms ║RunTime Analysis CS > 20ms > PS > 5ms > PE > 18ms > CE
+46ms ║Runtime (41186 bytes) successfully initialized in 5ms (v0.3.110.20191009) (45ms)
+47ms ║╔Execution stage started
+61ms ║║Skipped execution of physical command [Outside Lights].off([]) because it would make no change to the device. (2ms)
+61ms ║║Executed [Outside Lights].off (4ms)
+96ms ║║Comparison (time) 1340558 is_between (time) 1589156700000 … (time) 1589104140000 = true (9ms)
+97ms ║║Time restriction check passed
+99ms ║║Condition #9 evaluated true (35ms)
+100ms ║║Cancelling statement #9’s schedules…
+107ms ║║Requesting time schedule wake up at Sun, May 10 2020 @ 5:49:00 AM EDT
+118ms ║║Comparison (string) Home is (string) home = false (1ms)
+119ms ║║Condition #10 evaluated false (10ms)
+120ms ║║Condition group #8 evaluated false (state did not change) (57ms)
+123ms ║╚Execution stage complete. (76ms)
+125ms ║Setting up scheduled job for Sun, May 10 2020 @ 5:49:00 AM EDT (in 19599.382s), with 1 more job pending
+132ms ╚Event processed successfully (131ms)
5/10/2020, 12:22:16 AM +556ms
+1ms ╔Received event [My home].test = 1589084536556 with a delay of 0ms
+33ms ║RunTime Analysis CS > 13ms > PS > 5ms > PE > 15ms > CE
+36ms ║Runtime (41182 bytes) successfully initialized in 5ms (v0.3.110.20191009) (34ms)
+37ms ║╔Execution stage started
+70ms ║║Comparison (time) 1336598 is_between (time) 1589156700000 … (time) 1589104140000 = true (10ms)
+71ms ║║Time restriction check passed
+73ms ║║Condition #2 evaluated true (32ms)
+74ms ║║Cancelling statement #2’s schedules…
+83ms ║║Requesting time schedule wake up at Sun, May 10 2020 @ 5:49:00 AM EDT
+91ms ║║Comparison (string) Home is (string) Home = true (1ms)
+93ms ║║Condition #3 evaluated true (8ms)
+94ms ║║Condition group #1 evaluated true (state did not change) (53ms)
+96ms ║║Cancelling statement #4’s schedules…
+107ms ║║Executed physical command [Outside Lights].on() (7ms)
+108ms ║║Executed [Outside Lights].on (8ms)
+111ms ║║Executed virtual command [Outside Lights].wait (1ms)
+112ms ║║Requesting a wake up for Sun, May 10 2020 @ 12:22:21 AM EDT (in 5.0s)
+128ms ║╚Execution stage complete. (92ms)
+130ms ║Setting up scheduled job for Sun, May 10 2020 @ 12:22:21 AM EDT (in 4.983s), with 2 more jobs pending
+142ms ╚Event processed successfully (142ms)

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

WCmore · 2020-05-10 04:55:40 UTC

Hello and welcome to the club, Hugues.

I understand your reasoning for this… I’d be a pain to have to leave the house five times while testing out our code.

Unfortunately, with that choice, it totally changes the way the entire piston processes. Meaning, any successful test using a condition, it will fail when converted back into a trigger.

Ideally, our testing scenario should match as closely as possible to the final draft.

Notice the 6 lightning bolts in the left margin? Having a trigger in place changes the conditions back into real conditions. (reducing the lightning bolts down to 1 or 2)

While testing, my suggestion would be to change your original trigger:
IF Device changes to "X"
to a generic device, using the same verb:
IF RareBulb changes to on
or
IF SimulatedSwitch changes to on

This way, you can toggle the switch on or off to simulate presence changes. Once you are happy with the testing, it is simply a matter of converting the trigger back to the original.

PS. I realize that this post does not help you a whole lot in the short term… but I hope you can take some of the wisdom for the long haul.

WCmore · 2020-05-10 05:07:06 UTC

Speaking of short term…

I just noticed that lines 20 & 32 are not capitalized the same…

Although to be honest, I am not 100% confident that currentPlace can be a trigger.

huge101 · 2020-05-10 05:16:19 UTC

Hey, thanks for replying. here is exactly how I wrote it. not for testing.

WCmore · 2020-05-10 05:20:53 UTC

From that last screenshot, I suspect that currentPlace is not seen as a trigger…
If this is true, then all of your conditions still become triggers…

What this means is that you may need to find another option in the drop down besides currentPlace to be your trigger.

To test this, you can make a single block piston:

IF Sensor 1's currentPlace changes  <-- Trigger
    Then Send SMS or Notification
END IF

Unfortunately, this last test requires a real (not simulated) change of location.

huge101 · 2020-05-10 05:45:57 UTC

So I originally based (pasted )someones script. I rewrote from scratch. Two lightning bolts…

WCmore · 2020-05-10 05:58:24 UTC

OK cool, although I still think my previous posts apply with many handlers.

Has piston “vumv” ever fired when your location changed?

huge101 · 2020-05-10 06:02:14 UTC

Haven’t left the house for testing yet, will have to test tomorrow, later today I mean.

WCmore · 2020-05-10 06:04:05 UTC

Perfect.

Please Clear your logs (to clean the slate) and turn your logging level to Full so we get good information later.

Reference: Wiki / Logs

huge101 · 2020-05-10 06:06:13 UTC

Oh yeah for sure. New piston, forgot to turn on the log! thanks again!

Terminal · 2020-05-10 17:11:41 UTC

Something I noticed, which will simplify your code a bit.

Lines 18 and 20 of ‘vumv’ are the same triggers as lines 30 and 32. It seems unnecessary as it is in the IF statement that will only be true when these things are true anyway. So you really only need the condition in line 34.

Also having extra unnecessary triggers may cause unexpected results.

huge101 · 2020-05-10 18:23:22 UTC

Ok I did as suggested, cleaned it up a bit.

Preformatted text

WCmore · 2020-05-10 18:27:37 UTC

Looking much better… (although we still need to confirm that currentPlace can work as a trigger)

After editing a piston, please clear the logs once again, so they will align with the latest pic.

(if there are issues, it helps to also turn on Trace)

Note: We may come back to line 20 once the trigger is confirmed to work.

huge101 · 2020-05-10 19:19:11 UTC

I removed the time of day condition and went out. No lights.

5/10/2020, 3:12:43 PM +926ms
+2ms ╔Received event [Huge’s Phone].currentPlace = Home with a delay of 60ms
+37ms ║RunTime Analysis CS &gt; 18ms &gt; PS &gt; 6ms &gt; PE &gt; 13ms &gt; CE
+40ms ║Runtime (38412 bytes) successfully initialized in 6ms (v0.3.110.20191009) (36ms)
+41ms ║╔Execution stage started
+47ms ║║Comparison (string) Home changes_to (string) home = false (0ms)
+49ms ║║Condition #2 evaluated false (4ms)
+50ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+51ms ║╚Execution stage complete. (11ms)
+52ms ╚Event processed successfully (52ms)
5/10/2020, 2:50:54 PM +709ms
+0ms ╔Received event [Huge’s Phone].currentPlace = with a delay of 136ms
+35ms ║RunTime Analysis CS &gt; 18ms &gt; PS &gt; 5ms &gt; PE &gt; 13ms &gt; CE
+37ms ║Runtime (38338 bytes) successfully initialized in 5ms (v0.3.110.20191009) (36ms)
+38ms ║╔Execution stage started
+91ms ║║Comparison (string) changes_to (string) home = false (0ms)
+92ms ║║Condition #2 evaluated false (48ms)
+93ms ║║Condition group #1 evaluated false (state did not change) (50ms)
+95ms ║╚Execution stage complete. (57ms)
+139ms ╚Event processed successfully (139ms)

WCmore · 2020-05-10 20:00:49 UTC

It looks like currentPlace does work as a trigger for you…

It should fire when changing from anything else to “Home”.
(but notice the capital “H”)

Comparison (string) Home changes_to (string) home = false

huge101 · 2020-05-10 20:09:41 UTC

Changed the home for Home. Going for a walk.

huge101 · 2020-05-10 20:13:29 UTC

The piston is firing when saving after edit. Normal behaviour?

huge101 · 2020-05-11 00:03:48 UTC

Surprisingly, I made headways. The first chunk is behaving. The second chunk looks like it didn’t fire up. I’m thinking maybe the Home location change and me physically getting home happens at the same time; I have a different geofencing piston that changes to away/home based on my presence. They register at the same time, so in this case, i’m never away? make sense?

5/10/2020, 7:21:46 PM +112ms
+0ms ╔Received event [My home].time = 1589152907283 with a delay of -1172ms
+69ms ║RunTime Analysis CS &gt; 49ms &gt; PS &gt; 6ms &gt; PE &gt; 15ms &gt; CE
+72ms ║Runtime (38409 bytes) successfully initialized in 6ms (v0.3.110.20191009) (71ms)
+74ms ║╔Execution stage started
+101ms ║║Executed physical command [Outside Lights].off() (12ms)
+102ms ║║Executed [Outside Lights].off (15ms)
+110ms ║║Comparison (string) :e961a7bac45f76666575a6b42ae443ba: is_not (string) :e961a7bac45f76666575a6b42ae443ba: = false (1ms)
+112ms ║║Condition #11 evaluated false (7ms)
+113ms ║║Condition group #8 evaluated false (state did not change) (8ms)
+115ms ║╚Execution stage complete. (42ms)
+117ms ╚Event processed successfully (118ms)
5/10/2020, 7:16:47 PM +198ms
+2ms ╔Received event [Huge’s Phone].currentPlace = Home with a delay of 67ms
+44ms ║RunTime Analysis CS &gt; 23ms &gt; PS &gt; 6ms &gt; PE &gt; 15ms &gt; CE
+47ms ║Runtime (38411 bytes) successfully initialized in 6ms (v0.3.110.20191009) (43ms)
+48ms ║╔Execution stage started
+55ms ║║Comparison (string) Home changes_to (string) Home = true (1ms)
+56ms ║║Cancelling condition #2's schedules...
+57ms ║║Condition #2 evaluated true (5ms)
+58ms ║║Cancelling condition #1's schedules...
+59ms ║║Condition group #1 evaluated true (state changed) (8ms)
+61ms ║║Cancelling statement #4's schedules...
+79ms ║║Executed physical command [Outside Lights].on() (14ms)
+80ms ║║Executed [Outside Lights].on (16ms)
+83ms ║║Executed virtual command [Outside Lights].wait (1ms)
+84ms ║║Requesting a wake up for Sun, May 10 2020 @ 7:21:47 PM EDT (in 300.0s)
+88ms ║╚Execution stage complete. (41ms)
+90ms ║Setting up scheduled job for Sun, May 10 2020 @ 7:21:47 PM EDT (in 299.996s)
+102ms ╚Event processed successfully (102ms)

ike2018 · 2020-05-11 00:47:36 UTC

In this post you are being helped by 2 very advanced users…
But I just want to add my suggestion:

Use a timer for outside lights.

Every day 1 minute after SUNSET 
With switch 6
Do turn ON

Add a second timer

Everyday 3 minutes after sunset
      IF location mode is NOT HOME
      Then do this do that

Terminal · 2020-05-11 01:56:19 UTC

The second part didn’t fire because your location mode was Home. Your piston checks that you are not home.

If
Location Mode is not Home
Then
Do stuff with RGB Bulb 1&2

Comparison (string) :e961a7bac45f76666575a6b42ae443ba: is_not (string) :e961a7bac45f76666575a6b42ae443ba: = false (1ms)