Execution of a piston skipped

#1

1) Give a description of the problem
When SmartThings migrated my home to the new app, and SHM was no longer working with webCoRE and ActionTiles, I followed this write-up to make simulated switches to be controlled by both. Everything has been working great since then. Today, a piston did not execute a line where it Disarms SHM (turns on the Disarm switch) at 6am every morning if any of my family members are home and if SHM is in Armed (stay) mode.

2) What is the expected behaviour?
SHM Disarm (switch) should have been turned on.

3) What is happening/not happening?
(PUT YOUR INFO HERE)

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png1178×551 27.1 KB

5) Attach logs after turning logging level to Full
10/13/2020, 5:59:59 AM +99ms
+0ms ╔Received event [Home].time = 1602583200000 with a delay of -901ms
+74ms ║RunTime Analysis CS > 17ms > PS > 18ms > PE > 38ms > CE
+76ms ║Runtime (38265 bytes) successfully initialized in 18ms (v0.3.110.20191009) (75ms)
+77ms ║╔Execution stage started
+94ms ║║Comparison (enum) on is (string) on = true (2ms)
+95ms ║║Condition #3 evaluated true (8ms)
+126ms ║║Comparison (enum) present is (string) present = true (1ms)
+128ms ║║Condition #6 evaluated true (31ms)
+129ms ║║Condition group #2 evaluated true (state did not change) (42ms)
+130ms ║║Cancelling statement #4’s schedules…
+137ms ║║Skipped execution of physical command [STHM Disarm].on([]) because it would make no change to the device. (3ms)
+137ms ║║Executed [STHM Disarm].on (5ms)
+140ms ║╚Execution stage complete. (64ms)
+141ms ║Setting up scheduled job for Wed, Oct 14 2020 @ 6:00:00 AM EDT (in 86400.76s)
+147ms ╚Event processed successfully (147ms)

I am wondering if for some reason the ST automations aren’t keeping the switches in the correct state, or if webCoRE isn’t getting their status properly. Should I clear the ST automations and do everything in webCoRE?

#2

The Skipped execution of physical command [STHM Disarm].on([]) because it would make no change to the device log message means that ST believes the device was already on. The state is read from the ST device object.

So there seem to be two possibilities:

  1. Something has already turned the disarm switch on.
  2. Something that should have turned the disarm switch off, didn’t.

I don’t have STHM set up with virtual switches as when I tried it I found the ST automations, which need to set the value of three switches, were failing to do so correctly. Now this could have been because I was doing too much in a single piston at the webCoRE end and hitting issues with semaphore waits and getting everything out of sync (I was also trying to retain use of the “SHM status” as that can still work even if SHM isn’t running). I am certainly not the only person to have reported this behaviour though and there doesn’t seem to be a lot of rhyme or reason when it doesn’t work.

#3

Ditto here.