Moving coordinators between different supported host systems.

[MattWestb]

Now Z2M have getting betas stage support for EZSP coordinators its opens for "hot plugs" between host systems then user like trying out different systems.

If having one EZSP or ZB3 Ti coordinator its having all network, TC link keys and counters storage in the adapter = good.

Then taking down the "old" system and installing on "new" system of different "family" the coordinator have all for running the Zigbee network but the host system dont knowing the devices at all.

Do some clever devs knowing how to initiating the "new" host system reading the information and adding the devices that is paired in the "new" host system without repairing all devices ?

If its possible pleas put the information online so use can using it without "distorting" there working network and can doing "hot swap" between our host systems.

[puddly]

Do you mean including application-level information about joined devices in the backup, like their node descriptor, endpoint and cluster info, etc.?

Or do you mean keeping track of other devices on the network? Currently all children are exported as well as devices with security material so I think that will work.

[MattWestb]

Nop not in the backup more like one "hot swap" function in the host system.

If having one coordinator running in Z2M and shutting down the Z2M and installing one"clean" ZHA instance and starting it without any "device data" but the coordinator have all devices up and ruing in the mesh.

Then the coordinator have all devices but ZHA is not knowing them and need "populating" its database for getting the device in HA. And the other war around then going from ZHA to one "clean" Z2M.

[puddly]

If I'm understanding you correctly, that would require reading/writing to the device databases used by both projects and unfortunately they store different info. zigpy requires the simple descriptor to match quirks at runtime and stores this in its database, but Z2M does not. It would be a one way migration, since I think all the info Z2M needs can be pulled out of the attribute cache in zigpy's database.

[MattWestb]

No not writing the other host system database.

If you is running one stick on Z2M and all is configurated and you is killing Z2M but do not resetting the stick.

Then you is installing ZHA and like using your zigbee network that is up and running OK (in the coordinator but not in ZHA part) but ZHA is not knowing the device and need adding all devices in the database.

Also if you is running ZHA and and killing ZHA but not resetting the coordinator and then installing Z2M. Then the coordinator is OK but Z2M need populating its data to knowing all devices.

Its the part on both side adding the "known" devices in the system without needing resettling all devices.

One user was heaving CornBee running on de(F)CCOZ integration and was stopping the deCONZ integration and installed ZHA and all devices was "living" but i dont knowing if all was working OK in ZHA.

[puddly]

Hmm. This seems like something that would belong in Z2M or ZHA as an extension of the "permit joins" or topology scanning, would it not? The scans would discover new routers so maybe it is possible to read the child tables of the routers as well to find unknown battery-powered devices and to treat the discovery of "unknown" devices as an implicit join.

For battery-powered sensors like Aqara that are very difficult to contact, perhaps it would be better to treat messages from unknown devices as a "join" event and immediately start device discovery? They are already a part of your network so there is really no security impact.

Zigpy does know when "unknown" devices send it data but this sometimes can happen if a device changes its NWK address without notifying the coordinator. Explicitly performing device discovery when receiving messages from unknown devices would solve this issue as well (maybe sending an IEEE to NWK discovery request in this case would work too?).

In terms of getting this info into the backup format, I'm not really sure how this would look. As I said before, ZHA requires the node descriptor for quirks, which Z2M just does not keep track of, so there is no way to cleanly migrate from Z2M to ZHA like this.

[MattWestb]

In my described case its no "unknown device" for the coordinator then all devices is in the network and saved in the coordinators NVRAM.

Its only the "new host system" that is not knowing the devices and need getting the information of them.

Is one network scan adding the "known unknown" devices (devices that's in the network but not known by ZHA) in ZHA?

If yes then its easy moving from Z2M to ZHA.

Re power routers is normally (ZB3 shall) broadcasting one device accouterments then coming back to the network is ZHA triggering in that ?

The problem with sleeping end device direct connected to the coordinator is one thing that must being taken (I trying only connecting then to routers so they is not leaving then the coordinator is off line). And its lesser work repairing some sensors that all devices in the network.

[puddly]

all devices is in the network and saved in the coordinators NVRAM.

TI coordinators only seem to keep track of devices that have APS link keys or are directly joined to the coordinator. For example, my network has 52 devices but the entire NVRAM dump of my coordinator has only 24 devices, which are just the routers. No sensors are joined to my coordinator so they just aren't present in NVRAM.

Is one network scan adding the "known unknown" devices (devices that's in the network but not known by ZHA) in ZHA?

I don't think so, the results are only used at the moment for displaying the network graph. I will have to check.

Re power routers is normally (ZB3 shall) broadcasting one device accouterments then coming back to the network is ZHA triggering in that ?

Yes, a device announcement is treated like a join so you can usually get most routers re-joined by shutting off their power and turning them back on. But pulling the batteries out of sensors is usually a lot more difficult.

[MattWestb]

Then device announcements = repower is one way to trying.

If you is heaving "real zigbee 3" device they requesting one updated TC key after getting the network key and is using it and the coordinator is saving it. All my IKEA devices is requesting it but not the old motion sensor (and the old E27 CWS) that is ZLL and using the master link key (HA or ZLL).

ZHA with EZSP is not using it incited less secure hashed TC link key and the coordinator dont need saving all link keys in NVRAM.

Wot about doing one network scan and sending one leave with rejoining true to all for ZHA unknown devices so the device is doing one device announcement / rejoining ??

If its working doing one check after network scan and if its many "unknown devices" for ZHA then triggering on leave with rejoining true and putting one warning in the log for new joined devices (for not getting hacked devices silent joining the system).