Multiple DS18B20 dallas.sensor: Scratch pad checksum invalid!

ESPHome
102

Yes, and still working well. Even after the One Wire dallas upgrade.

#Old way, wrong now
#dallas:
#  - pin: D6
#    update_interval: 10s


one_wire:
  - platform: gpio
    pin: D6	

sensor:
  - platform: dallas_temp
    address: 0xB30069E200001928
    name: "Stepper box temp"
    update_interval: 10s

  - platform: dallas_temp
    address: 0xDD01142FDF00C728
    name: "Temperature East outside"
    update_interval: 10s

    
  - platform: dallas_temp
    address: 0xE00316554741FF28
    name: "Boiler in temperature near"
    update_interval: 10s

    
  - platform: dallas_temp
    address: 0x7B04165130D5FF28
    name: "Boiler out temperature near"
    update_interval: 10s

    
  - platform: dallas_temp
    address: 0x5E02131A7D65AA28
    name: "Boiler out temperature far"
    update_interval: 10s

    
  - platform: dallas_temp
    address: 0x4902131A6393AA28
    name: "Boiler in temperature far"
    update_interval: 10s

Logs:

[10:32:19][I][app:100]: ESPHome version 2024.6.6 compiled on Jul  4 2024, 16:53:04
....
[10:32:19][C][logger:189]:   Hardware UART: UART0
[10:32:19][C][gpio.one_wire:020]: GPIO 1-wire bus:
[10:32:19][C][gpio.one_wire:021]:   Pin: GPIO12
[10:32:19][C][gpio.one_wire:080]:   Found devices:
[10:32:19][C][gpio.one_wire:082]:     0x5e02131a7d65aa28 (DS18B20)
[10:32:19][C][gpio.one_wire:082]:     0x4902131a6393aa28 (DS18B20)
[10:32:19][C][gpio.one_wire:082]:     0xb30069e200001928 (DS18B20)
[10:32:19][C][gpio.one_wire:082]:     0xdd01142fdf00c728 (DS18B20)
[10:32:19][C][gpio.one_wire:082]:     0xe00316554741ff28 (DS18B20)
[10:32:19][C][gpio.one_wire:082]:     0x7b04165130d5ff28 (DS18B20)
[10:32:19][D][dallas.temp.sensor:054]: 'Temperature East outside': Got Temperature=28.0°C
[10:32:19][D][sensor:093]: 'Temperature East outside': Sending state 28.00000 °C with 1 decimals of accuracy

Hope it’s of help.

103

Curious which sensors you’re using


104

5 x Waterproof encased DS18b20 sensors. And one regular in the component box.

That gizmo was assembled 2-3 years ago, so I can not remember where I bought them.

105

Hello
I have same problems of this posts with an Esp32


please look at here :

106

Frustratingly after updating to the latest version of ESPHome I am now once again seeing these errors. Foolishly I didn’t make a note of the version it was working against but I was using

source: 
  type: git
  url: https://github.com/ssieb/esphome
  ref: ds
components: 
  - dallas
refresh: 1min

Which no longer exists so didn’t have any option. Arg, sometimes I hate ESPHome and the Dallas sensors.

107

I had the same issue starting on March 3rd.
After trying to find an issued with the hardware, I tried downgrading to the last version before the failure, which was 2025.2.1
An it worked. It’s now running ad before.

108

For info the Devs have now fixed the issues in the development version but I’m not sure what release this fix will be in


109

I’ve got 6 cheap DS18B20 sensors, with an esp32. After reading posts suggesting that one_wire may not work well with some esp32 models, I ended up creating 6 one_wire busses. It all worked well, apart from the relatively frequent scratchpad checksum errors. Once I fitted a 2kΩ pullip resistor (I didn’t have 4.7kΩ) between each data pin and 3.3V - almost all of the errors resolved. I had assumed the internal pull-up would be adequate but it wasn’t.

sensor:
  - platform: dallas_temp
    one_wire_id: x5
    name: ***whatever, I'm using 6 of these***
    update_interval: 10s
    filters:
      - filter_out: NaN      
       

one_wire:
  - platform: gpio
    pin: GPIO32
    id: ***whatever x6**
111

@James.a.simpson are you doing them each on their own GPIO Pin?

112

As I understand, the internal pullup is not document but are said to be around 30 to 50 kohm. There are claims that it shall work with the internal but I would recommend to always us an external pullup

113

yup. Each on it’s own pin

1 Like
114

Still the same error here, running esp32 with two ds18b20

1 Like
115

I also encountered this error whilst testing a new setup, but I think I know why my specific setup produces this scratchpad error with intermittent valid readings - and possibly this is echoed in some others experiences, especially if they’ve wired their 1-wire devices as 2-cores instead of 3. (IYSWIM)

For me - low voltage on the dallas bus. (I see at least one person says it resolved when they changed their esp’s power supply)

Physical wiring on 1-wire devices is kind of futzy. There’s the right way, and the wrong way - but the wrong way often works.

Right way
Red to +3.3 to 5v
Black to GND
Yellow to signl pin. (GPIO)

On my set up this always works, even with a string of seven DS18B20

However, when I first started using 1-wires in my house, I used a USB serial adapter to a PC and wired it up in parasitic mode, like so:

Wrong way:
Red and black to GND
Yellow to signal pin (GPIO)

(On the unwired DS18B20 sensors, this means bridging the two outer wires into one for black+red, with center pin as yellow)

This way sometimes works on ESPs, especially on shorter physical lengths of wiring - but the voltage is much less and it’s less reliable IME. (But sometimes reliable enough, and on my pc, it worked great)

Changing interval and number of devices on the bus also affects this - as each sample and each device takes a tiny bit of the teensy amount of power.

My unverified findings is that reducing the sampling frequency can often make this work because it allows the voltage to seep upwards just enough.

So in my setup, I’m connecting to existing sensors in a 2-core bus, which was working fine fed by a PC, and getting the scratchpad errors, which I interpret as “garbled signal received, possibly due to lack of power or poor physical connections”

But if I change that to a bus that’s wired 3-core, everything works perfectly without any other changes (aside from IDs)

Plenty of guides exist on the internet for wiring these things in both ways (plus a third that introduces an external 5v power supply) and each way sometimes works just enough to pass first inspection. Upshot is that I’m going to have to replace my sensors with 3-core.

I don’t think this is the problem for all of you, the symptoms don’t fit as it wouldn’t be affected by changing the firmware; but it could be for some. Or even if connected properly, beefing up the ESP’s power supply might help (in the same way that raspberry pi’s are a bit flaky if fed by a low output usb)

116

I’m still getting errors, and have been consistently with every version since 2024.12.0 (IIRC), but while debugging found that one sensor was particularly problematic.

I’m using three sensors with 3 meter wires, wired to power from the ESP32 (3.3V), and a 4.7㏀ pull-up.
Originally I was getting checksum errors 15% of the time consistently across all sensorsÂč. Even when I set two sensors to update_interval: never, I was still seeing errors on the active sensor.

Error rate for three temperature sensors: 14.6%, 14.3%, 14.7%
Error rate for three temperature sensors: 14.6%, 14.3%, 14.7%693×257 22.5 KB

Mostly by chance, I disconnected the problematic sensor to test if errors still occurred with only two sensors. Except for one checksum error after boot, just the two connected sensors didn’t have any more errors during my test. After swapping out the third sensor, I did start receiving errors again but at a much lower rate.

Error rate for three temperature sensors: 3.9%, 3.0%, 4.4%
Error rate for three temperature sensors: 3.9%, 3.0%, 4.4%702×260 26.1 KB

In either case, I only want a value every minute, so filtering out the errors and averaging multiple readings gives a reliable value. The occurrence of errors isn’t completely random, but in my case it looks like consecutive errors on the same sensor are uncommon and the probability of 3+ readings all being errors is very low.

    filters:
      - filter_out: nan
      - throttle_average: 60s

Another thing I had tried testing was setting the sensors each to slightly different update intervals (e.g. 17,18, & 19 seconds) so that it was less likely that readings were always being requested at the same time or conflicting with other sensors and routines that were on a 15s update interval, but this didn’t seem to have an effect on the error rate.
I’m still curious if being able to spread sensor readings evenly within an update interval period, or forcing a delay between successive readings, could have a benefit though. From what I understand from reading the sensor spec probably not when directly powered, but maybe when parasitically powered and the sensors need time to charge capacitors while the signal pin is pulled high.

Âč Curiously, I was getting a 12.5% error rate when tracking all sensors in the same two global variables (with one template sensor), but 14.5% when I tracked each sensor separately (6 global variables and 5 template sensors). I think this hints at there still being some timing / CPU use issues.

117

In the end, my problems were also caused by the power supply.

I was using a cheap 12V supply to a breakout board with an LDO (to 5V on Vin). The VCC to onewire was reading a steady 3.3V, but the 12V supply was fluctuating ±0.5V.
I changed to a better supply that gave a steady 12V as well as changing to the switching regulator that will go in my final circuit to handle 12V → 5V, and got the side benefit of lowering power consumption by 1.5W. Other than the occasional error just after boot, all sensors have been error-free (including an added fourth).

1 Like