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:
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…
Probably, I just have local control disabled on mine, so it’s always on and I’ve never cared about the “off” LED. I’ll look into that or a separate method.
I don’t have a Black dimmer to test with, but I think the parameter is the same (and most are except what’s just missing from the Black), so it should be possible…
If you would be willing to make the driver changes, I would be willing to test it on my black dimmer. I haven’t figured out groovy sufficiently to make the changes myself .
Does your driver allow for setting the default dimmer level (Black or Red) via Rule Machine, or remotely clearing a notification? I’d like to display a notification as long as the door is unlocked, but clear the notification once the door is locked instead of relying on us clearing the notification manually.
Adding a note here that I no longer update the driver I linked to above (I can’t edit posts here yet, apparently), but Inovelli has added most (maybe all?) of this to their custom driver. I have a newer custom driver I wrote after re-thinking the above a bit, but the same applies with Inovelli’s driver now also having most of this, so I’d recommend starting with theirs and not using the one I mentioned above in any case (but maybe the other if you still want to).