I had this issue also a while back and had to exclude and then re-include the switches. After that, they started reporting correctly back into Home Assistant via the zwavejs2mqtt module.
I have upgraded all my switches to 1.57 (28 of them). So far, they are running really well. I did have the issue where they were not reporting state back in to Home Assistant but that was after an earlier upgrade and after I excluded and re-included them, they are working fine.
I am seeing a small issue with some of the switches where I have no load on the line out pole. I use these switches as aux switches and have them paired back to the ‘load’ switch via z-wave associations. I found this when Home Assistant launched its new energy monitoring graphs.
I haven’t narrowed it down to all, but at least two of these aux switches with no load, when turned on, are reporting 1.6W of energy being consumed. The total power used report is also going up. Is this expected? Could it be it is reporting the 1.6W of power being used by the switch itself?
Happy to provide more details if this is not expected behavior.
P.S. This isn’t a huge deal but want to make sure it gets logged if it is an issue. Also, Inovelli for the win with the power reporting and visibility into HA whole home energy monitoring!
Just one question when you re-included them did you use S2 Authenticate ?
I tried rebooting the hubitat hub and pulling the air gap. Switch status still isn’t updating. If I click the refresh button, it does fix the current state the light is in.
I don’t think so.
Apologies if I am not using the right terminology, but when you say S3 Authenticate, do you mean include them as a Secure Inclusion?
If so, then no. I re-included my switches using non-secure inclusion as I have read that really just smart locks and access systems should be included using secure inclusion. I believe it’s not recommended due to the increased traffic secure puts on the zwave mesh.
There are 5 security levels supported by Z-Wave:
- S2 Access Control
- S2 Authenticated
- S2 Unauthenticated
I have read that really just smart locks and access systems should be included using secure inclusion.
Locks and door controls that grant access to secured areas should use S2 Access Control; Devices outside secured areas (e.g., a temperature sensor on your back porch) should use S2 Unauthenticated. Everything else should use S2 Authenticated if possible*.
I believe it’s not recommended due to the increased traffic secure puts on the zwave mesh.
S0 specifically generates 3X the traffic as either Insecure or S2 security, and that is one of the reasons it should be avoided today; S2 security levels should not place significant additional strain on the network beyond Insecure.
I would avoid Insecure if at all possible; Anyone in range of your network can snoop on any message sent to/from any Insecure device, and can inject fake messages to/from any Insecure device.
*Devices communicating via associations have to share at least one security group in common. If a smart bulb only supports S0, that might require placing the smart switch into both the S0 and S2 Authenticated groups if you want to control the bulb via associations.
That’s great information that I had not heard before! Thank you!
Some good Information Darthandroid, I figured as a beta firmware, Eric would want to know what is working and what is not. From all the tests that I have done, seem like there is an issue with 1.57 beta with S2 authentication with Hubitat C7 build 18.104.22.168. Just wonder if anyone else has noticed the same thing with a similar setup. I do have older Hubitat hubs I can test with.
I understand that should be the case. However, in practice that does not appear to be the case. I find it much more difficult to pair new devices with S2 and if I get them to successfully pair with S2, they seem to respond slower than Insecure devices.
Certainly for locks and other security-related things I would not use Insecure pairing. But for lights, switches, temp sensors, and other non-security things I’ve had much better experience pairing them Insecure.
Dislaimer: This is just my own personal experience and is not a recommendation for others to do what I do.
The plot thickens! That’s the feedback I had always heard as well. I wonder if it’s not so much a network bandwidth limitation as a processing limitation of the endpoints (hub, switch, etc). I don’t know the chip design well enough to understand if the encoding/decoding adds processing time to a request.
If it were the case that the network is not more congested with S2 but the endpoints took longer to process the messages, you would both be right!
If someone wants to change my lights have at it. I’m completely insecure minus locks and garage door and its LIGHTNING fast on HA and ZJS.
In fact, I ran a color change on ALL 27 of my inovelli devices last night just to see HOW fast it was, and it took less than a second for all of them to change colors. I even set it up so that the first and last were next to each other.
I did recently switch hubs to HUSBZB-1 and completely reset my entire network, but it seems to be running so so so so much better than my zwave_me stick. Plus i got zigbee so I could toss my ST hub where it belongs, in a bin in the basement.
Agreed! I have no worries about somebody sitting in my driveway trying to hack into my zwave network just so they can turn lights on and off.
you may want to re-phrase that
Just wanted to make sure this added in case someone tries S2 on HA with zwave-js. Z-Wave-js currently doesnt support S2, it is currently being worked on tho.
zwave-js does support S2, however you might not get it to work on red on/off switches.
[quote=“EricM_Inovelli, post:11, topic:8572, full:true”]
There are some users that have had to do a factory reset after installing this firmware.[/quote]
I went from stock to this firmware on the whole home (my bad), and I’ve noticed a lot of lights have a brief power cut (a single flicker) every 15-30-60 seconds. I have tried air gapping the units. It’s been several days now and I’m not relishing the thought of re-configuring all of these devices in Home Assistant. Does a factory reset just overwrite the settings of the dimmer with it remaining a part of the Z-Wave network?
If not, will going back to a previous firmware work, and do I need to go back to the stable firmware, or should I start trying previous betas?
Edit: I flashed the stable firmware and I’m still getting the blink/flicker effect every so often. What should I check at this point? A configuration setting? It looks like the dimmer was reset as the default color came back, etc.
Edit 2: Just noticed when set to their highest brightness they blink quite often. Lower the brightness, and the blinking appears to stop (didn’t test for long). Is this a known issue of later firmware? Previously they didn’t blink. Setting the upper limit may be my solution there.
FYI: The Generic hub guide fails to document the steps needed to flash the second file, and only covers the first one. If you were not paying attention, you might think you were done. I realized something was missing (I have two files, after all) and eventually found the missing details in the SmartThings guide.
- Did you update both targets with compatible firmware versions?
- Did you perform a HARD reset (config until red (20s) then release)?
Luckily, in HA if you exclude a node then include it and name it the same, HA will treat it as the same entity so all of your automations/scripts, etc. will see it again and behave the same (HA does this the RIGHT way).
That is nice! Its really annoying that ST and HE re-join them as new devices and leave broken links in all the automations.
Before anybody jumps on me, I know there is a ‘Replace’ function that can be used sometimes. But seriously, it would be sooooo much BETTER if HE could do exclude/include the way its done in HA.
For ST you need to change the “is” to a “was”. It was in the old Classic app but it’s not in the new one.
So you are correct:
Is firmware 1.57 final now and out of beta?
A LZW31-SN I received yesterday was preflashed with this firmware, so I’m wondering if there is a final production version or if the “beta” is the final.
Yes, 1.57 is the production version now.
For what it’s worth I got the secondary controller. Method working with ST so I don’t have to exclude when upgrading firmware.
So far it’s working very well as long as you follow the steps explicitly.
Yes , HA method is very nice, I’m probably going to dust off an RPI4 and install it and ease my way into it.
Thank you for confirming. As a quick heads up, this page still refers to 1.57 as beta.