Repository navigation
Conversation
vsychov
force-pushed
the
feature/zigbee-ip-backhaul
branch
3 times, most recently
from
September 19, 2026 21:33
7f49ea6 to
9138206
Compare
vsychov
force-pushed
the
feature/zigbee-ip-backhaul
branch
from
September 20, 2026 19:34
9138206 to
d8272bb
Compare
vsychov
force-pushed
the
feature/zigbee-ip-backhaul
branch
from
September 21, 2026 19:07
d8272bb to
d046835
Compare
Validate complete multipart boundaries before finishing uploads and release maintenance on disconnect or timeout. Initialize network identity before AP fallback and start background services only once, respecting USB mode. Handle peer allocation failure without throwing and recheck both radio roles after maintenance. Expose ESP firmware version 20260925.1 in the UI and boot console. Reviewed by a subagent before commit. Production and debug builds, 13 native/integration suites, and 57 acceptance-script unit tests pass. Late UART replies remain a separate unresolved issue.
|
Recommend that anyone interested in this type of Zigbee Router over Ethernet concept should check out this other discussion: Also see this related discussion: and the experimental draft TREL-like Ethernet backbone Proof-Of-Concept being worked on there for Ziggurat firmware: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi! I'm extending CZC firmware so Zigbee devices in separate radio coverage areas can use one coordinator through an encrypted IP connection between gateways. Zigbee software connects to a Master as usual, while Satellites provide remote radio coverage.
Would you be willing to accept this as an optional feature in CZC firmware? The modes are included in the main firmware, disabled by default and configured through the Role page.
Main changes:
The radio extensions are a separate change for Z-Stack-firmware PR #609. This PR contains the ESP32 implementation and requires compatible radio firmware for the new modes.
I tested the following cases:
Built with GPT-6-astra.