eluminocity: decouple delta-bridge web/RFID from MQTT broker + write_enable#29
Open
RAR wants to merge 3 commits into
Open
eluminocity: decouple delta-bridge web/RFID from MQTT broker + write_enable#29RAR wants to merge 3 commits into
RAR wants to merge 3 commits into
Conversation
…enable Two bench-caught bugs (2026-05-21 M12 flash), same root theme: the web UI's monitoring path was wrongly coupled to unrelated subsystems. Bug #2 — web/RFID starved while the MQTT broker is down. The main loop gated web_tick()/rfid_reader_tick() behind a `continue` in the broker- reconnect path, and slept the full backoff (up to 60s). With the default broker (127.0.0.1, never up) the web UI was permanently unreachable — and the web UI is the only way to fix a bad broker setting. Fix: the loop now runs at its normal period_us cadence regardless of broker state; the reconnect attempt is gated on a wall-clock deadline instead of a blocking sleep, so web/RFID are serviced every iteration. Bug #3 — /api/state showed charger_state_init() defaults (V/I/P=0, availability "offline") whenever write_enable=false, because main.c handed the web server a NULL shmem pointer. Fix: always pass &sm (a read-only attach when write_enable=false); reads work through the RO mapping. Writes already fail safe via writable_ptr(), but cs_apply_* now gates explicitly on sm->writable and returns a clear "write disabled (write_enable=false)" 503 instead of the misleading "shmem not attached" / "shmem write failed". - main.c: non-blocking broker retry; ws.shm = &sm unconditionally - commands.c: cs_apply_{rated_amps,authorize,clear_faults}_write gate on !sm->writable with a clear message - test_commands.c: +9 assertions — RO-shmem writes rejected, no mutation Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…ion suffix
The DcoFImage build packed a fixed BRIDGE_BIN (delta-bridge.m12) that no
make rule ever rebuilt — so editing src/ and running `make dcofimage`
silently shipped a stale binary. Cost a wasted bench flash on 2026-05-21:
the web-decouple fix was in src/ and the host test binaries but never
reached the device.
- `dcofimage` now depends on a new `cross` target that cross-compiles
delta-bridge fresh in the muslcc Docker image (same invocation CI
uses) — a stale binary is now structurally impossible.
- BRIDGE_BIN: delta-bridge.m12 -> delta-bridge. The .m<n>/.v<n> suffixes
were bench-juggling copies; git history is the version record.
Old delta-bridge.{m12,v10..v15} artifacts deleted (none were tracked).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…ig write findings docs/22: build invocation simplified to `make dcofimage` (now cross-builds fresh); new "Bench-validation results (2026-05-21)" — M12 image flashed + booted over 3 cycles, the config-seed / web-decouple / stale-binary bugs found and fixed, bug #3 confirmed live on hardware. docs/23: §7 — driving GetConfig() programmatically. The mknod /dev/sda workaround (bench-confirmed), and the critical full-replace finding: a partial DeltaEVSEConfig resets absent keys to defaults, so writes must carry all 36 keys. Plus the ErrorHandle SNMP-trap path. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.
Summary
Two bugs caught on the first real M12 bench flash (2026-05-21), same root theme — the web UI's monitoring path was wrongly coupled to unrelated subsystems.
Bug #2 — web/RFID starved while the MQTT broker is down. The main loop gated
web_tick()/rfid_reader_tick()behind acontinuein the broker-reconnect path and slept the full backoff (up to 60s). With the default broker (127.0.0.1, never up) the web UI was permanently unreachable — a chicken-and-egg trap, since the web UI is the only way to fix a bad broker setting. The loop now runs at its normalperiod_uscadence regardless of broker state; reconnect is gated on a wall-clock deadline instead of a blocking sleep.Bug #3 —
/api/stateshowedcharger_state_init()defaults (V/I/P=0,availability:offline) wheneverwrite_enable=false, becausemain.chanded the web server aNULLshmem pointer. Now&smis passed unconditionally (a read-only attach whenwrite_enable=false); reads work through the RO mapping. Writes already fail safe viawritable_ptr(), butcs_apply_*now gates explicitly onsm->writableand returns a clear503 write disabled (write_enable=false)instead of the misleadingshmem not attached.Changes
main.c— non-blocking broker retry (time()-gated);ws.shm = &smunconditionallycommands.c—cs_apply_{rated_amps,authorize,clear_faults}_writegate on!sm->writabletest_commands.c— +9 assertions: RO-shmem writes rejected with no mutationTest Plan
make test— 843/843 passmake dcofimage— builds, verify clean/api/statelive withwrite_enable=false; web UI reachable with broker down