Does this also include a fix for default level local for group bindings? Because that has never worked.i set 100 and it just turns the light on but not turn the lights on to 100%, it turns it on to the previous brightness setting. It doesn’t send a brightness command. (Home assistant and my switches are on 2.08)
1 Like
The default level sound similar to the problem I have with remote level. Firmware bug: defaultLevelRemote does not work - General Discussion - Inovelli Community
1 Like
It has never worked since I got the switches from the factory firmware to all the updates since.
We just got 2.12! I’m currently flashing all 30+ switches. Should be a fun night!
10 Likes
How’s that flash on ST?
Working as well as the mobile presence is in Hubitat. 
How’d the flash go? Any prelim experiences on reset issue? Thanks for sharing Eric!
1 Like
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.
13 Likes
Zigbee2MQTT does group binding as well… I have it working 100% of the time in two separate setups, one with 2x Blues and 6x A19 bulbs, and another with a single Blue and 5x GU10 color bulbs (all Hue). No Home Assistant needed.
1 Like
Yeah agree – that’s what I used for the Philips Hue video (I used ZHA and Z2M - both worked great) where I had like 13 bulbs or something ridiculous. Amazing speed. I’m hoping we can figure it out or push the other hub manufacturers to help support it.
1 Like
Do you know if default_level_local works on 2.13 for group binded lights?
I’m running multiple inovelli switches that all are binded to ZigBee groups with Philips hue bulbs in them and none do. default_level_local has a value of 255 but does not work. Even when I set it to 254 it suddenly became 255 again somehow but still doesn’t work.
Ideally based on what I read this parameter should do.
It should turn the binded lights on when pressed at the switch to whatever the setting is. My lights only turn on. Meaning they turn on to their previous brightness % and do not receive a brightness command in addition to their on command. So if their previous brightness was 1% as I use an off transition they turn on to 1% if turned on at the switch rather than 100%.
- 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).
Thanks for the update, @Eric_Inovelli. I’m eager to see this addressed when 2.13 is released. Wondering if you can provide a bit of context as to why lower non-neutral brightness was intentional (just curious as to what it was addressing). I still have 3-4 non-neutral switches I’m looking to replace, so hoping that the difference in brightness ends up being minimal.
I just asked the engineer – I swore he told me at one point, but I can’t find it in the chat. Hopefully I’ll have an answer tonight/tomorrow.
1 Like
Is that regarding the non-neutral issue or my question about default_level_local?
Oops, sorry, I for some reason only saw @Blue-cust’s response.
Let me share this with the engineer and see what he says today.
Just so I’m understanding correctly and I can possibly test it on my end (I don’t have the ability to do Group Bindings on SmartThings, but I can test on Individual Bindings).
You’re wanting to set the Default Local Level to xx% (let’s say 75%) and when you turn on the light switch that is bound to your bulbs, they should turn to 75%, correct? But in your case, they only turn on to the prior level?
Edit: I just tested this on Individual Bindings remotely and I am seeing the same thing (set remote level to 50% and my switch correctly went to 50%, but the bindings did not). Are you seeing the same thing remotely?
We are working on a 2.14 to address some trailing edge flickering (yes, trailing edge) so I will talk to him about this issue.
2 Likes
@Eric_Inovelli I’m not the person you’re asking, but I can confirm that I see the same behavior both locally and remotely on the Blue dimmers that are in smart bulb mode + direct bind to Hue bulbs. That is, the dimmer appears to ignore both of the defaultLevel settings and simply turns on to its previous level:
1 Like
Thanks! Yeah, Eric M and I were just talking about this and we’re going to try to test something with the engineer. Basically, right now it’s sending just an “On” command during binding, but we’re going to see if he can make it a, “Move to Level with OnOff” so that default level can be recognized.
I’m not sure on the implications for other bindings that are just On/Off bindings, but this is what we’re going to try to work through.
!!!
1 Like
Just an observation: the dimmers do appear to “pass along” the Command: Move to Level with OnOff (0x04) via bindings to the bulbs when you specify the level in a remote “On” command. It sounds like we’re saying that the dimmers aren’t using this Move to Level with OnOff command (with the values being set in the defaultLevelXYZ fields) when given either an On remote command or from a physical On button press.
Here’s a screenshot showing my dimmer (0x5589) sending that command as a broadcast out to the zigbee bulb group when I specify the brightness in my remote call:
So, to reiterate your point: This is the behavior we’re hoping for: the dimmer sending this Move to Level with OnOff command when given a physical button press if the defaultLevelLocal parameter is set to anything other than 255 (and similarly for the defaultLevelRemote parameter + remote OnOff commands).