Disclaimer: This is long, but hopefully it gives you an explanation and confidence we’re working on it. If you don’t feel like reading, the short answer is 2.12 did not work, but 2.13 has been working great and I need to continue to test for a few days to be confident.
What a fun weekend… spent it all flashing all the switches to 2.12 which at 20 min x 38 = pure sadness.
2.12 unfortunately did not fix the binding issue related to routing tables – however, we finally uncovered what is happening and do have a fix in 2.13, which I’ve been running since Saturday night / Sunday morning and it’s been working much better.
Let me give a better overview of the problems I was experiencing and also address some of the ones outstanding in this thread. I noticed in my initial comment a few days ago, I didn’t really give you guys a detailed explanation of my setup.
Zigbee Binding Issue
I have 10 different scenarios where Zigbee Binding is used:
- 5x Instances where 1x Inovelli Switch is bound directly to 1x Hue bulbs (1x A19 and 4x Can)
- 1x Instance that has 1x Inovelli Switch bound directly to 3x Hue bulbs (A19)
- 2x Instances where 3x Inovelli Switches are bound together
- 2x Instances where 1x Inovelli Switch is bound directly to 2 or 3x Osram Under Cabinet Lights
Here are my success rates in each instance working properly:
- I have a 99% success rate with the 1x Inovelli to 1x Hue Bulb.
- I have a 75% success rate with the 1x Inovelli to 3x Hue Bulbs
- I have a 40% success rate with the 3x Inovelli Switches bound to each other
- I have a 20% success rate with the 1x Inovelli Switch bound to 2-3 Osrams
Some of you are thinking, “dude, did you not realize you had a problem?”. That’s an excellent question and with everything in hindsight, I guess I did lol. With the Osrams, I read in the SmartThings forum that they had plenty of their own issues so I just chalked it up as they were the culprit. With the Hue bulbs, given that most of them worked flawlessly, I just figured there was some weird binding issue with the 3x that maybe I didn’t do it right or something went wrong and I just never fixed it. The Inovelli to Inovelli though, that one did bother me and I could never figure it out bc every time I set it up, it worked perfectly, but then failed later. Again, I just figured it was SmartThings being SmartThings.
Non-Neutral Brightness Issue
The disclaimer here is that I wear glasses and also have four kids which distract me and I don’t pay as much attention to light levels.
That said, when this was called out, I did some investigating and did confirm with the engineer that this was, “a feature, not a bug”.
I have 3 different areas where I have non-neutral wiring.
Overall Network Issues
This issue that’s been reported I haven’t directly seen as I don’t have a way to monitor it in SmartThings, but some of the problems I was experiencing indirectly (binding specifically) stemmed from this in looking back.
Rebooting Issue
I haven’t experienced this one personally, so I can’t speak to it, but from what I understand from the engineer is that it has to do with the memory allotted for neighbor tables. If there is network flooding, the switch can become overwhelmed and crashes. I’m sure there’s a much better technical explanation for this, but that’s all I’m able to comprehend.
Ok, so now that you have a background, let’s get into the results as well as path moving forward.
Firmware 2.12 Changes & Results
- Doubled The Size of Neighbor Tables: The bindings that were failing happened to be in very high network areas located right next to my hub (or very close). The theory was that these switches that held the binding information were getting pounded by network traffic causing them to lose the binding information stored in the table (this may explain for some of you, the rebooting issue).
- Reduced Unnecessary Zigbee Broadcasts: I don’t know exactly what this means other than what it says, but I do recall looking at the Zniffer logs and being completely overwhelmed at the traffic, so I’m guessing a lot of that was better optimized.
- Optimized Non-Neutral Brightness: This has improved significantly and it really is night and day (and I am embarrassed that I missed it – need to get a better prescription).
Upon testing this, I was optimistic and at first, things started to work perfect. Even the pesky Osram lights were working great! But then everything started failing again and this is where we discovered some additional information:
- SmartThings (via EZSP) only supports 26 neighbor tables
As soon as I brought the count down to 26 devices, the bindings worked flawlessly and NEVER failed. I mean NEVER. But as soon as I started adding in more devices, sure enough, they started to fail.
I thought, “Are you kidding me? This isn’t good bc this is something that is out of our control.”
There is no present way to make it so that the switches preserve and force the route for bindings. This part of the code is owned by Silicon Labs and is not open source (we are working with them).
We then found a potential solution that should work in the interim while we wait for Silicon Labs for advice and that is that we can put a feature in the switch that at least saves the binding table (it can’t force the switch to use that table, but it will remember it and if it fails, the switch will revert to that table and it will work on the second try).
Firmware 2.13 Results
So the big moment… what happened with 2.13?
Well, I must say that I’m pleased with 2.13 in the sense that the binding failure rate on the first go-around has increased dramatically and if it fails, it 100% works on the second time.
Here are the results so far:
- I now have a 100% (up from 99%) success rate with the 1x Inovelli to 1x Hue Bulb.
- I have a 100% (up from 75%) success rate with the 1x Inovelli to 3x Hue Bulbs
- I have a 100 (up from 40%) success rate with the 3x Inovelli Switches bound to each other
- I have a 90% (up from 20%) success rate with the 1x Inovelli Switch bound to 2-3 Osrams and a 100% success rate on the second try
Again, this is only after testing for a day, but what I can say is that these bindings would fail within 10 minutes before when I was testing it on < 2.12 firmware.
Moving Forward
I asked the engineer what he recommends for best practices with Zigbee Bindings moving forward and he replied with the following:
- If using Individual Binding, please keep it to 1 device (ie: 1x Inovelli Switch to 1x Zigbee Device)
- If using more than 2x devices, use multi-cast (Group Binding)
The problem with #2 is that some hub/gateways do not have a way to do multicasting and that’s where we’re working on a solution. I think the only one that has a current solution is Home Assistant (EDIT: SmartThings now can do this).
–
Those of you that have SmartThings and Hubitat (talking to myself here too), you’ll have to use individual binding until either the platform releases a way to do multicasting or we can come up with one (again, we’re working on it).
All of my test results above are with individual binding, so rest assured, this firmware still works great, it’s just that individual binding is not the preferred/optimal way to do bindings if using more than 2 devices.
–
We are also working with SiLabs to see if there is a way to force routes, but we do not have a TBD on that as they can be hit/miss on helping.
–
Any questions, I’m happy to answer as best as I can. As mentioned, I want to test for another few days to make sure, but I think after that, everything outstanding has been addressed.