To be upfront. I am not a programmer and don’t know how to fix this… And I totally acknowledge I am a back seat commentator.
If I knew how to contribute to fix this issue I would but that would take 5-7 years of education in a field that I don’t have.
So - why can’t there be a way of filter out NAN, scratchpad errors and timing/blocking issues within the esphome libraries. It’s not like it’s a minority that are experiencing these issues.
Surely some lines in code would resolve this?
I’ve tried everything, including suggestions from the OG Otto Winter, ChatGPT, this forum, DallasNg and even my own half assed attempts at lambdas to resolve this. Most of which crash/brick the daylights out of an ESP32.
See here:
And before anyone says it’s not possible because of this and this and this…
It IS possible - Shelly have done it.
All shelly units w DS18B20’S don’t complain (even when they’re connected to cheap DS18B20 clones). I’ve had 30 of them and speak from experience so they’re doing something better in their library than ESPHome.
Why dont I stay w Shelly’s then???
Well
1: Shelly’s can’t run a climate control onboard rock solid like ESPhome. They rely on Cloud or HA to achieve this unlike ESPhome.
2: Shelly traffic isn’t secure and encrypted like ESPHome
3: Shelly’s are flaky without an internet connection.
4: Shelly’s can’t do any form of onboard LED display at the same time as a climate control (even tho they don’t do onboard climate)
5: Shelly’s aren’t cheap.
Just suggesting to ppl that are smarter than me that the new one_wire/Dallas library could use some love from someone smarter than me.
Rant over.