Adding support to One-wire sensors via I2C bridges

[oscgonfer]

As discussed in #9995, one-wire sensors such as DS18B20 family will be done via I2C bridges (DS2482 series)

Support for the driver in question is available for two versions, and can be easily added in the firmware.

There are some details to iron out however, considering how this opens the door to supporting several sensors on the same bus measuring the same metric (which is currently not supported in the current protobuf structure). I suggest we divide this in two stages.

Short-term

Provide access to the driver for a single one-wire sensor, using the library above. This would solve the need for many users already, and we can start testing. This would require simply adding the DS18B20 series to the supported telemetry protos and add support for at least the 1-channel version.

Long-term (3.0)

On a separate PR, to avoid lagging the first implementation, I'd suggest we consider how this can be considered as part of other more bigger changes on the telemetry.proto. In particular, a nested approach for the protos could be considered for these sensors like the one in meshtastic/protobufs#852.

We need to be particularly careful to always report the readings on the same location. For instance, if we have 8-channels for temperature, on every device reset, we need to make sure that ch1 makes it to ch1 and not to another channel. For this, we could envision a repeated reading including the address in the payload:

message EnvironmentMetrics {
 ...
  /*
   * DS18B20 Data
   */
  optional DS18B20Data ds128b20data = 1;
}

message DS18B20Payload
{
    required uint32 ds28b20address     = 1;
    required uint32 ds28b20reading     = 2;
}

message DS18B20Data
{
    repeated DS18B20Payload dS28b20payload  = 1;
}

Then in the DS24800 class we can add ways to handle this.

@Elwimen and others, feel free to contribute.

[FFAMax]

While supporting I2C bridges like the DS2482 is a solid professional approach for multi-node buses, we shouldn't overlook the importance of native OneWire support directly via GPIO.
Forcing the use of hardware bridges significantly complicates the BOM and raises the barrier to entry for hobbyists. The beauty of the DS18B20 lies in its absolute simplicity: one wire, one resistor, and it just works. By requiring extra hardware, we risk alienating users who want to build quick, low-cost nodes using parts they already have in their "junk bins."
Let's keep the door open for simple, native GPIO integration (perhaps as a compile-time option to save flash). We should empower users to reuse the millions of existing sensors already scattered across the globe rather than forcing them to buy new silicon bridges.
P.S. In a world drowning in e-waste, let’s not "software-lock" the utility of perfectly fine hardware. There’s something poetic about being able to dig a 10-year-old DS18B20 out of the "ashes of civilization" (or just an old project box) and having it work instantly with modern firmware. Let’s prioritize sustainability and backward compatibility over architectural perfection.

[Elwimen]

I agree with both approaches. Personally I'm inclined towards not having extra hardware needed for such a simple device. #9995 does that, though I wanted to be smart and imagined use cases with 100–200 sensors on the bus (I do actually have the use case for this). The C++ STL (std::vector, std::sort, ) is what caused the 12kB+ flash hit, the protocol logic itself is lean. The fix is a fixed array sized to the protobuf cap plus a simple insertion sort, which brings it back to near-zero overhead.

On bridge IC selection: DS2484 and DS2482-100 share a compatible register set, they only diverge on the PCTLZ external MOSFET control bit. One driver with two macros covers both. DS2482-800 (8 channels) is a natural superset to add later. That answers the "why this one and not the other" question: you don't have to pick.

@FFAMax, and not only that, with native GPIO you can run multiple independent 1-Wire buses on whichever GPIOs you like, which is more flexible than any bridge IC. That said, the bridge does handle one thing better: the PCTLZ active pull-up control manages parasite power timing in hardware, which is genuinely cleaner than doing it in software.

My suggestion: keep native 1-Wire as a #ifdef-gated compile option for resource-constrained users and existing deployments, add the bridge driver as the recommended path for new builds. Both can output identical protobuf fields, consumers see the same data regardless of transport.

[oscgonfer]

#10078

[oscgonfer]

meshtastic/protobufs#886