Yes, in my case I am trying to integrate most of the switch notification as various alerts like door open, water detection, etc.
Trying to avoid having to adjust the notification settings in each switch if I change my mind on color, duration, etc…
I wouldn’t be opposed to an app, but I certainly not capable to write it…
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:
setNotificationLED("red", 10, "255", "slow-blink")
The general syntax is setNotificationLED(color, level, duration, effect), where the parmaters are:
Most of these are basically the options Inovelli gives you, though I added a couple in-between colors that I like better. 
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…
@BertABCD1234 can you TLDR this for me as to what you did? This is way above my paygrade 
Either way, thank you so much for your contributions, it sincerely means a lot!
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!
Been testing this driver and I can’t seem to get it to work from RM 4.0
I can get the commands to run from the device page, but not in RM…
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).
Interesting. I just ran mine:
and couldn’t reproduce the error:
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 have the most current driver on Git Hub from 6 days ago…
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…
Clearly this was my user error
@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…
Inovelli just updated their driver to reduce some of this chattiness, and I followed suit in a recent update. So, if you haven’t given it a try lately, see if the new update helps.
The “default” LED method has two parts, color and level. Level is technically optional…or will be when I update my method to fix the bug. The “notification” LED has four parameters: color, level, duration, and effect (the last two of which are also optional but I should probably check for the same bug). These correspond to the real-word attributes you need to calculate the value of what is ultimately one giant parameter. Are you saying you’d rather have it be just one “combined” parameter like Inovelli’s calculator would generate? I could certainly add that, but I didn’t because I think it’s a lot easier to put in my desired values and let the computer do the math for me. (Granted, RM makes it a bit of a chore to set parameters…)
If you don’t want to re-map buttons, you could take Inovelli’s methods for:
def zwaveEvent(hubitat.zwave.commands.centralscenev1.CentralSceneNotification cmd)
and
def buttonEvent(button, value, type = "digital")
and copy and paste them back over mine, then—technically not necessary but it will make things a lot cleaner—also search for “numberOfButtons” and change it back to 8. (But again, I personally like using button events for their intended use, at the expense of needing to do a bit of button-number math.)
The screenshot I shared was from a chat log specific to the new driver you had modified yesterday and directly linked to the setdefaultLED command that I triggered via a mode shift in RM 4.0. You can clearly see Parameter 13 & 14 repeating themselves. When I trigger this SetdefaultLED… I didn’t see the chattiness when I trigger the command from the device page, but only with rule manager…
Yes I would like to be able to set the combined parameter in a single entry with the hopes it would simplify the rule creation due to the tediousness of RM…and/or drive the parameter via a global variable where I can set a more common name for the decimal value of the parameter.
As for the button I already configure a bunch of button devices for my existing switches. If I adopt your driver I am force to update all of those Rules too…
I suppose I could make the edits you mention in my local fork, but really don’t want to deviate as I am not into maintain code…
Thanks again for opening my eyes to some more advance feature in hubitat. I am far from an expert as I am about 60 days in…
