Missed motion events; outage?

[ian_boje]

Hi Guys,

Recently, I’ve noticed some of my motion events are delayed or missed completely. It looks like I can see the events in ST’s logs, but they either aren’t making it webcore, or something else is wrong. I thought it was something I was doing wrong, but then I saw a post on the ST community forum. Are there any issues impacting the performance of webcore over the past few days?

Possibly unrelated: It did seem that there was a complete ST outage about a week ago, and I think that’s when my issues started. The ST outage was confirmed on the smartthings status page.

Thanks

Ian

[chani19]

I am also running into the same issue. Issue started around a week ago. Events happen on ST but doesnt trigger webcore pistons.

[wjames2020]

Same exact issue here. As mentioned, I noticed the issue began after the outage on 19 December.

[ian_boje]

Thanks for the info. Perhaps more information would aid in the troubleshooting. Have you noticed any patterns yet? For me, I think it’s been motion sensor related events. I don’t have a lot of manual switches. Events at specific times of days seem to work fine.

[Dale]

It happened to me tonight. I use a global boolean variable to trigger two different pistons. It has been working fine, but tonight one of the pistons didn’t run. Drives me crazy

[WCmore]

Nobody has posted a visual yet… but two quick observations:

Anytime a single event triggers more than one piston… there is a chance that one of them will not fire properly.

It’s not always possible, but ideally, any event should only execute a single piston.
(which can be as complex as you like)

---

…and the opposite (one trigger per piston) is equally important…

For what it’s worth, motion sensors can be some of the “chattiest” of devices. For reliability, I typically only place one motion sensor trigger in each piston.

If you cram multiple sensors in to the same piston, (especially if spread around in multiple conditional blocks), then this often leads to multiple timers simultaneously counting down… (which can easily cause problems) Not to mention the extra needless processing required at each and every event…

Basically, I try to code so there is never more than one timer in limbo, per piston.

---

The only reason I am mentioning these is because everyone in this thread is a (relatively) new user here.

[ian_boje]

Okay, here’s one that failed yesterday. The logs appear to have expired, so I don’t have them. I’ll try to collect them later.

I do have an ‘alarm’ piston that will also subscribe to the motion event. I’ll try turning that off to see if that makes a difference. If one does need to use the same motion sensor in more than one piston, would it then make sense to setup a global variable or virtual switch and update that with the motion status? I suppose one could trigger multiple pistons from a single piston too.

[Dale]

Anytime a single event triggers more than one piston… there is a chance that one of them will not fire properly.

Oh my, I didn’t know that. I have a boolean global variable @LuxOverThreshold which toggles based on outside illumination readings. Several pistons subscribe to this variable.

I also created boolean @SR_SS which toggles based on sunrise and sunset. Several pistons subscribe to this and also use it in conditions. I figured using the boolean would be more efficient than testing for sunrise and sunset in several pistons.

I need to rethink all this.

[ian_boje]

I made it a point today to walk past all of my motion sensors when leaving for work. It looks like one room stayed lit after I left. This was done after I disabled the alarm plugin.

Here’s some logs from smartthings graph:
2019-12-27 7:05:13.429 AM CST
2 hours ago DEVICE motion inactive Living room Zooz 4-in-1 sensor motion has stopped
2019-12-27 7:05:04.299 AM CST
2 hours ago DEVICE motion active Living room Zooz 4-in-1 sensor detected motion

And the logs from webcore (unfortunately, the trace/debug wasn’t enabled):

12/27/2019, 7:05:04 AM +378ms
+469ms ║Piston waited at a semaphore for 252ms
12/26/2019, 12:55:16 AM +151ms
+2615ms ║Piston waited at a semaphore for 2504ms

Here’s the piston that did this most recently:

The devices in that room aren’t compatible with smartthings, so Alexa watches my virtual motion sensor and turns them off/on based on that. At this time, the virtual motion sensor shows “active”, event though the physical sensor shows inactive.

The motion sensor “in use by” list from graph:

• Home / Living Room Controls (webCoRE Piston)
• Amazon Alexa
• Home / Home (webCoRE Storage)

Some questions I’m asking myself: Is the delay between motion and clear too short? Am I running too many motion sensors in different pistons? I’ve got 2 z-wave, 1 zigbee and 2 Wyze connected via ifttt.

[wjames2020]

Here’s the visual of my code. I basically have the same for multiple rooms and am having the same problem throughout. About 90% of the time everything works, but 10% the motion sensor changes to inactive and that doesn’t register in my piston.

[WCmore]

If one does need to use the same motion sensor in more than one piston, would it then make sense to setup a global variable or virtual switch and update that with the motion status? I suppose one could trigger multiple pistons from a single piston too.

Technically, SmartThings can handle more than one piston executing at one time… but what I have seen time and time again is, the more commotion happening at any one moment, the more likely some command will get lost along the way…

---

By the way, I may code a bit differently, but piston 04tfe looks good as is…

[WCmore]

I have a boolean global … which toggles based on outside illumination readings. Several pistons subscribe to this variable

What I do is, instead of subscribing to the global (and making it a trigger), I simply use IF conditions (effectively removing the lightning bolt in the left margin) to direct the flow of the piston(s).

In other words, if many pistons need to reference the global data, try to program so only ONE executes when it changes. All the other pistons can use conditions to check the global.

---

IE:

• Unlimited pistons can use conditions of a global… but
• Only one piston should be a trigger

[WCmore]

Piston waited at a semaphore

This is often because of more than one trigger per piston. (piston 8w7tp has three)

Moving the motion sensors to their own piston will greatly reduce the semaphore delays.

[ian_boje]

This is often because of more than one trigger per piston. (piston 8w7tp has three)

So, should I have a piston for each condition: Motion, Inactive, manual switch on, manual switch off?

I’ve been tempted to re-write all of my pistons now that I know more about webcore, but I think I still have more to learn. If I do so, I want to do it correctly.

By the way, I may code a bit differently, but piston 04tfe looks good as is…

I saw some using “Motion clear for X”, but didn’t know that was the option when I wrote mine. Is that the biggest difference in your code?

Thanks

[WCmore]

About 90% of the time everything works, but 10% the motion sensor changes to inactive and that doesn’t register in my piston

Piston pihb has ZERO triggers… This means that all of your conditions are treated as triggers. (notice all the lightning bolts in the left margin)

In a nutshell, this piston will run top to bottom, and execute any command not blocked by conditions whenever any of the lightning bolt lines changes to ANYTHING at all.

Your current triggers:

• Location changing to Home
• Location changing to Away
• Location changing to Night
• Location changing to X
• Motion Sensor 2 changing to active
• Motion Sensor 2 changing to inactive
• @BathroomsFreeze changing to false
• @BathroomsFreeze changing to true
• Sun sets
• Sun rises

When any of these 10+ things happens, the piston runs top to bottom.

At the risk of sounding like a broken record, when I want reliability, I try to only use one trigger per piston.

[WCmore]

should I have a piston for each condition: Motion, Inactive, manual switch on, manual switch off?

The following two triggers are actually only one:

• IF MotionA changes to active
• IF MotionA changes to inactive

I put both in the same piston, so only that piston fires when the motion sensor changes.

---

Pro Tip:

If you only use one of them (IF Motion changes to active), the piston will still fire when it changes to inactive. (so it’s better to keep both in the same piston)

[wjames2020]

Thanks WCmore for your help. I adjusted the code as you suggested (See piston snapshot below), but still have the same problem. I tested the piston by activating the motion and letting it turn off after the 3 min delay. On the fourth try, the light stayed on.

The piston log for the unsuccessful try shows:
*12/27/2019, 4:19:50 PM - Received event [Bathroom Motion].motion = active with a delay of 209ms
(It never registers as inactive so the light just stays.)

The previous (successful) log showed both the active and inactive events:
*12/27/2019, 4:14:43 PM - Received event [Bathroom Motion].motion = active with a delay of 243ms
*12/27/2019, 4:15:03 PM - Received event [Bathroom Motion].motion = inactive with a delay of 2898ms

[WCmore]

Your triggers look much better in piston aeyz2!

---

It never registers as inactive so the light just stays

Two things come to mind when the motion sensor is not faithfully reporting itself to the hub:

1. It might be time for a new battery
2. That device may be too far from the hub

Both of these are easy to test and fix.

---

A tougher possibility is you may have loops bogging down your SmartThings hub or heavy downloading / streaming to your home networking, which can essentially, impact your reliability. This one is much tougher to diagnose and resolve.

[ian_boje]

On the fourth try, the light stayed on.

If you check the smartthings graph event logs, do you see the motion clear events? I’m still thinking my issue is that the event isn’t making it to webcore.

[Dale]

Thanks WCmore, I now have one trigger per piston. A couple pistons have one trigger and one timer, I hope that is OK. As a result, I went from 6 pistons to 21 pistons. So far so good, and I have seen no missed triggers. Thanks again.