Treat messages from unknown devices as implicit joins and discover IEEE addresses

[puddly]

Devices that somehow manage to change their NWK address without notifying the coordinator are impossible to contact. Instead of dropping packets from them, we can discover their IEEE address and either update the NWK in zigpy's database or treat the device as a new join.

This allows for ZHA to be started up with a completely "unknown" network and for it to pick up devices as they're used.

[codecov-commenter]

Codecov Report

Merging #73 (ca4572e) into dev (6ce31d7) will increase coverage by 0.01%.
The diff coverage is 98.36%.

@@            Coverage Diff             @@
##              dev      #73      +/-   ##
==========================================
+ Coverage   98.42%   98.44%   +0.01%     
==========================================
  Files          43       44       +1     
  Lines        3681     3719      +38     
==========================================
+ Hits         3623     3661      +38     
  Misses         58       58              

Impacted Files	Coverage Δ
zigpy_znp/zigbee/application.py	96.18% <95.00%> (+0.07%)	⬆️
zigpy_znp/api.py	100.00% <100.00%> (ø)
zigpy_znp/commands/zdo.py	100.00% <100.00%> (ø)
zigpy_znp/utils.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6ce31d7...ca4572e. Read the comment docs.

[puddly]

Combining this change with the zigpy initialization refactor (zigpy/zigpy#744) let me import most of my network into a fresh HA installation in like 30-40s after "rebooting" my house at the circuit breaker:

Aqara quick initialization also works quite well, all of my motion and temperature sensors were instantly initialized after poking the button. In the future it would be interesting to see if the zigpy topology scanner (or maybe some broadcast that every single device can reply to?) can be used to speed this up or automate it, for installations where physically cutting power isn't simple.

[MattWestb]

Interesting if the router is "rejoining" and ZHA is doing one topography scan and reading the neighbor table of the router then you is getting the coordinator is getting the address of the SED the router is having. The next is then the SED is doing one check in or reporting attribute (if the coordinator have the same IEEE) and the coordinator can configuring them.
The mesh shall living / working after one "master reset" and finding ways around devices that is not working also the coordinator if its is online.

By the way as normal great work done !!!!!

[Adminiuga]

If we implement this at in zigpy, then in ZNP you would need to implement only ZDO_IeeeAddr_req handler?

[puddly]

If we implement this at in zigpy, then in ZNP you would need to implement only ZDO_IeeeAddr_req handler?

Z-Stack for some reason omits the NWKAddrOfInterest field for this specific request (though it's included in most others??) so you can't ask 0x1234 for the NWK address of 0x5678. To be fair, you'd have to know that 0x5678 is a RFD and is a child of 0x1234, so you likely don't need to know its IEEE address.

[Adminiuga]

I was thinking about sending the request directly to the unknown device, since the device just messaged and is listening for the incoming traffic.

Alternatively, could just define a method in zigpy and leave to the radio lib to implement it.

[puddly]

Yeah, that's what my current implementation does. I think it's better to start using more ZDO commands from zigpy. Should allow for energy scanning and stuff like this to be implemented in zigpy instead of duplicated in every radio library.