Zigbee2mqtt: Rework of Coordinator initialization - Timeouts

[tb-killa]

I see often that the Coordinator got Problems with the Initialisation of the Device themselve.(CC2531 = USB-Version) / don´t know if this also happen on (CC2530 = Serial-Port Version) too ?

What I found out was this:

The USB-Dongle takes 60 seconds before it will respond to a command after it is first plugged in (this is repeatable). If plug the dongle but not start the stack, the green LED on the dongle stays on for the 60 seconds, then goes out.
And now after this it will respond immediately for commands.

This seems to be a default Value because TI Stack Home-1.2.1 and the Include of the SBL (Serial Boot Loader) waiting after Power ON of the Coordinator before the jump to the ZNP Application Image Adresse and start them up.

This seems to be the Problem if Z2M do some Sort of Reset or the Coordinator Communication drop you have to wait the needing time too.

@Koenkk do the retry with timeout but i think this isn´t the right way for the future.

Through research I found out so-called "Magic Bytes", which lead to skipping the bootloader.

As we actually doesn´t allow to flash Firmware Versions directly via SBL we should implement this direct incall.

0xef should be the right value to bring the Coordinator Stick jumping directly to the ZNP Application.

This should be implemented directly via cc-znp or maybe provide some sort of interface via Z2M ?

[Koenkk]

looks good! How did you find this out? Is this documented somewhere?

[tb-killa]

@Koenkk
https://github.com/openhab/org.openhab.binding.zigbee/issues/2

https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/160948/1361000#1361000

[Koenkk]

This indeed allows the coordinator directly after plugging, thanks, great addition!