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
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.
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.
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.
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…
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.
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.
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
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!!!
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.
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?