All Pistons Stopped Triggering - Fixed by Pause/Resume


#1

Been using WebCore for only a week and have managed to get loads of pistons up and running and humming along nicely.

Today all my pistons have stopped responding to their triggers. I perform the action and can see the virtual switch in smartthings flip to on, but WebCore doesn’t respond.

From Webcore dashboard, If I pause a piston and then immediately resume, it starts working again.


#2

Can you post one or two of your pistons for us to look at?


#3

It was all of them, but here’s a simple example. For switching off a mirror with LED lights on it. The mirror has a button on the front to switch lights on/off. So this piston cuts the power for 3 seconds. This turns out the LED lights until I push the button on the front of the mirror again.

But there were other pistons that stopped responding to events too. Pause/Resume in WebCore fixed things as did a reboot of the SmartThings router. I don’t think this is a piston problem.

For some reason, it seems like my WebCore Pistons became unlinked from my devices. It was like this for about a day when I realised things weren’t working properly and investigated.


#4

Well it happened again this morning. I just woke up at 130pm because my Alarm piston did not trigger. No events were received from any of the switches…

![image|408x499]

According to the logs, there was no automatic trigger this morning “The wake-up alarm” virtual switch gets triggered by Smartthings Automations, the “In Bed switch Virtual Switch” gets set by the withing sleep sensor which is under my mattress and remains “On” all night while I’m in bed.

From SmartThings, device logs, wake up alarm triggers every day on schedule, and then switches off 3 seconds later, as intended. Webcore just isn’t listensing.

I’ve done multiple tests manually triggering switches in SmartThings. This piston just doesn’t trigger.

Here’s my advanced settings for the “With Condition”. Set to Never cancel, so that the Alarm reset switch can be reset without stopping the piston.

Here’s the logs showing a successful start yesterday morning, and a strange restart/resubscribe an hour later (not sure why, but that appears in the logs occasionally).

03/06/2021, 10:27:50 +718ms
+0ms ╔Starting piston... (v0.3.113.20210203)
+341ms ║╔Subscribing to devices...
+350ms ║║Subscribing to Wake Up Alarm.switch...
+454ms ║║Subscribing to In Bed Switch...
+456ms ║╚Finished subscribing (133ms)
+497ms ║Comparison (enum) off is (string) on = false (1ms)
+507ms ╚Piston successfully started (507ms)
03/06/2021, 09:45:03 +471ms
+1ms ╔Received event [Wake Up Alarm].switch = off with a delay of 74ms
+50ms ║RunTime Analysis CS > 19ms > PS > 5ms > PE > 26ms > CE
+52ms ║Runtime (38704 bytes) successfully initialized in 5ms (v0.3.113.20210203) (50ms)
+53ms ║╔Execution stage started
+59ms ║║Comparison (enum) off changes_to (string) on = false (0ms)
+61ms ║║Cancelling condition #2's schedules...
+62ms ║║Condition #2 evaluated false (4ms)
+63ms ║║Condition group #1 evaluated false (state did not change) (6ms)
+64ms ║╚Execution stage complete. (12ms)
+65ms ╚Event processed successfully (65ms)
03/06/2021, 09:45:00 +143ms
+1ms ╔Received event [Wake Up Alarm].switch = on with a delay of 73ms
+59ms ║RunTime Analysis CS > 17ms > PS > 6ms > PE > 35ms > CE
+61ms ║Runtime (38705 bytes) successfully initialized in 6ms (v0.3.113.20210203) (59ms)
+62ms ║╔Execution stage started
+69ms ║║Comparison (enum) on changes_to (string) on = true (0ms)
+71ms ║║Cancelling condition #2's schedules...
+72ms ║║Condition #2 evaluated true (6ms)
+81ms ║║Comparison (enum) off is (string) on = false (1ms)
+82ms ║║Condition #8 evaluated false (9ms)
+83ms ║║Condition group #1 evaluated false (state did not change) (17ms)
+85ms ║╚Execution stage complete. (23ms)
+86ms ╚Event processed successfully (86ms)

No further log entries from this piston despite me triggering both switches several times this morning.

Then after a pause and resume, and manual triggering of the switches, things work as expected.

04/06/2021, 13:48:38 +783ms
+1ms ╔Received event [Wake Up Alarm].switch = off with a delay of 67ms
+51ms ║RunTime Analysis CS > 19ms > PS > 5ms > PE > 26ms > CE
+53ms ║Runtime (38865 bytes) successfully initialized in 5ms (v0.3.113.20210203) (51ms)
+54ms ║╔Execution stage started
+61ms ║║Comparison (enum) off changes_to (string) on = false (1ms)
+62ms ║║Cancelling condition #2's schedules...
+63ms ║║Condition #2 evaluated false (5ms)
+64ms ║║Cancelling condition #1's schedules...
+65ms ║║Condition group #1 evaluated false (state changed) (7ms)
+67ms ║╚Execution stage complete. (14ms)
+69ms ║Setting up scheduled job for Fri, Jun 4 2021 @ 2:03:35 PM BST (in 896s)
+77ms ╚Event processed successfully (77ms)
04/06/2021, 13:48:35 +470ms
+1ms ╔Received event [Wake Up Alarm].switch = on with a delay of 67ms
+66ms ║RunTime Analysis CS > 16ms > PS > 5ms > PE > 45ms > CE
+69ms ║Runtime (38872 bytes) successfully initialized in 5ms (v0.3.113.20210203) (67ms)
+70ms ║╔Execution stage started
+78ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+80ms ║║Cancelling condition #2's schedules...
+81ms ║║Condition #2 evaluated true (6ms)
+89ms ║║Comparison (enum) on is (string) on = true (2ms)
+91ms ║║Cancelling condition #8's schedules...
+92ms ║║Condition #8 evaluated true (9ms)
+93ms ║║Cancelling condition #1's schedules...
+94ms ║║Condition group #1 evaluated true (state changed) (19ms)
+96ms ║║Cancelling statement #3's schedules...
+106ms ║║Executed virtual command executePiston (4ms)
+109ms ║║Executed virtual command wait (1ms)
+110ms ║║Requesting a wake up for Fri, Jun 4 2021 @ 2:03:35 PM BST (in 900.0s)
+115ms ║╚Execution stage complete. (45ms)
+116ms ║Setting up scheduled job for Fri, Jun 4 2021 @ 2:03:35 PM BST (in 899s)
+123ms ╚Event processed successfully (123ms)
04/06/2021, 13:48:14 +923ms
+2ms ╔Starting piston... (v0.3.113.20210203)
+244ms ║╔Subscribing to devices...
+274ms ║║Subscribing to Wake Up Alarm.switch...
+382ms ║║Subscribing to In Bed Switch...
+384ms ║╚Finished subscribing (144ms)
+417ms ║Comparison (enum) off is (string) on = false (1ms)
+429ms ╚Piston successfully started (428ms)
04/06/2021, 13:48:13 +162ms
+58ms ╔Stopping piston...
+152ms ╚Piston successfully stopped (94ms)

Anyone know what’s going wrong this is happening often. I did think about setting a traditional back-up alarm last night but fell asleep before I did it. But I NEED smart things to be reliable.


#5

I can’t see anything obviously wrong. I am wondering if the Live Logging in the IDE is showing any errors that might prove enlightening.


#6

I had this happen to me back in January or February, as did one or two others, following an ST outage, so your circumstances (and solution) may be different. Nevertheless, here is what I posted then. I don’t know how or why this worked, but I’m throwing it out there just in case you want to give it a try…

The solution that eventually worked for me was to go to the dashboard, click New Piston -> Create Duplicate and clone each piston, after which I deleted the old pistons. The “cloned” pistons trigger and function as they did before the outage.

It’s worth trying with at least one of your non-working pistons.


#7

Not quite the same issue but the ultimate solution was to “clone” the piston as @bthrock suggested.

I had a piston that processed a get request and forwarded the data to other pistons via the execute piston command. The piston triggered as expected and executed the other pistons but args were always null. I could manually send args using the external url so the secondary pistons weren’t the issue. After recreating the primary piston, balance has been restored in the universe.

TL,DR; Try to recreated your piston using a backup code.


#8

I am using execute piston pretty extensively so that I can have units of code encapsulated and not repeated all over the place. I wonder if there’s a problem with using execute piston?


#9

I have a few weird gremlins the past couple of days that have also lead me to consider this option btw.

Very simple approach, one piston executes another, the slave piston has been giving me issues with not completing its content. Been working fine for 3+ years and now its acting up, looks like the execution side.


#10

Generally not, unless it is generating errors in IDE. Data limits, etc.