I have this rule that notify when if any of the sensors stay opened for more than 6 minutes.
I received a notification for the wrong device (it should have notified "Porta Entrata" instead of "Porta Taverna"), maybe because that device was opened and closed in the meantime.
All devices are in the subscription
Is there a solution other than creating 3 different rules?
It’s a little hard to follow what you were expecting vs. what actually happened.
Did you open porta taverna, porta entrata, or both doors, before receiving the notification?
It looks like porta taverna was the last door that stayed open for six minutes and triggered an instance your rule.
A screenshot of rule logs might help clarify.
Unfortunately, the rule logs were off, but here are the device logs
Porta Taverna (the one notified)
Porta Entrata (the one supposed to be notified) - ignore the last 4 lines
Notification received at 17:01
(edit screenshot)
It does seem like something doesn’t add up from what’s visible in the screenshots.
Others might have additional suggestions, but all I can suggest is keep the rule logging on for events, triggers and actions. If this recurs, it might be clearer what the issue was.
I have seen similar behavior in the Notifications app that I have to let me know if any of a group of doors have been left open for too long. If there is another one of the devices in the Trigger list that opens and closes, before the the original door is closed... Then the notification will use the last door that triggered the rule.
This has been this way for years. Once simple way to resolve it is to create multiple rules, one for each door, so that the message is always correct. It is pretty easy to do this within the built-in "Notifications" app, as opposed to using Rule Machine. Just a simpler app, IMHO, for such a simple task.
Understood, but that's exactly what I want to avoid doing, I have other similar rules for windows and gates 
And yet OP went about this just the way many of us would have. It's little stuff like this that contributes to the angst expressed in another thread that's very hot this morning about User Friendliness.
I'm not saying that...
you don't get use to stuff like this.
BUT this is exactly the kinda thing that a User Behavioral Analysis might spot as a place to make some considerations to accommodate typical approaches.
Don't let this derail the thread here...just a comment after this thread had me thinking...."yeah, I woulda approached this JUST THE WAY HE DID and gotten unexpected results".
Just to make it clear
16:55:41 Porta Entrata - OPEN (First trigger)
16:57:25 Porta Taverna - OPEN
16:57:29 Porta Taverna - CLOSE
17:01:41 Notification (Porta Taverna)
17:02:13 Porta Entrata - CLOSE
I see very little overlap between that thread and this one.
Are you certain this is a user interface issue in this thread?
Yes I think that’s what I was seeing. Porta taverna opened after entrata, but not for six minutes.
So presumably the rule triggered twice. I believe the second trigger could have canceled the wait timer on the first.
But that still wouldn’t explain the notification when porta taverna appears to have been open for less than six minutes.
My guess: with a "sticky trigger," the value of %device% gets set immediately to the device that generated an event, rather than waiting until the "for how long?" timer on that trigger event is up. It seems more intuitive for it to only do it in the latter case, but there could be something that makes this hard to do, or it could just be an oversight given that sticky triggers are newer than %device%. One for @bravenel.
This would explain this sequence of events--right timing, just the unexpected %device% value (but indeed the one with the latest event):
And:
I've seen this, too; that behavior is for sure documented. 
(For example, selecting two contact sensors and "for how long?" will send a notification when either is in the selected state for the selected time, but always with the device name from the most recent event, even if that particular device hasn't been in that state that long. The timing is correct, and separate apps for each provides one solution. I've thought about writing a custom app that can "track" each separately for cases like this but never got around to it...)
I don't think the use of %device% will work with sticky triggers. Perhaps the first actions of the rule could be to check which of the contacts are open then write that to a local variable. Perhaps use Time Since Event to include only those open more that 6 minutes. Then speak the notification using the variable.
Oh that's the "unfriendliness" @PunchCardPgmr was talking about.
Thanks for the suggestion, I think it is feasible.
Nope, doesn't work (and over complicated)
Going with single rules
I'll admit this isn't a simple rule but it did work for me. What didn't work for you?
Note that I just logged the local variable and the Time Since Events uses exceeds so I took 1 second off the trigger stays time
Seeing your rule I've figured out what I was doing wrong, anyway thanks for sharing, It will be useful for others things.
Download the Hubitat app
