I haven't noticed any slowdowns using the built in integration, but I also have all my wifi devices/integrations segregated onto their own hub, and my zwave/zigbee devices are on their own.
Which the wifi hub does (according to my router traffic info) have over 10x the amount of traffic the device hub has.
Yeah that is probably why you aren't experiencing any issues with the separate hubs. I have everything on one hub. But I also have eliminated most all third party apps/drivers. Everything else runs great though, just Ecobee is problematic. I know their cloud service has a poor track record for up time, seems like multiple times a week sometimes its down.
Does anyone know what "system" variables are available for us to use.
I've had a rummage round the forum but cannot find anything that gives the info I'm after.
I've also had a play and with what I'm trying I'm getting a few "nulls".
I know there is
%now%
%device%
%value%
%time%
%date%.
What I would like to do is in a push notification have something like this.
Fred arrived at 18:00 on 21/10.
In "other" rule engines you can specify these types of variables like this.
Bert arrived at {$time24} on {$date}/{$month}.
This gives Bert arrived at 18:00 on 21/10 for example.
Any ideas/thoughts?
Thanks.
With respect to my prior post, Last Event Device was the missing piece—thank you for pointing that out, as I had overlooked it before.
I have a different feature request to propose: Could the set of actions triggered by a given rule be atomic, preventing races between multiple instances of a single rule?
Use case for me is that I have some contact sensors (Ecolink Garage Sensor and Ecolink Contact Sensors) that are logging multiple open/close events. Flaw in the devices, I suppose, but they're also listed as officially supported devices, so I think they should be supported with their flaws. To that end, I have selected “suppress duplicate contact events” for each device in my HE, but the duplicate contact events are still being reported. So I have rules that are supposed to trigger things when the contacts "change" to open, but the actions are being triggered two or three times every time the contact sensors open, regardless of whether the event is actually a change from the device's prior state (I wouldn't expect two "open" events in a row would both trigger a "changed" event, but that seems to be the behavior). I have tried using both private booleans and local variables (in different implementations of my rules) to prevent actions from being triggered multiple times, but I think multiple instances of the rule are racing because even private booleans / local variables as backstops to "suppress duplicate contact events" isn't suppressing the duplicate rule actions. I can't imagine a situation where non-atomic sets of rule actions are helpful—I would think that, for a given rule, it would always be more logical to run through all actions once before letting the rule actions fire again.
Please let me know if some other approach to solving this problem exists that I haven't discovered. Thanks!
Current rule implementation that is causing these issues is below:
I can't actually know, but I believe you're dealing with a known "feature" of some ZWave devices that send two messages. One is a "BASIC_SET" message and the another is "SENSOR_BINARY_REPORT".
I've experimented with this in the Aeon MultiSensor6 to confirm (for it) that it is indeed getting two individual messages. Possibly true for your device(s) too.
The Aeon Multisensor6 docs show:
Which makes it clear it should be sending ONE or the Other, not both. But for the Multisensor, setting that parameter 5 to anything, does nothing... always sends two messages.
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:
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.
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:
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
Download the Hubitat app
