[Released] Rule 4.0

Good diagnosis Contact Sensor EcoLink (Garage Door type) reports 2 events for each Open/Close

EDIT: BUT this is claimed to have been fixed in Hub Update 2.1.3 ?

Thanks, @waynespringer79 and @csteele. I appreciate this input. Unfortunately, this diagnosis, though I think it's correct, is beside the points I'm making and doesn't address the underlying issues I'm trying to raise:

  • "Suppress duplicate events" doesn't function (at least with my devices) as I would expect it would, namely, to suppress the duplicate Z-Wave events sent by the Ecolink sensors.
  • The "changed" event might be more accurately called "any", as it fires whenever any sensor event is logged, regardless of whether that is a change of device state.
  • The set of actions triggered by a given rule don't seem to be atomic, so private booleans and other hacks to try to backstop the "suppress duplicate events" and the "changed" trigger can't be relied on due to race conditions.

I'm simply requesting the above be considered as possible points to address in a future release of Rule Machine. Thanks!

This is not possible, as each instance has no way to know of other instances, and all instances share a single state, be it atomic or not.

The only way to do this is to design your rules so that multiple instances only occur in very well designed and controlled circumstances.

There is no way to accomplish this either, especially with a delay involved.

Rules with multiple independent trigger events, such as the one you show above, with a delay, are intrinsically going to be problematic.

The system suppresses successive events from a device that do not represent a change of state for the device. You haven't shown any logs, or device events to support that this is not the case. Also, the "changed" trigger DOES also look for an actual change in state for the device before triggering a rule. Again, without logs, it is impossible to see what is actually happening.

Thanks, @bravenel. I'm not on my local network at the moment but will share logs later. I appreciate the response.

EDIT: I suppose I would have proposed that the way to make the rules actions atomic would be to have an atomic global variable associated with each rule within the RM app (behind the scenes from users), and then the rule would have to get a lock on that variable before it could start executing the actions and would release the lock afterward. It's possible to do this, generally speaking, but I understand that it make not be possible within the environment that supports the RM app.

We don't support a locked memory environment in the hub for any app.

1 Like

Hi, @bravenel. As I promised earlier, here are logs and other screenshots—the above does not seem to be how HE is behaving for me with respect to duplicate events (you can see them below, 2 milliseconds apart).

Both Z-Wave events are logged for the software device, and the rule (which should fire only on "changed") fires twice, once for each of the two successive "open" events. Aside: You'll see I've gotten rid of the local variable in the rule, given your confirmation that neither a local variable nor a private boolean can solve this particular problem, due to the race condition.

Any thoughts are appreciated. Thanks!

EDIT: If I had to take a wild guess at what the problem could be, given that you mentioned the app environment doesn't offer multithreading locks or semaphores, I would assume the same may be true of the device handler environment. If so, that could be leading to races both within the device handler (preventing "suppress duplicates" from working) and within RM's internal determination of whether a "changed" event has taken place.

Trying make a rule with power meter.. And need help . .. How to make if power meter <4 and it for 5 mitutes then send voice notification... I can't find the condition duration or time... Etc

Hi, @848667. Here is an example of what you're trying to do, with a few caveats:

  • This rule will be affected by a race condition, as I describe above, but in RM 4.0 as currently implemented, race conditions will be unavoidable for certain desired behaviors, such as determining whether a power meter has remained above a certain threshold for a certain period of time.
  • My example notification isn't actually designed to work here—I can't get an Echo Speaks group to respond to the "send notification" actions, and I have to use Run Custom Action and playAnnouncementAll(string). The point here is just to show you an example of a notification that may work with other devices capable of delivering notifications.
  • The below is designed to deliver a single notification after the power meter has remained above 500W for five minutes, and no further notifications would be delivered until the power meter again falls below 500W.

I hope this provides you a useful starting point!

I would say that device driver is broken / programmed incorrectly. You didn't say what driver it is (that I saw anyway), but it is clearly a user driver. So contact the author and have them change it so duplicate events aren't automatically state changes...

Or edit it yourself adding a debounce timer on the event creation.

It seems to me you are trying to fix a driver issue with RM workarounds. I think it is better to fix the root problem.

Hi, @JasonJoel. No, the driver is the default driver listed at List of Compatible Devices - Hubitat Documentation.

I have identified two separate issues with race conditions above; agreed that one of them is unrelated to RM. The other, however, is an example of one that affects RM.

Aside: The issue with duplicate events was specifically said to have been addressed in the latest release of this driver from the HE team. Unfortunately, if the device driver environment doesn't correctly support multithreading, "suppress duplicate events" can't work as intended.

What is privet boolean.. Never tried...

EDIT: Never mind, I see your response above with details on the contact changes. I agree that if the code is executed faster than the 1st instance can complete, there is no way to avoid duplicate executions the way the system works today.

Then I would submit a support ticket to Hubitat's email, and ask them if they can improve their driver... I wasn't aware of any in-box drivers that would log repeat duplicate inputs as events. Although these are happening so fast that maybe it is unavoidable, even with debounce code.

Could you share your logic, I'm setting up my recirc now and not understanding in RM 4.0 how to do the 5 min or restart 5 min if another motion is triggered. Hmmm....

I'm sorry, not sure what logic you're referring to. Please give a bit more context...

My fault, was replying to your hot water recirculation rule. I want to trigger on for 5 minutes

If Motion OR [kitchen] [Master bath]
Then Water Pump Outlet ON for 5 minutes duration
Elseif Motion OR [kitchen] [Master bath] restart 5 minutes duration
Else Motion inactive Water Pump off

I'm struggling with how to make this work in RM 4.0

Do it like this:

Trigger Events:  Kitchen, Master bath Motion ANY changes
Actions:
   IF (Kitchen, Master bath motion ANY active) THEN
      Cancel Delayed Actions
      IF (Water Pump off) On: Water Pump
   ELSE
      Off: Water Pump, delayed 5:00 Cancel
   END-IF

So, if there is motion, first thing we do is turn on the pump. Later, when motion inactive happens for both sensors, start a cancelable timer for 5 minutes. If during that 5 minutes, either motion goes active again, we cancel the delayed off. Note that the small test to see if the Water Pump is off is a Simple Conditional Action, and is simply to avoid sending an on command if it is already on.

The Water Pump will not turn off until there has been no motion from either sensor for 5 minutes.

I went a slightly different route b/c I didn't want the recirc to come on everytime someone entered the kitchen. I created a VS, let it sync with Alexa, created a rule so now when we want hot water, we tell Alexa to turn on hot water, 5 mins later the recirc is turned off. Our gas bill dropped over 50% buy cutting back on the recirc

Here is my rule if you are interested

Rick

@bravenel Thank you Bruce.
Here's how I set it up based on your If statement. Still trying to understand 4.0 obviously, greatly appreciate the assist.

@toy4rick thanks for posting your recirc. Instead of asking Google/Alexa, thinking I could maybe use a pico button or light switch to activate the pump. Not sure it would fly to ask Google for hot water.

Ultimately, I'm hoping to save some gas and water costs by installing and automating the recirculating pump. All in I'm at ~$300 so I doubt I'd get that back over time, but my #1 goal is to please the wife who complains about not having hot water. Is this like Homer giving Marge a bowling ball with his name engraved if I give my wife the gift of home automation for her birthday? Guess we'll see.

LOL, I also have a master shower light switch (actually in the show) setup to turn on the recirc when we want to take a shower so we don't have to walk out to the kitchen and ask. Rather than ask google/alexa, the command is Alexa, turn on hot water. Since it's a VS, it's a command and there is no way to order water from Amazon for delivery service... Haha

Have fun

@848667 This is my rule I use for my washer and dryer, and works great. They're almost the same, except the washer rule has a "under 1W for 2 mins". Two important points:

  1. The washer rule is almost identical but has a delay for 2 mins to avoid false triggers. It frequently falls to lower power for about 60s, so there's a cancelable delay to avoid false triggering. Essentially if the power falls under 1 watt, but then within 2 mins rises above 50 W then it cancels the notifications.

  2. It's good to separate the high and low limits if you can. This will help avoid false triggers if it falls on the edge. For example if you have if (power > 50) .... else (power < 50) ... if the power levels bounces around 50.1 and 49.9 this can generate a lot of noise.