li3: decode status flags, fix info-sensor expire_after, restart bluetooth after first failed scan

- status_text: decode the 24-bit "status" field into human-readable flag
  names (e.g. "Cell Temp Low, Low Voltage") instead of raw hex, using the
  bit table pulled from com.lithionics.bms's array/advanced resource (dumped
  with aapt -- the app's own StatusCodeTable class references stale/wrong
  resource IDs and can't be trusted for this). Applied to "status" only;
  last_fault_code is a lifetime latch that accumulates many bits over time
  and isn't meaningfully summarized the same way.

- Fixed the info sensors (total_consumed, firmware_version, serial_number,
  etc.) showing "Unavailable" in HA a minute after connecting: they were
  getting the same expire_after as the periodic telemetry sensors, but the
  $info line the come from is only sent once per BLE connection, so HA's
  expire timer always fired. These are retained-topic diagnostics meant to
  hold their last value indefinitely; expire_after now only applies to the
  periodic SENSORS group.

- STUCK_DISCOVERY_THRESHOLD 3 -> 1: restart bluetooth.service after the
  first failed scan instead of waiting for three, cutting reconnect time
  roughly in third. Still rate-limited via BLUETOOTH_RESTART_COOLDOWN_S.

Also removed the per-line "RAW ..." debug print (was flooding the journal).

All three changes verified live on host wan via journalctl/mosquitto_sub.
This commit is contained in:
Andreas Wrede
2026-08-18 10:18:56 -04:00
parent 382f99b508
commit e5e776405a
2 changed files with 53 additions and 16 deletions
+2 -2
View File
@@ -282,8 +282,8 @@ script's docstring for the full field layout.
systemd restarts. This Pi's onboard Bluetooth adapter (Cypress/CYW43) occasionally
wedges bluetoothd's discovery state after a run of failed connects to this specific
device (`Discovering` stays `yes` forever, every subsequent connect fails with
`le-connection-abort-by-local`) — after 3 consecutive scan failures the daemon
restarts `bluetooth.service` itself to clear it, rate-limited to once per 5 min so it
`le-connection-abort-by-local`) — as soon as a scan fails the daemon restarts
`bluetooth.service` itself to clear it, rate-limited to once per 5 min so it
doesn't repeatedly disrupt the AP's other BLE gear (motion sensors, IR remote).
- This BLE module accepts only **one central connection at a time** — while
`van-li3-battery` holds it, the Li3 phone app can't connect simultaneously.