Sorry for the confusion, it did not fix the problem.
1 Like
Thanks.
@Eric_Inovelli As I noted above, this is ONLY happening with my Inovelli lights (strip and bulbs). My OOMI, RGBGenie, etc are all fineā¦
Youāre seeing it with strips as well?
In my case I updated the firmware while I was still using Hubitat and had the association setup initially there and never had this issue. It was only once I switched to zwaveJS that it started happening for me. But I see youāre a Hubitat user, and @flipontheradio was able to recreate using PC controller software, so that kills my theory of the issue being zwaveJS related.
Could the issue possibly be on the Dimmer side? Iāve done numerous firmware updates on the dimmers since updating the bulbs, and thinking back I did one very shortly after moving to zwaveJS as well.
Iām on HASS.
Itās not on the dimmer side, as far as I know. I use Zooz and RGBGenie controllers, and experience the same issues with those. Only my Inovelli receiving lights display this issue.
Additionally ā Group 3 association behavior is wrong on the bulbs. Not sure where, as I havenāt sniffed, but only my bulbs donāt properly respond to group 3 requests from all my controllers, independent of brand.
I setup a small automation to try to force the misbehaving bulb to turn on/off. Very simple, when the switch is toggled, delay 1s (for association to do itās thing), check state of the bulb and if itās not the state it should be, send the command to turn it on/off.
You can see here, Bulb 2 is in the wrong state after the association command is sent.
Interestingly, even after it sends the manual turn on/off command, the bulb itself doesnāt respond.
As I type this, bulb 2 is on above my head.
Home assistant currently shows the bulb is off.
As done zwaveJS
But the bulb is clearly on
Iāve also noticed this only happens with on/off. Any dim commands respond as they should. If I press and hold the switch, the bulb will turn off.
Still an issue. Is this only Home assistant zwave JS? Has anyone done an issue on the ZJS server github?
I donāt think itās zwave JS at all since I have the same issue with openHAB and that doesnāt use zwave JS for the communication to the USB stick as far as Iām aware
I had three bulbs associated in my officer using Hubitat. The only time I had unreliable behavior was when bulbs were included with any type of security. Once I removed the security and associated all three bulbs again, it was smooth sailing.
I initially thought this was a zwavejs issue since I didnāt notice this issue on Hubitat but did notice on zwavejs. But now Iām leaning towards firmware based on my last post.
-The bulb misses (or ignores) the initial off command from the association. It is still reporting itās state as on.
-After sending a second off command via an automation, the bulb now reports itās state as off but is still on. This is why I believe it may be firmware related.
All mine are included with no security.
1 Like
Agreed. Maybe Iāll go back to 2.30 and see whatās what.
As far as firmware versions go, I see it on everything from 2.28 and up.
@EricM_Inovelli any thoughts?
1 Like
Itās been a bit since any posts were made on this topic, but Iām experiencing the same issue where one of three LZW42 bulbs associated with a LZW31-SN red dimmer occasionally donāt turn off or on with the others. My success rate with the one bulb turning on or off seems to be about 75%, and itās the one closest to the dimmer physically. I donāt know how to re-add a device to an association group with the PC Controller once removed so I canāt test different bulb order to see if it happens differently if another bulb is āfirstā in a group.
For reference, all of the bulbs have been updated to 2.31 and the dimmer is on 1.57 with 1.45 Holtek. Non-secure inclusion, Home Assistant for normal usage but association created using the PC Controller since zwavejs/HA doesnāt seem to have association capability that I can find. Using groups 3 and 4 (group 2 only does instant-on?). Also, Iām using the physical paddle on the dimmer to control the lights, so I donāt believe either HA or zwavejs is the culprit. Current configuration on the dimmer is as follows: Parameter 12 has all options (Local, 3-Way, Z-Wave Hub, Timer) enabled, parameter 21 is Neutral (if it matters), parameter 22 is Multi-Switch (Auxiliary Switch), Parameter 52 is Smart Bulb Mode. I can provide more configuration parameters for both the dimmer and bulbs if required. The aux switch behaves the same and is a GE Add-on (not sure what model number).
Since this seems to be a cross-hub/hub-independent issue, itās likely to be something with one or both of the firmware(s). Itās not totally a deal breaker since repeating on/off switching eventually fixes it, but it sure is annoying. Hopefully this info is helpful in bug hunting!
1 Like
Easiest way to setup association with zwavejs is using the zwavejs2mqtt add-on. You donāt need to use any of the mqtt features, most simply use it as a front-end for zwavejs. Under the device thereās a groups tab and you can add/remove associations from there. If you havenāt checked out the add-on yet, I recommend you do. It makes the whole zwave2js experience so much better.
1 Like
Inovelli is looking into this with the manufacturer.
1 Like
I know I made this thread a while ago, but just reiterating that this is still an issue. It worked indefinitely after factory reset as I mentioned earlier. However, again, I needed to heal the network for a different issue, and then the issue restarted with exactly the same symptoms.
This is incredibly reliably reproduced on my setup. Factory reset and add, repeat process until it actually works ā Heal network and it breaks again, where the āoldestā association becomes unreliable.
Has there been progress with the manufacturer? Can I send them my exact bulbs or something to help them reproduce the issue?
Iām pretty sure there is nothing going on between Inovelli and the manufacturer right now. There has been hints of an investment deal that should help de-sour the relationship.
Have you heard of any updates on this? Iām still experiencing it in a few places in my home.
I am in direct communication with Eric on this and the issue still remains and manufacturer is refusing to support at this time.
PJFās status is essentially correct still that they are negotiating a slew of new terms/products with a US-based partner and hopefully will bring them back onboard to start supporting their product.
Ultimately, itās frustrating because the manufacturer is unwilling to even debug the product even though itās a known issue.
1 Like
Hey folks, wanted to add some data points here. I started seeing this problem myself a couple weeks ago. TL:DR - get rid of any device on your network with S0/S2 security, see if the problem persists.
I run home assistant with zwavejsmqtt with a aeotech gen5 zstick (from 2016 so old-ish?). I have 50 devices on my network. I use a zooz zen34 remote switch controlling 4 lzw42s via direct association. The setup has been stable for about 9 months. About a month ago I started seeing the exact behavior noted above: 3 of the 4 bulbs would turn off. The last bulb was unreliable. I would see broadcast storms of repeated messages in the debug view. Adding a āback upā automation in HA to turn off the lights after a couple seconds to try to clean up the stuck bulb didnāt work. The only fix was to sit there for a minute or so fiddling with the on/off buttons until eventually everything turned off. I also have a lzw31 switch controlling 2 lzw42s outside my front door that started doing the same thing.
Following this thread I got my hands on a nortek husbzb-1 and rebuilt my network - no dice. I followed some crazy instructions to upgrade that stickās firmware to z-wave 6.09, rebuilt the network - it was even less stable. I swapped the zooz zen34 for a lzw31, nothing. On a whim - I went back to the aeotech stick and rebuilt the network but disabled S0/S2 security on all devices - rock solid performance. No message storm, lights turn on/off instantly.
Putting it all together - roughly a month ago - I added some lights and a lzw31to another room. That dimmer was the first device where s2 security actually worked during inclusion. Prior to that I had no devices anywhere on my network using security. My wildly uneducated guess is that I have some old devices with firmware that hangs/crashes when routing secure and insecure traffic.
I also started seeing network heals fail and started seeing devices randomly drop from the network
1 Like