As per this thread, I’d like to be able to disable the standard LED on/off behaviour when in dumb light mode.
Any chance we can get a parameter / toggle for this?
It’s been ages since I’ve used notifications, instead I manipulate the default colour of the LED strip. The reason I do this is because the default on/off LED behavior still triggers and it drives my OCD crazy when I have that flash of blue when the LED is set to red.
I can picture this option as something like “Disable default LED on/off behavior when notifications are on” as well.
I believe existing Parameter 17 is the one you want. Try setting P17 to 0 “do not display load level” and I think that will do what you’re asking. You may also want to set P97 and P98 to 0 (led bar intensity when on/off)
4 Likes
Interesting!
So this is almost exactly what I’m looking for. I tried it but now instead of it staying on for 2 seconds, it flashes for maybe 50-100ms. This is way better but clearly there’s something else still causing it to go on for a moment. Any ideas? I’ll put this into that thread I linked as it’s a bit off topic here.
Same as @Rob here! I need to know when the MG24 will be standard in the Blue series and can’t order ahead of then. I have over a hundred switches to buy and install, and thus need OTA firmware updates. 
Any guidance appreciated @Eric_Inovelli
2 Likes
Any chance we could get an addition “button down” event added?
Are you asking for the VZM31-SN? If so, button up/down and config are all supported.
When I say “Button down”, I’m referring to the button triggering an action when one of the 3 buttons (up, down, or config) are pressed down initially. Right now, there doesn’t seem to be one (they’re all “Button up”, as in the action is not triggered until the buttons are let go).
Said another way, I’m looking for the following additions:
“up_press”
“down_press”
“config_press”
Do you mean these -
Or you’re referring to when you press and hold but don’t release?
The latter, but where it triggers instantly when the rocker/button is pushed – so no delay.
This is the ideal behavior for somebody who wants their lights to respond as quickly as possible.
Sounds like what you’re looking for is Pressed, Released and Held. I may be wrong here, but I’m not sure if that would be possible because of the held option. For held to work, there has to be a delay on when it’s pressed to be able to determine if it’s being held or if it was just pressed.
2 Likes
Of course, but it would be possible to have all 3 available to us so we can decide which we use to trigger our automations.
I, for example, don’t really use ‘hold’ anywhere and would just prefer to have the lights respond quicker.
If this functionality was added, it could easily be ignored by those who prefer the way it works right now. For anyone who uses the buttons for single-press only, they would of course prefer to have the trigger be on press, not release. It could be a setting (to enable / disable it) but it doesn’t even seem like it would be entirely necessary since each of the actions could be listened to / ignored independently.
We went through this on the LZW series where we were able to disable multi-tap and eliminate delays. If you set the delay parameter to 0 it should instantly send the “pushed” command from the switch, but you will never get any multi-tap signals.
Very good point. As long as multi tap is enabled, there should be no noticeable speed increase between pressed and released because of the delay needed for multitap as well. Disabling scene control completely by setting the delay to 0 would be the only way to speed it up.
Anyone else getting errors like this on hubitat?
errorjava.lang.NullPointerException: Cannot get property ‘type’ on null object on line 2132 (method parse)
Each one of my 6 blues has been doing this periodically.
what are you trying to do with the switch when these errors appear?
Looks like a driver bug that should be easily fixed if reproducable. Also what driver version (date) are you running?
The most recent one happened immediately after I rebooted hubitat and the one previous to that on a different switch happened with no interaction at all. So from what I can tell so far it just happens on its own.
ok then I’ll need a bit more information from the logs.
Make sure you have at least INFO logging enabled for one of the devices that is reporting this error.
Then, the next time the error appears in the logs, show me several other log entries that appear before and after the error.
also, don’t forget to tell me the driver date (should be listed in the State Variables section)
1 Like
