Woke up this morning and found out that I left my garage door open all night.
I have a contact sensor on the garage door (but doesn't work perfectly - more on this later).
To prevent this from happening again, I made 2 updates.
Made a Notification to send a text to my phone and announce on Alexa if the Garage door is ever open for more than 10 minutes (repeats 3 times, every 10 minutes).
Created a rule using this guide ( https://support.inovelli.com/portal/en/kb/articles/how-to-setting-up-notifications-in-rule-machine-hubitat) to change the LED in my bedroom to a flashing red/orange when the garage door is open. But how do I make the LED return to its regular state when the garage is closed? The guide does not give instructions on how to reset the notification. I attempted to add a "wait" rule and then a "reset" notification, but this has not worked. I want the light to flash red/orange until the garage door is closed. Did I choose the wrong option for reseting the notification?
Separate note:
I have a contact sensor in the garage, but i often see on my dashboard that the sensor is incorrect. What is the best way to confirm the garage door is closed?
I have both the button and the sensor on my Dashboard, but is there a way to set up a redundancy to check? maybe if I use two contact sensors and then figure out a way to ensure they are giving me the same results? Any suggestions for this issue would also be greatly appreciated!
"Reset" resets the cumulative power metering attributes, so that isn't what you want. "Stop Notification" should work, so I'm not sure why that isn't (no parameter needed in case you're trying one). That should also be equivalent to a Start Notification with a parameter of 0, as setting the underlying parameter (16, but since you appear to be using Inovelli's driver, I wouldn't worry about it) to this value is the method to stop the notification.
In the mean time, during my initial rule I set the notification to last for "infinity" since I want to be always be notified if the garage is open... but now I can't stop it? (even while just troubleshooting the rule)
On the device side, you should at least be able to stop it by double-tapping the config button. In the meantime, to troubleshoot the problem, I'd leave Rule Machine out of the picture and just try these commands directly from the device page first. If you are not familiar with this page, go to "Devices," then click/tap into the page for your switch. Towards the top will be a series of buttons representing available commands for your device. Put in any parameters if needed (the calculated notification value for Start Notification; nothing for Stop Notification--only fields with asterisks are required...EDIT: but note that if this is the fan/light switch, you probably do want to specify the endpoint, as mentioned below). Then, click/tap the button to run the command.
(Another thing to verify: could the device have fallen off your network? Simple commands like "On" and "Off" wouldn't work from the device page in that case, and neither would these, which could explain why you can't stop anything.)
You have to use startnotification to end notifications as well. In the inovelli instructions where you can choose the color and pulse or blink or whatever, choose "off, notification cleared", then copy that parameter value into the start notification field.
So THIS is key... I tried doing "stopnotification" with the string parameter set to "notification cleared" but this didn't work. I had to do "startnotification" TWICE - both to turn on the notification AND to turn it off!!
Yes Inovelli Red Fan + Light Switch. And I did tell it which to stop, added second parameter with
"xxxxx, 2" to denote the fan notification but that didn't work, until I changed the second "stopnotification" to "startnotification" with the string parameter set to "off notification cleared"
Tried this method as I was hoping the LED would return to it's "normal" state. In that if the fan was on at 30%, the indicator light should be at 30%, but when I did "StartNotification" and selected "Clear notification" it just gave me a blank LED as if the fan was off, when it was actually on.
Unfortunately, this did not work. My regular blue 30% fan status flashed for 1 second and then the flashing red/orange (Garage open notification) returned.
Any ideas? Is the Stop notification parameter a number, string, or decimal?
From Inovelli's driver, "Stop Notification" does the same as "Start Notification," except it just provides a value of "0" for the notification parameter (which is what should stop it, so if that's not working, then that's odd and something they might want to investigate; I know it works on the LZW30-SN, which is what I assumed when you said "Red switch," but I haven't tested on the LZW36 fan/light switch...but apparently they think it should).
Using "stop" is the proper way and more understandable.
Not sure what your other device settings are.
Some I have:
LED Strip intensity=100%
LED Strip Intensity (When off)=30%
Create "LED Color" Child Device -> On
I set the non-notification colors on that child device. Notifications sent through the parent override the colors set in the child for normal on/dim/off behavior.
In order to fix this, I did "StartNotification" and selected "Clear Notification" where you select how fast it blinks, but you need to set the duration to a few seconds. Previously I had it set to "infinity". Once, I selected "5 seconds" and updated the string parameter, the LED was off for 5 seconds, and then returned to the "normal 30%" status based on the current speed of the fan.
Thanks guys. I have three red dimmers and one fan switch. I never did figure out (although I admit I did not spend a lot of time on it) how to send a notification to the lower (fan) indicator. I was not aware of the ,1 or ,2 option.
I actually think that makes it more complicated; you don't need a conditional if you just trigger on what sets things into motion. But either way works! Even the above, which is a paradigm staff began suggesting a while back: note that the "open" event--the trigger--starts running the actions, which then wait for a "closed" event. That "Wait" creates a subscription (if the door is already closed, which since it just opened it probably isn't; I'd use "Wait for event" instead of "Wait for condition" given the general advice, but that's another issue...). Then, when that happens, the next action--cancelling the notification--will run.
As far as performance and resource utilization goes, isn't the "changed" event, internally relying on those same subscriptions? Or would I be doing any good by explicitly subscribing to "open" and then adding a wait for event (again: as far as performance and resource utilization goes)?
But either way works! Even the above, which is a paradigm staff began suggesting a while back: note that the "open" event--the trigger--starts running the actions, which then wait for a "closed" event. That "Wait" creates a subscription (if the door is already closed, which since it just opened it probably isn't; I'd use "Wait for event" instead of "Wait for condition" given the general advice, but that's another issue...). Then, when that happens, the next action--cancelling the notification--will run.
