We are releasing a beta firmware for LZW30-SN users that would like to take care of some of the bugs that they may have experienced. There are a few enhancements as well.
This firmware should be stable, but if there are any issues, please let us know. I recommend updating one switch and testing it out for a week or two before updating your whole collection.
There are instructions included in the link.
Update: Firmware 1.16 has been replaced with 1.17 that has more bug fixes and enhancements. Info can be found here:
@EricM_Inovelli - Dang…guess I have something to do tonight.
I was really hoping to see an adaption of configuring the On/Off for single pole or 3/4-way modes like the dimmer models. I think this would help a lot of issues utilizing dumb switches with the On/Off models.
That is actually something we have really been discussing with our manufacturer (over the last few days) and I wouldn’t rule it out as something that we add by itself in the near future (v1.17). There is an auto detect method on the current firmware that works most of the time, but it would be great for users that have problems with it. A config parameter that allows the user to select 0-Auto, 1-Single Pole, 2-3-way dumb, 4-3-way aux.
It will be available for OTA like this beta is. Do you mean on a particular platform? Some hubs can do OTA currently (not many), but we are working on getting it working with a couple other hubs.
Edit: What I meant by “working on getting it working with a couple other hubs” was that we have been in talks with a large mainstream hub company about their Z-Wave OTA strategy and we are patiently waiting for @bcopeland to wrap up his work on Hubitat. I just didn’t want to call him out specifically because I feel like we have bugged him enough already.
I just updated a couple of my switches, and I can confirm that this issue is indeed fixed: “Fixed when local protection is enabled, the settings for “State after power restored” did not work.”
Also, I found an easier way to do the OTA update for those that want to avoid the hassle of all the exclusion/inclusion. I just bought a second Z-Stick, included it on my existing Z-wave network, and performed the OTA update from there. HomeAssistant didn’t mind at all!
** EDIT **: Of course I figure it out right after I send this. I saw a post on HE where @bcopeland mentioned something about association group 1. Looking at those devices they had 01 and 6E in my association group 1. No idea how they got there as I haven’t messed with associations on those devices, but once I removed the 6E (01 must be there) everything started working instantly. So it looks like it was hanging up on sending out the events to the associated devices and getting delayed. I’m going to leave the post below here so you can see what I was talking about.
Hey @EricM_Inovelli. I’ve updated all my Red Series Switches to the latest firmware but I’m seeing a delay in the local responses sent and curious if you have seen this. I’m running on HE and write my own drivers so I am able to track what is happening.
Basically if I turn the switch on/off physically, I get the “CentralSceneNotification” notification almost instantly that a button has been pushed, and then a “SwitchBinaryReport” a number of seconds later to signal that the switch has been turned on/off which causes any automation based on the on/off even to execute 6s+ later. I am also getting multiple “CentralSceneNotification”, “SwitchBinaryReport” and “MeterReport” events happening and this is on all of my switches. Here is an example of some relevant logs to show this.
This is what happens when I physically turn the switch on/off.
01:17:37.440 pm info[zwaveEvent MeterReport] Power report received with value of 0.0 W
01:17:37.428 pm info[zwaveEvent MeterReport] Power report received with value of 0.0 W
01:17:27.783 pm info[zwaveEvent SwitchBinaryReport] Switch Binary report received with value of off
01:17:27.754 pm info[zwaveEvent SwitchBinaryReport] Switch Binary report received with value of off
01:17:21.834 pm info[zwaveEvent CentralSceneNotification] Button '6' was 'pushed'.
01:17:21.806 pm info[zwaveEvent CentralSceneNotification] Button '6' was 'pushed'.
01:17:15.673 pm info[zwaveEvent SwitchBinaryReport] Switch Binary report received with value of on
01:17:09.907 pm info[zwaveEvent CentralSceneNotification] Button '1' was 'pushed'.
01:17:09.854 pm info[zwaveEvent CentralSceneNotification] Button '1' was 'pushed'.
If I turn it on via a zwave command it works almost instantly. A basic report comes in almost as soon as I send the command.
01:18:51.693 pm info[zwaveEvent MeterReport] Power report received with value of 0.0 W
01:18:51.671 pm info[zwaveEvent MeterReport] Power report received with value of 0.0 W
01:18:44.346 pm info[zwaveEvent BasicReport] Basic report received with value of off (0)
01:18:41.512 pm info[zwaveEvent MeterReport] Power report received with value of 0.0 W
01:18:41.479 pm info[zwaveEvent MeterReport] Power report received with value of 0.0 W
01:18:37.317 pm info[zwaveEvent BasicReport] Basic report received with value of on (255)
As you can see the power reports always coming in much later though. I have all power reporting disabled on all of my switches but that report comes in due to changes in the latest firmware.
I have been able to work around one of the issues at the driver level allowing the automation to occur when I physically turn on/off the switch right away.
However, there is an issue if I try to turn the switch off too fast it will then hang up for a number of seconds before sending the proper zwave events back to HE.
I wonder… If the weird associations were on the device before… If this is what was causing the weirdness we saw in firmware updating this device…
Very possible. But I just went through all of my devices and most of them had a combination of 3 ID associations.
Looking into it further. Those all relate to the secondary zwave controller which i was using for sniffing. 2 of the 3 were older IDs as I had added and removed it a few times. So something new I’ve learned to be careful of as well. I guess it adds itself in automatically at some point.
The great news is now that I’ve cleaned this up and all the noise from power reporting things are fast and working well (until maybe tomorrow when a new issue will arise).
The “GET” option in the Z-Wave PC Controller is not pulling back info on the current firmware so it doesn’t let me flash the new one. Any idea why?
I wonder… If the weird associations were on the device before… If this is what was causing the weirdness we saw in firmware updating this device…