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!
@mamber I was poking around in my hubitat logs again and noticed another odd warn message for these.
dev:19582023-11-17 08:02:30.063 PMwarnMaster Bedroom Door Switch Unknown Cluster(Cluster:0x8001) catchall: 0000 8001 00 00 0040 00 09C0 00 00 0000 00 00 8A00CDCE05FEFF693494C009
It seems that all 6 of my devices have done that a few times in the past couple of days. Any chance you know what may cause that? I am turning on debug logging to see if I can catch anything else in the meantime.
I suggest turning off Debug logging unless specifically asked by a developer (or me). It generates a ton of data that is mostly meaningless except when troubleshooting a repeatable error. Leaving it on continuously overloads the hub and makes it very hard to read the other relevant info in the logs
If you want to see more than Info logs, Try playing with Trace logging instead of Debug
Did this ever get discussed further? I would love to see double, triple, quadruple, quintuple held events along with the press events. You can use it for color cycling as well as brightness control. Say you have a room with dumb lights and smart lights. You can have the single presses actuate the relay which controls the dumb lights, then the double presses control other smart lights, but double hold up could increase the brightness of the smart lights, and double hold down, could decrease. Of course this could be expanded to any number of actions.
Basically extending this table to include tap and hold, double tap and hold, triple tap and hold, etc over just tap x times and hold/release events.
| Action | Button # | Event | Code |
|---|---|---|---|
| Tap Up on Light Paddle 1x | 1 | Pushed | 0x0200 |
| Tap Up on Light Paddle 2x | 2 | Pushed | 0x0203 |
| Tap Up on Light Paddle 3x | 3 | Pushed | 0x0204 |
| Tap Up on Light Paddle 4x | 4 | Pushed | 0x0205 |
| Tap Up on Light Paddle 5x | 5 | Pushed | 0x0206 |
| Hold Up on Light Paddle | 6 | Pushed | 0x0202 |
| Release Up on Light Paddle | 7 | Pushed | 0x0201 |
| Tap Down on Light Paddle 1x | 1 | Held | 0x0100 |
| Tap Down on Light Paddle 2x | 2 | Held | 0x0103 |
| Tap Down on Light Paddle 3x | 3 | Held | 0x0104 |
| Tap Down on Light Paddle 4x | 4 | Held | 0x0105 |
| Tap Down on Light Paddle 5x | 5 | Held | 0x0106 |
| Hold Down on Light Paddle | 6 | Held | 0x0102 |
| Release Down on Light Paddle | 7 | Held | 0x0101 |
| Tap Config Button 1x | 8 | Pushed | 0x0300 |
| Tap Config Button 2x | 9 | Pushed | 0x0303 |
| Tap Config Button 3x | 10 | Pushed | 0x0304 |
| Tap Config Button 4x | 11 | Pushed | 0x0305 |
| Tap Config Button 5x | 12 | Pushed | 0x0306 |
| Hold Config Button | 13 | Pushed | 0x0302 |
| Release Config Button | 14 | Pushed | 0x0301 |
Is it true that when using zigbee bindings with smart bulbs, the Blue 2-1 does not send any ramp rate to the bulbs when telling them to turn on/off? (as indicated in this thread for the Z-Wave switches)
If that’s true, please consider it a feature request! I would expect the ramp rate parameters to be applied to smart bulbs when using Zigbee bindings, too! 
2 Likes
This really would be a great feature if possible