For whatever it's worth (not much), I can't reproduce a problem with this.
This rule works as expected with no timing issues:
The logs show both open and close tests working correctly after the corresponding device event:
Where is the state changed after an event? Is it changed and stored in the driver or does the driver inquire on the hardware for the 'current state'.
Back to my rule that's not working as shown in post #1. What do I do?
If you really want to test the trigger event value, use %value%. The trigger event (any event actually) has a value, and that ends up saved in the app to fill %value%. This is different from asking the device for its current attribute value (which evidently can have timing issues -- see below).
The driver receives messages from the device via Zigbee or Z-Wave (or whatever), and upon parsing those messages determines that an event has occurred, and sends the appropriate event to the hub's event queue. From there another hub process handles that queue, notifying apps with subscriptions for that event and updating the attribute value in the driver (note that this is a separate discrete step from the event message from the device itself). Because there are separate processes there is independent relative timing. The attributes are stored as part of the driver state. The driver does not query the device as to its state, but instead is keeping track of the attribute value based on the messages sent by the device.
3 Likes
A simple trigger on the contact opening, no IF-THEN test, just turn on the light. Wait one minute, turn it off. Your rule in OP doesn't care about the close event, only the open event.
Thanks for the explanation. My original post showed the rule as having a wait time of 1minute but say if I want a 5 minute wait time and I close the door within those 5 minutes I do want to detect the closed event and turn the light off when the closed event happens.
Well, to my eyes the OP rule takes care about OPEN and CLOSE events. Assuming there is no timing issue with evaluating IF statement, for the OPEN event the entire set of actions will be executed but fot the CLOSE event only last OFF action will take place. Or another words last action should be always executed on both events. Is not it?
No it's not. This is the problem. You can see in the logs on the original post that the closed event is recognized by both the hardware and the app event log, but the 'Off' action is never executed! I thought that's what we are discussing, that off event never executes.
I second this, but I admit it's taken me a while to come around to this mentality... I don't know why - it's not like there are awards for combining a bunch of stuff into one rule, but I can definitely relate to the appeal of trying to consolidate all actions under one tent.
Bruce is right -- rules are free, and KISSing them down is never a bad idea. I just name related rules similarly so they stay next to each other in the list.
I get that the "changed" thing is attractive (been there, done that), but it's simply oftentimes more trouble than it's worth. I've stopped using it in favor of multiple lighter rules instead, and performance/reliability is improved.
This is exactly my approach for organizing rules. But:
- list is too long;
- names are also too long because of prefixing;
- after a while logic is not easy to follow because multiple rules must be observed at the same time;
The result is: Balancing between single complex rule vs bunch of small rules is not easy task.
The only valid reason IMO to use *changed* for a two-state sensor is if the automation literally doesn't care about which event happened --- that's the intent of this feature.
Starting with a given state, such as 'door closed', a rule that uses Door Open for the trigger, followed by whatever actions should happen, followed by Wait for Condition Door Closed, then the appropriate actions -- this is how this sort of rule should be structured. It's possible to make the Condition for the Wait a bit more complex if needed, or add a Timeout to it, if you want the closed actions to happen anyway after 5 minutes or something.
2 Likes
Thank you @bravenel
I re-built the rule using your suggestion and all works as required. Here is my new rule
I will remember this approach going forward and will attempt to avoid the 'changed' trigger.
Thanks to all who participated
Ian
3 Likes
Room lighting works good for these types of automations as well.
1 Like
Just came to say, cantankerousness aside, folks DO appreciate when you take the time to explain the workings behind the curtain .
It's like an ongoing "Short Course for your Community", even if sometimes it is frustrating having to spell out things you understand fully...but others are just trying to get some framework of.
The expanded explanation of this process is a case in point:
1 Like
