Blue Series 2-1 Switch - Enhancements/Bugs Thread

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 -
image

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)
image

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 :astonished:

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 :confused:

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!