Multiple DS18B20 dallas.sensor: Scratch pad checksum invalid!

ESPHome
1

Hello,
I have problems with my 1-wire bus when I connect more than 1 ds18B20 sensor to one line.

  • The cable is shielded
  • the cable is 50cm long ( :slight_smile: ) first bus and cable with 1 DA18B20 (like no problems) second bus and second cable with 2 DS18B20, and there i get with every second sensor a Checksum problem
  • i changed the resistors from 4,7K to 3,3K and 2,2K (nothing helps)
  • The Dallas sensors are all original MAXIM(Dallas) DS18B20 sensors
  • i try already with different Ds18B20 sensors (same same)
  • I configured 2 1-wire buses (everywhere the same problem)
  • I use an ESP32-S2-saola-1

I get the following output in the ESP log

[12:51:47][D][dallas.sensor:082]:   Found sensors:
[12:51:47][D][dallas.sensor:084]:     0x3f00000df6546028
[12:51:47][D][dallas.sensor:084]:     0x3100000df746fa28
[12:51:47][C][dallas.sensor:089]:   Device 'bigbox/ds18b20/uc_box_stepdown_temp'
[12:51:47][C][dallas.sensor:089]:     Device Class: 'temperature'
[12:51:47][C][dallas.sensor:089]:     State Class: 'measurement'
[12:51:47][C][dallas.sensor:089]:     Unit of Measurement: 'Ā°C'
[12:51:47][C][dallas.sensor:089]:     Accuracy Decimals: 1
[12:51:47][C][dallas.sensor:097]:     Address: 0x3100000df746fa28
[12:51:47][C][dallas.sensor:098]:     Resolution: 12
[12:51:47][C][dallas.sensor:089]:   Device 'bigbox/ds18b20/uc_box_temp'
[12:51:47][C][dallas.sensor:089]:     Device Class: 'temperature'
[12:51:47][C][dallas.sensor:089]:     State Class: 'measurement'
[12:51:47][C][dallas.sensor:089]:     Unit of Measurement: 'Ā°C'
[12:51:47][C][dallas.sensor:089]:     Accuracy Decimals: 1
[12:51:47][C][dallas.sensor:097]:     Address: 0x3f00000df6546028
[12:51:47][C][dallas.sensor:098]:     Resolution: 12
[12:51:47][C][dallas.sensor:075]: DallasComponent:
[12:51:47][C][dallas.sensor:076]:   Pin: GPIO4
[12:51:47][C][dallas.sensor:077]:   Update Interval: 30.0s
[12:51:47][D][dallas.sensor:082]:   Found sensors:
[12:51:47][D][dallas.sensor:084]:     0x1b00000df723ec28
[12:51:47][C][dallas.sensor:089]:   Device 'bigbox/ds18b20/panel_1_temp'
[12:51:47][C][dallas.sensor:089]:     Device Class: 'temperature'
[12:51:47][C][dallas.sensor:089]:     State Class: 'measurement'
[12:51:47][C][dallas.sensor:089]:     Unit of Measurement: 'Ā°C'
[12:51:47][C][dallas.sensor:089]:     Accuracy Decimals: 1
[12:51:47][C][dallas.sensor:097]:     Address: 0x1b00000df723ec28
[12:51:47][C][dallas.sensor:098]:     Resolution: 12
[12:51:48][C][cd74hc4067:025]: CD74HC4067 Multiplexer:
[12:51:48][C][cd74hc4067:026]:   S0 Pin: GPIO6
[12:51:48][C][cd74hc4067:027]:   S1 Pin: GPIO7
[12:51:48][C][cd74hc4067:028]:   S2 Pin: GPIO8
[12:51:48][C][cd74hc4067:029]:   S3 Pin: GPIO9
[12:51:48][C][cd74hc4067:030]: switch delay: 2
[12:51:48][D][dallas.sensor:143]: 'bigbox/ds18b20/uc_box_stepdown_temp': Got Temperature=26.1Ā°C
[12:51:48][D][sensor:094]: 'bigbox/ds18b20/uc_box_stepdown_temp': Sending state 25.06250 Ā°C with 1 decimals of accuracy
**[12:51:48][W][dallas.sensor:261]: 'bigbox/ds18b20/uc_box_temp' - Scratch pad checksum invalid!**
**[12:51:48][D][sensor:094]: 'bigbox/ds18b20/uc_box_temp': Sending state nan Ā°C with 1 decimals of** accuracy

i found this website

and changed my code in dallas_component.cpp file. But that didnā€™t help either.
But Iā€™m not sure if the compiler read this file again.

i changed the code-section
/config/esphome/.esphome/build/bigbox-lightcontroller/src/esphome/components/dallas/dallas_component.cpp

But not works for me.
does anyone have any ideas?

Best regards
Achim

2

the Dallas sensor has been broken since Nov, current feeling is that it will not be fixed.

3

Iā€™ve not had problems with any esp8266 Esphome device running with an DS18b20, besides small breakage between 2023.5.0 and 2023.5.2

[02:36:26][C][dallas.sensor:075]: DallasComponent:
[02:36:26][C][dallas.sensor:076]:   Pin: GPIO12
[02:36:26][C][dallas.sensor:077]:   Update Interval: 10.0s
[02:36:26][D][dallas.sensor:082]:   Found sensors:
[02:36:26][D][dallas.sensor:084]:     0x5e02131a7d65aa28
[02:36:26][D][dallas.sensor:084]:     0x4902131a6393aa28
[02:36:26][D][dallas.sensor:084]:     0xb30069e200001928
[02:36:26][D][dallas.sensor:084]:     0xdd01142fdf00c728
[02:36:26][D][dallas.sensor:084]:     0xe00316554741ff28
[02:36:26][D][dallas.sensor:084]:     0x7b04165130d5ff28

My yaml section if it helps.

dallas:
  - pin: D6
    update_interval: 10s    
sensor:
  - platform: dallas
    address: 0xB30069E200001928
    name: "Stepper box temp"
  - platform: dallas
    address: 0xDD01142FDF00C728
    name: "Temperature East outside"   
  - platform: dallas
    address: 0xE00316554741FF28
    name: "Boiler in temperature near"    
  - platform: dallas
    address: 0x7B04165130D5FF28
    name: "Boiler out temperature near"
  - platform: dallas
    address: 0x5E02131A7D65AA28
    name: "Boiler out temperature far"
  - platform: dallas
    address: 0x4902131A6393AA28
    name: "Boiler in temperature far"
4

Reading the link has made me nervous to switch to ESP32. I have seven Dallas running from ESP8266. So far have not missed a beat

Ps. I have itchy fingers and always run latest updates

5

but some peoples have to use the ESP32 like me.
And i read a lot of bugā€™s with the dallas-lib in esphome if anyone use the ESP32.
I not understood why the programmers have so much problems to fix this bug.
thousends of peoples use in her home or on any place the DS18B20 on a ESP32, iā€™m sure nobody would like change it to any other board like ESP8266 or mnaybe to any Arduinoā€¦ oooh i forgetā€¦ why not change to a raspberry

6

I also like to have the latest updates.
I find it best to have a few ā€œsacrificialā€ devices that have a bunch of sensors but not really doing anything to upgrade first. If they update fine then roll out the updates to working devices.

Saves me lots of headaches.

1 Like
7

I am now also getting intermittent scratch pad errors, was working fine for 2 years, canā€™t pinpoint exact release where it started, but within the last 1 month.

8

Itā€™s clearly not a great position to be in for the project as a whole, but you can always run older ESPHome firmware on the device if it does what you want. Itā€™s not like internet-connected hardware that has to be kept up to date for security reasons.

No issues with five DS18B20s on a single wire here, but thatā€™s on an ESP8266 that seems to not be affected.

9

Is there any solution to this, or a workaround or something?

10

My problem was solved by replacing the power supply for ESP 32. When working from the electrical network through the UPS and step-down DC-DC converter was constantly this error. After connecting the power from the charging for the phone, the problem completely disappeared.

11

not yet ā€¦ i hope there will be a bugfix soon

1 Like
12

Any further news on this. I have been gradually porting projects that have been running for years based on the Arduino IDE so I know the HW is good. As soon as I build using ESPHome then scratchpad errors stop the Dallas sensors workingā€¦

13

I have the same issue with ESP8266. Iā€™m using original (10x) and a (1x) clone ds18b2 sensors. All sensors report the same invalid scratchpad checksum!.

Commenting the InterruptLock Lock; lines in the read_scratch_pad() function didnā€™t help.

14

A possible workaround that works for me is to set each sensor on the string to a different resolution. As soon as I have two or more sensors with the same resolution those ones will report scratch pad errors.

1 Like
15

I struggled to get some Wemos D1 mini clones working, turned out the onboard voltage regulator was poor quality. I powered the DS18B20 from a second regulator, added some 1uF Caps on in/out and started workingā€¦The genuine WEMOS D1 devices do not have the same issue. However, all can generate scratchpad errors.

1 Like
16

Iā€™ll test that theory, maybe it is a hardware issue. I have some 8266 ESP12 modules lying around and some spare ESP32 modules. Iā€™ll test them with a clean power source.

Update: No change, still the same errors.

17

About a year ago, I spent literally weeks with the devs trying to solve this exact problem on some of my ESP32s. The problem goes away on certain devices (some c2/c3 variants) and manifests on others. To add to the complexity, it is sometimes intermittent.

@Ssieb and other devs toiled for days sending me new revs of the Dallas driver. I captured dozens of logic probe traces. Nothing we tried worked. So, basically I settled on the one ESP32 that works if I need Dallas sensors, the Wemos D1 ESP32 mini. Or the wemos D1 mini (esp8266). There are alternate Dallas libraries that can also be tried, but using those also had no effect.

This is a thorny problem for sure!

I just posted a question to the devs on Discord to see if any progress has been made

image
image1532Ɨ146 37.3 KB

Iā€™ll post here if thereā€™s more info.

And his reply

image
image1473Ɨ203 34.9 KB

1 Like
18

It is a bizarre problem, I have a LOLIN S2 mini with 5 Dallas sensors running my own code coded via Arduino IDE and the accompanying Dallas / 1-wire Library which works perfectly with zero issues, as soon as I load an ESPHome solution on the same device it has all sorts of scratchpad issues and devices not discovered reliablyā€¦

Can I suggest that some notes are added to the ESPHome documentation stating that the Dallas sensors shouldnā€™t be used for new designs as people are still assuming this is a working solution and then spending days trying to debug and yet there isnā€™t a single note anywhere in the ESPHome documentation, which in my mind is the biggest failing of the ESPHome, tell your users!!!

19

The Dev had me run a simple Arduino sketch and it also worked perfectly, and that was in all the chips that had problems. So itā€™s definitely in the ESPHome libraries.

Iā€™m just an end userā€¦ itā€™s not my call on what the docs say.

Someone will probably need to send the developer a failing chip with a sensor. Then they can reproduce it and fix it. Short of that I donā€™t see this problem going away onits own. Remote diagnosing this kind of nasty problem is next to impossibleā€¦

Any volunteers willing to step up and send a Dev a chip and a sensor? Iā€™m sure heā€™d send it back once he figures the problem out. Iā€™m asking where he lives. I only use D1 Mini ESP32s any longer. I moved away from all the other variants. Too many strange issues to chase.

Jeff

20

Iā€™ll sweeten the deal here in the quest to further our hobby and get this problem fixed once and for all. If someone volunteers a chip and a couple sensors that fail with ā€œchecksum errorā€ and it does it consistently, I will pay for the postage to send the chip and sensors both to the Dev and back again to you once he fixes the problem. He lives in Canada.

Message me here or email me Jeff at modeltstarters.com. Iā€™ll send you a postage paid label to the Dev and send you a copy of the label heā€™ll use to send it back to you. Iā€™ve got untold hours already invested here, whatā€™s a little more in postage?

1 Like