Skip to content

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

Merged
RAR merged 4 commits into
mainfrom
eluminocity-fix-web-decouple
May 22, 2026
Merged

eluminocity: decouple delta-bridge web/RFID from MQTT broker + write_enable#29
RAR merged 4 commits into
mainfrom
eluminocity-fix-web-decouple

Conversation

@RAR

@RAR RAR commented May 21, 2026

Copy link
Copy Markdown
Owner

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 4 commits May 21, 2026 10:35
The default config was written to /etc/delta-bridge.conf.default but
first-boot.sh seeds from $DBDIR/delta-bridge.conf.default
(/etc/delta-bridge/delta-bridge.conf.default). The cp failed silently
and first-boot.sh still printed "seeded ...", so the unit booted on
compiled-in defaults (web_enable=0, rfid_enable=0) — no web UI, no RFID.

Bench-caught 2026-05-21 on the first real M12 flash: the eraseblock fix
booted clean, but the web UI never came up. Root-caused to this one
path mismatch; delta-bridge's own log history confirms web + RFID work
when a config file is present.

- build-dcofimage.sh: write the default to etc/delta-bridge/
- first-boot.sh: guard the "seeded" message on cp success
- verify_dcofimage.py: assert the default at the correct subdir path
  (the verifier had encoded the same wrong path, so it passed the bug)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…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>
@RAR RAR changed the base branch from eluminocity-fix-config-seed-path to main May 22, 2026 20:04
@RAR RAR merged commit 61ba88b into main May 22, 2026
7 checks passed
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