One_wire and dallas sensor: Scratch pad checksum invalid!

ESPHome
1

I have been trying to get another set of Dallas temp sensors to work consistently on a new installation with a WeMOS D1 Mini. I have another D1 Mini with two Dallas sensors connected to one pin that has been working fine for months no errors. This install has been plagued.

I’ve read a lot of issues others have had and made changes trying to track this down, but am starting to wonder if these things are just too finicky?

Today I made some changes, switched to 5V and used Cat-5 twisted pairs wired up like this:
Blue wire: Data
Blue-White: Ground
Orange wire: 5V
Orange white: Ground

I read that it was preferable to keep the pairs twisted and run ground on the other wire like this. Before this change I was just using Blue: Data, Orange: 5v, Brown: Ground.

When I first made these changes the three sensors all reported fine and there were no errors for about 30 minutes, and then the dreaded Scratch pad checksum invalid! errors started occurring on the 2 sensors at the end of the line.
As I’m writing this the first and last just reported correctly, but the middle one failed. Then on the next update interval both of the last 2 sensors failed.

Some Info:

  • HomeAssistant 2024.11.3
  • ESPHome 2024.12.4
  • one_wire on D2 GPIO 4 (have not tried another pin)
  • 2.2k pullup resistor (after trying 4.7k)
  • powering the dallas sensors with 5v (after trying 3.3V)
  • Total cable length from WeMOS to last sensor: 3 meters

Each of the sensors is soldered to a proto board and connected to screw down terminals for the Cat-5 wire coming in and out. So 6 screw down connections: Ground, Signal, 5V coming in and the same going out to get to the next sensor.
(My other WEMOS D1 with two sensors I just soldered the sensors directly to the Cat-5 cable, but that cable is only 2 meters long going from ceiling to floor. This new installation is under my porch and cabin and I had issues with the wire breaking while trying to run it). Tested voltage at the last sensor and 5V shows up.

Here’s my current config. I did try and set different update_intervals for each sensor to see if that made a difference if they were not all trying to update at the same time. Did not seem to make a difference.

# Dallas 1-wire setup
one_wire:
  - platform: gpio
    pin: D2

sensor:
  - platform: dallas_temp
    name: "Porch Low Temp"
    address: 0x340624a2055a7728
    filters:
      - filter_out: nan

  - platform: dallas_temp
    name: "Under Cabin Temp"
    address: 0x8c0624a1fc3d4928
    filters:
      - filter_out: nan

  - platform: dallas_temp
    name: "Water Heater Temp"
    address: 0x520624a1c71e7a28
    filters:
     - filter_out: nan

Here are the errors

[16:52:44][D][dallas.temp.sensor:054]: 'Porch Low Temp': Got Temperature=5.2°C
[16:52:44][D][sensor:093]: 'Porch Low Temp': Sending state 5.18750 °C with 1 decimals of accuracy
[16:52:49][W][component:170]: Component dallas_temp.sensor cleared Warning flag
[16:52:50][W][dallas.temp.sensor:139]: 'Under Cabin Temp' - Scratch pad checksum invalid!
[16:52:50][W][component:157]: Component dallas_temp.sensor set Warning flag: scratch pad checksum invalid
[16:52:51][W][dallas.temp.sensor:139]: 'Water Heater Temp' - Scratch pad checksum invalid!
[16:52:51][W][component:157]: Component dallas_temp.sensor set Warning flag: scratch pad checksum invalid

I have not tried adding 150 Ohm or 100Ohm resistors in series on the Signal line. I suppose that is my next test. But after 2 days of crawling around under the house and bringing things back to the bench, I’m starting to wonder if the one_wire protocol is too finicky for use with Home Assistant / ESPHome???

Seems like most other Topics I read about this issue were solved by one of the things I have tried, or by that update back last summer to get around the one_wire bug.
Hoping someone else has some good advice.

thanks,

-kai

2

Odds are you have fake ones, since many (especially the affordable ones) are fake. Many of the fakes work reasonably well. Some are flakey.

Some people only put a single sensor per pin and turn off the checksum.

I have had remarkably good luck with them, even the fakes and have real ones that have been working well for over a decade. The real ones are great. The fake ones vary in quality.

3

Hi Neel,

Thanks for the link–that is a deep rabbit hole of research on these ‘clones’. I recently bought a batch from Digikey that were about $3 each–but I’ll go and check to see if the three that I’m using in this project are from that order or from something earlier. Since I’m only trying to connect up 3 or 4 to this WeMOS, maybe one per pin is the way to go for now.

appreciate the info.

-kai

4

All of my DS18b20s are fakes. More than a dozen. The genuine device costs 5X more, but for home use the error is acceptable.

The series resistor is to prevent “ringing”. Think of it as an echo out of control. I’ve only seen it once and haven’t been able to replicate it since. Any value from 100 Ω to 10K Ω will work because the current in the data line is in nanoamps.

The data killer is in cable capacitance. Added capacitance degrades the signal. You can use CAT3,5, or 6 cables if you wire it to avoid twisted pairs. Do not connect the x/white wires to anything. Just use the solid colored wires.

Long cable runs also add to the cable capacitance. There is no specification for cable length, but there is a specification for the rise time. How fast can a data bus be pulled up to a logic high. More capacitance means longer rise time. A stronger pullup resistor (lower resistance) can help. But too strong and the master device can’t pull the data line low to start the data exchange. You really can’t tune really long cable runs without an oscilloscope.

That’s because this is how the one-wire protocol works. The controller starts communication by pulling the data line low, then every connected device returns with its serial number and type code.

You weren’t very specific about how long the cable is.

5

first post says 3 meters, which is not long in my experience.

There are app notes from Dallas/Maxim/whatever their name is now that explain the details, but you need a solid understanding of electronics for them to make sense.

I have found most of my sensors (mostly fake, probably) to generally work fine. I have also seen really weird things and many implementations of the protocol work most (but not 100% or even 99.9%) of the time.

The checksum is a standard way of validation of communication. Some implementations (of communication) assume there will be no error (at least none of importance) and do without it or ignore it. This works fine … until it doesn’t.

Since you are seeing checksum errors, what we have here is a failure to communicate.

6

No, 3M is not long, but I read the post that this was only one sensor. How long are the others?

An additional thought, if one sensor is slow to respond, it can delay other sensors on the same bus from responding, resulting in checksum errors. Running each device on its own bus and GPIO might isolate that.

7

Steve,

That’s interesting that you recommend not using the twisted pairs. The reason I switched to using them is after reading this document from Dallas / Maxim called “MicroLAN in the Long Run” about running 1-wire networks. Here’s a section that got me to try this alternative wiring:

Differential inductance decreases as the distance between
conductors is reduced, so use of adjacent pairs or, preferably, twisted pairs is recommended. Twisted pairs reduce unwanted coupling from nearby interference sources because the currents induced in the
wires flow in opposite directions in the two conductors and tend to cancel. Category 5 twisted pair phone line is recommended for all but the most demanding performance requirements.

Then I read someone else’s config where they put the GND on the white wires of the pairs. Before doing this I was not using the twisted pairs and the results were similar: Brown, Orange, and Blue.

I also just looked at my sensors that I bought from Digikey and they are not Maxim, but UWM brand. UMW DS18B20 Datasheet

Have you used the serial resistor on the data line in your configuration?
Did you put them only at the beginning and end of the line, or at each sensor?

My wire is broken into 3 sections:
600mm : WeMos to 1st sensor
1900mm: 1st sensor to 2nd sensor
600mm: 2nd sensor to 3rd ( last sensor)

For the last 24hrs the 1st and 3rd have been doing okay, but the 2nd sensor is constantly giving the checksum errors.

thanks for the help.

8

-shielded cable
-capacitors
-praying

Also be aware, that you should pull up to 3.3V if you care about your Esp.

9

Ha! I might be about to go to step 3 (praying).

Oh, pull-up to 5v is bad for ESP? On all pins? I started with 3.3V and switched to 5v to see if it would make a difference.

thanks!

10

Yes.
You can power the sensor at 5V, but you shouldn’t pull the data line above Esp32/8266 operating voltage.

1 Like
11

Thanks for the warning!

12

I missed that- anything over 3.3V on a GPIO pin can damage the chip. (Speaking from first-hand experience).

To twist or not to twist, that is the question.
Also from the Maxim specs:

The maximum capacitance of the data cable to ground is typically around 800 pF. This capacitance is crucial for the proper functioning of the 1-Wire communication protocol, as it ensures reliable data transmission over the single-wire bus.

As I said, added capacitance slows the rise-time that the protocol depends on. The typical capacitance of a twisted pair in a Cat 6 cable is around 14 pF/ft. Since the twisted pairs of CAT6 cable are themselves twisted, but fewer twists per foot overall. So only using the solid-colored wires, you minimize the twist rate. (Yes we’re talking about picofarads, but every pico counts.) Shielded cable does slightly increase the capacitance of the wires.

Use doorbell wire. The capacitance is typically quite low in the range of a few picofarads per foot.

1 Like
13

Thanks for the advice everyone.

I just powered it down to not damage the ESP. I’m going to re-think my design. Really only need two temp readings. Outdoor ambient and under my cabin, so I could run two sensors on two different lines for that.

Pause and begin again.

14

There is no downside to using one line per sensor.

1 Like