RM5 Help - Notify at $time if doors open/unlocked

[mhl2020]

Hello, I think this should be pretty simple, but I've read Rule 5.1 | Hubitat Documentation and am still having trouble. I want to create a rule like this:

Trigger: 10 PM
Actions: Notify me (push)
Condition: Any doors open (contact sensor), Any locks unlocked

Ideally, the notification would identify the device (i.e., "Front Door is open") but that's not a requirement.

I've tried using a required expression like this:

I just get a notification saying "Triggered: 0 (null) at 11:01" when doors are open/unlocked AND when they are all closed/locked.

So I tried deleting the required expression and using conditions instead like this:

It says the conditions are unused, but I'm not sure how to begin using them. The rule still notifies me with "Triggered: 0 (null) at HH:MM" in all cases, even when devices are open or closed.

Can anyone help me finalize the rule and figure out what I'm doing wrong? Thank you so much.

[hydro311]

For a time-based rule that runs once a day, my opinion is that a Required Expression doesn't bring much to the fight -- there's not much value to gatekeeping a rule like that that just runs once a day.

I'd leave the trigger as-is and then use conditional statements in the rule to achieve the desired notifications.

You created the conditions, but they are currently showing as "unused" because you haven't used them yet in a conditional statement (If-Then) yet within the Actions portion.

This portion of the Documentation discussed building conditions (the link will auto-scroll to the correct spot).

Then this portion of the Documentation discusses how to build conditional statements in Actions.

You may be able to group together "like" things in a Conditional statement to achive the desired notification, or you may need to break them up more.

I'm not the smartest person for managing the variables like %value% etc, so I'd defer to other users's advice for how to structure the actual Notification setup.

[ogiewon]

Here is the simplest way I have found to do it in a single rule. It is a bit brute force, but it is not like I am adding/removing these devices very often.

My Rule Machine example above is for Locks, but you could just as easily use it to monitor the status of door/window contact sensors.

I use the built-in Notifications app to monitor all of the doors in the house, to notify me if any of them have been left open for too long.

[hydro311]

Ha, yes, I too use the brute-force method.

I'm sure I could likely consolidate/streamline my actions more somehow, but hey, it works... My initial attempts to streamline led to inconsistent results for stuff like %device%, %value% etc, and I simply never had enough interest to chase down the operator-error why's behind those misses. So brute-force it is

[jlv]

There's an app that does exactly this, avoiding the need to brute force each sensor in the rule:

[RELEASE] Device Status Announcer (TTS or notification if lock unlocked, door/window open, etc.)

I just wrote a small app for myself to replace a hard-to-edit (if devices change) rule I was previously using and figured I'd share in case anyone else has a use. The basic idea is that you can choose locks, contact sensors, and motion sensors of concern, then choose to get an announcement (TTS) and/or notification either at a specific time or when a switch turns on if any of those devices are in an "undesired" state (lock unlocked, contact open, or motion active). (Placing link to code near t…

[hydro311]

That looks like a nice option - thanks for posting!

I have some needs & caveats for my notifications that aren't available with that, so I'm fine with my admittedly clunky rules -- I very rarely ever need to touch them (and they're even more rarely ever actually used), so any maintenance isn't a hassle for me.

[croweflight]

You have to be more explicit in your action section.
Make a list of simple conditionals one for each device.

if door open: speak your speaker(volume 50: %device% is open)
if lock unlocked: speak your speaker(volume 50: %device% is unlocked)
and so on.

[Johnnyvaneddie]

What does the term "Brute Force" mean. Wondering if I have some rules using that and if it is bad.

[ogiewon]

@Johnnyvaneddie

What does the term "Brute Force" mean.

In the context of this particular conversation, it simply means writing a rule that explicitly checks each sensor, and provides a notification specific to that sensor. Normally, we'd like the rule to monitor a group of sensors and notify us based on which sensor changed. But in the case of checking a bunch of sensors at a specific time of day, that doesn't really work. Thus, we can 'brute force' it as shown below.

[Johnnyvaneddie]

So your other notification rule above is OK or would it be Brute force as well?

[kahn-hubitat]

Or you could use the secure app modufied and ported by me that can check and skert if anythung us open/unlicked etc when your house changes mode or at a specific time after. If that is your ultimate goal.
It slso can alert if things are left open or try to relock doors and alert when all is ok.

[ogiewon]

@Johnnyvaneddie

So your other notification rule above is OK

My other example is not brute force. It is using a more elegant, event driven design to notify when any selected door has been left open for 15 minutes. However, this does not meet the OP's requirement of checking the status of the doors at a specific time of day.

A brute force method of doing this would be to create a periodic polling type of trigger, every 5 minutes. This rule would then look for any sensor that has been 'open' for longer than 15 minutes and then notify the user. This rule would run every 5 minutes 'brute force' looking for an issue. This is very different than a rule that intelligently uses sensor events to determine if/when to notify. Polling every 5 minutes in this example is 'brute force'.

Hopefully that helps. If you have some examples of your own automations that you'd like to know if there is a more elegant/efficient solution, just create a new thread and post a screenshot of your automation. The community will quickly provide feedback and suggestions to help improve things. Event driven programming is a different way of thinking compared to a lot of traditional polling/looping style of programming.