With the ability to configure 5 Notifications per switch and 4 settings per notification I have now encountered a new issue that is triggering my OCD…I know if I manually configure each notification at setup I can edit the settings these 20 settings per switch, but this is now rather tedious with 7 switches deployed… If I however what to change any one settings I am now required to log into the 7 devices and adjust the settings…
I know with how with Rule Manager to trigger the Notification child devices with single rules, so that is not my problem…The issue is how to link the switch parameters…
Desire is for Notification Configuration/Settings to be all the same in each switch…And either create a Variable for each Notification setting that could be entered into the switch and then only be required to change it is one locations…
@EricM_Inovelli you seem to Hubitat resident expert any thoughts?
I call it “CDO” (the letters have to be in the correct order!)
So are you asking for something that would duplicate notifications/settings to multiple switches? That could be a cool app. I know, for my exterior switches, I’d probably configure them all the same way. It would be nice to set/modify these switches once and then migrate the settings to others.
This would probably be best done by adding a custom command to the driver to set the parameter for the notification LED. I’ve modified the driver for my use by doing something similar to change the “default” LED status (I basically wanted my default LED color to change by Hubitat mode and go back to that if a “real” notification LED got set and cleared, so changing the default seems like what I really wanted). It looks like it would be possible to add another command to set the notification LED status–it’s just another Z-Wave parameter, which RM can’t manipulate directly but could with a custom command if you code the command in the driver to change it. You could then use a custom action in RM to call this same command (once) on any number of selected switches without needing to turn on (or worry about at all) a bunch of child devices. If you’ve used HomeSeer’s 200-series switches and dimmers, I’m thinking something along the lines of how their setStatusLed command in the SmartThings DTH (and most ported Hubitat drivers) works.
Does that sound like what you’d be looking for? I make no guarantees that I’ll be able to do this soon-ish, but it seems like it would be easy enough to modify the driver I created for personal use and share it with this addition if someone else would find it useful. (And of course, if you’re up on Z-Wave and Hubitat drivers, you could also do it yourself.)
(EDIT: Below is for the dimmer. Based on your post date, I assume you might mean the switch. It should be do-able there with similar modifications, but I don’t have any switches at my house to test with.)
I lied. I had some time tonight and played around with further modifications to the driver and came up with this:
I haven’t tested it much, so there might be some bugs. (Note that I also remapped some button/number events in ways that make more sense to me, so watch out if you switch from Inovelli’s stock driver with scene automations configured.)
As an example of how you might use the new custom command:
I will have to study this and see if this will work for me. Additionally I am traveling a bunch over the next weeks for work and as a rule I don’t mess with the home automation setup while traveling as the WAF suffers…
Ha, that’s how I felt looking at your driver! Took me a while to figure out what a lot of it did. All I did (besides making the buttons work in what I’d consider a more Hubitat-like fashion) was add a couple custom commands to allow you to set the “regular” and “notification” LEDs via these commands. That way, you can set them to arbitrary values using Rule Machine or similar without needing to worry about having created child devices with your desired settings ahead of time (and you can use the “regular” LED as a sort of “permanent notification” as I do, where its color corresponds to my hub’s mode and the “real” notifications override that but go back to this when cleared). These commands/functions just modify the same Z-Wave parameters that the device preferences or child devices for the same parameters do (definitely had to copy your math to figure out parameter 16…), just using a function instead of a preference or child device.
The child devices are definitely easy to use, and on SmartThings they’re pretty much a necessity unless you have webCoRE or something to run a custom command. They work fine on Hubitat too (disclaimer: I think something I modified prevented my driver from being able to create them, but I’m not sure why since I didn’t touch that part of the code; still works if you use the original driver and then switch). However, since Hubitat has Rule Machine built in, which has the ability to run custom commands, people who are comfortable with that could just change the notifications that way instead. I think that’s what the poster was asking for…but it’s definitely something I wanted to do.
I haven’t used my setNotificationLED (parameters: color, level, duration, effect) command above yet—basically a way to modify parameter 16 using a command—but just added it since I thought that’s what they asked for; I did, however, add a command called setDefaultLED (parameters: color, level) a while back that I had been using. Here’s an example I was talking about that syncs the LED color and level–so basically modifies parameters 13 and 14–with my location mode:
The other command could be used in a similar fashion for “real” notifications (but again, so could turning on a child device if you have one created—that wasn’t an option at all here and is why I did this first).
Thanks for doing this! Definitely the next level… Being able to set the LED brightness based on the time of day and color based on other input. Awesome!
The error message is telling you that you are passing a number (not sure what but maybe numeric hue?) but the command requires a string (the color name) and a number (the level). You can see some examples of usage in my post, but you’ll need to do something like setDefaultLED("yellow", 10).
I recently made some changes to the driver but don’t think it should have affected this. If you haven’t updated in the last couple days, maybe try again? (Follow the link, as the importURL may have changed).
I’m still not able to reproduce this behavior, but I will check out Inovelli’s latest driver changes (none of that should have affected this), try to merge theirs with mine, and check this with dimmer again later today. I’ll upload a newer version if I find anything…and actually will probably upload a new version regardless because Hubitat is making some changes in their next firmware version that will cause this driver (and probably Inovelli’s if theirs still works as the original did) to break with regard to scene/button handling.
If you haven’t tried already, consider re-doing that rule action. It’s logging both parameters but it almost seems like it might not be sending the second…
Got home delete the custom driver, rebooted the hub, reinstalled customer driver, wrote new rule similar to yours with modes controlling the default led and still have an error…
I have updated the driver, merging my previous changes with Inovelli’s new changes. I’ve also tested with a rule like the above, and everything is working for me. Perhaps something was wrong with the older version on GitHub. Here is my latest:
Also, make sure you’re using “string” and “number” (not “decimal”) as the first and second parameter types, respectively, in Rule Machine. Hope this works for you now!
@BertABCD1234 This statement was were I was wrong, I had entered the two as a single string and didn’t differentiate the string “Red” and number “10”. A quick update of the rule, and this seems now to be working…
@BertABCD1234 Been tinkering around with this for the night and it seems to be working,but I see a lot of noise in the log when monitoring. Additionally entering the 4 parts or each parameter for every customer action inside of my complete rules makes this a bit of a bear to manage, but it certainly works…
Would you consider adding parameter 16 (dimmer) and 8 (switch) to your hubitat drivers so it would be fully accessible command assignable in RM 4.0 via the custom action. I am okay using a decimal calculator to come up with a value, but it really would be simple to assign the Notification options in RM and we would have almost unlimited options to drive the LED.
As you might know @BertABCD1234 as already developed options to do this, but it is based upon his custom driver , and I don’t fully want to remap all my buttons based upon his driver so I was hoping for some official support in your hubitat driver…
Thinking that if the command was fully accessible in RM so I would be able to use a Global Variable with a 8 digit decimal number preassigned for each type of Notification preset I desire, then I would just have to use use the Global Variable for the Value of the Customer Action and I would have everything I need…
All I did (besides making the buttons work in what I’d consider a more Hubitat-like fashion) was add a couple custom commands to allow you to set the “regular” and “notification” LEDs via these commands. That way, you can set them to arbitrary values using Rule Machine or similar without needing to worry about having created child devices with your desired settings ahead of time (and you can use the “regular” LED as a sort of “permanent notification” as I do, where its color corresponds to my hub’s mode and the “real” notifications override that but go back to this when cleared). These commands/functions just modify the same Z-Wave parameters that the device preferences or child devices for the same parameters do (definitely had to copy your math to figure out parameter 16…), just using a function instead of a preference or child device.
