Missed motion events; outage?

#76

@WCmore, apologies, I thought you were a developer with WebCore. Thank you for your suggestions but I do not believe they apply here. Multiple people reporting the same issues even with virtual switches starting at the same time does not feel like the same old “try to be more efficient” situation.

#77

I am not a dev for webCoRE, but a hard-core user (and programmer) with tens of thousands of pistons under my belt.

Just to clarify, I am not defending SmartThings here, but I was trying to emphasize how our code impacts our entire SmartHome.

IE: When too many things are trying to happen in any one moment, occasionally one (or more) may get lost in all the commotion. I have seen this hundreds of times!

#78

So, @WCmore what would be the recommended best practice if you need to perform different actions based on 3 different states of the same device? Say, I need to get a notification when my garage door changed to open, then a notification when the garage is closed and also a notification in case the garage is open for XX minutes. Would creating 3 different pistons, one for each trigger, help? Currently I have one piston with 2 triggers (changes to open / changes to closed) and another different piston checking “stays open for XX minutes”… Thank you!

#79

All three of these use the same trigger. (specifically: GarageDoor’s contact)
Whenever that contact changes, any piston with those IFs will execute.

Because of this, I would try to put all three in the same piston.
(and then consider it a single trigger piston)

Pro Tip:

“stays open for XX minutes” will trigger when the door opens or closes, but will not do any action until the timer expires.

Because of this, that block can remain separate, if you like.
(just be aware that with this method, 2 pistons fire at each contact change)

#80

Ugh, that’s frustrating. I just split many of my “Switch” pistons that had both “On” and “Off” activities on them because I thought maybe it was the complex pistons that were causing my conditions not to trigger. I had also added two motion sensors to relatively high traffic areas so I was rewriting my logic to pause pistons that utilized triggers on these motion sensors when motion was detected in an area. The piston would then be resumed when motion was detected in another area (and those pistons would be paused and so on). Unfortunately this appears to already not be working as smooth as needed for the same reasons as why I’m exploring it in the first place, because pistons aren’t triggering or having to be run twice.

#81

Me too! I split my stuff into separate pistons because I thought the longer pistons could be the cause of the missed triggers. Weird enough, similar triggers and actions created using the SharpTools rule engine do work and do not miss any trigger…but there I needed to create 3 different rules: open, close and stay open.

I really don’t know. The very same piston structure sometimes works, sometimes doe not. When I see the logs, I simply don’t see the events on a subscribed device. It opens or closes and there is nothing in the log…

#82

Just playing with a switch on and off and keeping an eye at the live log, I notice I am getting this random “time outs” on the execution…

image
image.png1348×509 31.3 KB

This is the piston:

image
image.png1178×805 40.3 KB

#83

I try to avoid using this “double trigger” logic:

IF Something triggers
    Then Turn off Switch 3
END IF

IF Switch 3 changes to off
    Then do stuff
END IF

I avoid this logic because whenever “Something triggers”, it executes a command, that is also a trigger… Thereby starting the piston all over at the top, and going thru the code line by line once again.

This is the root of your “time out”…

#84

The issues don’t seem to be on pistons side - I’m having the same issues described here for ~2 weeks now. And looks to be getting worst…

Simple scene pistons that triggers lights on and off based on a smart switch are not working as they worked for one year without one single failure.

On ST side all events are properly logged.

Looks to be a connection issue between the 2 platforms, not sure.

Any webCoRE developer here that can take a closer look on this?

#85

Do you have stuff working in there now? Is that having the same issues that we’re seeing in webcore? I might consider moving some of my automation over to something else.

#86

No issues there. I do have some stuff running there for testing purposes. Did not give up on WC just yet t:) However, rules in Sharptools are much more limited than in WC, but definitely more flexible vs the native automation capabilities available via the ST apps.

Weird problems happening lately
#87

I guess its “possible” that triggers that worked 100% of the time for over a year (like in my case) could simply stop working 100% of the time due to a change in infrastructure between smartthings and Webcore and our inefficient/poorly written code.

But I think the more likely case is, something happened recently at either smartthings or Webcore that is now causing our code to not function 100% like it used to. There are several of these threads out there written slightly different across smartthings and webcore.

#88

I’ve also been experiencing similar issues with lights not always turning on or off based on motion. Also noticing much more delay and inaccuracy with door sensors. Webcore telling me a door was left opened although the door is closed and logged as such in smartthings.

Definitely something going on but I haven’t looked into it much though.

#89

For everybody who has found this thread recently and may not have read the whole thing, I’m convinced the root cause is a SmartThings issue. They acknowledged as much on this thread:

From the investigation I’ve done on my own, I’m fairly certain that this issue is also the root cause of what @WCmore observed:

Which means that the platform issue has been around for a while and nobody noticed it because it didn’t happen as often as it does now.

Technical details: each webcore piston is a child smartapp on the platform. Therefore, if a piston misses an event, that really means that a smartapp missed an event. It also means that this issue isn’t specific to webcore – it should affect anything running on the SmartThings platform. In fact, people on the linked thread have seen the same issue with other smartapps and even the native automation.

#90

update…

:slight_smile:

Webcore has stopped reacting/responding to smartthings switches following hub reboot
#91

i was coming here to post the same thing… :slight_smile: Here’s hoping the issues are resolved!

#92

I reset the counters on my test pistons (counts simulated motion events). This morning, it looks like no events were missed. To me, this appears to be resolved.

I’d like to thank @dds82 for finding the error and getting it to Smartthings support I didn’t have the same luck with support.

#93

I’m beginning to see this problem again, primarily with one sensor (that I’ve noticed at least). I’d post the logs but there isn’t much to glean from them–event in ST, nothing in WebCore.

#94

I had quite a few dark rooms last night, but went to bed instead of troubleshooting. It seemed fine this morning. To me, I thought I was having internet/connectivity issues as nobody else posted comments about trouble.

Is it working for you today? If not, I might start up my testing pistons to see if events are disappearing.

#95

https://status.smartthings.com/incidents/kk66yzj27q1m


Issues with Device Control

Resolved - All services have fully recovered and users will no longer see issues with device control, creating locations in the new SmartThings app, or loading the SmartThings Classic app and web interface. Please contact us via support.smartthings.com if you have any questions.
Jan 13, 23:49 EST

Update - Users may also experience issues creating locations in the new SmartThings app, as well as issues loading the SmartThings Classic app and web interface. We continue to investigate.
Jan 13, 23:27 EST

Investigating - Some users in the Americas may be experiencing issues with delays or intermittent failures in device control from the mobile app and automations. We are currently investigating and will provide updates as available.
Jan 13, 21:30 EST