MAC dependency to backup and devices migration

[wassfila]

For a short summary, see next comment. Long version : With the increase of the number of smart devices, zigbee starts loosing its attractiveness in comparison to other networks such as wifi or other due to the pain of repairing devices. As example, for many devices, in a standard RF network environment, the pairing only succeeds when the coordinator is right next to the device, which in case of being attached to a server might represent a logistic issue for some devices that are attached to the environment such as heat thermostats or others.

The issue / feature request here is to prevent repairing of devices as much as possible which could be handled in two complementary ways :

Batch

1. Switching to a different server that has a different Coordinator

Fine granular

2. Migrate a single device from a Coordinator to another

3. Although I understand that migrating a single device might not be possible without interacting with the device, so a solution here would be a sort of handshake where two servers agree and re negotiate with the device to reassign it to another coordinator without the user intervention, I know I might be daydreaming as this might be beyond what zigbee allows or even against what zigbee wants to prevent.

so back to 1. In this scenario, I have a cloud of services running OpenFAAS, OpenStack, Kubernetes or any other fancy private cloud system, the only thing that would prevent a zigbee2mqtt service to migrate to another instance is currently (to the best of my understanding), the MAC address of the coordinator.

An issue was opened here #2987 for configuration dependency then followed up with #141 for ieeeAddr address change which got stale and closed, but my question here is if possible to do it the other way around.

Is it possible to somehow configure the MAC address in the config file, so that it's possible to start the service with one previously known MAC address ? That would not need any modification nor any transaction with the devices when switching from one service and HW server to another.

I don't think this would conflict with security as the secret does not rely on the MAC rather on the network key, which can already be configured.

Or maybe if someone could think of a way on how to share the "Coordinator as a service" maybe at serial to network proxy level. That would be out of the scope of this repo but still might result on not requiring to solving by any modification to the zigbee2mqtt service.

@wsw70 @Koenkk for info.

[wassfila]

I would like to answer a part of my questions for usage of serial port through the network, it's pretty easy using ser2net on one machine and socat on the other, this gets transparent to the user of the device. https://www.acmesystems.it/socat

So to summarize, the questions still open :

• Is it possible to configure the MAC aka ieeeAddr of a coordinator ?
• Is it possible to move a single device from one zigbee2mqtt service+coordinator to another without the user having to repair the device ?

[wassfila]

I did not check the doc for a long time, but it's actually already described there and even easier, without the socat https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html

[MPM1107]

The primary and secondary IEEE addresses are defined in the firmware and are as such indeed freely modifiable. You would have to compile your own firmware and flash it to change the address though.

As far as switching over a device goes, most (but not all) devices will enter pairing mode if you remove them from the network. So if you enable joining on network B and then remove a device connected to network A, it should automatically connect to network B. This can of course be done programatically for all devices in the network to transfer a whole network to a new coordinator. It does require both to be running at the same time though.

[wassfila]

The primary and secondary IEEE addresses are defined in the firmware and are as such indeed freely modifiable. You would have to compile your own firmware and flash it to change the address though.

That's cool, at least I know it's feasible, if I'm not the only one who sees interest bringing the IEEE address to the config, this could be flagged as a change request to the firmware. the address change would have to be exposed through the host API so that the host could apply it from the user config file.

As far as switching over a device goes, most (but not all) devices will enter pairing mode if you remove them from the network. So if you enable joining on network B and then remove a device connected to network A, it should automatically connect to network B. This can of course be done programatically for all devices in the network to transfer a whole network to a new coordinator. It does require both to be running at the same time though.

That sounds easy, I'll try that. I'm not sure if not some or most of the devices I have apply restrictions that a user has to long pressing a button to set them again in pairing mode, my network is mainly composed of aqara contact, buttons and temp sensors.

[Koenkk]

Which of the 4 cases mentioned in https://www.zigbee2mqtt.io/information/FAQ.html#requires-repairing do you want to address here?

[wassfila]

Which of the 4 cases mentioned in https://www.zigbee2mqtt.io/information/FAQ.html#requires-repairing do you want to address here?

I'm a bit confused, the IEEE address changes when the device physically changes, yet Switching from CC2530/CC2531 device (physically) is listed within the things that do not require repairing.

If that is the current status, then I need to re-test that again and I'll close this ticket.

I still cannot explain why having a different IEEE address than the devices have been paired with would not be a problem, but I think there should be a difference between does not require repairing and does not require re-association with the devices but as long as that is hidden from the user, it should be ok.