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
Finally got it to happen again. Driver date is 7-1-2023 and here are all the logs before and after the error.
I can send them in text form if you would prefer that.
1 Like
Ok I know exactly what that is. It will be fixed in the next release. I need to finish up on the new Blue Fan Switch driver and then an updated Blue 2-1 driver will follow shortly after that.
P.S. Iām assuming you turned on Trace and Debug to give me more data, but I didnāt really need it, just the Info logging before the error. Hopefully you donāt leave Trace and Debug on all the time 
3 Likes
Thank you! Yup, turned those on just so I got everything I could. Now that you know the issue I will turn them all back off.
Iām not sure if I should post this here or in the firmware thread, but I had an interesting side effect from having to use the jtag harness to re-flash one of my switches.
Since Iāve received them, Iāve never had any of the Inovelli blue light switches function properly as routers (repeater). As a result, Iāve also never been able to use ZHAās feature to connect a new device via one of my blue switches. I know a lot of people have had that issue as well, but quit following it since this has been fine for me, as my zigbee network is relatively strong.
Flash forward to needing to update to the 2.15 firmware. One of my light switches refused to take it, all others handled it just fine. I requested and borrowed the jtag flasher and flashed that one switch. Looking this morning, I realized that I now have a handful of devices connected through that one switch. I have also added a couple of devices via that switch as a test, which was successful.
Still, none of the other switches will allow me to add via them, nor are they doing any kind of routing.
I am not sure what is going on here, but Iām somewhat regretting not doing the process on the rest of my switches, as I thought they were functioning fine.
@EricM_Inovelli, Iām wondering if you have any insight as to why this would be, or if this would be helpful information in any way? Iām definitely now tempted to pick up a cheap jtag device (there was one linked in the other thread) and making my own harness for it.
3 Likes
That is very interesting. On one of the switches that is 2.15 from OTA, can you factory reset it and join it to the network again? I wonder if something has changed since they were originally included into the network. Both switches should be running the same 2.15 firmware so it is surprising that they are different in that way.
Ah! I donāt know why I didnāt try thatā¦ Probably because that never worked in the past 
It is, indeed, working on its own now with a switch that didnāt need the hardware flash after factory resetting!
This is great news! Thank you!
2 Likes
Nice!