Repository navigation
Replies: 23 comments 14 replies
|
Short answer: the firmware itself has no WiFi/network stack — the NCP link is USB-Serial/JTAG only, so the coordinator doesn't put itself on the network. But ser2net/socat is exactly the right idea and it works: they bridge the local serial device to a raw TCP port, and Z2M's Two ways to do it: A) On the machine the C6 is plugged into — ser2net or socat, e.g.: # ser2net v4
connection: &con01
accepter: tcp,6638
connector: serialdev,/dev/ttyACM0,115200n81,localB) No PC at all — our sister project CDC2NET. It's a transparent USB-host → raw-TCP bridge on an ESP32-S3 (a C3/C6 can't be a USB host, the S3 can). Plug the C6 coordinator into the S3 board and it exposes the coordinator's USB-Serial-JTAG as a raw TCP port (default Then in Z2M serial:
adapter: zboss
port: tcp://<bridge-host>:6638 # or :2329 for CDC2NET's defaultOne caveat: this is a plaintext byte stream over the LAN (no encryption/auth) — keep it on a trusted network or tunnel it. The C6 does have WiFi, so a future firmware could expose the NCP stream over the network on-device — that's something we may look at later, but it isn't implemented today. |
0 replies
|
Many thanks for the detailed answer and your work in general! I look forward to possible WiFi implementation in the future. In the meantime, CDC2NET looks like an interesting solution. How difficult would be to redirect serial communication from current USB-Serial to one of the C6's hardware UARTs and expose Rx and Tx directly on GPIOs? I'm looking into connecting a C6 directly to my OpenWRT router's TTL serial port where I could install the ser2net package. |
0 replies
|
Good news: that exact request just landed as issue #2 as well, and a UART transport is now on the roadmap — tracked there: #2 To answer "how difficult": it's a contained change. The transport layer in this firmware is a thin byte pump (a single source file), and the shipped build already keeps all console logging off — the NCP framing must not be polluted — so a hardware UART is free to carry the frame stream. The UART code inherited from the original codebase was never functional and has been removed, so it's a fresh-but-small implementation: UART driver init with configurable pins/baud, plus the same read/write task pattern the USB path uses. Your OpenWRT-router-TTL + ser2net setup is exactly the use case it would serve — just mind the 3.3 V logic levels on the router's TTL header. No ETA yet — subscribe to #2 for progress. |
0 replies
|
Update: v1.3.45 is out and ships the UART host transport — the "C6 directly on the OpenWRT router's serial header" setup you described is now supported out of the box: https://github.com/tostmann/esp-coordinator/releases/tag/v1.3.45
If you get a chance to try it on your router, feedback would be very welcome — test reports are being collected in #2. |
0 replies
|
This was the fastest progress from "no ETA" to "released" that I have ever seen :) |
0 replies
|
Update — there's now an experimental native-WiFi build to try. Following up on this thread (and the UART transport that shipped as v1.3.45): the Experimental flasher: https://install.busware.de/zboss/coex/ How it works:
Why "experimental": the C6 has a single 2.4 GHz radio shared between WiFi and Zigbee (software coexistence). Espressif rates the "WiFi-STA + always-on coordinator" case as supported-but-unstable, and on the bench I can't measure real-world coexistence quality conclusively. Whether it's good enough for a usable coordinator depends on your RF environment — that's exactly what I'd like help measuring. Please use a spare stick and a throwaway test network, not your production setup. If you give it a go, I'd appreciate a report back here: your AP / environment, which Zigbee and WiFi channels you used, how many devices, and how stable it was (join reliability, LQI, any dropped sessions, behaviour under heavy WiFi load). Tips for a fair test:
|
0 replies
|
I have tested this and it...works...but unreliably. It seems to work at the beginning, but after half an hour or so, z2m looses connectivity with the adapter and fails to send any commands to it
At this moment, coordinator's web page is fully accessible. It seems that z2m does not try to reestablish the connection on it's own. A simple restart of z2m container without touching the coordinator solves the issue temporarily and zigbee device starts responding immediately. Environment: Coordinator set to zigbee channel 11 (2405 MHz), WiFi set to channel 11 (2462 MHz), your version of z2m container running in QNAP Container Station, one zigbee smart plug connected, relatively quiet wifi environment (no traffic on my wifi, low interference on wifi channel 1, overlapping with zigbee channel 11 as the test was done during the night). |
0 replies
|
@peca89 — thanks, this is genuinely useful: the first real external datapoint on the coex build, and a clean one. You confirmed the coordinator was still alive (its web page responded), your channel hygiene is good (WiFi ch 11 at 2462 MHz vs Zigbee ch 11 at 2405 MHz — non-overlapping; the only RF overlap is ambient WiFi on ch 1 against Zigbee 11, not your own AP), and you isolated it to the host side (a z2m-only restart fixes it). Exactly the kind of report that moves this forward. What's happeningThis is the host-side recovery gap, not primarily a radio problem. When the TCP socket to the coordinator drops, the zboss adapter in zigbee-herdsman did not emit a Fix now shipping (no reflash)The z2m image now carries the herdsman fix that closes the silent part — on an unexpected port close the zboss adapter emits Be clear on what that does, though: z2m does not transparently reconnect in-process. On that event it logs Once the image rebuild finishes: then restart the container. No coordinator reflash needed — this is purely host-side. This is recovery, not the root causeTo be blunt: this fixes the symptom (z2m no longer wedges silently), it does not explain why the TCP link drops after ~30 min. That's the next thing to chase, and I don't want to guess. Single-radio coex makes a transient stall plausible in principle — but your channels are well separated and your WiFi is quiet, so a plain socket-level idle/keepalive/NAT timeout on the path (Container Station's networking included) is an equally live suspect. Data will tell those apart. What would helpAfter you update and it recurs:
The ~30-minute regularity is the most interesting clue right now; if it stays near a fixed interval after the update, that points hard at an idle/keepalive timeout rather than the radio. Status reminderCoex is still experimental, and as your report shows the link itself isn't stable yet — this update makes the failure recoverable, not absent. Please keep it on a spare stick and a throwaway network, and keep a full backup via the stable USB build in case you want to roll back. |
0 replies
|
Oh, sorry. By all means I did not mean regular 30min dropouts. It just "felt like" 30 minutes. I'm going to pull new image, leave it running and inspect the logs later to try to find out regularities, if any. |
0 replies
|
I'm not sure what happened last time when I tested this...but today is the 7th day as this runs without issues. Z2M hasn't restarted on its own since 7 days ago. After the fix on the z2m side, it now does inteed restart if you force the coordinator to loose connection - I tested this by disabling wifi on the router side. After reenabling, everything came up on its own, without touching z2m container or the coordinator. I only have one zigbee smart plug connected and it logs sensor changes consistently for the past 7 days. Not the most representative test, but I can consider this to be, at very least usable at its current state of development. Thank you. |
0 replies
|
Thanks for the follow-up. The genuinely useful part isn't the 7-day run with one plug — it's that you forced a break (router WiFi off) and watched the chain come back on its own. That exercises the whole recovery path: under the hood #1779 makes the zboss adapter emit On that: I'm not going to pretend the earlier instability was root-caused. It's just not reproducing for you now, and I don't know why — could be the pre-#1779 image, a transient on the network path, or something coex-related. What #1779 changed is the failure mode, not the failure: if the link drops, it now self-heals (given an auto-restart container policy) instead of wedging. That's recovery, not prevention. "Usable at this stage" is a fair read, with that recovery caveat in mind. The limits stand though: one device, light traffic, is a functional check, not a stress test — scale and RF contention (more devices, busier WiFi) are still the open unknown. Single shared 2.4 GHz radio between WiFi and Zigbee is, by Espressif's own rating, the worst coexistence case, so it stays experimental. On where the fix lives: #1779 was merged into Koenkk/zigbee-herdsman on 2026-06-15 (merge commit If you ever push it harder — more devices or a busier WiFi environment — that's the data I'd most like to see. And the standard caveat for anyone reading along: spare stick, throwaway network, not your production setup. Thanks again. |
0 replies
|
Environment: M5Stack NanoC6 (ESP32-C6 rev0.2), running as Zigbee coordinator via esp-coordinator firmware. Setup:
Overall stability: good so far. Logs here |
0 replies
|
Thanks for the report — this is the first external coex datapoint with more than one device on it (the only prior coex tester ran a single plug), so it's genuinely useful. A few observations from your log, and one question:
One question so I read this correctly: is this the native-WiFi coex build (device joins your WiFi itself, z2m points at Honest caveat: the log covers ~8 minutes, so "good so far" is a functional check, not a stability result. The open question for coex is still duration + scale — does it stay up over hours/days, and how does it behave with more devices or a busier WiFi environment? If you keep it running, the data I'd most value: how long it stays connected without a z2m restart, the WiFi RSSI at the coordinator's spot, and whether any drops correlate with WiFi load. Spare stick / throwaway network as always. Thanks again. |
2 replies
|
z2m conf |
|
Shelly 2PM Gen4, Aqara Light Switch H2 EU, esphome with zigbee component on ESP32-C6 + DHT22 See more logs |
|
This is the datapoint I was hoping for — thanks. Two things confirmed, one open. Confirmed it's the native-WiFi coex build: The good news, and it's real: the coordinator and the TCP link stayed healthy the whole time. Your NanoC6/DHT22 streamed temperature and humidity uninterrupted right through the window where the other two devices were failing — no wedge, no dropped socket, no The trouble is isolated to two devices: the Aqara Light Switch H2 EU never completed its interview ( Honest read: this is per-device reachability, not a network-wide failure, and I can't tell from the log alone whether it's coex RF contention hitting those two spots or device-specific behavior. Both are live: the Aqara H2 EU has a reputation for fussy interviews on non-ember coordinators, and the Shelly 2PM Gen4's z2m converter polls custom clusters ( What would actually disambiguate it, if you're up for it:
The caveat from before still stands: one session, so this is a signal, not a verdict. But "coordinator stable, two specific devices flaky" is a much more tractable place to be than "the whole thing falls over." Thanks for pushing it past one plug. |
1 reply
See more logs |
|
Two useful things here — the routing map and the USB comparison — and they point in slightly different directions, so let me take them in turn. The USB-vs-coex comparison is the disambiguation I was hoping for. "A little more stably, fewer errors via USB" is the honest answer: coex contention is a real contributor, but it isn't the whole story — those two devices aren't perfectly clean even on a dedicated radio, so part of this is device-side and part is the shared 2.4 GHz radio. The map fits that: both end devices sit behind the Shelly 2PM (their link target is the router, not the coordinator), and the Aqara is a sleepy end device ( This run is also much cleaner than yesterday's — roughly 5 outbound timeouts in 20 minutes instead of a storm, with all three devices reporting normally in between. You noted it improved after a z2m reboot, but you also power-cycled the coordinator, so both got a fresh start at once and I can't tell which one cleared the backlog. That's worth a cheap test next time it degrades: restart only z2m, leaving the coordinator running. If that alone fixes it, the buildup is host-side; if it takes a coordinator power-cycle, it's firmware-side. That single A/B would tell us a lot. Point 2 — coordinator power-off and z2m not reconnecting — has a concrete cause in your log: you're on zigbee-herdsman 10.0.7, which predates the #1779 recovery fix. Without it, an unexpected socket drop doesn't raise Net: coordinator stable, coex is a measurable contributor on top of two already-demanding devices, and the reconnect gap is a herdsman-version thing with a known fix. The map plus the A/B is genuinely the most useful coex datapoint so far — thanks. |
1 reply
|
Glad to help you, great project, both on USB and via TCP |
|
OK, it "finally" happened. Coordinator stuck, z2m kept continuously restarting itself as expected, http status page of the coordinator still accessible and device is pingable, so wifi stack still works. Z2M debug logs attached, with bunch of "dead..." frames. I still didn't reboot the coordinator. Is there anything else I can do to help debugging the device in it's current state? |
4 replies
|
Reading your log, the sequence is clear: the coordinator came up with a wiped network (top of the log: What decides the next step is the firmware version on the stick:
One cheap datapoint while it's still wedged: let z2m restart once more and grab that log. Still a 30 s timeout on To recover: power-cycle the coordinator and tell me what it does — comes back formed, or comes back wiped again and z2m re-restores. That behaviour is itself a clue. |
|
Z2N did a few more loops with 30s timeout, so logs look the same. Status page says I'm on v1.3.61-coex Could I get more debug data over UART while it is still stuck? Soldering Rx/Tx on a could device will be interesting, though. |
|
I reproduced this on the bench with the exact backup image from your logs — and the problem is the backup itself, not the restore. Your coordinator's on-flash ZBOSS network state is corrupted: the network bytes (PAN, key) are physically still there, but ZBOSS can't parse them on boot, so it comes up factory-blank. Writing your image to a test C6 reproduces the blank every time, while a freshly-formed network on the same stick restores and resumes perfectly — so it's not the restore path, not coex, not anything host-side. Your saved image just encodes an unloadable state. That's also what your original "blank after 7 days" was: the network NVRAM got corrupted during operation — most likely an interrupted flash write (a power/USB glitch at the wrong moment). After that, every boot reads it as blank, z2m backs up the already-broken state (it looks valid — your PAN is right there in it), and restore faithfully writes the broken bytes back, so it blanks again. That's the loop you saw. Recovery — and this is the unwelcome part: this particular backup can't bring the network back. Delete z2m's On our side this exposed a real firmware gap worth fixing: One question, only if you happen to know: was there a power cut / unclean shutdown around when it first went blank? That would confirm the trigger. Thanks for leaving it wedged so I could catch it in the act. |
|
Hmm, so it might be that this isn't coordinator's fault after all... I'm not aware of the power glitch. C6 board is plugged into wall phone charger all the time and I didn't physically touch it. Attached is tail of the log when it happened. Network was working ok, my smart plug reported updates. I wanted to pair a new device, so I went to z2m and changed logging to debug. Before trying to pair new device, I first tried to clean up two ikea remotes that didn't interview successfully before, but since these two didn't have batteries at the time, I force-removed them from z2m. At that time, everything went down. I deleted the |
|
Update — I found the actual cause, and it's fixed. It wasn't a power glitch or random NVRAM corruption. When you remove a device, z2m sends a ZDO Mgmt_Leave to the coordinator, and the firmware was passing that to a low-level ZBOSS call that — for a device the network layer no longer knows (e.g. an offline or half-interviewed one) — made the coordinator do a network-leave on itself: the PAN went to 0xFFFF and the NVRAM blanked, live, with no reboot. z2m then backed up that blank state and restored it back, which is the loop you saw. So my earlier "corrupted NVRAM" read was the symptom; the trigger was the device removal itself. I reproduced it on the bench and fixed it: device-leave now goes through Espressif's official esp_zb_zdo_device_leave_req API, which doesn't self-wipe (a self-addressed leave is refused outright). I verified it end-to-end over the WiFi/TCP path — formed a network, fired the same kind of leave that used to wipe, and the coordinator kept its network; device removal works correctly again. It's live now in the experimental WiFi-coex web flasher as v1.3.62-coex: https://install.busware.de/zboss/coex/ . One heads-up: flashing is a fresh install, so you'd re-do the Improv Wi-Fi setup and re-pair your plug — but it stops the wipe from happening again the next time you remove a device. Your current network is fine as it is; this is about preventing a recurrence. Thanks for the detail in your report — "no power event, and it went down when I force-removed those remotes" is exactly what pointed at the cause. |
0 replies
|
@peca89 — how did the v1.3.62-coex build hold up on your side? That one gates the self-leave bug behind the spontaneous wipes: a |
0 replies
|
Update for the coex testers: the coex build on the web flasher (install.busware.de/zboss/coex) is now v1.5.75-coex — it brings the coex variant up to the current master (v1.5.73) plus the coex-specific work that had accumulated on the branch:
One transparency note on backups: the raw NVRAM backup Z2M pulls from the stick covers the full @peca89 if you're still on v1.3.62-coex, this is the recommended update. |
0 replies
|
Thank you! Sorry, I've been away for past few weeks so I didn't have time to experiment further. I will update once I have something new. |
0 replies
|
Regarding the 2-chip CDC2NET solution: Espressif created the so called Espressif Thread Boarder Router https://docs.espressif.com/projects/esp-thread-br/en/latest/hardware_platforms.html which is a small board with 2 USB-C connectors and a combination of an esp32-H2 and an esp32-S3. It aims to matter devices but certainly could also be used for zigbee. Price of the board is a bit more than 10 USD. |
4 replies
|
Good pointer, thanks — that board fits this discussion well. Espressif themselves market it as the "ESP Thread Border Router /Zigbee Gateway Board" (ESP32-S3-WROOM-1 + ESP32-H2-MINI-1), so using it for Zigbee is very much intended. A few notes from the official schematic (https://dl.espressif.com/dl/schematics/esp_thread_br_zigbee_gw_schematics_v1.3.pdf), because the wiring details decide what this board can do with this firmware: What should work today: the H2 half as a plain USB coordinator. USB1 on that board is wired directly to the ESP32-H2's native USB-Serial/JTAG (USB2 goes to the S3). So the stock esp32h2 build from the web flasher should flash and run on the H2 of that board exactly like on an H2 devkit — with the S3 simply sitting idle. I don't have this board on the bench yet, so this is "read from the schematic", not "verified on hardware" — but there is nothing board-specific in that path. The 2-chip network setup needs one missing piece of firmware. On this board the two chips are interconnected via the H2's UART0 (to S3 GPIO17/18) plus reset/boot strap lines — there is no USB path between the S3 and the H2. CDC2NET is a USB-host→TCP bridge, so it does not apply here as-is. The matching architecture on this board would be:
Two honest caveats on that second path: the firmware's UART transport is hardware-validated on the C6, but has never been exercised on an H2 (H2 support in general is field-confirmed over USB only). And the H2's ROM bootloader normally prints a boot banner on UART0 at reset — the coordinator's own RX is gated against line noise, but that banner flows the other way, toward the host, and how Z2M's zboss adapter reacts to pre-frame bytes on a TCP port is untested. So: interesting hardware for this use case. Usable today for the plain-USB path (H2 coordinator, S3 idle), and a sensible candidate platform for the network path once an S3-side UART bridge firmware exists. This looks worth checking properly, so we will order one of these boards and verify both paths on real hardware in the coming weeks — first the plain-USB path (H2 coordinator via USB1), then the UART transport on the inter-chip link. Results will be posted here. If you happen to try the USB path before that, feedback is of course still welcome. |
|
UART Communication between the two chips can use the spinel protocol https://github.com/openthread/spinel-spec and https://datatracker.ietf.org/doc/html/draft-rquattle-spinel-unified-00, mainly described in the espressif SDK thread part. |
|
@xbln — good pointer, and it's worth being precise about where Spinel fits. Spinel is a Radio Co-Processor protocol: it turns the H2 into a "dumb radio" and runs the full 802.15.4 network stack on the host side. That is exactly right for the board's native role (Thread border router / Matter), and it's how OpenThread's RCP works. For a Zigbee coordinator, though, the approach here is deliberately the opposite: the whole ZBOSS stack stays on the H2 — that's what esp-coordinator is, a ZBOSS NCP. So the H2 isn't a Spinel radio, it's a full coordinator that speaks the ZBOSS NCP serial protocol. The inter-chip link therefore only has to carry that NCP frame stream — there's no Spinel layer in between. On the Thread-BR board that means:
I did look at the alternative where the S3 runs a full IP stack and the H2 exposes the NCP over TCP itself, but the transparent-bridge route is simpler, keeps the H2 lean, and has a nice side effect: because the bridge (not the H2) terminates the TCP connection, a coordinator reboot doesn't tear down the host's connection — the host keeps talking through the bridge, the way an external USB-UART adapter survives an While the board is still in transit I validated this end-to-end on the bench, with a transparent serial↔TCP bridge standing in for the S3: Z2M forms a network, a device pairs and interviews, on/off control works, and the link rides through a coordinator reset — all over the bridged connection, not USB. The board-specific pieces (the real inter-chip UART, the H2's ROM boot banner on that line) get verified on the actual hardware once it arrives, and I'll post those results here. |
|
@xbln — following up on the promise from July 22nd: the board arrived, both paths are verified on real hardware, and the second one turned into something more than a test. Path 1 — the H2 half as a plain USB coordinator. Works exactly as the schematic suggested: the published There is a catch the schematic does not show, though, and it matters in practice: Espressif's factory border-router firmware on the S3 reflashes its bundled Path 2 — the inter-chip UART. This is the interesting one, and it is now a finished thing rather than an experiment. The H2 runs esp-coordinator with its NCP frames on the inter-chip UART instead of USB (this board needs Because two chips are awkward to flash by hand, the whole thing ships as one image: https://install.busware.de/cdc2net/zbgw/ One click writes the S3 firmware and, in a separate flash partition, the H2's firmware. On first boot the S3 finds the factory Verified end-to-end on the board, over both uplinks — network formation, a factory-new device joining on air in about three seconds, interview, pairing, and on/off round-trips. Configuration on the Zigbee2MQTT side is just: serial:
adapter: zboss
port: tcp://<gateway-ip>:2329No add-on hardware needed. WiFi is provisioned over the very same USB-C port you flash from, via Improv; if you would rather not use a cable, leaving the gateway unconfigured for about two minutes opens its own access point with a configuration page. The Ethernet sub-board is optional — when fitted, a wired link is picked up by DHCP at boot and takes precedence. Two things to be honest about:
Thanks for the pointer — that board would not have been on our bench without it. Details and the full write-up now live in their own thread: Discussion #10. |
|
Hello. flashed namoesp32-c6. 4 devices... |
2 replies
|
@seravd2 Two things first, then the checks. Key leak: the What the logs say: every failure is One fact, not a diagnosis: you are on the coex build — single C6 radio time-shared between WiFi and Zigbee, as the warning on its own status page says — with Zigbee channel 11 (2405 MHz) sitting inside WiFi channel 1 (2412 ±10 MHz), at WiFi RSSI −68 dBm. I have not reproduced your symptom, so that is something to rule out, not a cause. Cheapest first:
Also: broken since the first flash, or did it start later? If 1 changes nothing and the info-level log is clean, the next A/B is the plain USB (non-coex) firmware on the same stick and devices — that separates coex-specific from not. Bigger step, so let us see 1–3 first. |
|
@seravd2 — quick check-in, and no news from my side: I have not been able to reproduce the Even a one-liner helps:
"Changed nothing, still broken" and "it went away on its own" are both useful answers: the first keeps radio contention on the table, the second points somewhere else entirely. And if you have moved on to a different setup in the meantime, just say so and I will stop chasing it here. |
|
More data. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I'm very much excited about the possibility of using ESP32-C6 as a zigbee coordinator. However, I don't understand from the documentation is it currently possible to connect to zigbee2mqtt backend via wifi (ser2net or socat) or only via serial?
All reactions