XIAO NRF52: Support for DS18B20 Temp Sensor + Improved battery readings

[FFAMax]

Hello, Team.

New: XIAO NRF52: Added support for DS18B20 temperature sensor (1 sensor for now).
New: XIAO NRF52: Added battery status reporting (connected/not connected).
New: XIAO NRF52: Initial support for battery charging status (based on voltage levels to detect if the battery is charging or discharging).
Affect: All platforms: Devices with 101% battery will no longer show as "Line Powered." This will be migrated to a separate metric once the feature is fully implemented. #8711

Tested on XIAO NRF52.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[NomDeTom]

New: XIAO NRF52: Added support for DS18B20 temperature sensor (1 sensor for now).
New: XIAO NRF52: Added battery status reporting (connected/not connected).
New: XIAO NRF52: Initial support for battery charging status (based on voltage levels to detect if the battery is charging or discharging).
Affect: All platforms: Devices with 101% battery will no longer show as "Line Powered." This will be migrated to a separate metric once the feature is fully implemented. #8711

I would suggest splitting this into separate pull requests.

With regard to DS18B20 sensors (which I know relatively well, and use a number outside of the Meshtastic project) I believe 1-wire sensors were removed at one point to save on pins and to reduce flash consumption - the functionality is replicated by I2C sensors and they're a similar order of cost.

Do you have any idea of how this will affect flash consumption?

[garthvh]

Dallas sensors were removed because they can't be auto connected and configured, not really sure what moving away from 101 as the powered value does, would make graphs worse and require rework in both clients

[FFAMax]

I would suggest splitting this into separate pull requests.

Agree. Will do.

With regard to DS18B20 sensors (which I know relatively well, and use a number outside of the Meshtastic project) I believe 1-wire sensors were removed at one point to save on pins and to reduce flash consumption - the functionality is replicated by I2C sensors and they're a similar order of cost.

1. This request came from the community so at least somebody happy by having it again :)
2. On the Internet I found people also asking for it, even building firmware
   https://github.com/jeremyd/meshtastic-firmware/releases/tag/v2.5.16-ds18b20 (https://www.reddit.com/r/meshtastic/comments/1ixhhuv/ds18b20_renegade/)
   jle1n0@1afbe14
   So anyway better to keep it onboarded.

Do you have any idea of how this will affect flash consumption?

Can leave it only on specific platforms like XIAO NRF52 if any concerns. So compiler will skip if not enabled.

Dallas sensors were removed because they can't be auto connected and configured

@garthvh could you please elaborate, what do you mean "they can't be auto connected and configured". Once sensor connected to proper pin and telemetry enabled, it will work. This code particularly can support even many on the same pin, like environment, components, etc.

not really sure what moving away from 101 as the powered value does, would make graphs worse and require rework in both clients

The 101% reading was initially a workaround, but now I've encountered this historically developed issue. The battery is one entity, and the power line is another. It can't be called 'warm' because it's more like 'milk'.
Let's work on #8711 to separate these entities properly so we can report accurate information.
The last time I checked, the device was connected to the power line, and it showed 100% charge. It was difficult to determine whether the battery was fully charged or not, because the graph still showed 100%, even though the device was plugged into the power line."

[garthvh]

Not sure where you got the workaround info, but it is not correct.

[thebentern]

Support for this i2c conversion for the Dallas 1-wire sensors is on my list. As @garthvh said, we only support i2c sensors unless something is baked into the hardware. It gives us the most options without complicating the configuration with pin definitions
https://www.adafruit.com/product/5976

[FFAMax]

I just double-checked the XIAO NRF52840: the SDA/SCL pins are used for NSS and RF_SW.
An I²C conversion might work if there’s a built-in option; otherwise, it would require additional components.
For now, the only zero-cost option I see on the XIAO NRF52840 is to use a spare pin that’s 1-Wire compatible.
If I overlooked any details, please feel free to point them out.

It gives us the most options without complicating the configuration with pin definitions

@thebentern I agree. We need to make sure it doesn’t interfere with the main project while still being useful on specific platforms, and it should be easy to enable without requiring new code. This isn’t only about the code itself - it also involves testing and everything around it.
It’s not easy to onboard a well-tested feature, but very easy to off-board one.
This approach satisfies the needs of a portion of the community who want specific features, and at the same time shows that their effort has value and their contributions aren’t ignored or dumped. That helps keep people motivated to do good work, test properly, maintain compatibility, and avoid ending up with “it works only in my private branch” solutions.

[NomDeTom]

@FFAMax

If I overlooked any details, please feel free to point them out.

The NRF is capable of moving most functions around. If you look at the list of build environments, you'll see there's an i2c variant of the seeeeeeeeeeed NRF52 kit, using the back 2 pins for i2c. It's my preferred arrangement, actually.

I've been discussing this with TheBen on the discord (where the conversation is quicker!). While I'm a fan of the ds18b20 (not sure if I've mentioned it, but I'm a big fan!), given the current limitations and the comparable cost between the ds18b20 and e.g. AHT20 or SHT40 which provide the same function, I can see that incorporating the extra library, even behind a build flag, is adding a future support issue.

As for building special variants, I'm working on a solution to that, as well, because I like to move pins around to suit my own needs, and I don't want to have to mess around any more than I have to.

You're more than welcome to pop over to the discord to discuss what is on the to-do list for the project right now.

[sandos]

One huge advantage of onewire is the amount of sensors you can connect. No address clashes.

[NomDeTom]

One huge advantage of onewire is the amount of sensors you can connect. No address clashes.

I think it's outweighed by the fact that there's not much more than temperature sensors that are suitable for Meshtastic use, and current telemetry protobufs don't support more than one sensor of that type.

I agree in general that they're a good sensor type to support, but here it's a case of "not now".