Zigbee2mqtt: Flashing with fixed channel, pan_id, network_key

[Erelen-Laiquendi]

About this instruction: https://www.zigbee2mqtt.io/information/flashing_without_re-pairing.html
If I manually setup channel, pan_id, network_key in my config - is this solve problem? And all devices will connect automatically after update firmware, without re-pairing?

[Koenkk]

Channel and network_key will always be honoured.

pan_id not! If the pan_id is already in use by another zigbee network a new one will be picked, this behaviour cannot be overiden currently.

[bizziebis]

When there is a zigbee network nearby, does it select that pan_id as base and add 1 to it? Or does it take the default 0x1a62 and add 1 when necessary?

[Koenkk]

default (0x1a62) or the one specified in configuration.yaml + 1.

[bizziebis]

Hmm.. reading some Z-stack documentation it would require altering the call to ZDApp_CoordStartPANIDConflictCB so there is no pan_id conflict handling anymore, thus no pan_id+1. That could lead into some strange situations I guess.

[Erelen-Laiquendi]

Variant with tinfoil-protection ;)
If protection is not full and channel will be increased, in logs (with log_level=debug) I'll see real channel, that coordinator started on?
And in this case, can I re-flash one more time and try again (with better Faraday cage) to avoid re-pairing?

[Koenkk]

@bizziebis this was the key! Firmware version 20190215 can now be flashed without having to re-pair devices.

https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/CC2531/bin (only available for CC2531 yet).

[Erelen-Laiquendi]

Thanks @bizziebis, thanks @Koenkk.
It's ultimate answer to all my questions :)

[h4nc]

@koenkk so setting the pan_id in the configuration is useless (this doesn’t come out from the docs, could you add a line “currently useless to set pan_id.

Also do zu understand it right.

With the newest firmware we don’t have to shield the device with tin foil any more?

We can just reflash it and don’t mind something?
If yes maybe it would be great to add that to the docs to, currently there is a how to flash without repairing (that tells you to move away from the network and other suggestions).

So this is obsolete
http://www.zigbee2mqtt.io/information/flashing_without_re-pairing.html

[Koenkk]

@h4nc pan_id will actually always be honored with the new firmware.

With the newest firmware we indeed dont have to do this, but before we push this firmware to master, lets first throughly test it.

Once it is in master, I will update the docs.

[h4nc]

When do you think will this go to master?

[Koenkk]

@h4nc after some more users tested this and verify it works.

[h4nc]

@koenkk I will test it and come back.

I don’t understand what you meant with “the pan_id will be honored”

Does it mean it takes the value from the config?

[Koenkk]

yes, it takes the value from configuration.yaml

[h4nc]

Ok, so I already updated to this dev version.

I did not shield ms device and also not moved away from my network.

I did not test all devices yet but the ones I already testet work (5 tested out of 14).

So looks good, count me to the Users that verify that it works.

Thanks 🙏

[h4nc]

However again I have the issue that the devices don’t show a connection in the zigbee map (they are in independent bubbles, but this still work).

To add them again. I will have to permit join on and that perform a repair.
This way it works reliable.
I know that the map isn’t high at your priority list, but I wanted to note it here, maybe this helps someone to figure out the issue on this one too.

[apeeters]

Flashing 20190218 worked fine, without re-pairing. I did not specify any pan_id in the configuration. Just had to wait a few minutes for the network to settle. Excellent work!

[h4nc]

@apeeters do you use the zigbee map? If yes are your devices still connected in the map?

[apeeters]

@h4nc Currently my Tradfri bulbs report offline. Aqara devices seem to be online.

[h4nc]

@apeeters mine also showed as online but they did not show a connection to any other device.

[Koenkk]

Thanks all for testing the new firmware, I guess this issue can be closed as the problem isn't there anymore.