Multiple DS18B20 dallas.sensor: Scratch pad checksum invalid!

ESPHome
62

That wasn’t actually true. At least on the S2, it appears that the wifi was interrupting in between those two sections and messing up the first timing. That change fixed the checksum errors I was getting while watching the OTA logs. I can’t reproduce any checksum errors now.

63

ok, but I think the wifi issue is so intermittent that its hard to say from just looking at one sensor in one environment.

I could see that I was wrong above saying that the reset pulse only returns false when the bus isn’t initially high, there’s also the presence check taking place after 70 ms. But… the wifi related interrupt could step in at anytime and if it e.g. does this at this point, the code will return false

image
image701×523 26.5 KB

But since we know the communication line by default (due to e.g. the wifi interrupt issue) isn’t 100% stable I feal that using the checksum provided in the protocol for re-transmission would increase the stability of the component. It might not fix all the problems but at least some of them. If you have the possibility, please also try to stress the bus by adding capacitors with various values around 1nF to stress the bus and see if you still have a stable communication. I did sometimes and sometimes not

64

It wasn’t intermittent at all. It was happening very regularly. And since after that fix I can’t reproduce any issues, there’s nothing more I can do unless someone else can provide a reproducible issue or other useful information.

1 Like
65

I was using the dallas_ng driver with the occasional scratchpad error, perhaps 1 per hour. I reverted back to the standard dallas driver and confirmed that I immediately started getting a few errors every minute. Then switched over to the replacement and I haven’t seen a single error in the last 2 hours so for me it seems to be a fix. I’ll keep monitoring and report if I do see any errors.

For info I’m using an ESP32S2 with 2 sensor strings, one with 5, one with 4.

66

FANTASTIC!!! Glad its working.

67

@gedger Can you clarify which solution you are using. The thread is not real clear on the solution.

68

Directly from the ESPHome devs:
devs have come up with a possible fix. Add this to your ESPHome file

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

Thanks for clarifying. Will implement it when I get back from vacation and see how it works.

70

Not had a single warning now in 20 hours so the fix from the developer is solid.

71

If anyone else is still having issues, I’ll need to see at least logic analyzer traces of the data line.

72

Hello
I still have problem with ds18b20. Maybe I’m doing something wrong with code, could you paste .yaml for dallas with modification?
Thanks

73

Same problem here.
Added the external_components: mod to my yaml but it does not fix the problem.

Running with 3x DS18B20 on NodeMCU without problem on same hardware.

Config ESP8266 NodeMCU V2 , 3 sensors on GPIO12 .

Reverted back to Nodemcu with MQTT…

74

Sadly I’m still having this issue. Everything works if I revert back to my previous micropython code. It will be at least a week before I can get a LA on it as it’s running the fridge/freezer in my RV and I’m traveling.

4 ds18b20 sensors on an ESP32 wrover-e pin 23

edit: I am stupid. The format of the sensor ID is different in micropython. Everything works great. Thank you @ssieb for your hard work here.

To any one still having issues, validate your sensor addresses are correct.

1 Like
75

Hello, I can reproduce issue. So i dont know if there is any espHome devs here.
kr

76

Best would be probably to check the github issues and add yout findings (yaml, logs and discription how to reproduce the behauviour)

77

I think looking at wifi interrupts could be a lost cause as my issue is with a ethernet version of ESP32.
I had five DS18B20 sensor that had been working flawlessly for 12 months and i’d taken most updates as they’d come along and currently im on version 2023.12.9.
Only once i’d added a 6th sensor (from unknown origin) to the string did my problems start.
I removed that rogue sensor and it was never the same and 4 of my 5 sensors had scratchpad issues for 90% of the time.
Applying the dallasng driver helped my system

78

This fix seems to not be working anymore
Has somebody an idea what the correct branch is now?
Failed config

external_components: [source /config/esphome/serverfan-steuerung.yaml:20]

Remote branch ds not found in upstream origin.
source: 
  type: git
  url: https://github.com/ssieb/esphome
  ref: ds
components: 
  - dallas
refresh: 1min
79

I am using the ‘dallasng’ custom component and that seems to work well.

Sorry, on my phone or I would post a full link. A search here should find it.

80

I suspect the fix is now rolled into the main stream?

81

I have managed to fix this issue by wiring the dallas sensor to GPIO23. Before I had it wired to either GPIO 0, 2 or 4 and none of them worked. So just try other GPIOs until you find the one that works. If that does not help, you could try to use “index: 0” instead of address…

dallas:

  • pin: GPIO23

sensor:

  • platform: dallas
    index: 0
    name: “Temperature #1”

Also I’m only using 1 dallas sensor, so I’m not sure if it helps with multiple.