How is your setup. A RPi with HAOS or?
As I read it, it has been working earlier, and stopped on the upgrade?
Thanks for responding:
- Home Assistant Blue
- ConBee II Zigbee stick
- Plugged into the Home Assistant Blue via a 2’ USB extension cable so I can mount the ConBee away from the electronics
It worked flawlessly until the upgrade to 2022.07.0 (which also changed the Python version)
It’s strange. Looks like something else is blocking ZHA acces to the conbeeII?
Do you have Deconz add-on or Deconz integration installed? It should not be installed.
Anything else that could access the conbeeII.
Nope, I know not to install Deconz. It’s not installed. I have nothing else plugged into the serial ports, it’s the only USB device attached.
Sorry, im out of ideas. I use Z2M and a sonoff 3.0 dongle, hence can not test. Was using ZHA and conbee earlier. Hope someone else with ZHA and Conbee can help out.
Well, after at least a dozen restarts of HA, and several power cycles of the Home Assistant Blue…
The ConBee II just came back and the integration loaded properly; but, about 50% of my devices are still unavailable.
I’m thinking this is a Home Assistant OS on Home Assistant Blue issue…
I have a Blue too & can report I have the same issue since update.
I have just updated to 2022.7.3 in the last 5 minutes & it is still broken !!!
I have the issue on a RPI 4. It worked perfectly before the update to 2022.07
Same here RPI4. all my devices have a status of unknown.
For everyone posting “me too” I have the following suggestions:
- Determine if your ZHA device is loading at all or not, by looking at your Integrations and seeing if the ZHA integration is loading or not. If it’s failing to load at all, this is the issue, you’ll likely just have to power cycle your unit until it comes back. My only suggestion is also re-seating your SD card as this was something I did when mine came back.
- If your integration is loading, but many devices are being listed as unknown, you’ll likely have to repair them. Mine required a combination of just activating the unit (if battery powered, in order to get them to report status) or full pairing (by resetting them and re-adding them).
- DO NOT delete and re-add your Integration, as you risk losing your whole mesh if you do (I believe it’s saved in the zigbee.db file, so back that up just in case if you go this route).
So you solution is either reboot and re-seating the SD card, either repair the units that are unavailable either re-add them? While this could actually help, what I can tell you is that I did almost everything you say and I still have the same issue currently, some devices after a while start reporting as unknown. And I noticed that happens to other integrations other than ZHA… for instance some Wi-Fi integrations sometimes report as unknown although they are working properly from Voice Assistants, HomeKit and Custom Apps (like Tuya integration) so I’d say that something on the HA lastest updates that are creating those issues. Also I really don’t want a system where I need to re-add Zigbee devices every day or need to restart the system and re-seat the SD card
Then you should roll back to a pre 2022.07 build from your Backups. From what I’ve read everything will restore and be stable, then wait and let the HA devs figure out what’s going on and fix it.
Unfortunately not for me. I rolled back but same issues.
Maybe because it rolled back to " Home Assistant Core 2022.6.7" but the supervisor is still 2022.07.0?
Yup, I tried rolling back but nothing worked.
I had to resort to re-pairing every zigbee device one at a time to get things running again.
Ball ache, but all sorted now.
2 Likes
I rolled it back to 5.5 still no go. so I re-paired every device. working now.
Has anyone opened a github issue? I haven’t seen any listed. The developers might not be aware if it isn’t reported.
Since I can’t duplicate it after the re-pairing and I’m not willing to leave it broken, I didn’t bother. There’s nothing I can give them to help them fix it.
I tried to repair the devices but it looks like I can’t even pair anything. I installed a complete fresh version of HassOS without any changes and tried to pair a device. It is found but during the “interview process” nothing happens. The log shows this:
New device 0x064f (00:12:4b:00:23:b7:82:98) joined the network
[0x064f] Scheduling initialization
Received frame on uninitialized device <Device model=None manuf=None nwk=0x064F ieee=00:12:4b:00:23:b7:82:98 is_initialized=False> from ep 0 to ep 0, cluster 19: b'\x00O\x06\x98\x82\xb7#\x00K\x12\x00\x8e'
[0x064f:zdo] ZDO request ZDOCmd.Device_annce: [0x064F, 00:12:4b:00:23:b7:82:98, 142]
Tries remaining: 3
[0x064f] Requesting 'Node Descriptor'
Tries remaining: 2
[0x064f] Extending timeout for 0x13 request
Received frame on uninitialized device <Device model=None manuf=None nwk=0x064F ieee=00:12:4b:00:23:b7:82:98 is_initialized=False> from ep 1 to ep 1, cluster 6: b'\x08\x00\n\x00\x00\x10\x00'
[0x064f] Received ZCL while uninitialized on endpoint id 1, cluster 0x0006 id, hdr: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, is_reply=1, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=0, command_id=10, *is_reply=True), payload: b'\x00\x00\x10\x00'
[0x064f] Uninitialized device command '10' params: Report_Attributes(attribute_reports=[Attribute(attrid=0x0000, value=TypeValue(type=Bool, value=<Bool.false: 0>))])
Received frame on uninitialized device <Device model=None manuf=None nwk=0x064F ieee=00:12:4b:00:23:b7:82:98 is_initialized=False> from ep 0 to ep 0, cluster 32770: b'\x13\x00O\x06\x01@\x8e\x00\x00P\xa0\x00\x00\x00\xa0\x00\x00'
[0x064f] Got Node Descriptor: NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=0, maximum_buffer_size=80, maximum_incoming_transfer_size=160, server_mask=0, maximum_outgoing_transfer_size=160, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)
[0x064f] Discovering endpoints
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0x064F ieee=00:12:4b:00:23:b7:82:98 is_initialized=False> from ep 0 to ep 0, cluster 32773: b'\x15\x00O\x06\x01\x01'
[0x064f] Discovered endpoints: [1]
[0x064f] Initializing endpoints [<Endpoint id=1 in=[] out=[] status=<Status.NEW: 0>>]
[0x064f:1] Discovering endpoint information
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0x064F ieee=00:12:4b:00:23:b7:82:98 is_initialized=False> from ep 0 to ep 0, cluster 32772: b'\x17\x00O\x06\x14\x01\x04\x01\t\x00\x00\x05\x00\x00\x03\x00\x04\x00\x05\x00\x06\x00\x01\x00\x00'
[0x064f:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=9, device_version=0, input_clusters=[0, 3, 4, 5, 6], output_clusters=[0])
[0x064F:1:0x0000] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=25, command_id=<GeneralCommand.Read_Attributes: 0>, *is_reply=False)
[0x064F:1:0x0000] Sending request: Read_Attributes(attribute_ids=[4, 5])
[0x064f] Delivery error for seq # 0x19, on endpoint id 1 cluster 0x0000: message send failure
Tries remaining: 2
[0x064f] Already have endpoints: {0: <zigpy.zdo.ZDO object at 0x7f73e21630>, 1: <Endpoint id=1 in=[basic:0x0000, identify:0x0003, groups:0x0004, scenes:0x0005, on_off:0x0006] out=[basic:0x0000] status=<Status.ZDO_INIT: 1>>}
[0x064f] All endpoints are already initialized: [<Endpoint id=1 in=[basic:0x0000, identify:0x0003, groups:0x0004, scenes:0x0005, on_off:0x0006] out=[basic:0x0000] status=<Status.ZDO_INIT: 1>>]
[0x064F:1:0x0000] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=27, command_id=<GeneralCommand.Read_Attributes: 0>, *is_reply=False)
[0x064F:1:0x0000] Sending request: Read_Attributes(attribute_ids=[4, 5])
[0x064f] Delivery error for seq # 0x1b, on endpoint id 1 cluster 0x0000: message send failure
Tries remaining: 1
[0x064f] Already have endpoints: {0: <zigpy.zdo.ZDO object at 0x7f73e21630>, 1: <Endpoint id=1 in=[basic:0x0000, identify:0x0003, groups:0x0004, scenes:0x0005, on_off:0x0006] out=[basic:0x0000] status=<Status.ZDO_INIT: 1>>}
[0x064f] All endpoints are already initialized: [<Endpoint id=1 in=[basic:0x0000, identify:0x0003, groups:0x0004, scenes:0x0005, on_off:0x0006] out=[basic:0x0000] status=<Status.ZDO_INIT: 1>>]
[0x064F:1:0x0000] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, is_reply=0, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=29, command_id=<GeneralCommand.Read_Attributes: 0>, *is_reply=False)
[0x064F:1:0x0000] Sending request: Read_Attributes(attribute_ids=[4, 5])
[0x064f] Delivery error for seq # 0x1d, on endpoint id 1 cluster 0x0000: message send failure
So some message sending failure but I’m not sure how that even happens.
The really weird thing is how some devices work and others don’t. If I reconfigure the non-working devices some attributes have this orange explanation point and the reconfiguration fails.
Any idea? Especially why some devices work and others not?
Maybe something with the baud rate as in this post?
FWIW, zigpy was just bumped in 2022.7.5. Not sure if it helps folks or not. Mine have been stable since getting my ConBee II back and re-pairing the devices that fell out of the mesh.
TLDR: Never use the USB 3.0 Port and a 2.4 GHz device together even on another Raspberry Pi nearby!
Long version:
OMG! What a waste of time!
The error on my end had nothing to do with an update or anything else on that setup. It was simply a coincidence that around the same time as that update came out I added a second Raspberry Pi as a home server with an SSD on the USB 3.0 port. I placed it right next to the one with HA on it. I found in some forum that the USB3 port can interfere with 2.4 GHz signals and that’s exactly what caused the issue. I had to re-pair all devices and now everything seems to be fine again.
Thanks for the help!