Anything is possible but the events we’ve been discussing here started well before 06:00 today. But, who knows how long it takes stuff like this to bubble up.
Not sure if this will help or not but there is a hotfix going out on Wednesday…
We can only hope!
Thanks all, this seems to be a system-wide issue. Please report back if there are still problems once that ST status page shows the problem resolved.
Inconsistent execution of multi contacts to change thermostat program
Hopefully that update fixes it, number of notification based pistons are really degrading the WAF right now!
I’m still getting TimeoutException on and off… this one is for a fuel stream temp logger.
1:31:35 PM: error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds: 711843377918464 @line -1 (error)
I’ve narrowed down my issues to a piston changing the state of a device (on/off) and the piston that acts on that trigger having issues evaluating the state.
Normally I turn a virtual device on/off by calling the URL of a piston that turns the device on or off (from a shell script on another computer). If I turn the switch on or off with another method (home remote or a python script) I seem to have more reliability with the piston triggering by that state change and evaluating the state.
Me too. Same error messages both before and after the firmware update. Rebooted the hub too. So, the firmware didn’t fix my particular issues.
I’m going to throw out a couple of things to see if anything resonates with anyone:
- I think the pistons I’m having issues with all have Virtual Switches as part of the command flow
- It appears that my problems became obvious the same day that Echo Speaks 3 came out and I installed it. I doubt this is it, but again, seeing what sticks.
I am curious if these are “Virtual Switches” or “Simulated Switches”.
(they use different Device Handlers)
I’m also interested in whether they were created in the IDE or created from a third party app.
Some of them are Virtual and others are Simulated. Same with IDE-created vs 3rd Party app - some of each.
I will also say that when I flip the virtual or simulated switches in the ST app, the results are somewhat better than when I activate the switches via Alexa or Action Tiles. To me, that points to the later activations adding a bit more overhead to the piston activations and flows and pushing us off the cliff regarding timeouts.
Hmmm. Let me think about that for a bit.
I’m not affected by the firmware as I have a grandpa hub
Don’t think too hard about it, still pretty inconsistent. I’ve got something working now that seems to be reliable.
Before, the trigger was “Switch turned ON”
Now the Trigger is “Switch” changes, then I add a 5 sec wait before I evaluate the switch (On/Off) and then execute the appropriate routine.
I’m on a V2 hub. If that’s not Grandpa, then I guess it’s a Dad hub.
There may be some validity to this…
I have not noticed a single slow down in my SmartHome… but then again, I never check the status of a
condition immediately after that same device was acting as a
On the occasions where I do check, it is always later in the code, after at least a second has passed.
Perhaps 5ms is not enough time for the new state to be stored and able to be referenced.
I have a pretty basic piston.
If presense changes to Present, then:
- If brightness ____ turn on _____. Else, if brightness ____ turn off ______. <----- Executes fine
- If time ____ then turn on ______. <-------- Executes fine
- Run “I’m Back” <----- Not running
Consistantly for the last 3 days this happens and the same piston being used for years. No updates to any code (Webcore or ST) for over 3 weeks. I just changed from synchronous to asynchronous to see if that helps.
Issue persists since the Firmware upgrade to 9.
FWIW, this was one of the first pistons I wrote years ago and haven’t touched it since. So, something indeed changed, but such is cloud computing.
I agree. Something has changed and it’s not our Pistons.