protobufs icon indicating copy to clipboard operation
protobufs copied to clipboard

Encode non-present battery somehow

Open oscgonfer opened this issue 6 months ago • 4 comments

This is a small PR along with https://github.com/meshtastic/firmware/pull/7048 to encode battery levels as -1 when the battery is not detected.

This PR by itself doesn't do much, other than modifying the comment in the proto and changing battery level to int32_t.

oscgonfer avatar Jun 16 '25 07:06 oscgonfer

This is considered a breaking change to all of the clients and nodes expecting uints for this value. Additionally it inflates the size of the DeviceMetrics allocation, which makes the NodeDB on device bigger per node, since we use this on nodes. Can we perhaps explore using a different (postitive) magic number for this? We use 101% for charging for instance.

More broadly, Meshtastic has gotten pretty far without representing a separate state for battery disconnected. Is there a use-case for knowing which nodes have batteries and which do not?

thebentern avatar Jun 16 '25 11:06 thebentern

Oh! Sorry for that!

The use case is again for the environmental sensing one, where we use sensors sometimes on battery, and is convenient to know what the battery status is, and for instance, if connected to a solar panel, to know if it's charging or not.

If I understand this correctly, I think that there would be an overlap between knowing the current battery charge values (0-100) and the fact that a battery is charging (101). Would there be a way to know at the same time, for instance, if the battery is charging and what the charging value is?

I know this makes the business logic more complex but... what about?

  • Value between 0 and 100 -> Battery charge level (not charging, I assume current behaviour)
  • Value eq 101 -> Powered Current behaviour
  • Value between 200 and 300 -> Battery charging (and at Value-200 level) new behaviour
  • 400 -> Battery disconnected (new as well)

This wouldn't break anything right?

oscgonfer avatar Jun 16 '25 13:06 oscgonfer

Oh! Sorry for that!

The use case is again for the environmental sensing one, where we use sensors sometimes on battery, and is convenient to know what the battery status is, and for instance, if connected to a solar panel, to know if it's charging or not.

If I understand this correctly, I think that there would be an overlap between knowing the current battery charge values (0-100) and the fact that a battery is charging (101). Would there be a way to know at the same time, for instance, if the battery is charging and what the charging value is?

I know this makes the business logic more complex but... what about?

  • Value between 0 and 100 -> Battery charge level (not charging, I assume current behaviour)
  • Value eq 101 -> Powered Current behaviour
  • Value between 200 and 300 -> Battery charging (and at Value-200 level) new behaviour
  • 400 -> Battery disconnected (new as well)

This wouldn't break anything right?

That would work, however on 99% of the boards, the battery will either report just 'connected/101%' or the actual battery level, even when charging. Charging Circuits are REALLY dumb in that regard, and we do a lot of guessing with ADC voltage levels already to detemine the state. Notable exception is the T-Beam and other Lilygo devices using the AXP series of charge controller chips AND the new Elecrow M1/M2 devices with their own rather convoluted charging circuitry. If you have a node hardware that can actually reliably validate these different states i am open to the addition :-)

The nPM* series of PMICs from nordic semiconductor could probably pull this off btw.

caveman99 avatar Jun 25 '25 09:06 caveman99

Aha! OK, I'll double check how we do it in our current hardware and revisit this once there is an actual board.

oscgonfer avatar Jun 25 '25 12:06 oscgonfer