[2.2.4.158 C7] Need a way to detect/act on wait timeouts

Somehow, the HE Hub, HSM, and Ring Hubs all got into a serious tangle tonight (all times are "pm") when I came back from the store (the house was "armed away" for HSM and Ring).

I unlocked my garage door at 8:52:39 and that event showed my proper name as the "unlocking" person. My "Unlocked from Outside Door" rule saw that and fired at 8:52:40.

There were several other door "unlock" events generated:

I opened my garage "inside" door at 8:52 (according to Ring). The HE Hub saw the Ring Door Sensor open at 8:52:51 (via the Ring App). And, looking back at the "unlock" events, you'll see the lock was still throwing "unlock" events after I entered--that's odd.

But, the root of the problem: the sensor thought I opened, entered, and closed the door within 0.6 sec (it showed the closed event at 8:52:51 as well, "51.161" for the open, "51.784" for the door close).

The improperly too rapid "open/close" events hosed up my rule:

("ArmedNight" is a local Boolean variable)

I have a "Wait for condition" on the door sensor showing open. I wait 1 sec after that and then check the sensor status (see: Odd Bug with Wait for the reason I did that--there was a RM race condition).

The reason is that I am needing to detect the difference between the Wait for Condition being true (i.e., I really opened the door) and it timing out (I unlocked the door and never opened it).

Because of the mentioned "race" condition, I had to put a 1 sec delay in the rule to workaround that race condition--and it has generally seemed to let the sensor state be properly updated. In "real life", there's NO WAY I'm opening the door, entering, and closing it in under a second (and, Clark Kent doesn't live here either! :slight_smile: ).

At this point, due to the odd timing issues, my rule has decided that I never opened the door and proceeds to button up the house again by locking the door and NOT disarming.

@bravenel @gopher.ny:

All in all, I think the root of the issue is that there's no way I know of to safely detect when a "Wait for condition" (or "wait for event") times out--and that is BADLY needed.

If nothing else, some special "system" Boolean variable could be set/cleared to reflect the whether or not the last "wait" timed out.

The rest is TL;DR--but might be good for a laugh or pity. lol (thank heavens, I have no wife/spouse, or my WAF would be in the tank!!).

Note that things continued to really go down hill after this. I waited until 15-20 seconds before my "entry delay" time ran out to go to the Ring Keypad (on my Ring Hub) and manually disarm the system.

For reasons unknown to me, the RING stuff wasn't working well either. When I entered the code and pressed "disarm", the Ring system totally failed to respond--for a significant amount of time. I repeated the disarm 2-3 times and the keypad didn't register.

This pushed the disarm event out until after the "entry delay" expired for both the Ring system AND the HE HSM.

At that point, the HE Hub rules I wrote went into full alarm mode--all the lights came on, it triggered alarms wailing, everything.

And, the Ring alarm went off too. The monitoring service called me (but, by then, the disarm HAD registered--thankfully, no cops got involved).

However--all the sirens were still screaming. I think some of that was because the HSM and alarm rules hadn't caught up.

As you can see, the HE HSM got the disarm event triggered at 8:54:03--which was about 12 sec after the alarms were all set off by the end of the entry delay.

I tried doing an arm then disarm to force some rules to run and clear out the HSM's settings, but that didn't work well either (you can see those at 9:02:16 and 9:02:24).

I suppose that the rapid arm/disarm events had so many rules running at once (that weren't meant to run so quickly) that it caused my "Ring<>HSM" sync rule to arm HSM in "armedHome" mode.

And, it just got worse from there.

I ended up pulling the power & battery from the Ring hub to reset it. After it came back on, I think the HE Hub had rules (or the HSM) that re-triggered all the Ring Devices to alarm (thru the User Ring app).

And, although the dashboard looked like the HSM was disarmed, every alarm in the house was still wailing.

I then rebooted the hub--and that took several minutes it seemed. Somewhere about then, I got into the Ring Phone app and started trying to manually clear the alarms I could (but, a few didn't seem to have "silence/clear" options).

Somewhere about 2/3rds of the way through the reboot/restart process, the HE Hub finally reset all the alarms that I had connected to the HE Hub. and there was finally peace in the house.

I think I need to create some sort of rule to do what it takes to make everything STFU--so I can have some peace and quiet while I try to get things back in order when they get all hosed up.

Geez.

We'll add this. The information is already there, as you can see in the logs. It just needs to be put into %device% or %value%, so that it becomes accessible to the rule to be tested.

2 Likes

It looks as though Wait for Events/Condition never touched setting %device%, %value%, etc. I think it probably should.

So for your situation, you'd be able to lose that second test, and replace it with this, assuming you have a local variable called Timeout

Set Timeout to %device%
IF (Timeout = 'timeout') THEN
    xxxxx
ELSE
    yyyyy
ENDIF

Check out these logs from my testing, both with an event and a timeout:

From this rule:

I'm a bit confused.

Is that a future release change--or is there something that will work right now?

I assume the "Wait" would go between the set and the If?

This is current development work, for next release. What I showed would be after the Wait.

2 Likes

There's a Where's Waldo test in what I posted above, one that shows a significant upcoming change to RM.

Who can spot it?!

A month ago I asked exactly this and you told me it was impossible. I'm so glad you're adding this!

Ha, that's not really what I said, and that was true until I started working on it today. It's still true until next release. :sunglasses:

3 Likes

This is making me very curious... I see ‘Timeout’ in red instead of the usual (F)... that would be nice if that’s part the upcoming change!

Is there a prize to who guesses right? :stuck_out_tongue_winking_eye:

Ha, no, that's just Discourse (this forum software) coloring text entered as code.

The prize is the satisfaction that comes with the discovery!

1 Like

The wording “Wait for conditions: a omni sensor inactive” in the rule… doesn’t refer to any specific one. And conditions is plural. Is that a new way to select several devices at once?

There's Waldo!

Current version says "Wait for Condition". Next version will support full logical expression just like IF (conditions) THEN...

4 Likes

Does that mean the RM will bump up a version?

What will we need to do to take advantage of the new syntax (iow, convert from the current version to the new one)?

Thx!

Yes, good catch. It will be Rule-4.1. As always, existing Rule-4.0 rules will go on working, can be edited, etc. New rules will be 4.1. There would be no reason at all to replace 4.0 rules with 4.1 rules. 4.0 rules will have Wait for Condition, while 4.1 will have Wait for Conditions.

We will still fix bugs found in 4.0 for quite some time, as whatever it is would also affect 4.1.

1 Like

So, if I need to take advantage of the "wait for conditionS" function, is there any process to convert a rule?

Or, do you have to build it totally from scratch (I assume this)?

I guess my bigger question is related to the %device% variable and if that will be surfaced in the existing RM version?

There is no mechanism to convert a rule from one version to another.

In which context?

Will I need to create new rules to use the "timeout test" function you're adding or will that part be put into the existing RM version as well?

That will be in 4.0 and 4.1.

1 Like