Update for the coordinator.

[Szewcson]

Hi, maybe you could add app images for the releases? I was thinking about creating small HA app for flashing coordinator with the new releases (since I'm now vibe coding and debugging similar solution for nrf dongle), but maybe there is no point with fragmenting the ecosystem. Also I think it will be the best if the images came from official source.

Edited: I just found that there is an closed license fork that add that and also update mechanism for Z2M, but i still thinking if the images comes from official source it will be the best.

[tostmann]

Useful question, and the answer splits into one thing we should just do and one constraint worth knowing before you build against it.

The constraint: this firmware cannot do OTA. partitions.csv has a single app slot (ota_0), no second one, so there is no A/B partition pair for esp_https_ota to swap between. Any updater — yours, ours, anyone's — has to flash over serial. That is not a policy decision we can lift with a different image; it is the layout, and changing it would cost more app space than the 4 MB parts have to spare.

The thing we should do: publish app-only images, and attach both kinds to the GitHub releases. Today only the merged factory.bin per chip is published, on the web flasher, and the releases carry no assets at all — so "from the official source" is a fair complaint. What we publish is also blunter than it needs to be: the merged image spans 0x0 to roughly 0xB4000, which means flashing it at offset 0 rewrites nvs, otadata and phy_init as blank. zb_storage sits at 0x1FB000, outside the image, which is why the Zigbee network survives a web-flasher update at all. An app-only image written at 0x20000 touches none of that — it is the right artefact for updating an already-commissioned coordinator, and it is what your app would want.

So: app image plus factory image as release assets, from the next release on. The manifest stays as it is for first-time flashing.

On fragmentation — I would not worry about it. Serial flashing from inside Home Assistant is a real gap; the web flasher needs a browser with WebSerial and a machine that can see the port, which is exactly what a headless HA box does not have. If you build it, tell me what you need from our side beyond the images — a stable URL scheme per release and a version string you can compare against GET_MODULE_VERSION (command 0x0001) is what I would guess, and both are easy.

One caveat for your app, since it bit us this week: opening the USB-Serial/JTAG port with DTR/RTS asserted is the esptool auto-reset sequence, and it drops the chip into the ROM loader instead of the running NCP. If your app talks to the coordinator before flashing it, open with both deasserted.

I have no view on the fork you found — I do not know what is in it.

[Szewcson]

https://github.com/BioFieldUA/esp-coordinator - this project. I found it with chatgpt which name it a fork. It looks like it is not a fork, but a but a new simmilar project.

[tostmann]

Correction to my reply above: the claim that a second app slot "would cost more app space than the 4 MB parts have to spare" is wrong. The partition table in the published images (C6, C5 and H2, all v1.5.77) has ota_0 from 0x20000 to 0x1FB000 (1900 KiB), then zb_storage and zb_fct ending at 0x1FF400. The 2 MiB from 0x200000 to the end of the 4 MB part is unused, and the app image itself is about 590–640 KiB on all three chips. A second slot the size of ota_0 fits at 0x200000 (ending at 0x3DB000) without moving any existing partition.

What stays true: the shipped firmware has one app slot and no update code path, so today every update is a serial flash, and your app has to flash over serial for existing devices.

What a second slot would mean: a new partition table. The firmware has no code that writes its own table, so the switch itself has to happen over serial once. Appending a slot leaves nvs and zb_storage where they are, so that step alone would not touch the network data. Whether an update mechanism follows is a decision I have not made, so treat it as not planned.

[tostmann]

v1.5.77 now has release assets: the app image and the factory image for the C6, C5 and H2, plus SHA256SUMS: https://github.com/tostmann/esp-coordinator/releases/tag/v1.5.77. The app image goes to 0x20000 and leaves nvs, otadata, phy_init and the network data alone. Future releases get the same set.

Correction to the caveat in my first reply: a normal open does not reset the chip. Linux asserts DTR and RTS on open, and the USB-Serial/JTAG controller treats that state as no action; the reset into the ROM loader needs the line sequence esptool sends. Your app can open the port the usual way.