What you are seeing (-127°C on ESP32 but not on ESP8266) is a very typical 1-Wire timing sensitivity issue.
The fact that the same hardware works on the ESP8266 but not on the Nano ESP32 strongly suggests that this is not a wiring or sensor problem, but a software/timing-related difference between the platforms. The ESP32 (especially with RTOS, interrupts, etc.) is much more sensitive to timing deviations in bit-banged protocols like 1-Wire.
Switching from OneWire to OneWireNg “fixes” the issue because the implementation is more robust with respect to timing – but it doesn’t really change the underlying nature of the system: communication errors can still occur under real-world conditions.
The important point is that readings like -127°C (and also 85°C) should not be treated as rare anomalies or purely hardware faults. They are normal indicators of temporary communication failures.
In practice, a robust system should therefore not rely on perfect communication, but explicitly handle these cases in software:
- detect invalid readings (-127°C, 85°C, etc.)
- retry reads where appropriate
- validate results before using them
- use a fail-safe output strategy
In my own measurements, I observed nearly 1000 read errors within ~27 days on a single sensor, while still maintaining completely valid output values by applying recovery and validation logic.
So while choosing a better library helps, the real solution is to design the system in a way that tolerates and handles these errors.
I documented this in more detail here (including measurements and practical strategies):