Arrrrrgh, now it’s spreading again… now 4 of the Blues have bound themselves together, along with a smattering of zigbee plugs to boot. Pretty soon here, I’ll be able to simultaneously turn on/off every ZB device in my house with one of those switches.
And Parameter 51 doesn’t seem to be a reliable indicator anymore – one of those switches still shows “0” there.
This has been a fun ride, but my order’s now placed for mix of Zooz and Caseta replacements – I can’t have a bunch of switches in my house be this unpredictable.
Hopefully everyone else’s Blue journey ends happily!
ETA - I uninstalled Inovelli’s binding app yesterday after a trial experiment, so I don’t think that’s somehow gone rogue behind the scenes.
This sounds like the switches are not initialized and they are sending their commands to the global group. I suggest resetting the switch and rejoining it. Whatever platform you’re using track the logs and make sure the configuration is successful.
If that doesn’t solve it look for group bindings. There are some devices (Aqara switches, plugs etc.) that like to automatically add themselves to groups.
My 2 cents from afar… Feels to me like one of 3 things could be broken. The Innr plugs, the Inovelli Blues, or the HE. Given the Innr plugs have been running for a while that would be my last guess. The two new bits of software running in this network is the HE driver and the software on the Blues.
Since we can’t easily change the Blue’s software is it possible you have some other hub you could try? Home Assistant with zigbee2mqtt or zha?
The other option is logging. Can detailed logs that can be generated from the HE? I have nothing to base my guess on other than a gut feel and that’s the HE is configuring the switch somehow. Logs might give more info to confirm or thwart that theory.
Good call - I don’t have an alternate platform to try, and I quite honestly don’t have the desire at this point to crawl through any logs – today was pretty rough trying to make heads-or-tails of this stuff and I’m just frankly burned out on these switches for now.
I’m now shifting my focus on planning out my replacements, since these switches are in high-use areas and I need to address that ASAP.
I’ll definitely keep an eye on firmware and driver progress in the coming months - perhaps someday this bug will get figured out either by Inovelli (or Hubitat or whoever). If so, I’ll definitely consider dusting off my Blues again – they do have some pretty cool features that aren’t found elsewhere.
It started with the plugs, but the scarier evolution is that I’m now up to 5 Blues that have bound themselves together (turning any one Blue on/off also turns on/off 4 other Blues + plus the rando Innr plugs that somehow got sucked in too).
Thus far, reset / re-pair is a very temporary fix, but the bindings return pretty fast. I initially thought Parameter 51 was an indicator, but that’s not true anymore – at least one of the recently bound switches is showing “0” there right now.
It is a crazy deal for sure! Prior to all this, my zigbee mesh was strong, in tip-top shape and running super well… I had no problems doing any of the initial Blue installs yesterday and these crazy bindings didn’t start happening until today (I hadn’t been messing with anything today when I noticed them).
I thought maybe it had to do with a Hubitat power-down I did this morning, but now I’m not so sure – the worst of these bindings (i.e. switch-to-switch ones) started well after that shutdown.
Alright I read thru this entire thread and have a better grasp as to what’s happening.
I think what really needs to happen is we take a look at logs. I understand that’s probably the last thing you want to do and I don’t blame you so in the effort to save time, energy and frustration on your end we will come up with a gameplan and then list it out step by step so we only have to do it once.
Let’s take a break tonight and we’ll reconvene tomorrow.
In the meantime, we’ll pick up some Innr plugs to try to replicate. It’s a longshot to replicate things so it would be amazing if you could get us some logs when the time comes as it will point us in the right direction.
Who knows, maybe you got the special Halloween firmware
True dat… My one last hail-mary I’ll try to work on today (but I have a day job I that can’t keep blowing off too ) is to nuke the 5 infected Blues, and then restore a previous Hubitat database. Then clean up that old database and finally do a soft-reset & restore on my Hubitat with that clean database
That should clear out any hint of the Inovelli Zigbee binding app (just in case some leftover dregs from that is somehow behind this).
3 of my Blues are still working as hoped this morning (no rando binds), so that’s good news.
Wanted to give a quick update here in that we’ve received a firmware file that should fix this. It’s more of a patch that we will come back to later with the actual fix (let me explain) but we’re testing it right now.
What we believe is happening is that we put a feature on this switch that would allow you to start Zigbee binding directly from the switch itself (rather than have to go through the hub) and this feature is somehow being activated inadvertently.
We never could get this to work properly and it looks like it was never removed prior to production (as we were going to add it back later once we figured out how to get it to work).
So, the fix here is to remove this feature from the latest firmware. We will add it back in later on when we are able to get it to work. But at the very least, this should fix the issues we’re seeing here.
If you don’t mind, could you give us a day or so to test it out @hydro311? This firmware also has some other fixes in it that we’re testing so we want to make sure those work before releasing it publicly as Hubitat requires us to upload the file to their server for updating and we don’t want it to be released to everyone if there’s an issue.
I don’t think this is true that only the coordinator can initiate, see “End device binding” in the spec.
Devices like the RGBGenie remote depend on this behavior. After joining the remote to a network, you can walk the remote up to individual devices on that network and bind them into groups controlled by the remote. IIRC, some devices require special action before they will participate. eg, a Hue bulb needs to be power-cycled within the last minute or so.
Last time I checked, a factory-fresh Tradfri E1743 can force control Innr plugs on my network. I haven’t taken the time to dig into it, but if nobody beats me to it, I’m curious and could probably easily reproduce and capture some traffic.
@dmulcahey 's comment on group membership and the global group is interesting. I’m super new to thinking about the ZB spec, and am mostly just speaking up because I’ve seen similar behavior before. May be way off on root causes.
WOOT - I can wait to check out the update - thank you!!
I spent time this morning resetting all the Blues and then soft-resetting my Hubitat database to a “safe” prior backup to ensure any potential gremlins get cleared out.
I stupidly forgot the Blues work fine as a basic switch (w/ a load of course) when reset, so that’ll work fine for while here - it at least buys me some time to ride this out without my wife going totally nuts.
I sprinkled some spare Picos back in to take care of the bigger scene-control needs – they’ll work fine as a stop-gap.
If all goes well, I’ll just return the replacement gear I have enroutre - that would be awesome!
This whole reset thing was painful, but if (god forbid, ha) this fix doesn’t work, I at least now have a good, solid backup saved that’ll make another hub reset wayyy easier.
Thank you again – this is awesome news – I’m optimistic this will fix the issue (or at least get us a heckuva lot closer) – that’s super welcome news!
Hey just wanted to follow up here and see if you’ve seen any improvement? I thought I read in one of the other threads that you hadn’t experienced any issues with the latest firmware, but I wanted to make sure I wasn’t dreaming haha.