cpcd-rtl8196e is missing

[hlyi]

@jnilo1 Under build instructions of 2-Zigbee-Radio-Silabs-EFR32/25-RCP-UART-HW/README.md, you mentioned cpcd-rtl8196e. But I couldn't find it under 25-RCP-UART-HW. Do you know where I can find it? I am interested in have cpcd run at the hub. and HomeAssistant running zigbeed and zigbee2mqtt. Thanks!

[jnilo1]

You cannot find it because it was never there — my bug, not your search

cpcd-rtl8196e/ has never existed in any published tree. It is in no branch's history, and it is not on my machine either: it got as far as a directory name, was excluded from the repo as unfinished (25-RCP-UART-HW/.gitignore still lists it under "Work in progress, not ready for release"), and was abandoned. The README line advertising it has been dangling since January. Sorry for the wild goose chase — I am removing the line, because a README pointing at a directory nobody can ever have is worse than no line at all.

That leaves the real question, which is better than the one you asked. Let me separate what is impossible from what is merely unbuilt, because I had those two confused myself until I went and checked.

The hard fact: zigbeed can never run on the gateway

Not "would be slow" — cannot exist. The Zigbee PRO stack that zigbeed links against ships precompiled in the Silabs SDK, as ar archives of object files. Here is the complete set of architectures Silabs builds it for:

$ ls gecko_sdk/protocol/zigbee/build/gcc/
arm32v7  arm64v8  cortex-m33  cortex-m4  i386  x86-64

No MIPS anywhere in the SDK, and the stack is closed source, so nobody outside Silabs can produce one. That is why build_zigbeed.sh picks zigbee_x86_64 / zigbee_arm64 / zigbee_arm32 from uname -m and hard-errors otherwise: there is nothing else to select. So "the whole chain on the hub" is off the table permanently, and that is not a decision anyone here gets to revisit.

But your split — cpcd on the hub, zigbeed on HA — is not blocked. It is just unwritten.

I nearly told you it was impossible, on the grounds that cpcd only speaks AF_UNIX to its clients. That is true today but it is not a wall, and it is worth being precise about, because our existing TCP patch is easy to mistake for the answer here:

• Downstream, toward the radio — a pluggable bus driver: driver/driver_uart.c, driver_spi.c, and the driver_tcp.c we add. That side connect()s to tcp_server_address. This is the one we already moved across the network.
• Upstream, toward applications — server_core/server/server.c: nine AF_UNIX call sites, zero AF_INET. Stock cpcd, untouched by us.

So our patch moved the radio across the network, not the application. Moving the application too would be a second, different patch — and every piece on that path turns out to be open source. zigbeed itself never calls CPC: it takes a --radio-url and hands it to otSysInit(), and the actual CPC client is OpenThread's platform-abstraction/posix/cpc_interface.cpp (BSD-licensed source), talking to libcpc, which we build ourselves from cpc-daemon. The closed binary is the Zigbee stack, and the Zigbee stack is nowhere near the transport.

So: cpcd's server side plus the libcpc client side. Two ends, both source, neither exotic. Not an afternoon, but not a wall either — and the honest cost is not the writing, it is carrying a patch on two upstreams across their releases, forever, for a link that has to be exactly right or the radio misbehaves in ways that are painful to debug.

Which makes the real question: what would it buy you?

There is a genuine argument for it, and if it is the one you have in mind I would like to hear it said out loud. Today the TCP hop carries raw UART bytes — the in-kernel bridge is a byte pipe — so the CPC session itself spans the network, and a stalled or dropped TCP connection is something CPC has to notice and resynchronise from. Moving cpcd to the hub would keep the CPC link entirely on-box over the UART, and push the network boundary up to a layer with more tolerance for latency. That is a real engineering position, not a preference.

What it costs is the patch surface above, on a link where the current arrangement is now well-tested — the zigbeed reconnect crash in #112 is exactly the class of bug this split can produce, and it is fixed and quiet now.

So tell me which one is driving you. If it is "the radio should not care whether Home Assistant is up", that is the interesting version and worth its own thread. If it is "one less moving part on the HA box", the container is genuinely the smaller moving part and I would just start here:

What ships today

EFR32 (RCP) --UART 460800--> RTL8196E in-kernel bridge --TCP:8888--> [ cpcd -> zigbeed -> Zigbee2MQTT ]
        the hub                                                            your HA machine

Which is your setup exactly, minus moving cpcd. Start from 25-RCP-UART-HW/docker/docker-compose-zigbee.yml — mosquitto, ghcr.io/jnilo1/cpcd-zigbeed and Zigbee2MQTT together. Set RCP_HOST to your gateway's IP (RCP_PORT is already 8888) and flash the radio with ./flash_efr32.sh rcp. You get EZSP v18 out of a Series 1 radio, which is the entire point of the RCP path.

One caveat, since you are on a G4: the RCP build for sengled-e39-g8c compiles but has never been hardware-validated, and no prebuilt is committed for it — CPC does not do software flow control, so that board builds with flow control none and leans on the bridge as its flow partner. You would be the first to run it, and I would very much like to hear how it goes.

[hlyi]

@jnilo1 Thanks for your detailed explanation as always!

My goal to move as much as workload to distributed devices as much as possible and keep distributed device updated with the latest FW stacks, Also reduce network traffic as much as possible. As you mentioned that zigbee stack could not run on MIPS. So the next best thing is CPCd on the hub, so it doesn’t have to transport all 802.15.4 traffic to CPCd daemon on the host. If I have quite a few G4 hubs around house, it could reduce load on the host. The question is that if it requires a lot of effort to have this type of infrastructure built.

[jnilo1]

cpcd on the gateway: built and tested

Rather than estimate the effort, I cross-compiled cpcd for the RTL8196E and ran it on a gateway this afternoon. It works. Statically linked against musl for the Lexra core, cpcd 4.5.3.0 completes the full CPC handshake with the RCP over the local UART at 460800 with hardware flow control:

Info : [CPCd v4.5.3.0] [Library API v3] [RCP Protocol v5]
Info : Secondary bus bitrate is 460800
Reset Sequence : Obtained Secondary APP version
Info : Daemon startup was successful. Waiting for client connections

A CPC client attaches to it on the box and opens endpoint 15_4, the 802.15.4 endpoint a Zigbee host stack drives. The binary is 490 KB static, which fits the flash budget comfortably.

So that half is not the obstacle. What remains is the part described earlier: cpcd serves clients over AF_UNIX/SOCK_SEQPACKET, so a remote zigbeed cannot attach. That needs a patch to cpcd's server side and one to libcpc's client side — both open source, plus framing work to carry SEQPACKET's message boundaries over a TCP stream. Roughly a weekend for a working version. The larger cost is ongoing: two patched upstreams to carry across every release, on a link that has to be exact.

On traffic

The bridge is a byte pipe over UART1, so what crosses the LAN per hub is bounded by the configured baud rate: 460800 8N1 = 45 kB/s, both directions summed. The radio cannot fill that in any case — 802.15.4 at 2.4 GHz is a 250 kbit/s PHY, roughly 30 kB/s of airtime shared by the whole PAN before MAC overhead and backoff. Several hubs with saturated PANs come to a few hundred kB/s on a wired LAN.

cpcd on the hub would not remove that traffic. The 802.15.4 payload still has to reach zigbeed on the host; only CPC's link-layer framing would stop crossing the network.

On host load

zigbeed is where the CPU and memory go; cpcd is a transport shim. zigbeed is also the component that cannot be moved, because Silabs ships the Zigbee PRO stack as a closed binary for six architectures and MIPS is not among them. With cpcd on the hubs you would still run one zigbeed per hub on the host, and save one small daemon per hub.

On keeping stacks current

This is already what the RCP architecture provides, and it provides it by keeping the stack on the host: you upgrade zigbeed and the EFR32 is untouched. That is how a Series 1 MG1B ends up speaking EmberZNet 8.2.2 / EZSP v18 when Silabs froze on-chip Series 1 support at 7.5.1. Moving the stack toward the hub would cost that property rather than add to it.

A different rationale, if it applies

There is one argument for cpcd on the hub that the numbers above do not undercut: robustness. Today the CPC session spans the network, since the TCP hop carries raw UART bytes, so a stalled link or a restarted host is something CPC has to detect and resynchronise from. cpcd on the hub would keep CPC on-box and move the network boundary to a layer that handles latency and reconnects better. With several hubs this matters more, not less. The zigbeed reconnect crash in #112 was this class of problem.

If robustness across multiple hubs is closer to what you are after than bandwidth or host CPU, that changes the assessment and is worth discussing separately. On the traffic and load figures alone, the effort does not look justified.

The files are attached — and they are yours, not the project's

cpcd-rtl8196e.zip contains everything: the build script, the CMake toolchain for the Lexra core, cpc-probe.c, a README with the full results and the reasoning, and the two binaries I ran on the bench. They are static MIPS-I, so they will run on a G4 hub as-is — it is the same RTL8196E. You would need RCP firmware on the MG13 first, and as mentioned that build has never been hardware-validated and has no committed prebuilt, so you would be the first.

To be straight with you about where this stands rather than leave you guessing: I am not going to maintain this, and the design is not going into the repository. Not because the idea is bad — you were right that the port was writable, and it turned out to be a single afternoon. It is that the remaining piece would leave the project carrying patches on two upstreams indefinitely, and by the numbers above I cannot justify that maintenance against what it returns. Taking on something I would not keep working properly would serve you worse than saying so now.

So the code is offered as a starting point with no strings and no support. If you take it further — particularly if you build the client-side TCP and find the robustness case pays off across several hubs — I would genuinely like to hear how it goes, and the door is open to revisit this on evidence. The cross-compile question at least is settled now rather than folklore, which is the part that was costing everyone time.

cpcd-rtl8196e.zip

[hlyi]

@jnilo1 Thanks a lot for the insight and providing compiled cpcd!

You are right about the robustness when running cpcd on the hub. That's also one thing I am looking for. Based your notes Direct Ethernet connection: The CPC protocol is sensitive to latency. Avoid WiFi or congested networks. in EMBERZNET-8.x-GUIDE.md. I assumed that running cpcd on hub will be better.

You brought up a lot good points of extra effort maintaining this solution. Maybe I was under wrong impression that CPC carries all traffic including zigbee/BLE/openthread, and when a client connect to CPCd, CPCd only sends related packets, say zigbee, to the client, other packets are filtered. If the assumption was right, the TCP will carry less traffic than UART.

Let me study more on the information you provided, and think about if it is the right path going forward. Nevertheless, I deeply appreciate the extra effort you putting into discussion!