How to Configure Built-in Zigbee Radio (Home Assitant Yellow)

I’m brand new to HA, and I received my Yellow a couple of months ago and, at the time, the Zigbee radio seemed to be OK. (Full disclosure, I never had any reason to try it, so I assumed it was OK.)

Recently, I had reason to recover my HA system from a backup and reconfigure it again. Now, the Zigbee radio integration is missing. I tried to add it using Add Integeration which is OK until I try to configure it. Every time I try it, it gets to the end, then I get the dreaded Failed to Connect message. My configuration steps are:

  1. Select Zigbee Home Automation integration, and start configuration

  2. Select Serial Device Path as /dev/ttyAMA1 - Yellow Zigbee module - Nabu Casa (Second radio button) and submit

  3. Select Radio type as EZSP = Silicon Labs EmberZnet protocol: lelabs, HUSBZB-1, Telegesis. (First radio button option) and submit

3 Next page confirms device path, port speed as 115200 and data flow as Hardware (makes no different if I sent software, the results are the same) . Hit submit.

The I get the dreaded error message Failed to Connect

The error log shows:

A quick check of /config/.storage/core.config_entries displays:

Screenshot 2023-05-07 at 1.32.01 PM

Really confused and would appreciate any guidance on resolving this issue.

Thanks in advance.

Hi, Did you get this fixed? I am having the same issue.
Thanks

Hi.

Sorry, just reread your post and realized I responded about the Border Router, not the Zigbee issue.

I did NOT solve this issue. I just tried to configure the Zigbee integration, specifying the Yellow built-in radio, and it failed (again). Really no idea who I can speak to that can resolve this issue. If you find a solution, please respond to the post.

Once again, sorry for the confusion.

Darrell

Okay, this is getting very frustrating. At this stage, I don’t know if I have a hardware problem or a simple configuration issue. I’ve searched high and low looking for information on any built-in hardware diagnostics that can tell me (a) if the radio board is working, or (b) to auto-discover its default settings (that way, at least I’d know if I’m selecting the right values).

I’ve tried powering the box down, re-seating the radio module (although it seems pretty secure and may in fact by hard soldered onto the motherboard), but the symptoms are always the same. Today’s logs revealed:

Logger: zigpy_deconz.api
Source: components/zha/radio_manager.py:178
First occurred: 9:04:19 AM (1 occurrences)
Last logged: 9:04:19 AM

No response to ‘Command.read_parameter’ command with seq id ‘0x02’

Followed by:

/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:288: PinFactoryFallback: Falling back from rpigpio: No module named ‘RPi’ warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:288: PinFactoryFallback: Falling back from lgpio: No module named ‘lgpio’ warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:288: PinFactoryFallback: Falling back from rpio: No module named ‘RPIO’ warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:288: PinFactoryFallback: Falling back from pigpio: failed to connect to localhost:8888 warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:285: NativePinFactoryFallback: Falling back to the experimental pin factory NativeFactory because no other pin factory could be loaded. For best results, install RPi.GPIO or pigpio. See 23. API - Pins — GPIO Zero 1.6.2 Documentation for more information. warnings.warn(NativePinFactoryFallback(native_fallback_message))

(Whatever the hell all that means.)

I’m suspicious that its actually a radio issue, as the same radio also serves Matter (I believe), and my Thread integration isn’t showing any errors.

I can’t believe that I (and obviously, Manx) are the only people having this issue. ANY guidance would be greatly appreciated.

This. You can’t use /dev/ttyAMA1 if Thread is active. You need the multiprotocol add-on.

afbeelding

Thanks. I tried this, and this was the result:

Logger: aiohttp.server
Source: components/zha/radio_manager.py:178
First occurred: August 5, 2023 at 10:11:37 AM (2 occurrences)
Last logged: 3:18:00 PM

Error handling request
Traceback (most recent call last):
File “/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py”, line 433, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py”, line 504, in _handle
resp = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py”, line 117, in impl
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/security_filter.py”, line 85, in security_filter_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/forwarded.py”, line 100, in forwarded_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/request_context.py”, line 28, in request_context_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/ban.py”, line 80, in ban_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/auth.py”, line 236, in auth_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/view.py”, line 148, in handle
result = await handler(request, **request.match_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/config/config_entries.py”, line 181, in post
return await super().post(request, flow_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/http/data_validator.py”, line 72, in wrapper
result = await method(view, request, data, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py”, line 110, in post
result = await self._flow_mgr.async_configure(flow_id, data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/data_entry_flow.py”, line 296, in async_configure
result = await self._async_handle_step(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/data_entry_flow.py”, line 392, in _async_handle_step
result: FlowResult = await getattr(flow, method)(user_input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/zha/config_flow.py”, line 188, in async_step_choose_serial_port
if not await self._radio_mgr.detect_radio_type():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/zha/radio_manager.py”, line 178, in detect_radio_type
probe_result = await radio.controller.probe(dev_config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/zigpy_zigate/api.py”, line 510, in probe
await asyncio.wait_for(api._probe(), timeout=PROBE_TIMEOUT)
File “/usr/local/lib/python3.11/asyncio/tasks.py”, line 479, in wait_for
return fut.result()
^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/zigpy_zigate/api.py”, line 535, in _probe
await self.connect()
File “/usr/local/lib/python3.11/site-packages/zigpy_zigate/api.py”, line 235, in connect
self._uart = await zigpy_zigate.uart.connect(self._config, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/zigpy_zigate/uart.py”, line 154, in connect
_, protocol = await zigpy.serial.create_serial_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/zigpy/serial.py”, line 31, in create_serial_connection
transport, protocol = await loop.create_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/asyncio/base_events.py”, line 1045, in create_connection
infos = await self._ensure_resolved(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/asyncio/base_events.py”, line 1419, in _ensure_resolved
return await loop.getaddrinfo(host, port, family=family, type=type,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/asyncio/base_events.py”, line 867, in getaddrinfo
return await self.run_in_executor(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/concurrent/futures/thread.py”, line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/socket.py”, line 962, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -5] Name has no usable address

The Yellow has only one radio for both Zigbee and Thread. According to what stack you flashed on it, it works for Zigbee, for Thread, or simultaneous for Zigbee and Thread. For the last one, the multiprotocol stack needs to be flashed.

Thanks, Francis.

Actually, I didn’t flash any stack on it - I just bought the assembled Home Assistant Yellow, so whatever that came with - that’s what I have got. I could have sworn that when I first got it (about 8-9 months ago) that Zigbee was working, but can’t be sure as I’ve never tried to use it.

Mind you, I’ve never used Thread either, but it does seem to be working - or at least the integration is recognizing Border Routers on my Apple devices. I’m wondering if it would be easier (and safer) just to buy an external Zigbee radio if I ever need one?

In the add-on store, you can find
afbeelding

You can use that to flash a Zigbee stack on your Yellow.

Copy, thanks. Will this impact any Thread software that’s already on Yellow, or is the Zigbee code completely independent?

Honestly, I’m not sure. It seams you can have a Thread integration without having a border router on the HA box

OK, thanks. I just downloaded the firmware flasher. I think that given the choice of the radio being flashed to use Zigbee OR Thread, I’d opt for Thread (future-proofing, plus I don’t have any Zigbee devices yet). But, if flashing the firmware doesn’t impact the existing Thread code, then I’m game to try it.

Thanks for the info.

Franics, as they say (somewhere): “You Da Man”.

  1. I ran the Silicon Labs Firmware flasher and it seemed to go OK.
  2. I then restarted my Open Thread Border router. (It had been disabled, probably when the firmware was flashed, so it took some time to start) that came up OK.
  3. Then, for kicks, I tried the Zigbee integration installer and yes! That came up OK.

So, it looks like I’m up and running with both Thread and Zigbee. (Time for a full backup, I think.)

Once again, many thanks.

1 Like

I’m having similar issues. With a Yellow booted from yellow-installer-20230821.img.xz.

The onboard radio refuses to configure for Zigbee.

I pick /dev/ttyAMA1 as the serial port. It then fails to detect the radio type. And presents a list - I’m guessing that it should be the ezsp Silicon Labs EmberZNet.

If I enable thread I can see my various border routers so I assume that as they share the radio it must be present and working.

Using the Silicon Labs flasher it tries probing at various baud rates before giving up with “Error: Failed to probe running application type”. Same happens if I Ssh in and try to do it manually.

I can plug in a SkyConnect zigbee USB stick and get that to work but I was wanting to see if the onboard radio would work.

I have a completely vanilla installation wiped clean. Booted from the Yellow OS card. With nothing else enabled. And it still fails.

If anyone can point me in the right direction I would sincerely appreciate it.

According to this:

In this section:
USB Connected:
Home Assistant SkyConnect (by Nabu Casa)

USB connected adapter with integrated antenna.

This dongle/stick ships with standard Silicon Labs EmberZNet Zigbee NCP (Network Co-Processor, Zigbee only) firmware as opposed to the RCP (Radio Co-Processor, multi-protocol) firmware. It is recommended you remain on an NCP firmware which will allow it to work out-of-the-box like any other EZSP adapter.

While the RCP firmware allows you to utilize the adapter with other protocols such as Thread, it requires offloading large parts of the application onto the host computer using an additional service, Zigbeed (Zigbee daemon) instead. This service is not currently included with Zigbee2MQTT/zigbee-herdsman and you will be required to install and maintain the dependency yourself. More discussion can be found hereopen in new window.

If Zigbee2MQTT fails to start, try adding the following to your Zigbee2MQTT configuration.yaml (for the Home Assistant addon inside the /config/zigbee2mqtt/ folder)

serial:
  adapter: ezsp

I tried adding adapter: ezsp in the serial: section of the Zigbee2MQTT portion

port: /dev/ttyAMA1
adapter: ezsp

This seems to start it up, please let me know if this works for you

Is there a way to flash the built in radio on the Home Assistant Yellow to only work for Thread? I’ve switched to an external Zigbee Coordinator and want to switch off the built in zigbee as my first preference, but if switching to Thread only can achieve the same outcome and I can still use Thread functionality in the future that would be a bonus.

1 Like

Did you ever get an answer to this? I’m having same issue with new Yellow.