ZHA mesh not healing? Unknown device Warnings

[erkr]

The problem

Yesterday we had a power outage of one hour, and when every thing was back up and running, 3 end devices are lost (2 iikea symfonisk and an aqara lumi weather sensor). But there are also a lot of Unknown device warnings in my log(see below), so it seems these devices are present on another address then expected by ZHA. Why doesn’t heal the mesh, by triggering these devices to renegotiate there network address?

best Eric

What version of Home Assistant Core has the issue?

Core 2024.4.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ZHA

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: zigpy.application
Source: runner.py:189
First occurred: April 7, 2024 at 14:39:26 (578 occurrences)
Last logged: 13:19:25

Unknown device AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xB8E5)

Additional information

No response

[home-assistant[bot]]

Hey there @dmulcahey, @adminiuga, @puddly, @thejulianjes, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `zha` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign zha` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

zha documentation zha source _{^{(message by IssueLinks)}}

[puddly]

Why doesn’t heal the mesh, by triggering these devices to renegotiate there network address?

It does. NWK addresses are dynamic and ZHA looks up devices by their IEEE address in case a device with an unknown NWK is detected. If the device is known, we update its current NWK. If not, it's treated as a new join.

"Healing" doesn't exist as a concept for ZigBee, unfortunately. The mesh just manages itself. You can ask devices to leave or to rejoin but what they do after that is up to them.

[erkr]

Thanks for the quick reply! Healing was not the right wording☺️. Good to know it works that way. The symfonisks rejoined by just manually activating them, but for the aqara weather sensor no go. I pressing the update button (to send weather data on demand). That only resulted in extra logs, but no new address, I had to re-pair that device. Anything I can do? Probably aqara had incompatibility issues with address refreshing

[puddly]

That only resulted in extra logs, but no new address

Can you post the log?

[erkr]

Sorry, I performed several restarts since re-pairing that aqara device. So I don't have the latest log anymore. But it was exactly this one with an increased number of occurrences:

Logger: zigpy.application
Source: runner.py:189
First occurred: April 7, 2024 at 14:39:26 (578 occurrences)
Last logged: 13:19:25

Unknown device AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xB8E5)

The device is an Aqara:

IEEE: 00:15:8d:00:08:f1:39:61
Nwk: 0xa2b7
Device Type: EndDevice
LQI: 255
RSSI: -43
Last seen: 2024-04-08T14:50:56
Power source: Battery or Unknown
Quirk: zhaquirks.xiaomi.aqara.weather.Weather2

signature:

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4151, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=0, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": "0x0104",
      "device_type": "0x0302",
      "input_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x0402",
        "0x0403",
        "0x0405",
        "0xffff"
      ],
      "output_clusters": [
        "0x0000",
        "0x0004",
        "0xffff"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.weather",
  "class": "zhaquirks.xiaomi.aqara.weather.Weather2"
}

[bombaata]

Same behaviour here with Aqara TH sensor (lumi.weather) on 2024.4.4

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4151, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=0, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": "0x0104",
      "device_type": "0x0302",
      "input_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x0402",
        "0x0403",
        "0x0405",
        "0xffff"
      ],
      "output_clusters": [
        "0x0000",
        "0x0004",
        "0xffff"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.weather",
  "class": "zhaquirks.xiaomi.aqara.weather.Weather2"
}

IEEE: 00:15:8d:00:02:c7:74:41
Nwk: 0x4f44
Device Type: EndDevice
LQI: 255
RSSI: -64
Last seen: 2024-04-28T13:48:40
Power source: Battery or Unknown
Quirk: zhaquirks.xiaomi.aqara.weather.Weather2

Logger: zigpy.application
Source: runner.py:189
S'est produit pour la première fois: 28 avril 2024 à 13:48:08 (304 occurrences)
Dernier enregistrement: 10:30:04

Unknown device AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xF6DF)
Unknown device AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x4F44)

[bombaata]

device working fine with 2024.5.1

[erkr]

device working fine with 2024.5.1

For me, loosing devices that didn't update their nwk address, with unknown network address error's as a result, typically happens once or twice per month. So I'm a little curious how you concluded it is solved with 2024.5.1.

Best Eric

[bombaata]

My Aqara TH sensor (lumi.weather) device didn't respond with ZHA 2024.4.4 and now works with 2024.5.1.

[erkr]

Ah that sounds like a different issue. maybe yours was resolved by a new quirk in the latest release. This issue is about devices that work fine for months and then suddenly have a wrong address