Lights on/off with location mode change issue

execution
light
#1

1) Give a description of the problem
I have a piston that changes the location mode, this seems to execute fine. I have another piston that turns the lights on or off depending upon time and/or location mode change.
Up until a week ago this was working absolutely fine, but now, it is turning the lights on, but failing to turn them off when the location changes to ‘home-asleep’

2) What is the expected behaviour?
Lights should turn on at sunset or if location mode changes (if its after sunset, smart home monitor is disarmed and location mode is not ‘home - asleep’.

the lights should turn off if the location mode changes to ‘home - asleep’

3) What is happening/not happening?
The lights are turning on as expected at sunset. But they are not then turning off later qhen location mode changes to ‘home asleep’

**4) Post a Green Snapshot of

SmartSelect_20201210-113827_SmartThings
SmartSelect_20201210-113827_SmartThings.jpg1014×796 127 KB

5) Attach logs after turning logging level to Full

Logs

10/12/2020, 11:38:56 +566ms
+1ms ╔Received event [Home].test = 1607600336565 with a delay of 0ms
+106ms ║RunTime Analysis CS > 20ms > PS > 25ms > PE > 61ms > CE
+109ms ║Runtime (40319 bytes) successfully initialized in 25ms (v0.3.110.20191009) (106ms)
+110ms ║╔Execution stage started
+146ms ║║Comparison (time) 41936682 happens_daily_at (time) 1607615520000 = false (1ms)
+148ms ║║Condition #2 evaluated false (32ms)
+152ms ║║Cancelling statement #2’s schedules…
+157ms ║║Requesting time schedule wake up at Thu, Dec 10 2020 @ 3:52:00 PM GMT
+165ms ║║Comparison (string) :47b910cec7fb65a8cb1c73fcc2a47035: changes = false (0ms)
+166ms ║║Condition #3 evaluated false (4ms)
+168ms ║║Condition group #1 evaluated false (state did not change) (51ms)
+173ms ║║Comparison (string) :47b910cec7fb65a8cb1c73fcc2a47035: changes_to (string) :d992162b789465b09555a1194e12a166: = false (1ms)
+176ms ║║Condition #13 evaluated false (5ms)
+178ms ║║Condition group #12 evaluated false (state did not change) (7ms)
+198ms ║╚Execution stage complete. (88ms)
+203ms ║Setting up scheduled job for Thu, Dec 10 2020 @ 3:52:00 PM GMT (in 15183.232s)
+217ms ╚Event processed successfully (216ms)
10/12/2020, 09:14:26 +969ms
+1ms ╔Starting piston… (v0.3.110.20191009)
+302ms ║╔Subscribing to devices…
+338ms ║║Subscribing to Home.mode…
+418ms ║║Subscribing to Living Room Lamp…
+419ms ║║Subscribing to Office lamp…
+420ms ║║Subscribing to Conservatory left - white…
+421ms ║║Subscribing to Conservatory right - white…

#2

Could it be a simple mis-spelling on lines 27 & 43?
(it is spelled “Home - Sleep” in your piston)

Also note that pushing “Test” on this piston won’t do anything.

When troubleshooting a piston like this, the best test will be a genuine trigger.
(IE: such as changing Location mode)

A Full Log showing that “broken” trigger will help to diagnose.

On another note, it is very possible for line 23 to be false anytime past midnight.
Sunrise/set times change when the day changes…
(and technically. 1:00 is before 18:00)

I’d likely change line 23 to:
IF Time is not between Sunrise and Sunset.
… or a variation of:
IF Time is not between 4:30 AM and Sunset.
(both of which cover the dark hours)

#3

On the face of it, the structure looks OK (albeit the “Smart Home Monitor status is Disarmed” is probably a bit past its sell by date now).

The piston would appear to have subscribed to the location mode correctly so it would be good to see what the logs say (if anything) when you change the location mode to and from ‘Home - Sleep’.

I don’t know how robust webCoRE’s location mode handling is. The unique identifier for a mode is a UUID so I’d hope it would adapt to any mode name changes you may or may not have made.

The string you see in the logs for a mode is an MD5 hash of “core.UUID” with colons surrounding it, where UUID is the mode ID mentioned above.

#4

Thanks. Once this has triggered on (which it should do shortly) and then should have triggered off i will resend the logs. Thanks

#5

Please make sure the log matches the latest piston posted here.
(preferably with Trace turned on)