Pistons have stopped working! [daylight savings time issues]

fixed

#222

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.


#223

I’m on the latest version, (v0.2.0fe).
As for the logs, I didn’t enable logging level for that piston.


#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.


#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


#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.


#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


#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.


#229

Go into the webcore app (within the ST app), select settings and then ‘Clean up and rebuild data cache’.


#230

That fixed it!
Thank you Robin!!!
Dashboard is now humming a happy tune!


#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.


#232

Any logs?


#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:


#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.


#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.


#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.


#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)


#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):


#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 :frowning:


#240

There’s a thread on the main SmartThings forum about mode changes being ignored. This is likely a wider issue than just WebCore.


#241

You described perfectly the issue I got and that bothers me tremendously!