Mimicking the HSM sensor check


#1

The short version of this is: Can a RuleMachine rule be created that mimics the arming pre-check (described in this thread) and which can send or speak a notification that identifies the specific "open/unlocked" device?

I created a simple Triggered Rule that checks the window and door sensors in the house, in effect so that I can check whether or not the HSM will actually arm the house before I leave the geofence that triggers Away mode. (It's annoying to get to the edge of a geofence on foot, only to find that the house couldn't arm itself!)

So I created a rule that mimics the routines that HSM executes when arming the house, so that I can find out if my house isn't going to be secured before I'm blocks away:

[Library Window, Front Door, Basement Outside Door, Garage Door, Server room window, Kitchen door to deck] any open

When there are any open sensors, I get sent PushOver notification ("The house is not secure. The %device% is %value%.")

The app is triggered by a Virtual Momentary button ("Security check"), pushed either on a dashboard, or by voice command to Alexa.

When I run it with one of the doors open, however, I get the notification

"The house is not secure. The Security Check is on."

Because of course! The device triggering the event is the Security Check button, so %device% is being interpreted as referring to the trigger button, rather than the offending door sensor.

I thought maybe I'd have to create a set of individual Rule-only Rules ("front door open","back door open") each of which has its own

PushOver: %device% is %value%

statement in the Select Actions for False section. So I did that, and then I created a simple Trigger-only Rule that would run each of the Rule-only Rules. But again, because the trigger is the "event device" I guess, my PushOver messages always say "Security Check" instead of the failing device.

Essentially, I'm roughly mimicking the Rule shown here, but you'll notice that the notification there can only muster "Front door closed or other door open."

Is it possible that there is an expanded placeholder vocabulary that has something like %target% or something? Or that %device% could somehow adopt a contextual meaning that allows it to do double-duty?

Even easier, maybe — could HSM simply segment the existing pre-arming check as a callable event by itself?


#2

The reason for that is because the device that the rule will use is the one that triggered the event, not the one in the evaluation of the rule down below.

The ultimate way to resolve this is to add a restriction list to the Arming Error in HSM. That way, it would only check those Contact Sensors that you designate before arming.


#3

Thanks Ryan, I understood that, and I already have a proper routine in place for when I'm arming the house. The point is that I'm trying to mimic that routine outside of the context of arming the house. Basically, it's the equivalent of running a "test" arming of the house, but without arming it. It seems like all of the pieces we'd need are in HSM already, we just can't call them directly.

As for the %device% placeholder, I get that it is always populated by the device that called the event, but if Rule Machine is evaluating a series of "conditions" that that have a truth "state", it seems like you could have something like %condition% and %state% placeholders available. Though I can see that incredibly complex rules would have a potentially prohibitively long %condition% string, e.g.

[Security check] reports that [It's Tuesday and mode is Evening and the dining room temperature is not above 75º and (Bob is sad and not lux < 40 in the living room) and the entry window is open] is [true] and so I cannot arm the house.

but still...it seems like we do have all the information necessary to do that, no?


#4

I am using @bptworld's Snapshot to do something similar. Bryan added the ability to check for things that were not in the correct state and display just those things. Perhaps he could add the ability to "speak" those things that were outside of spec,


#5

If you are interested in a custom app, I have one called ‘check open contacts’
This will check open contacts and speak any open but also turn a switch on/off if there are none.

Http://hubitat.uk

Andy


#6

Andy, at least in my situation, I wanted something to look at what state something should be in rather than just whether it was open or closed. If at a given time something should be open but was closed, that would be something that was not in the proper state and needed to be flagged. Same with a switch that needed to be on not off. I don't remember if Snapshot has thermostats or locks or any device that has a "state" that could be evaluated and required for a situation.


#7

Andy, your app sounds like it might just do the trick, and I'll check it out. Just a little surprised that it requires a custom solution!

I do think it's cool that there's a whole Cobra ecosystem growing in the Hubitat wilderness. I appreciate your work!


#8

I was looking for something similar inside HSM, but actually isn't there, so for now I'm using Cobra Check Open Contacts as suggested.

@Cobra I've sent you a PR on Github for Open Contacts to trigger it on HSM Status change, so it can be used as automatic HSM sensor check


#9

Snapshot does something very similar to this! Using both speech and/or pushover.

Done :wink:

Snapshot handles devices, contacts, locks, temps and soon will have presence.


#10

Thanks for your PR.
I’ll have a look at your code and update accordingly.

Andy