Encode non-present battery somehow

[oscgonfer]

This is a small PR along with meshtastic/firmware#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.

[thebentern]

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?

[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?

[caveman99]

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.

[oscgonfer]

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