I just updated from 2.3.2.135 to 2.3.2.138 (skipped the interim 2.3.2.136), and now my rules that used to use Last Event Device are messed up.
Previously, if I set multiple different types of triggering devices (like a trigger for contact changed and a second trigger for motion changed), I could use Last Event Device effectively to figure out which type of device had caused the rule to fire. So I could have a rule that would do different things if the last event device was a contact sensor vs a motion sensor when it was useful to have a single rule because of interacting conditions.
Now, however, Last Event Device seems to persist attributes until they are updated. So if I have a door that closes and then a motion sensor that goes inactive, with both of these triggers for a single rule, that rule's Last Event Device has both contact = closed and motion = inactive (as opposed to just motion = inactive, if that was actually the last device that triggered the rule).
UPDATE: Alternatively, maybe the equals operator has changed so that it now returns true (whereas previously returned false) when comparing against null. Revisiting the prior example, maybe what's happening underneath the hood is that Last Event Device does, in fact, have only motion = inactive, but Rule Machine now evaluates contact = closed to true when the Last Event Device wasn't a contact sensor.
Is this a bug or a change in the intended behavior?
You've got to show screenshots of both the rule in question, and logs that show what's is going on.
There was a change that potentially affected Last Event Device. I need this information to be able to know what is going on.
Sure, here's a screenshot of the rule:
(Edit: I would note that the rule structure is a bit unnecessarily complex at this point because a long time ago its behaviors were more complex, and I just haven't gone back and refactored it. For example, the ELSE ¬ IF … END-IF ¬ END-IF block at the top could be collapsed into just an ELSE-IF … END-IF.)
The logic is as follows:
- Once the door is closed while mode is Home, a five minute timer starts.
- If, while that timer is running down, anything happens other than a motion sensor becoming inactive (i.e., if any physical switch is pressed, the door is opened, or any motion sensor becomes active), then the timer is canceled.
- If the five-minute timer does run down without having been canceled, then the system infers that I have left and changes mode to Away.
- If any activity occurs while mode is Away, the system welcomes me Home (and just in case, the system also refreshes Life360, but the separate refresh rule prevents more than one Life360 refresh within five minutes).
This all used to work just fine before I updated from 135 to 138: when the door triggered the rule, Last Event Device contact would be closed/open and motion would be undefined; when motion triggered the rule, Last Event Device motion would be active/inactive and contact would be undefined; when a physical switch triggered the rule, both contact and motion would be undefined.
Now, however, you can see above in the screenshot that Rule Machine thinks both Last Event Device contact = closed and Last Event Device motion = inactive at the same time (even though none of my devices has both contact and motion attributes). Furthermore, the logs show that somehow the rule is now being triggered multiple times in a row, which has never happened before:
The reason why the rule is executing multiple times is that Last Event Device contact = closed seems to stay true even when the door isn't having any activity at all and motion sensors are going active/inactive while I move around.
I hope this is helpful. Let me know if I can provide any other details. Thanks.
1 Like
There is a bug found and fixed that is causing this. Check when the next release comes out. The bug was just introduced in 138.
1 Like
