Going on 5 hours and still connected. I’m cautiously optimistic… typically it disconnects within a couple minutes to 2 hours.
Still working 9 hours later… We will see if it’s working in the morning!
I need to lay off the gifs…
This is interesting guys – hopefully we’re onto something!
I gif too much too.
Is it pronounced gif as in gift or jif as in jiffy?
gif from gift… but you will find many people that argue that.
Yes, there really is a site about it at this point…
G-I-F, or Gulf India Foxtrot. Working in the IT field for 35+ years, clear and concise communication is more important than trying to make a cutsey word out of a TLA or FLA (*) that doesn’t convey the proper spelling…
(*) TLA = Three Letter Acronym, used in sarcasm as an explanation of why TLA’s should be avoided.
It is pretty crazy with acronyms out there. I work for Xerox and for a very long time we have had an actual site you could go to and search for acronyms to try to figure out everything people were including in their documents.
TLA/FLA were new to me… thanks for lighthearted moment.
It is still working!!!
It has now been 19 hours since making that change.
I did however see a strange behavior a couple times while turning the light on and off this morning. I have my ramp rate set to 2 seconds. When tapping the light button, the light turned on in 2 seconds. When turning it off, it took about 10 seconds to dim. strange… I’ll try and get a video of it. Next time I toggled the light it worked as expected. 2 seconds on - 2 seconds off.
I think that might have been a one of strange occurrence. Still holding my breath that this “fixes” the issue and that it could be completely fixed in a firmware update in the future. @EricM_Inovelli I’m happy to try any beta firmware when we get to that point. I have a USB Stick paired to my Hubitat as a secondary controller and have done a few updates to my red dimmers with the desktop Z-Wave PC Software, so I’m already familiar with the process.
Hopefully, there is a thank-you in a future changelog in it if this leads to the fix!
I live in a very small house, where the WAF laughs at home automation because every light switch in the house is within 10 steps. Three LZW30-SN’s, one ancient GE/Jasco switch, two stray Z-Wave contact sensors, a motion sensor, and a siren. Many of the posts I’ve seen in various HA forums are from people with 25+ Z-Wave devices.
If this winds up fixing (or at least partially mitigating) the disconnect, let me add an additional question…how many Z-Wave (and Plus) devices are on your mesh?
Rationale: My first disconnect may have been triggered by a Z-Wave mesh change shortly after installing the switch, since it was initially paired to my hub from a different location in the house. Once the mesh settled, it took four days of intentionally trying to lock it up to make it disconnect again. If people with more frequent disconnects also have 25+ devices on their Z-Wave meshes, their increased congestion and multi-hop paths may be slowing down the Z-Wave side even more…causing the 2.4GHz receiver’s buffer in the switch to overflow more frequently.
If someone’s canopy module still disconnects but less frequently, we should not rule this out as the cause. The canopy module is probably still sending status updates and other packets, and all that we are doing is lightening up the load by disabling energy monitoring packets…
I just counted my Z-Wave devices. I have 30 in my house. All Z-Wave Plus.
3x LZW36
15x LZW31-SN Red Series Dimmers
2x LZW30-SN Red Series Switches
2x LZW42 RGBW Bulbs
1x Dome Water Shutoff
1x Aeotec Gen5 Siren
1x GE Motion Dimmer
2x GE Fan Switches
2x GE Outdoor Plugs
1x USB Z-Wave Stick
I’m still up and running at 18 hours. I’ve been trapping logs out of Hubitat just in case, but I don’t think they are going to give up much info.
The one thing I did notice yesterday was when I air gapped the switched, yesterday, I (somewhat) intentionally sent the switch several commands quickly, namely using the fan’s rocker switch to speed and I had to air gap the switch again only a few minutes after the primary failure reset.
I just tried to do the same thing and I definitely had some slow down/hiccup in response time, but the “buffer” seemed to eventually pick up.
I’m going to test the switch out again shortly to see if I can force a failure. Again the logs don’t look like they are telling me much, but I am trapping them.
Most definitely!
Also, just an update, the firmware engineer has been trained in (as in riding a train) to the manufacturer’s headquarters and will be stationed there until the root cause is discovered. He’s created a 2.4 Ghz sniffer which will monitor network information as well as created an anti-interference function that we’ll be testing this weekend.
The communication channel frequency is 2402 Mhz, whereas the frequency during pairing is 2405 Mhz, so we’re also suggesting to avoid Channel 1 & Channel 2.
We’ve also floated the theory of energy monitoring causing issues and we’re monitoring that as well.
One thing we will also need help on if possible is to start collecting back some of these problem canopies/switches so we can send them to the manufacturer for testing. We’ve sent on a couple early beta units that had similar issues, but the manufacturer has not been able to replicate the issue on their end.
Currently, they’ve pulled 15 production models and are running them in the same room, shooting commands to/from to try to replicate this issue and have not been able to replicate anything. One thing I’m not certain on is if they have them paired to any hub or anything, so I’ll check that.
Curious to see if this energy monitoring theory pans out!
@Eric_Inovelli, if it is determined to be a firmware issue with the canopy has there been any discussion as to how we will push a firmware update to our units?
This isn’t just the energy monitoring. Disabling that just lightened up the RF traffic. Please have them do their testing with a busy/jammed Z-Wave mesh, and reporting usage data to a paired hub.
Another crazy “while we wait” thought. Someone mentioned accidentally pairing two switches to one canopy module. If this can be repeated (and only one of the two switches is paired to a Z-Wave hub), it would be interesting to see if the paired switch disconnected and the un-paired switch can still control the canopy module. This scenario would just about completely rule out the canopy module as being the location of the bug…