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

Hardware
, , ,
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:

1 Like
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

203

Is anyone else having an error with their SkyConnect/ZBT-1? It’s no longer showing in my hardware section, and all I get is this red bar with no message.

image
image1797×108 2.23 KB

And in the logs I’m getting an error

Logger: homeassistant.config_entries
Source: config_entries.py:2894
First occurred: 13:01:48 (1 occurrences)
Last logged: 13:01:48

Error occurred loading flow for integration homeassistant_sky_connect: cannot import name 'CONF_DEVICE_BAUDRATE' from 'zigpy.config' (/usr/local/lib/python3.12/site-packages/zigpy/config/__init__.py)

I’m running OS 13.1, with Supervisor 2024.09.1 and HA 2024.09.03. The dongle is currently running the multipan firmware, but I want to convert back to the standard zigbee only firmware. I can’t exactly do that in the current environment as the stick doesn’t show up anywhere (although I can still use zigbee2mqtt and the multiprotocol addon to control zigbee devices)

204

I poked around in the HA core code, and it is a bit of a mystery to me as why you are seeing that particular error. Is it possible that you also have the ZHA Integration showing up in the UI->Settings->Integration? (if I remember correctly the ZHA Integration may not actually say “Zigbee Home Automation” but something like “Sky Connect” with the Zigbee icon)?

205

You can not use a single SkyConnect to Zigbee2MQTT and the ZHA (Zigbee Home Automation).

The zigpy message means that you have ZHA integration but you mentiln that you use Zigbee2MQTT.

You need to buy another Zigbee Coordinator to use seperately if want to use both ZHA and Z2M.

Zigbee Coordinator is a serial devoce so limitation goes for all Zigbee gateway applications.

Read the ZHA docs → Zigbee Home Automation - Home Assistant

Note that ZHA only supports connecting a single dedicated Zigbee Coordinator radio adapter or module with a single Zigbee network and that the Zigbee Coordinator cannot already be connected or used by any other application.

206

Thanks, but ZHA is not in use, only Zigbee2MQTT

207

Yeah I understand that you say so but that zigpy message you are getting seems to indicate otherwise. So are you really 100% that you do not have the ZHA integration installed and it is trying to connect to your Zigbee Coordinator? If you do have the Zigbee Home Automation integration installed but not using it then you should disable or remove or at least make sure it is not trying to connect to your Zigbee Coordinator (which the zigpy mesaage suggests it is doing).

I might be wrong (as I am not using the multi-protocol addon or multi-pan firmware) but far as I known ”zigpy” is a library that is only used by the ZHA (Zigbee Home Automation) as a dependency. At least to me a message that mention ”zigpy” suggest that you have ZHA installed.

Regardless, you should flash the SkyConnect with EmberZNet NCP firmware and disable the multiprotocol addon then reconfigure for that as Zigbee2MQTT does not officially support it (and it is experimental anyway so not even recommended for ZHA). That information is available in SkyConnect docs as well as mentioned in Zigbee2MQTT docs too. See

And