I'm running a wire of 12 ds18b20 sensors on a esp32. The wire (utp5 cable) is 1m to the first sensor, and then 15cm between every sesnor. Power via 3.3v pin of the esp32 (wroom32 dev board) a resister of 4.7k between positive and the data wire (connected to pin 32). I'm not using parasite mode.

If I run the software (esphome) while powering it via the usb port, it all works as intended, all the 12 sensors nicely report their temperature, no errors.

In "deployment" the ESP in operation is powered by a relays board (that takes 12v input from a beefy power source) and translates it to 5v (LM2596 rated for 2A). This 5v is directly connected to the 5v (and gnd) pins of the dev board, it powers up, and does all it's work as intended by controlling the relay board. And so does reading out the sensors. Except for the first in the chain and the last in the chain, these report: Scratch pad checksum invalid!, consistently, without every managing to read the correct values.

I only have a simple multi-meter, so I've checked the voltages I could think of:

measurement via usb via relay board
5v on esp 4.80v 5.03v
3.3v on esp 3.35v 3.35v
3.3v on last sensor 3.35v 3.35v

I'm truly confused, the voltage that the sensor get is the same, I see no drops, it looks clean, only noticeable differences is the 5v pin, that is a bit lower for the USB powered version, but I would expect the converter on the esp not to have a problem with that.

So, what could be happening here? What should I measure? To be clear, I've detached all the other output pins of the esp, to avoid the relay board operations influencing the tests.


1 Answer 1


I've had the same problems with ESP32.

First, read this answer and use the voltage translator circuit to run the sensors on 5V. That will give you much better noise immunity.

Second, the onewire library on ESP32 does not work. This is due to delayMicroseconds() adding 1-2 µs to the requested delay, which messes with the onewire bus timings. Symptoms are similar to what you're experiencing, ie some sensors consistently return errors while others work.

Solution: install a onewire library with accurate timing. OneWireNg would also work, probably. The default onewire library does not.

  • \$\begingroup\$ Ouch, I'll try switching it to 5v. The onewire library sounds interesting, although interestingly, the same firmware did work when switching the power source. \$\endgroup\$ Apr 25, 2022 at 7:54
  • 1
    \$\begingroup\$ Yes, the timing on the default library is marginal, so it works under some conditions... until it doesn't. It looks a bit "haunted", creating those weird bugs, but the root cause is the bad timing. \$\endgroup\$
    – bobflux
    Apr 25, 2022 at 9:42
  • \$\begingroup\$ FYI: latest version of ESPHome has fixed this timing issue: github.com/esphome/esphome/pull/3181 but I was already on that, so I'll try the switch to 5v logic. \$\endgroup\$ Apr 25, 2022 at 12:18
  • \$\begingroup\$ Oh, so they're not using the default lib that doesn't work either XD good for them. BTW, are you using a counterfeit "LM2596" module from the usual suspects? If so, I suggest you check the actual output voltage with a scope, you may be in for a surprise... \$\endgroup\$
    – bobflux
    Apr 25, 2022 at 12:40
  • \$\begingroup\$ I'm using a pre-assembled relay board, something like this: amazon.com/SainSmart-101-70-103-16-Channel-Relay-Module/dp/… . I sadly lack a scope (it's on my wishlist). I've been reading some more on esphome's github repo, and fallout from these timings fixes might be that the 4.7k resistor is too high, and should be reduced to 3.3k. Gonna try that as well later today. see for example: github.com/esphome/issues/issues/3165 \$\endgroup\$ Apr 25, 2022 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.