Is webCoRE slow this morning (16 September, 2019)?


#12

https://graph.api.smartthings.com/

Experiencing same issues here.


#13

https://graph-na02-useast1.api.smartthings.com/


#14

Slow for me too. My pistons aren’t executing in a timely manner.


#15

I’m on https://graph.api.smartthings.com/


#16

https://graph.api.smartthings.com/


#17

https://graph.api.smartthings.com/


Conditions evaluating incorrectly
#18

https://graph.api.smartthings.com/


#19

I’m also seeing Piston waited at a semaphore for 7511ms for one contact check but not others that do the same exact thing. Most are on 9/16 but I had one on 9/14 as well.


#20

I’m not sure if this is related but I’m hoping it is.

https://status.smartthings.com/

Investigating - Starting around 6 a.m. ET, users may have started experiencing issues adding Hubs and devices via the SmartThings app. Users may also see issues with control and status updates in certain parts of the app, including but not limited to device groups, SmartThings Home Monitor, and other monitoring automations. We are currently investigating and will provide updates as they are available.
Sep 17, 12:53 EDT


#21

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.


#22

Not sure if this will help or not but there is a hotfix going out on Wednesday…


#23

We can only hope! :wink:


#24

https://graph-na04-useast2.api.smartthings.com/


#25

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

Hopefully that update fixes it, number of notification based pistons are really degrading the WAF right now!


#27

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)


#28

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.


#29

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.

Anybody?


#30

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.


#31

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.