fix battery_level

[mverch67]

This PR fixes the battery_level field which has been hijacked by a powered state (battery_level > 100).

While powered to USB / charging the battery the UI has no percentage information about the battery level except when re-implementing the battery curves (i.e. deduct from actual voltage) which are already implemented in the firmware. For a user this is a poor experience as he doesn't see the actual percentage level of his device to know when it's fully charged, but many devices already provide this detail of information.

This PR removes this semantic from battery_level by defining a clean new battery_status field that provides distinct charging information and helps to preserve the percentage information during charging.

Checklist before merging

• All top level messages commented
• All enum members have unique descriptions

[github-actions]

The latest Buf updates on your PR. Results from workflow pull-request / build (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Jun 4, 2026, 12:07 PM

[thebentern]

@jamesarich @garthvh I like this strategy. It would be a good one to run through the cross platform design?

[jamesarich]

Yes let's. Also in the same vein I've noticed that the BLE BAS battery reporting isn't working appropriately and could possibly benefit from this as well.

[oscgonfer]

I think this is nice. How do these get populated in meshtastic?

If the info is reported from charger ICs, I would suggest reporting battery presence and charging state if we have the info too, separate from the last status proposed.

In many chargers, we can get the following info:

• Battery info:
  "Not charging",
  "Pre charging", (maybe not needed - just "charging")
  "Fast charging", (maybe not needed - just "charging")
  "Charge finished",
• USB info:
  "Unknown",
  "USB host connected",
  "Adapter connected",
  "USB OTG connected",

So maybe the list could be longer?

enum BatteryStatus {
  /*
   * No further information
   */
  BATTERY_STATUS_UNKNOWN = 0;

  /*
   * Running on battery (not externally powered)
   */
  DISCHARGING = 1;

  /*
   * Externally powered and actively charging
   */
  CHARGING = 2;

  /*
   *Externally powered and fully charged
   */
  FULLY_CHARGED = 3;

  /*
   *Battery not present
   */
  NOT_PRESENT = 4;

  /*
   * Externally powered but not charging due to anomaly (temperature, fault detected)
   */
  CHARGE_FAILURE = 5;
}

Maybe this would unload a bit the NOT_CHARGING option if we get the info from the chargers?

[mverch67]

Maybe this would unload a bit the NOT_CHARGING option if we get the info from the chargers?

It may not be possible to get the detailed info but could be assumed if percentage is at 100% and not charging then the battery may be full.
I found NOT_CHARGING more neutral rather than claiming there has to be a CHARGE_FAILURE. Can also add both.

[oscgonfer]

Maybe this would unload a bit the NOT_CHARGING option if we get the info from the chargers?

It may not be possible to get the detailed info but could be assumed if percentage is at 100% and not charging then the battery may be full.

That sounds good.

I found NOT_CHARGING more neutral rather than claiming there has to be a CHARGE_FAILURE. Can also add both.

Maybe best to not assume failure then, if we can't know for sure.

[mverch67]

Maybe best to not assume failure then, if we can't know for sure.

My point is that in your list there is no other option than failure (or full) if it's not charging, so I opted for a more neutral NOT_CHARGING rather than having to set it to CHARGE_FAILURE. E.g. the charger could be manually turned off, or the device does not support charging like the T-Beam 1W.

[oscgonfer]

Maybe best to not assume failure then, if we can't know for sure.

My point is that in your list there is no other option than failure (or full) if it's not charging...

Oh, but the battery could be not present as well. This is very useful for debugging devices too.

Will you keep the list as the original then, or consider adding other suggested options?

[mverch67]

Will you keep the list as the original then, or consider adding other suggested options?

What about:

  BATTERY_STATUS_UNKNOWN = 0;
  DISCHARGING = 1;
  CHARGING = 2;
  FULLY_CHARGED = 3;
  NOT_CHARGING = 4;
  NOT_PRESENT = 5;
  CHARGE_FAILURE = 6;

[oscgonfer]

Will you keep the list as the original then, or consider adding other suggested options?

What about:

  BATTERY_STATUS_UNKNOWN = 0;
  DISCHARGING = 1;
  CHARGING = 2;
  FULLY_CHARGED = 3;
  NOT_CHARGING = 4;
  NOT_PRESENT = 5;
  CHARGE_FAILURE = 6;

Looks great to me! ❤️ I can support on the firmware side if needed.