Any errors in the IDE logs? Also, what version are you on? Some older versions were rate limited by ST because of a bug, the bug was fixed in the latest version and that may fix your issue. If that IS the issue.
Pistons have stopped working! [daylight savings time issues]
Alwas
#223
Iâm on the latest version, (v0.2.0fe).
As for the logs, I didnât enable logging level for that piston.
ady624
#224
It doesnât matter, if thereâs an error, it would show up regardless of the logging level. I will be hopping on a flight soon, so if I stop replying, itâs because of the flight.
Alwas
#225
looking at the device history, it âsaysâ off command was sent, piston is called âBalcony Off delay after Goodnightâ⌠but the light stayed on all night!
2017-11-25 5:06:00.770 PM CET
16 hours ago DEVICE switch on Balcony was turned on
2017-11-24 11:06:45.458 PM CET
1 day ago DEVICE switch off Balcony was turned off
2017-11-24 11:06:45.301 PM CET
1 day ago APP_COMMAND off Balcony Off Delay After Goodnight se
Alwas
#226
Ignore that, that data was from the evening of the 24th when it ran correctly, last night (the 25th) the piston just didnât run.
Woodsy
#227
I do not know if it relates, but my dashboard refuses to load this morning.
In the logs I see:
7:36:19 AM: error physicalgraph.exception.StateCharacterLimitExceededException: State cannot be greater than 100000.0 characters
Kebel871
#228
Iâve found the hub to be inconsistent in the last few days too. Looks like webCoRE and ST is doing everything good, but the hub never issue the command.
Robin
#229
Go into the webcore app (within the ST app), select settings and then âClean up and rebuild data cacheâ.
Hilly_2015
#231
Just want to report that Iâve been having further issues too (v0.2.0fe)
All my issues tend to stem from this simple mode change piston:
We were both home, but none of my âEveningâ pistons fired because this didnât do itâs job.
Hilly_2015
#233
No logs on the actual piston itself. Is there anything else I can get from the hub itself to help?
The mode should have changed at roughly 15:49pm.
The only thing I can find at that time was the following:
Robin
#234
Turn on full logging (below the piston in the piston preview page)⌠then check those logs after the desired time to see what happened.
Maybe change the piston so it triggers sooner for testing purposes.
bobbles
#235
I have something similar.
I use the only when function.
ONLY WHEN
Location mode is not away.
THEN
Every day at 19:30
DO
Set mode to Evening.
EDIT. Forgot to mention that I have a wait in there as well.
Here it is.
Bit of belt and braces going on as well.
Hilly_2015
#236
It also didnât fire a piston when all of our presence sensors left this morning worryingly. Iâll change all my pistons to use full logging and respond back with any further issues.
iridris
#237
I have a piston that ran this morning - logs show all the proper commands being executed, but SmartThings didnât seem to receive the commands. The piston was setting the mode to âNannyâ and disarming SHM. Again, the piston ran and executed these commands but the house stayed in âHomeâ mode (and consequently switched to âAwayâ when I left for work, arming the house while the nanny was inside still).
11/27/2017, 7:59:59 AM +158ms
+1ms âReceived event [Home].time = 1511787600000 with a delay of -843ms
+334ms âRunTime Analysis CS > 29ms > PS > 220ms > PE > 86ms > CE
+347ms âRuntime (37851 bytes) successfully initialized in 220ms (v0.2.0fe.20171109) (344ms)
+348ms ââExecution stage started
+357ms ââComparison (string) :b11771d3d5c283d77773906d5a1aae7a: is (string) :b11771d3d5c283d77773906d5a1aae7a: = true (2ms)
+359ms ââCondition #1 evaluated true (6ms)
+360ms ââCondition group #null evaluated true (state did not change) (7ms)
+365ms ââComparison (time) 28799521 happens_daily_at (time) 28800000 = true (0ms)
+366ms ââTime restriction check passed
+368ms ââCancelling condition #5âs schedulesâŚ
+369ms ââCondition #5 evaluated true (6ms)
+370ms ââCancelling statement #5âs schedulesâŚ
+373ms ââRequesting time schedule wake up at Tue, Nov 28 2017 @ 8:00:00 AM EST
+376ms ââCancelling condition #2âs schedulesâŚ
+377ms ââCondition group #2 evaluated true (state changed) (15ms)
+380ms ââCancelling statement #11âs schedulesâŚ
+428ms ââExecuted virtual command setLocationMode (45ms)
+723ms ââExecuted virtual command writeToFuelStream (290ms)
+745ms ââExecuted virtual command setAlarmSystemStatus (18ms)
+748ms ââExecution stage complete. (401ms)
+750ms âSetting up scheduled job for Tue, Nov 28 2017 @ 8:00:00 AM EST (in 86400.093s)
+768ms âEvent processed successfully (768ms)
Robin
#238
Iâm not sure why the logs would report successful execution if that was not the case⌠does your fuel stream update with the correct info? Is it possible another piston somewhere is being triggered by the mode change?
Maybe build a super simple piston:
IF
Location mode changes
then
with location
write data point âLocation Modeâ to fuel stream ModeTest
Then you can see if it changes to âNannyâ before switching straight back to âhomeâ or whateverâŚ
Also, unrelated but makes for a cleaner piston⌠rather than using âIF Time happens daily atâŚâ, use âevery day atâŚâ, shouldnât make a big difference but sometimes it helps with eronious cancellations of running pistons.
To access this function, click options and check âshow advanced statementsâ
Then you can pick Timer (and other cool things):
rudip
#239
Iâm having the same issue, almost everyday, since 11/16 (Beta Firmware 19.17).
Some devices (ZigBee, Z-Wave or LAN) just stop responding (receiving or sending commands).
You can see that the SmartApps (SmartLighting, WebCoRE, etcâŚ) were executed, and in the Device events to commands were sent to the device, but the Device never executed the commands (On, Off. change ColorâŚ). Using the ST App the same device does not respond to any commands. It looks like everything is happening in the Cloud but is not reaching the Hub, or the Hub is not sending the commands to the device.
After a Hub restart everything works like a charm 
iridris
#240
Thereâs a thread on the main SmartThings forum about mode changes being ignored. This is likely a wider issue than just WebCore.