I’ve had this problem for a while and I was just reading to see if there is anything new about the error and then spot this page. Tried the code from @erapade and everything seems to work. Installation on Wemos D1 mini went smoothly and checksum error is gone. I have 10 sensors running, each with 2-5m cable. Thanks to @erapade
Thanks for informing. I was going to give this up but now I got some energy.
I think you shall also try this instead of my mod, and please report back in this thread how it works. Some posts up in this thread you will also have a reference to this:
external_components:
- source: github://nrandell/dallasng
2 Likes
Good work, unfortunately I only have access to ESP32 variants at the moment so can’t test, sorry.
But please test the other alternative “nrandell”. As I understand that has been proven on ESP32 for quite some time now and uses a completely different codebase
Testing the “dallasng” library on my ESP32s2 with two Dallas strings, one has 5 sensors the other 4 sensors is much improved. It still raises an occasional scratchpad error, but probably less by a factor of 20…
1 Like
Proves the most important thing. We need to make sure we communicate correctly with the devices and that there are rooms for imprevements
Why do you have to use the ESP32?
Because for many projects an ESP8266 is too slow or doesn’t have the necessary interfaces, for instance multiple ADC. Plus the cost difference now between the ESP8266/ESP32 is fairly small so unless you’re making 1000 units you may as well buy the ESP32 and be future proofed.
1 Like
Absolutely, before moving over to ESPHome my hardware ran without error for 18 months using a solution built via the Arduino IDE and the standard One Wire / Dallas libs. As soon as I ported to ESPHome the scratchpad errors started, so it’s 100% a software / timing issue.
I should mention that the devs and I could both use the Arduino Dallas sketch without errors. Its only when using the ESPHome code that the problem appears. He was baffled by this, so that’s why we need to get him an actual device he can test with.
1 Like
This is working perfectly with an ESP32S2 for three sensors over a 10m bus. No more errors and ‘Unknown’ values. Thank you!
In my case, because the commercial device I am using is based on an ESP32…
Yeah, it has to be something with ESPHome…the problem is identifying the root cause. ESPHome is pretty advanced compared to running a sketch reading the Dallas sensor. And since it relies on precise timings, there is a lot that could affect this.
Right now I am using the dallasng library mentioned above. It is less than a week, so way to early to say if it is “rock-solid” or not. But I will use that library until I see any other progress being made, since I prefer to run “stock” ESPHome when it comes to libraries.
When something new is ready for testing I can probably help, as long as I know that the new SW will boot on ESP32, since it is a bit tricky to hook it up to a computer to flash it.
I tried that library as well an it was a little better but not good enough to use. Hopefully the esp one of the members is sending me will arrive soon…
Jeff
So far, I only see this issue:
But it is not (yet) causing any issues reading the temperature. It does indicate that something is not entirely ok with the Dallas code though.
Thanx for awesome advice in this thread. I’ve been struggling with 4 dallas sensors together with an azDelivery ESP32 wroom. I was having issues like scratch pad checksum and conversion fail etc.
I tested the dallasng with no luck. Finally I was playing around with different resistors as suggested in different threads (from 4.7k to 1k). When measuring resistance over 3.3v and data I noticed that I had about half of the value over the resistor. Also I had som small connection between 3.3 and ground (my instrument didnt beep when testing soldering joints) but when measuring I could clearly see that there was i small connection.
I cleaned my testboard from flux residue and all the sensors came alive!!
Long story short, If you read this thread and make the assumption that your hardware/software is faulty (like I did). Measure your resistance in the final circuit! It seems like the current sw-code is very picky.
2 Likes
Just a work-note from my side.
I’m doing other things with HA right now so this is not on priority right now. But… As I prepared some Sonoff Basic R2 (that’s where my ESP8266 comes from) to act as PID Climate regulator I added some Dallas sensors (just a single one) to each of them. All worked fine except one. The failing one was discovered with it’s ROM code but then getting CRC failures.
As My family don’t like the house being cold I didn’t do any investigations, I just switched to the “dallasng” code and it then worked fine. I also tried switching to my own code and that also worked fine.
There’s more to do from an investigation side in all of this but as of now we at least have some options we can try. The options are:
external_components:
- source: github://nrandell/dallasng
or
# Please note that this code has no intention to work with ESP32
# even though it might work.
# And there's no guaranties, be prepared to flash with serial cable
# if things goes wrong.
external_components:
- source:
type: git
url: https://github.com/erapade-forks/esphome
ref: Testable_in_ESP8266
components: [dallas]
Just a note though. Even though I created (the last code) myself, I stick with the original one whenever that is working fine and I recommend everyone else having the same approach
1 Like
The 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
Added above line to file and it did not solve the issue. Rolled back to version: 2.0.4 in framework section and that resolves all but a few random checksum errors. My setup has 8 ds18b20’s on it.
If the only change was within the dallas component itself I don’t think this will help since reading the scratchpad was already protected (as good as it can be) from interrupts even before.
With “as good as it can be” I mean that we are not able to protected from interrupts happening in e.g. the wifi communications as I understand.
But… I got some ideas. For intermittent checksum errors, there should be at least one re-try whenever we are reading the scratch pad, this since we know things can happen due to that we can’t trust the interrupt lock to fully protect the communication with the sensor. I mean, that’s what the checksum is there for anyway…
So, this code should include a repeat if the checksum is not correct. Currently it kind of always returns true and does not check for crc errors:
The problem is that it today only returns false when the reset pulse doesn’t go through and that only happens if the bus isn’t high when starting to reset (i.e. should never happen).
While implementing a repeat in the read_scratch_pad method can be done very easily, there’s other code effected that needs to be adopted to this change for the whole code to make sense. Let’s see if I can manage to propose the code change or if the developer does this (preferred)
Having this change will not solve all the problems, but it will protect from wifi interrupt related interferences and other occasional on the edge timing related issues.
And knowing we have this issues with wifi related interrupts, maybe we shall make sure that when we write to the scratch, we also can read back the values correctly as well. Writing to the scratch pad only happens once in the process when we setup the sensors and configures the alarm limits and the resolution, but to be on the safe side…