Blues binding themselves to Innr plugs?

Any history of hauntings or native burial grounds on your property? Tis the season…

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.

1 Like

First just wanted to say sorry about the frustration. It sounds like a disaster and I understand the need to switch.

For what it’s worth, we reported this thread to the engineers and @EricM_Inovelli is on it.

Although, this seems to be the only thread and time this has been reported (that I can tell - it’s been a hectic couple weeks) so there’s not much to go off of.

If you’d like to allow us to make this a happy ending, we’re here to work with you, but if your mind is made up, I completely understand.

1 Like

reset & re-pair didn’t help – it looks like it works initially (just like the initial installations), but the bindings all return within a couple hours.

I’m now up to 5 switches that have bound themselves together. I just hope the remaining 3 somehow escape this plague!

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.

1 Like

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.

Thanks Eric! I’ll definitely lurk in the community here in the coming weeks & months – I’m confident a future firmware or driver update will get to the bottom of this eventually.

At that point, I’ll likely dust off a few of my Blues again - they are (otherwise) awesome switches overall!

No worries - are you open to questions from us to help diagnose things? You’re right, many people do have those plugs and I’d hate to see this issue continue.

1 Like

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.

1 Like

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 :ghost:

3 Likes

This has got to be unintended hub control. Bindings can’t/won’t be initiated by anything except the coordinator in the zigbee spec.

I think there is something up with the binding app or the HE installation in general…

2 Likes

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 :sweat_smile:) 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.

5 Likes

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.

1 Like

That great news - thanks Eric!

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!

2 Likes

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.

Thanks for following up, Eric! So far so good on Hubitat with 2.05 – sounds like EricM will release 2.08 on Hubitat relatively soon, and I’m confident that will really seal the deal.

After updating to 2.05, I had one Blue bind to a bunch of Innr plugs and one Leviton plug-in zigbee dimmer, but I factory reset it & re-paired it, and it’s been fine since.

You guys are doing great dealing with all these unanticipated issues - thank you all!

1 Like