Setting Private Boolean in RM-4.0 not working correctly with SmartThings Sensor

I am attempting to use a Samsung SmartThings Multipurpose Sensor as my mailbox notifier using the accelerometer as a trigger

There is no issue creating a basic rule in RM4 whereby an acceleration event from the sensor triggers the rule action sending a notification to my phone:

However, where I am running into problems is when I attempt rate limiting notifications using a Private Boolean:

What appears to go wrong is that the Set Private Boolean True --> delayed: 0:10:00 action never seems to change the Private Boolean back to True after its delay. I have checked the logs and the sensor works every time there is movement. I even tried this rule using the sensor's contact sensor instead of acceleration with the same result. Is this a bug? I have essentially the same rule for my back kitchen door notification rule using a generic contact sensor and it's never had the issue this SmartThings sensor is experiencing leading me to believe it has something to do with the SmartThings sensor or driver.

Could be because the condition is re-evaluated after 10 minutes and it fails. Here is my mailbox rule where I notify a few neighbors too given our delivery time is so unpredictable. I also have a virtual presence sensor get flagged when mail arrives and departs when it’s picked up since my kids sometimes get it before I do. I just check my dashboard to know whether it’s been picked up or not. So far this has been working great.

What is the behavior you're seeing versus what you expect? The default state of Private Boolean is False, so I'd recommend flipping your truth values around to get something like this instead so you know it starts the "right" (un-restricted) way:

IF (Private Boolean is False) THEN
  Set Private Boolean True
  Notify "Mailbox opened"
  Set Private Boolean False --> delayed 0:10:00 

You might also consider something like this instead--this would make it wait until activity stops (or contact closes if you wrote it that way instead) and would take care of multiple future executions hanging around waiting to set the PB false if your sensor happens to trigger a bunch of events and not just one, but I don't think the results would be substanitally different from what you already have:

Trigger: Sensor *changed*


IF (Sensor active) THEN
  IF (Private Boolean False) THEN
    Notify "Mailbox opened"
    Cancel Delayed Actions
    Set Private Boolean True
  Set Private Boolean False --> delayed 0:10:00 (cancelable)

Either of the above would take care of your problem if the issue is that the initial notification never happens. If you get a bunch right in a row right when it activity starts, then instead I'd guess the ST sensors might send a bunch of "active" events when there's movement, not just one, so PB might not have time to get set to True (or False in your case) before the rule runs again and checks the value. In that case, using a "real" local variable might help with that.

If it's neither, a description of what you see plus some logging might help narrow it down. Good luck!

Every rule I have has PB value of true if I am not using it so believe it defaults to true.

Ha, I had that backwards. You're right. (I have forgotten the days of thinking back to when these were usable as naïve restrictions and false would mean to not run.)

1 Like

Eventually, I'd like to set up rules to only allow new mail notifications during days of delivery, and restricted to the regular typical hours of delivery (9am-6pm). The notification rate limit via Private Boolean is meant to prevent notifications from spamming me if it's a windy/stormy day causing the accelerometer to go crazy. It's very breezy this evening and I've already received two false mail alerts.

Reasons for using an accelerometer over the contact sensor is so I can simply attach the sensor underneath my mailbox to help protect it from the elements. It won't block the sensor's RF signal by being outside of a metal box. Also, being outside the mailbox will prevent the sensor from getting in the way of packages and mail. And lastly, it is a very simple method to create a "smart" mailbox.

If all this fails or works poorly due to false alerts I will then reconsider my setup.

But how could this be when the delay in my rule isn't cancelable and no additional acceleration events have occurred since the first event that triggered the rule? It's as if the rule is stuck on the Boolean being False. I have experimented with various ways of triggering the rule and with a minute delay to test things. So far, nothing matters. Once the rule runs once, the Private Boolean never changes back to True.

Here is an updated RM4 rule that I would consider ideal if the Private Boolean would ever change back to True after the delay. :confused:

Don't use Private Boolean. It is false now and you will have to write another rule to ever get it back to true now. Instead, create a local boolean variable. This will do the same functionality and you can change it within the rule interface manually without having to write another rule.

The problem is that PB got screwed up at some point and your delayed action setting it true was canceled. So, now it is false and there is no action scheduled to set it back to true. To fix that, you would have to write another rule with just an action saying set the PB true for this rule and then save it, re-open it and run the action.

However, I would ask, are you using this as an accelerometer or contact sensor. If contact, there's no reason you need the boolean logic and just trigger off the sensor either opening or closing, instead of both. If you're using it as an accellerometer, then I understand that logic. However, are you able to get a strong enough signal with the sensor inside your mailbox? Be careful it doesn't drain the batteries overnight since it's inside a big metal box.


Trying to use the accelerometer so I can keep the sensor outside the mailbox. This particular SmartThings sensor has both, contact and acceleration sensors in one device.

I think this is what's going on. Just a moment ago I tried using a virtual contact sensor to test my rule and as you said, PB is simply not getting set back to True no matter what triggering device I use. I will attempt to create a local Boolean variable. and see how that works.


Ok, I wrote a test rule using a local Boolean variable. It worked the first time and I received a notification on my phone. But now it is stuck as a false local Boolean and won't reset. :confused: Did I create this rule incorrectly?

Edit: I rebooted the Hubitat, manually set the Local Boolean back to True and retested the rule. Two times now the local Boolean went back to True after the delay. Will test again in the morning but I believe your solution is indeed correct.

Thanks again and I will update this post with my findings

FWIW I have my Iris contact sensor mounted underneath. You don’t have to use the magnet that comes with the sensor, any string magnet will work and I am using a round rare earth magnet that you will see attached to the mailbox door. See picture on this post.

1 Like

Thanks for the tip. I will likely do what you did with a rare earth magnet + contact sensor due to a lot of false positives from the accelerometer today because of wind (doesn't take much movement to trip the accelerometer).

1 Like