Skip to content

eluminocity: decouple delta-bridge web/RFID from MQTT broker + write_enable#29

Open
RAR wants to merge 3 commits into
eluminocity-fix-config-seed-pathfrom
eluminocity-fix-web-decouple
Open

eluminocity: decouple delta-bridge web/RFID from MQTT broker + write_enable#29
RAR wants to merge 3 commits into
eluminocity-fix-config-seed-pathfrom
eluminocity-fix-web-decouple

Conversation

@RAR
Copy link
Copy Markdown
Owner

@RAR RAR commented May 21, 2026

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 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 — 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 normal period_us cadence regardless of broker state; reconnect is gated on a wall-clock deadline instead of a blocking sleep.

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. Now &sm is passed unconditionally (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 503 write disabled (write_enable=false) instead of the misleading shmem not attached.

Changes

  • main.c — non-blocking broker retry (time()-gated); ws.shm = &sm unconditionally
  • commands.ccs_apply_{rated_amps,authorize,clear_faults}_write gate on !sm->writable
  • test_commands.c — +9 assertions: RO-shmem writes rejected with no mutation

Test Plan

  • make test — 843/843 pass
  • make dcofimage — builds, verify clean
  • Bench: web UI + /api/state live with write_enable=false; web UI reachable with broker down

Stacked on #28 (config-seed fix). Merge #28 first.

RAR and others added 3 commits May 21, 2026 12:25
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant