A "changed" subscription wakes the rule for either event, and in this case you are doing a small computation in the actions (the conditional) to figure out what that event was. With a single trigger like "open," the rule only wakes for that specific event, and there's no need to check for what it was in the actions. Both of these should make things more efficient overall, though in the grand scheme of things, I can't imagine the difference would matter much. But given that creating conditionals takes more clicking in the UI, I'd consider it a win for humans either way. 
1 Like
Make sense. This is the reason I come here every day, always leaning something new 
This does not work consistently.. Any idea why?
I have the setting to continually blink orange once the garage door is opened until it is closed. I want to make sure that as long as the door is open, the switch is blinking orange so I know if I need to check/close the garage.
When I open the garage door, the notification works perfectly every time - LED blinks orange. BUT... when the garage door is closed it does not always turn the notification off.
The sensor is registering that the door is closed, since I can see the "closed" icon on my dashboard.
Any thoughts? Do I need to add something to check the status of the garage door every 5 minutes as a backup in case the switch from open to closed is missed?
From a rule perspective, that should be fine: you can turn on "Actions" logging to be sure, but I'd otherwise have no reason to expect the rule shouldn't run your last command after the door closes. What's more likely is that the switch isn't responding to the command as expected. I'm assuming you used the community calculator tool to arrive at that value, and I guessing it normally works (if never, including directly from the device page, that's another story)--but if you just want to turn the notification off, a value of 0 should do that with any of their devices without needing to calculate anything. Probably not the issue here, but something you could try.
Otherwise, logging or sending the command again might help, though the latter might indicate Z-Wave network problems worth investigating.
Logging shows that the "Sensor Open" and "Sensor Closed" are being correctly received. However the notification on the device always starts when the sensor opens, but consistently fails to stop when the sensor closes.
I've tried:
- String of 0
- Entering the Inovelli value for "clear notification"
- Tried starting a new 5 second notification, thinking it may stop and go back to 0 after the notification ends (but instead the original notification continues after (since that was designed as a LONG notification, to ensure that I don't miss the notification - always on if garage door is open).
Eager to hear any new ideas....
Havenāt tried this with RM, but from webCoRE I just issue the notification off() command from the notification child device (could also use the stopNotification() command from the parent) when Iām done.
Is this the best way to set up a repeating rule to check the status of the garage door? - Never did something like this.
Basically, I'm thinking of setting up the initial notification as a 1 minute notification so that it should automatically shut off after 1 min. BUT...I also want to make sure that if I left the garage open 20 minutes ago and I walk into the room with the switch that I'm notified. So I'd want it to repeatedly check the state of the garage every minute - if Open, initiate 1 minute notification on switch, if closed then do not re-initiate the notification on the switch?
So I got a new garage door, put on a new (much more reliable) tilt sensor.
I came back to this thread to try and fix/make this notification system on my Innovelli switch work.
BUT NOW NOTHING IS WORKING!! As soon as I open the garage door, the sensor correctly changes from "closed" to "open" and yet... the Switch Notification does not change at all!! Before it would start to work and then I just had issues reseting it, which is what I thought I would have been working on tonight, but instead now I can't even get the initial DOOR OPEN NOTIFICATION!
Any ideas??
Here is the current rule I was going to test...
There are two things you could do to narrow down the problem:
-
Turn on (at least) "Trigger" and "Action" logging for the rule above. This will show you what the rule thinks it's doing and when. It's possible (though unlikely IMHO) that the rule is not triggering, thus causing your problems. In that case, just going into the rule and hitting "Done" may help re-initialize things. (Check the "Logs" page if you're not sure where to find the results of your efforts here.)
-
Try the
startNotification()command directly on your "Master Light/Fan" device from its device page, using the same two parameters you provided above. If it does not work on that page, it definitely wont' work in a rule (or any app), and you've narrowed it down to a problem with the device or command.
