Wait for event - Expected behavior or bug?

I have my Arlo cameras integrated into HE via SmartThings and hubconnect. The cameras are used as motion sensors. All the video stuff is handled in the Arlo app. I use HE to monitor motion and after so many events on one camera I notify and then turn the camera off for a set period of time to help save battery life.

This has worked great for sometime, but recently I am getting double triggers from the cameras. The double trigger is not a HE problem, not sure why this started, probably something on the ST side.

My rule to save battery gets activated on a camera motion sensor active event. I can handle a double trigger here by using a wait for event elapsed time. If I get a double active trigger the wait takes care of it.

The problem arises after I get my preset number of recordings. I then use a WAIT for event motion inactive(the trigger for the rule is active only) and then turn off the camera. When the camera goes inactive I will again get a double inactive event. In the event log for the device the events will be less than 100ms apart.

Below is an example of an active event occurring twice. It is similar for an inactive event. In the event log they show a time of 8:16:21.124 and .200 respectively. In the HE log it shows both occurring at 8:16:21.369. This I handle with the wait for event elapsed time. I see two triggers in the log and two waits but once the wait is complete, the actions after the wait only execute once.

All actions after the wait for inactive event will show running twice in the logs. They are in fact running twice because one of the actions is to send me a notification via pushover that the camera has been disabled. I get two notifications. Other than the double notification it does work.

This section of the log shows what happens after the wait for event with a double trigger event. It shows a wait over for the trigger event occurring at 9:53:35.291 and again at 9:53:35.299

The device event log shows them occurring at 9:53:35.017 and .043

It seems the first event should continue the rule and the second should be ignored. I assume this must be due to the short time difference between them?

I hope all that is clear.

Sounds like a race condition, where the second trigger happens before the first one has cancelled the wait subscriptions. You need to introduce a mechanism to debounce those triggers. There is a sample app in our GitHub public repo that does that for contact sensors.

1 Like