Companion core stats always report battery_mv: 0 #144

New Issue

2026-10-27T09:35:22+01:00

adam commented

2026-10-27 09:35:22 +01:00

EDIT: a bit vibe coded, so my apologies if that's frowned upon. this did seem like a straight forward fix..
MeshCore companion clients display the battery of the device they are connected to. A Python repeater always reports 0, so the field is dead in every companion app — even when a sensor plug-in is actively reporting a battery.

The plumbing is otherwise complete on both sides:

clients request it via CMD_GET_BATT_AND_STORAGE
openhop_core companion/frame_server.py packs battery_mv into the STATS_TYPE_CORE frame
the repeater fills in a placeholder

repeater/main.py, _get_companion_stats() (present on both main and dev):

if stats_type == STATS_TYPE_CORE:
    return {
        "battery_mv": 0,        # <-- hardcoded
        "uptime_secs": uptime_secs,
        "errors": 0,            # <-- also hardcoded
        "queue_len": min(255, queue_len),
    }

Meanwhile SensorManager.get_summary() is already available on the same class and its readings carry battery_voltage_mv / battery_voltage_v — openhop_modem, waveshare_ups_d, lafvin_ups_3s and ina219 all publish one.

Context

I run a solar-powered openHop modem on a mast, driven by a repeater over pymc_tcp. Its battery was visible in /api/stats and would have been visible in Home Assistant, but the phone showed nothing — and the node went flat overnight. Battery state is useful for a companion app to show for an off-grid node.

Suggested fix

Surface the first sensor reading that publishes a usable battery voltage, accepting mV or V, returning 0 when none is available. PR follows.

errors: 0 is hardcoded too; I have left that alone as it needs a source of truth

EDIT: a bit vibe coded, so my apologies if that's frowned upon. this did seem like a straight forward fix.. MeshCore companion clients display the battery of the device they are connected to. A Python repeater always reports `0`, so the field is dead in every companion app — even when a sensor plug-in is actively reporting a battery. The plumbing is otherwise complete on both sides: - clients request it via `CMD_GET_BATT_AND_STORAGE` - `openhop_core` `companion/frame_server.py` packs `battery_mv` into the `STATS_TYPE_CORE` frame - the repeater fills in a placeholder `repeater/main.py`, `_get_companion_stats()` (present on both `main` and `dev`): ```python if stats_type == STATS_TYPE_CORE: return { "battery_mv": 0, # <-- hardcoded "uptime_secs": uptime_secs, "errors": 0, # <-- also hardcoded "queue_len": min(255, queue_len), } ``` Meanwhile `SensorManager.get_summary()` is already available on the same class and its readings carry `battery_voltage_mv` / `battery_voltage_v` — `openhop_modem`, `waveshare_ups_d`, `lafvin_ups_3s` and `ina219` all publish one. ### Context I run a solar-powered openHop modem on a mast, driven by a repeater over `pymc_tcp`. Its battery was visible in `/api/stats` and would have been visible in Home Assistant, but the phone showed nothing — and the node went flat overnight. Battery state is useful for a companion app to show for an off-grid node. ### Suggested fix Surface the first sensor reading that publishes a usable battery voltage, accepting mV or V, returning 0 when none is available. PR follows. `errors: 0` is hardcoded too; I have left that alone as it needs a source of truth

adam closed this issue

2026-10-27 09:35:22 +01:00

adam commented

2026-10-27 09:35:23 +01:00

@yellowcooln

@yellowcooln

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#144