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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user