Delay notifications for contact sensor

I'm hoping someone can help me write a RM rule for a contact sensor.
The sensor is being used on a food container to log, remind and notify of our many animals' feedings.
Currently only one, but would like to implement more if the system works.

If the sensor is opened it turns on a virtual switch for that animal
If the sensor is opened and the virtual switch is already on, then it sends a notification over Pushover and TTS that the feeding has already occurred (I have another rule for the virtual switches to reset over a given timeframe to account for different feedings)
If the specified time for a feed happens and the virtual switch is off, then a reminder is sent for that too.

I'm trying to avoid the misfiring of notifications when the container is opened and the sensor sends open/close/open, as the lid is raised.
Currently expressed as: (Trigger) Sensor open -> IF virtual switch ON, then notify.
I'd like to include something like: IF virtual switch ON AND sensor has been opened in last 15 seconds, then cancel.

Is this possible in RM?
Am I better off creating another virtual switch or motion sensor with a 15 second delay before auto-off?

I've tried searching, but don't know how to express what I need here.
Thanks in advance.

First, if you don't have your heart set on Rule Machine, it sounds like Simple Automation Rules would work for you. The two key features that should help you make it work are the "only once within this many minutes" option (technically can't do 15 seconds, but would 1 minute be good enough?) and the "Restrictions" section, which can be used to not send a notification based on a specific switch state. This would probably be easier than using a Rule.

However, if you wanted to use Rule Machine, I think using something like Private Boolean (or really any variable, but this is built-in) to track whether the sensor has been opened recently should work. For example:

Trigger: Sensor opened


Cancel Delayed Actions
IF (Private Boolean is True) THEN
  Set Private Boolean False
  IF (Virtual Switch on) Notify: "The thing!"
Set Private Boolean True --> delayed 0:00:15 (cancelable)

(I used a simple conditional, which displays as only IF, for the notification since you're only checking a single condition and performing a single action. If you want more--or even if you don't--you could also expand that into a "full" conditional, using IF THEN and END-IF).

1 Like

Thanks for the response.
Simple Automations, although I'm sure its a more suitable place for some of my rules, I couldn't find a way to make it happen.

I couldn't find this. Only the option to turn off after x minutes - this isn't ideal, as I want the virtual switch to stay on for the remainder of that feeding period.

RM seems like the way to go, but I haven't worked with booleans before. I just did a little bit of research and I don't even entirely understand your sample rule.
I tried it though, and it activates the switch, but there is no notification after 15 seconds.

Sorry, I said "Simple Automation Rules" but meant "Notifications"! Here is what I was thinking there:

"Only once within this number of minutes" option in Notifications app

Besides this, also check out the "Restrictions" section. (You may still need SAR if you want to use a switch and don't want to manipulate its state with a rule, but if you've already got that part figured out, then no need.)

But back to the rule, off the top of my head I don't see any reason why that wouldn't work. Since you appear to be using an Echo Dot, my first thought is that maybe TTS isn't working on that device. You could try using a log or a push notification or something more reliable just to test. To really help you see what's going on, you could also turn on (at least) "Actions" logging for the rule, then watch the logs during or after to see what it's doing when.

Here's a brief explanation of the rule: it uses Private Boolean (PB) to track whether the sensor has opened recently. The default value of PB is true, and that's also what this rule resets it to after 15 seconds. During the 15 seconds after the sensor opens, however, it sets PB to false and speaks the notification, only if it's not already false. After 15 seconds it should again be true. The "cancelable" and "Cancel Delayed Actions" are there to rest this so it only rests to true after the most recent opening if multiple ones happen within 15 seconds, though if that's not a problem you care about you could remove both of those options/actions.

1 Like

Thank you.
Thee SAR/Notifications method seems okay apart from the "Only once within this number of minutes part" - ideally, I want it to be: Don't notify at all (none times within x minutes), unless the virtual switch is ON - but that ON state must have changed at least x minutes ago.

The restrictions covers switch ON part. But I don't want the notification at all, unless the switch is already ON prior to opening.
Because a fumble with the container could lead to the sensor reporting ON-OFF-ON in the space of 2 seconds. Therefore the restriction stopping the multiple notifications due to switch state is not effective, as the switch state changed as a result of the first sensor trigger, the second sensor trigger fires the notification. When in reality, the animal had not been fed yet.

I guess a simpler way to put this, is that the opening of the sensor would ideally not trigger the ON state of the switch more than once per x minutes. Or the sensor event that triggers the notification has to wait x minutes before doing so.

Can a sensor be silenced to prevent double trigger?

The Notifications app was just an idea, something I'd recommend if it works, but it probably won't work (at least not easily) here. Was there any problem with the rule above? You can't silence device events (at least not without a custom driver and doing something there, but that's not the right place in my opinion). What you can do is choose if or how an app or rule resonds, which I tried to do in the rule above. Logging may help if you want to see what it thinks it's doing when.

I didn't get a chance to get back to RM, but will try that tonight and let you know how I go.
Thanks again :slight_smile:

Apologies for my delay here, I haven't had a chance to test this out again until now. I appreciate you helping me through this.

The notifications weren't consistent, but I'm doing my best to understand the logic of it first, but quite confused by the boolean thing still.
I'm struggling to apply a real-world reference to the booleans in this use case. I think I understand the logic, just not the application.

The following two scenarios have made the troubleshooting difficult without this knowledge, but I have since concluded the following truths:

-The notification does not fire when the virtual switch is ON (animal already fed), and the boolean is FALSE - this first IF statement seems like it should be a prerequisite condition, rather than an option, because without it, I don't get a notification. But perhaps that is what your intentions are here.


-The notification does fire when the virtual switch is OFF and the boolean is TRUE, although it does appear to prevent repeats of the notification during the delayed timeframe.

This part threw me specifically. I don't want the notification to speak unless the virtual switch is already on. The "sets PB to false" and "already false" aren't clear to me, as I don't know how that applies. ie. Why would the boolean be false? When the rule isn't true? So if the virtual switch is OFF, then the rule/boolean is FALSE, so there should be notification? Then why do we want it to notify if FALSE.

Sorry if this comes across the wrong way, I'm not picking at your advice, I'm just trying to understand it so I can be self-sufficient in the future.
Many thanks!

No problem! Maybe we should start with the Private Boolean. I'm not sure if you have any programming experience, but if not, a Boolean variable is simply one that can be one of two values, true or false, so it's useful for tracking binary states--in this case, "has this happened in the last 15 seconds?". In Rule Machine, each Rule gets a built-in "Private Boolean" variable (it's nothing you couldn't also track with a local or global variable or even yet another virtual switch), which defaults to true. So that's how it should be to start, and it's also what I'm resetting it to, with a delay (to prevent repeated notifications in the meantime), when done. As a prerequisite to doing the notification, I'm checking to see if it's true. If it's not, that means we've already set it false, as we've started the notification sequence, where setting it false is the first step within there. (Now that I'm looking at this again, maybe you'd want to put that "Set Private Boolean False" inside the "IF (Dog is on) THEN" block? My impression is that it shouldn't matter much and it will all be reset after a few seconds anyway, but perhaps you have a reason to prefer one or the other.)

This really looks like it should work to me, but perhaps I'm missing something. In your screenshot #1, if PB is false, that means the sensor was opened recently (5 seconds in your example). It is my understanding that you don't want a notification in that case, regardless of whether the "Dog" switch is on or off, since you're within that "cooldown" period. Consistent with this, the rule will skip everything in that innermost IF since it doesn't matter. PB should get reset to true shortly thereafter; if not, there's another problem. In screenshot #2, PB is true (so the sensor hasn't been opened recently), but the "Dog" switch is off. It is my understanding that you don't want a notification in that case. In both cases, I see the rules working as expected.

I might be missing or misunderstanding something, so feel free to switch the conditions you're testing to do what makes sense for you! Hopefully this at least helps explain what I was thinking.

PS - I should mention that you could also keep this a bit simpler and use two different rules: one that sets PB on the other rule (you can set PB on one rule from another, though you could also use a global variable or another virtual switch), and then...the "other" rule that's basically what you have now but with only the checks instead of the "set"s for the PB (or whatever you use to track that particular status).

Thanks again, that did clarify some things for me. I have some programming experience, but not extensive.

This bit alone helped. So, the PB is basically "trigger happened? true/false - default to true" - thats cool, most of the info I've found about booleans talks about the rule being true, not the trigger. Gotcha.

Correct that I don't want a notification if the sensor was opened in the last 5 seconds, but I do want one if the switch was already ON prior to the rule triggering, outside of this timeframe.

As above, I don't want a re-trigger alert, but I do want a this switch was already on alert. This would signify that said animal has already been fed.

Perhaps this is related to the PB being False? Because the statement: "IF switch is ON, then Notify" is fairly simple, and is what I used initially.
This screenshot was taken a few minutes after the sensor was last opened, so was not triggered/opened recently. Wierdly, it appears that sometimes this PB does not reset to TRUE - perhaps something else causing this? Remove the cancelable?
Sometimes hitting 'update this rule' in RM updates the PB value, sometimes not.

You understand correctly that I don't want a notification in this scenario, although in this example, I do receive one. This works in eliminating re-triggers, but for some reason, still gives the notification.
I thought it was clearer above, but I may have missed it - I have a Simple Automation Rule to turn this virtual switch on when the sensor is opened. This rule is obviously turning the switch on before this rule can process it, so although it was OFF when I opened the sensor, by the time the rule got to the IF statement, the switch was ON, so it notifies - correct?

Right now, I haven't touched the sensor in a few hours, PB is TRUE and switch is OFF, so this is when I would not want a notification, but I got one. I'm guessing because my last assumption is true.

Global variables (?), multiple switches.. Nah lets just get through this one first!

In Rule 4.0 (not sure what version of docs you were reading), rules do not have truth values: they are just triggers (events that will make your rule run) and actions (the parts of the rule that can send commands to devices and whatnot). Private Boolean is also nothing unless you make it something (this again was a bit different before, but now it's just a built-in variable you get for free and can use or not use as you see fit). So it's not necessarily that, but in this case, that is what I'm trying to make it. :slight_smile:

Technically, my rule won't account for this, but if you don't mind that the second opening within 5 seconds won't cause the notification, it may be simpler to ignore if I'm not thinking about this problem wrong: you'll just have received the notification 5 seconds (or less) ago, and after 5 seconds, you'll be eligible to get another--just not two within 5 seconds of successive openings.

A couple things: if you're doing a lot of testing and happen to click "Done" or "Update Rule" while waiting for PB to be reset to true, it won't happen--that scheduled job gets cleared either time you do either of those actions. So just waiting should work, barring catastrophic events like a loss of power to the hub. Second, the green/orange "status" of conditions in RM will not dynamically update; they'll be read only when the page is loaded. So, a refresh (or going out and back in) would be one way to view current informatino. Not sure if either of those could explain what was happening here.

You certainly could remove the "Cancel Delayed Actions" action and the "cancelable" option on the delay. These work together to effectively reset the 5-second timeout should the sensor be re-opened within the 5-second countdown (otherwise, you'll still be counting based on the first opening...and technically again on all openings thereafter), but with such a short interval, perhaps you're unlikely to care about this distinction. It shouldn't inherently solve any problems, however.

A technical note: triggers always fire if an event that happens matches a trigger (you do have some control over exactly what events match the trigger, like "opened," "closed," or "changed"--which would cover either state--in your case, but something like "but not within the last 5 seconds" isn't one of those things). You can use conditional actions to not do (or to do) certain things based on whatever you're evaluating. That's what I'm using PB for.

This shouldn't have happened. The states should be as your screenshot "2" above:

Rule screenshot with PB true and virtual switch on

The notification will not happen because the IF (Dog is on) conditional evaluates to false, and this the "Speak..." action inside is skipped. For the next 5 seconds, you also won't get any notifications at all regardless of the switch state because PB will be set to false, so that outer IF, the IF (Private Boolean is true), will also evaluate to false, skipping everything inside, which is all actions except the delayed "Set Private Boolean True" that should reset PB back to True after 5 seconds.

If this is not what you saw, turning on logging for the rule ("Triggers" and "Actions" might be the most helpful) may help you see what is going on--what's running when and what's being skipped (e.g., inside a conditional that isn't true). Or again, maybe my logic is off somewhere and maybe the explanation of what I think is happening will help you figure out what should actually happen to get it to work how you want. :slight_smile:

Okay I think I've got it. I just want to clear up a couple of things first, so we're both on the same page. I started typing these responses before I figured it out, so technically irrelevant now, but it may help others.
Not interested? TL/DR? Go to the bottom of this comment for solution.

Is there a way to ignore the first notification with a rule? Ignoring with my head is possible, but is not a whole lot different from just ignoring the re-trigger from fumbling with the container, thus making the rule redundant. I want to make it fool-proof for the wife/kids as well - if they hear any notification, they will take it as truth.

Thanks. Good advice there

Agreed. It appears as though the contact opening triggered twice? I tested again as per screenshot 2 above, opened the sensor once, and it is still open now. As you can see from the logs, it didn't speak the second notification, but it did the first.
I assume the reason for notifying is because, although the virtual switch was OFF when the rule was triggered, by the time the rule processed the speak logic, that virtual switch (Dog) was ON? Does that make sense, or is it even possible? I may be overthinking it. EDIT: I think I am, because I prevented a similar case in my solution.

I'm thinking that having a second virtual switch or rule, like you suggested (apologies for dismissing it earlier - I think I felt like it was complicating things), or a motion sensor with a 5-second reset that signifies "contact open in last 5 seconds" may be an easier way of making this happen. I'll do some experimenting and report back.

Note: I've changed some of the device names times through testing, but I'm sure the logic is there still:

UPDATE (Solution):

Simply put, I delayed the turning ON of the virtual switch, and used a virtual motion with timeout, instead of PB, to set the status of whether the sensor was opened recently or not.

I have again changed the names of the devices, in an effort to simplify, so hopefully it doesn't confuse things.
Dog's Food = Contact open/close Sensor on food container
Dog Feeding Status = virtual switch that displays ON when feeding has occured within given time (hours), and defaults to OFF with Simple Automation Rule, twice daily
Dog Food Opened Recent = Virtual Motion with Switch driver by @cwwilson08, that I already had installed for other purposes. This triggers an ON state when active, and defaults to OFF after 12 seconds.

RM Rule 1:
I have delayed the virtual switch ON to 12 seconds, to align with the virtual motion default time-out. The 12 second delay prevents any notification from opening the sensor, or any subsequent fumbling/re-trigger, within the first 12 seconds that the container is considered OPEN.

RM Rule 2:
Simply to notify only if the sensor was opened > 12 seconds ago prior to the rule triggering AND IF the animal has already been fed.
If the sensor was opened in the last 12 seconds, or the animal was not previously fed, then no notification.

There is a potential here where the animal was fed recently, but the sensor was opened in the last 12 seconds, I won't get the notification. However, in this scenario I'm sure there would have been a notification at the time that the sensor was opened previously. Not an issue that I can foresee.

Again, thanks for all your help @bertabcd1234. Shame I couldn't get it to work with booleans, but this is much simpler for my use case I think. Maybe I can get booleans to work with future rules.
It doesn't seem right to have 2 rules with the same trigger, but given the delays, it seems to work. Also, this appears to be a huge programming task for just one animal, but as in the OP, we are running a small sanctuary here, so if successful, this will save A LOT of questioning each other and manual logs.
Feel free to point out any potential points of failure, should you see them! :slight_smile: