Home Assistant SkyConnect (Home Assistant Connect ZBT-1) - official Zigbee and/or Thread USB radio dongle from Nabu Casa

Hardware
, , ,
183

You choose to ignore that loads of users in this community and other home automation communities have reported the same or similar symptoms/problems with Aqara/Xiaomi device when using all types of Zigbee Coordinator adapters based on radio chips from Silicon Labs, Texas Instruments, Dresden Elektronik, and more in many different open-source and closed-source Zigbee implementations (including the ZHA integration, Zigbee2MQTT, deCONZ/Phoscon, OpenHAB’s ZigBee Binding, Hubitat, and Zigbee for Domoticz Plugin).

The most basic troubleshooting processes always consist of starting with the most obvious which is sorting out the known issues that are easy to workaround, thus removing those from the equation, and in this case, EMF/EMI/RMI is well known to cause huge issues for all Zigbee radios, and especially the Zigbee Coordinator, regardless of which Zigbee adapter you use and what Zigbee radio chip it is based on. If you choose to ignore that then you are starting your Zigbee troubleshooting journey at the wrong end.

And being affected by EMF/EMI/RMI interference is not just a “shortcoming” of the SkyConnect dongle but a “shortcoming” of all Zigbee radios and it affects all brands/models of Zigbee Coordinator adapters as well as devices, and those can clearly be seen in all open-source Zigbee implementations using any Zigbee adapter (as those do not normally try to hide the issues that EMF/EMI/RMI interference causes, unlike most commercial Zigbee hubs which have proprietary software that show nothing of what happens under the surface so the user only see if it works or not and not how good or bad it works).

It is hard to impossible to even start to troubleshoot to find the true root cause of any issue with a Zigbee device if it is located in a noisy environment due to EMF/EMI/RMI interference (also known as signal noise), and while it is possible to hide and hack around some of the symptoms of EMF/EMI/RMI interference in firmware and software this is, in the end, EMF/EMI/RMI interference impact on radio waves and electronics is only physics so the or the easiest solution is for the user just take some simple actions to avoid EMF/EMI/RMI interference in the first place, and that means using long USB extension cable in a USB 2.0 port as well as placing the Zigbee Coordinator and Zigbee devices away from USB 3.0 devices/cables, Wi-Fi radios and other known strong sources of EMF/EMI/RMI interference that spans over the 2.4GHz frequency range. Just check out this demo (which you will get the same result if using any other brand/model of Zigbee Coordinator adapter):

Maybe skim through these reputable references to understand this is the truth and not just excuses:

Then you choose to ignore the tips and confirmation from others about this thread that applies to all open-source Zigbee implementations using any Zigbee adapter → Xiaomi & Aqara Devices - Pairing & Keeping them connected - Devices - Hubitat

As mentioned in many home automation communities, some people have had great success using Aqara/Xiaomi devices with open-source Zigbee implementations using any Zigbee adapter but many others have huge problems, and that is because it depends on your overall setup, environment, and which Zigbee Router devices use, much more so than the actual Zigbee adapter you use and what Zigbee radio chip it is based on.

2 Likes
184

Sorry if I am hijacking a thread for SkyConnect. I have a Sonoff dongle E which I flashed today with multi pan firmware. I was able to successfully transfer my old zha backup and things worked for a few mins. I then did a restart of Home Assistant and Zigbee wouldn’t work, fails initialising. I posted logs in the below thread. Any one else faced similar issues with SkyConnect as it uses the same chip? I then flashed the zigbee firmware and migrated everything back.

185

Yeah that is definitivly something that is off-topic and should be in a seperate thread, not be discussed here.

186

I have a SkyConnect that is currently just sitting around doing nothing as I had to migrate back to my Sonoff Dongle-E due to the constant reliability and connection issues with my end devices on the SkyConnect. Call it just bad luck or there is truly some kind of issue with the SkyConnect, but for weeks on end, I just had to keep struggling with every Zigbee device in my house. That all stopped when I switched back to my old Dongle-E.

I didn’t have a chance to read through the entire thread here, but from what I can make out, if the main issue with the SkyConnect is that it’s susceptible to interference, then why not provide an aluminum shield case and an external antenna that we can solder on to the pcb, to convert it into something similar like the Dongle-E? Or is there anything directly on the PCB that needs to transmit or broadcast that it cannot be enclosed inside an aluminum case?

I personally don’t think that an extension cable of any kind will solve its problems, at least not for me. No matter how far I place the SkyConnect from my PC or any USB 3.0 devices, I have an insanely high amount of 2.4GHz interference in my vicinity due to how dense my housing complex is, and the only way to give it a better fighting chance is to shield it as much as possible from any interference.

I’ll gladly purchase an aluminum shield case + antenna adapter kit so I can actually use my SkyConnect again, and flash my Dongle-E into a repeater to further improve my network around the house.

187

I picked one up and am a newb at all of this.
A lot of fun for an old guy. And HA green.

I hooked up several Aqara entry sensors and a motion sensor for lighting to test function. Alarmo integration etc.

It was a little weird at first, of course I had no idea what I was doing at first. Works good.

I have a ranch home and the signal shows good everywhere, basement, furtherest room etc.

No repeater yet.:crossed_fingers:

Should anyone need a Skyconnect hookup here in the usa. When I bought mine their stock said 1800, @ $25 plus shipping. Still shows 1500 or so.

https://www.mouser.com/ProductDetail/Nabu-Casa/HASKYCNCT?qs=Imq1NPwxi770AoKCmeV2hQ%3D%3D

188

Zigbee Router devices are extremly important for your Zigbee network mesh to work so your need to sort that that ASAP or your batteries will drain very quickly. Read and follow these best practice tips-> Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage

Note that many Aqara and Xiaomi devices have buggy firmware that lock to device they are first paired to which means that you need to re-pair them if you later add Zigbee Router devices as they will not automatically move to better Zigbee Router devices. See → Not many people know that... A random collection of Zigbee trivia

189

@Hedda

Thank you, I will read this thoroughly.

Based on what I’ve read prior and I saw this too, I figured I’d have to add some mesh devices.
And pair the existing over again.

Theres only five so far, so not a problem or I hope

I’ll go with 3 and hopefully that will suffice. I already have Aeotec Zi in my cart from weeks ago. Two upstairs and one down.

I was mostly testing Aqara devices and other than the first device, have had no connection issues or pairing. No interference yet. And ive got WiFi all with my mesh WiFi.

Perhaps I’ll understand Zigbee better when I’ve absorbed this.:+1:

190

I know this isn’t much consolation, but my handful of Aqara devices have worked flawlessly, with both the Conbee2/ZHA and now SkyConnect/ZHA. There’s never been difficulty with pairing them, or them staying paired/connected. And that was before I learned that you could pair/re-pair a devices with the “Use this (router) device to pair a new device” option!

My Hue Motion Sensors, on the other hand, are an ongoing nightmare…

I feel like there’s a level of detail or interoperability that isn’t inherent to any one brand, but more environmental or system-specific, because when I read comments like “Aqara are known to have poor firmware”, that comment only seems to come out when someone has bad experiences with them, but never when they don’t. WHO has concluded that Aqara zigbee devices have “bad firmware”, based on what insights? Likewise, when someone has difficulty with Hue devices, Hue “being difficult” when not on its own Hue Hub is only offered as a response when there’s a problem, never when it works as expected.

Ergo, there is a level of uncertainty at play that isn’t addressed with unhelpful comments like “Brand-X is known for…”. And this is why I hate forums, they’re the best and the worst…

191

Update:

Some months have passed and I had at least 2 incidents with sky connect where it stopped working completely after updates and I even had to re-pair all my zigbee devices.

I realised after a while that most of the problems were related to the multiprotocol firmware, so I removed it and just kept ZHA.

After that, I saw less issues, for example Aqara sensors are not dropping anymore (except leak sensors, but that was known and accepted when I bought them).

So the root cause of issues with Sky connect is bad software, just as I said in my first post.

192

Regardless of what devices have issue with, always first be sure to follow all these best practices → Zigbee networks: how to guide for avoiding interference + optimizing using Zigbee Router devices (repeaters/extenders) to get best possible range and coverage

Bad firmware issues with Zigbee devices from Aqara, Xiaomi, and Tuya are constantly being brought up by by practically all developers of different community driven Zigbee gateway solutions (including developers of open source projects like ZHA, Zigbee2MQTT, OpenHAB, and Domoticz). See example this still ongoing 6-year old community guide thread for Hubitat which also applieas to all other Zigbee gateway solutions as well → Xiaomi & Aqara Devices - Pairing & Keeping them connected - Devices - Hubitat

Not heard any general complaining about bad firmware for Philips Hue devices.

There is however a general difficulty with new Zigbee devices that extend their feature-set beyond simple lighting and basic home automation functionally, as then developers will need to write custom device handlers (also known as quirks, converters, translators) that are special for each specific device, otherwise, it will not expose all attributes, see:

https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices (which are about ZHA quirks device handlers for Home Assistant GitHub - zigpy/zha-device-handlers: ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices. )

and

https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html (which are about zigbee-herdsman converters for Zigbee2MQTT)

Developers of all implementations, including commercial Zigbee gateways/hubs/bridges also need such customization for any special devices features and functions, see example these docs about device handlers for Samsung SmartThings Hub → Device Handlers — SmartThings Documentation 1.0 documentation

193

You are :frowning: ? - a new OT thread might yield a better responsef

194

Is the “Home Assistant Connect ZBT-1 Multiprotocol” a new hardware variant of SkyConnect? …

…or is “Home Assistant Connect ZBT-1 Multiprotocol” just a new name for existing SkyConnect USB stick hardware variant and this pull request is only preparation for any potential future hardware variants of SkyConnect that might or might not ever come?

Does anyone have more information about this hardware product named “Home Assistant Connect ZBT-1”?

Not sure but wondering if this ZBT1 hardware could possibly be an updated/improved board design variant or even an upcoming new product with perhaps a newer SoC model?

EFR32MG24 or MGM240P based SkyConnect + not using PCB trace antenna would sure be nice! :wink:

1 Like
195

I’ve googled ZBT-1 already, but still have no clue.

196

The only other thing I found since above post asking about “Connect ZBT-1” was that 5-days ago it was added and listed seperatly from SkyConnect in the README for the Silicon Labs Multiprotocol Add-on:

NOTE: This add-on has the option to automatically install the right firmware for Home Assistant Yellow, SkyConnect, and Connect ZBT-1.

My guess based on those PR commits the “Connect ZBT-1” might be a variant shipping pre-flash with OpenThread RCP firmware by default instead of EmberZNet NCP firmware like for the “SkyConnect”?

Selling two dongles with with same hardware but different firmware would direct new users to buy separate dedicated radio adapter dongles from the start, which should give them a better experience.

At least that would make sense to me if they now want to try to steer existing/new users away from using Multi-PAN/Multi-Protocol on a single radio adapter dongle and instead guide people to using a separate dedicated radio adapter dongles for Zigbee and Thread. Which is now more clearly recommended:

There is a third, experimental, firmware option that supports multiprotocol, which allows the Silicon Labs chip in these products to connect to both Zigbee and Thread networks with one radio. We announced our intent to release a firmware supporting multiprotocol when we launched Home Assistant Yellow and Home Assistant SkyConnect, and this firmware has been available since December 2022. It integrates the Silicon Labs SDK, which adds this support for multiprotocol. During the further development and testing of the multiprotocol firmware, we have concluded that while Silicon Labs’ multiprotocol works, it comes with technical limitations. These limitations mean users will not have the best experience compared to using dedicated Zigbee and Thread radios. That is why we do not recommend using this firmware, and it will remain an experimental feature of Home Assistant Yellow and Home Assistant SkyConnect. If you currently have the multiprotocol firmware installed but don’t actively use it to connect to Thread devices, we recommend that you disable multiprotocol. Nothing changes for current users of the multiprotocol firmware who are happy with their experience. The experimental multiprotocol firmware will remain available, but we will not recommend it to new users. Instead, we will focus on making sure the dedicated Zigbee and Thread firmwares deliver the best experience to users.

By the way, they also mentioned during the Home Assistant 2024.2 Release Party that the RCP Multi-PAN effort will be put on the backburner for now:

https://www.youtube.com/watch?v=8-YwXkgD3CY

The point made was there is there that are downsides with RCP Multi-PAN, (especiually once start adding more than a few devices), so it will until further notice Multi-Protocol support on a single radio adapter SoC chip always remain experimental. Now is instead always highly recommended to have one separate dedicated Zigbee Coordinator radio adapter and one (or more) separate dedicated Thread Border Routers (which can include a Thread Border Router radio adapter dongle).

Apart from limitingthe network size (total amount of devices) main disadvantages of Multi-PAN are:

  • Matter over Thread support using a OpenThread USB dongle like the SkyConnect is still very experimental (but this applies equally to using standalone OpenThread Firmware).
    • IT is still generally recommended to use external Thread Border Routers via Apple or Google.
  • RCP Multi-PAN requires constant updating of firmware as each major 4.x release breaks ABI
    • This in turns means that you will likley be forced to always use the latest cutting-edge firmware which may introduce new bugs that there is not yet any workaronds for.
    • There have been recent stability issues with Silabs Gecko SDK 4.4 and to some extent 4.3
  • Prior to Silicon Labs Gecko SDK 4.4.0 which introduce fast channel switching the Zigbee and Thread networks must share same channel or it would break things, (while after Silicon Labs Gecko SDK 4.4.0 the fast channel switching feature should in theory only cause a slight reduction in range if Zigbee and Thread channels are not the same).

@agners Can you share anything about Connect ZBT-1 or have any thoughts and input on wheather or not Nabu Casa will make and sell seperate dedicated radio adapter dongles for Zigbee and Thread?

197

This latest (not yet merged) pull request makes it sound like “Home Assistant Connect ZBT-1” is just a new name for the original “Home Assistant SkyConnect” + with that being related to Nabu Casa wanting to steer new users to not using it with MultiPAN/Multiprotocol firmware and use seperate dongles with dedicated Zigbee Coordinator or Thread/OpenThread firmware:

198

This was confirmed during the “State of the Open Home 2024” stream, so it is the exact same product:

Also mentioned that they now sold (or at least shipped?) over 100,000 SkyConnect dongles so far.

199

Is there a way to pick up the last released firmware version number for the SkyConnet ?

Would be nice having a sensor telling me to upgrade the dongle.

200

Not that I know, however if I remember correctly they mentioned a new feature idea on “State of the Open Home 2024” stream about possibly adding SkyConnect firmware updates as update entity (update entities platform) so that it would show up under repairs, and if so then I guess it could contain such additional information about the update?

201

Note! It is now recommended to no longer use the RCP Multi-PAN (multiprotocol) firmware that allows using a single SkyConnect dongle as a Zigbee Coordinator and Thread Border Router at the same time.

As both the RCP Multi-PAN (multiprotocol) firmware required to simultaneously run two different network protocol stacks like Zigbee and Thread/OpenStack concurrently on a single radio adapter/dongle has proven not to be very stable (at least not in larger networks) + the complexed architecture and many software components it is dependent is much more work for developers to maintain, it is now instead strongly recommended to always use separate radio adapters/dongles with dedicated firmware for each network protocol.

There is a third, experimental, firmware option that supports multiprotocol, which allows the Silicon Labs chip in these products to connect to both Zigbee and Thread networks with one radio. We announced our intent to release a firmware supporting multiprotocol when we launched Home Assistant Yellow and Home Assistant SkyConnect, and this firmware has been available since December 2022. It integrates the Silicon Labs SDK, which adds this support for multiprotocol. During the further development and testing of the multiprotocol firmware, we have concluded that while Silicon Labs’ multiprotocol works, it comes with technical limitations. These limitations mean users will not have the best experience compared to using dedicated Zigbee and Thread radios. That is why we do not recommend using this firmware, and it will remain an experimental feature of Home Assistant Yellow and Home Assistant SkyConnect. If you currently have the multiprotocol firmware installed but don’t actively use it to connect to Thread devices, we recommend that you disable multiprotocol.

The developers also mentioned during the Home Assistant 2024.2 Release Party video that MultiPAN/multiprotocol development will be put on the back-burner due to it being generally unstable and too much hassle, (so I would not expect any focused efforts to improve it, though some will probably still trickle though indirectly from upstream as Silicon Labs continues to release new versions of the Silabs Gecko SDK / GSDK which contains improvements, bug-fixes, and firmware updates).

So if you have previously enabled multiprotocol and you are currently only using SkyConnect radio dongle as Zigbee Coordinator and have no Thread devices connected via the SkyConnect radio stick then the new recommendation is to disable multiprotocol and continue using the SkyConnect as a dedicated Zigbee-only radio.

If you still want to use Thread via a USB radio dongle then the suggestion seems to be to buy another SkyConnect stick and re-flash that with the dedicated Thread (OpenThread RCP) firmware, so that they can it used separately for Thread-only as an OpenThread Board Router.

A tip is that can also re-flash the one to be used as Zigbee with the Zigbee EmberZNet (NCP) firmware to truley make it into a dedicated Zigbee Coordinator:

Click “UPDATE FIRMWARE” → “CHANGE FIRMWARE” in SL Web Tools then choose “Zigbee (EZSP)”:

image

PS: More detailed explanation on why should use separate radio adapters for each protocol found here:

202

FYI, new official Zigbee and Thread firmware releases for SkyConnect + Yellow and future Silicon Labs firmware will from now be released straight from the SiLabs Firmware Builder repository

As such the “old” silabs-firmware repository is now listed as archived and will not receive more updates but it will remain available as it contains all past firmware versions.

PS: Off-topic however interesting is that the silabs-firmware-builder now also contain Z-Wave Controller firmware for the upcoming official Home Assistant Z-Wave Controller USB adapter hardware that Nabu Casa is working on → Z-Wave is not dead - Home Assistant