DS18B20 freaking out / continuously reporting 85°C

ESPHome
3

How long are the cables to the sensors?

What value pull-up resistor did you use?

85°C on DS18B20 almost always means powering issues.

1 Like
4

reported temp 85 degrees in case of DS1820 means that you don’t have a connection with sensor, not that it’s “freaking out”. No sensor connected will return 85. Check length of your cables → power supply to the sensor - do you have parasitic power? It can cause problems. Like tom said: power supply issues or communication issues.

1 Like
5

Might be a “new” fake ds18b20 with a special feature set?

6

:100:

I guess if you have posted logs we would have seen that the one wire bus resets after each reading and therefor starts again with the power-up temperature of 85°C

7

Sry for my late reply to you all.

I wasn’t at home and will check everything in the evening but I don’t think it’s about the length of the cable as I use the same temerature probe on the same ESP32 for the lower temperature of the heatpump.

Maybe it is about some hardware-connection / soldering problem then.

8

Ok, so it was just a loose cable / a bad contact.
Everything is working now.

Thanks for your support!

9

For future readers, you can simply filter out the value “85” from the “faulty” sensor. Use ESPHome’s filter_out.

sensor:
  - platform: dallas
    address: 0x1c0000031edd2a28
    name: "Livingroom Temperature"
    filters:
      - filter_out: 85.0

This obviously means that you’ll loose specifically 85C. If you’re actively using this range, it’ll jump from 84.9C straight to 85.1C. Shouldn’t pose a real problem imo.

Not a solution, but a workaround.

1 Like
10

It goes back to old AVR’s, but i always wondered why manufacturers chose this stupid number for showing (not available) sensor. Way more logical would be one or other limit end, or even “out of the range” number, say, 200 degrees…
I use this sensor for central heating system with pellets, sp 85 degrees is a number which can happen…

11

You could pick a better sensor for that instead. e.g. a thermocouple.

12

You’re absolutely right. I might do that at a later stage… luckily temp almost never gets up to 85.

13

Still, why the heck did the sensor engineers choose a value in the measurement range to initialise to?

14

Looking at the DS18B20 datasheet it actually describes the 85°C as “power-up” reading :bulb:

:point_down:

Solution to the 85 °C-Problem

There is a simple, undocumented, way to discriminate between the power-up 85 °C-reading and a genuine temperature reading of 85 °C in DS18B20 of Family A [5]: <byte 6> of the scratchpad register. If it is 0x0c, then the 85 °C-reading is a power-up reading, otherwise it is a true temperature measurement.

Might be challenging for users to integrate this into esphome but if a feature request is raised maybe it can end up in the official component which would then could automatically discard this “power-up” readings :rocket:

15

Now, after update to 2024 I’ve got this issue. Parasitic power, 1kOhm pull up. With older versions (<2024) this was fine. So something in lib must be wrong.

16

Would you mind to be a little more specific? At this point in time we got already 8 releases in 2024 and on top of this a lot of point (bug fix) releases. Also the older version would be good to know otherwise it will be hard to do any proper investigation :person_shrugging:

17

Unfortunately I can’t, I jumped from 2023 to something 2024.(6?), now I have 2024.8.0. For sure I know there was the big change in yaml dalas → one_wire.
More sensors on bus. Seems like every time after reset it publishes 85. And sometimes repeated bus reset, so one of the sensors has 85 all the time.
One of my yaml:

one_wire:
 - platform: gpio
   pin: 27

sensor:
 - platform: dallas_temp
   address: 0x724b847d0a646128
   name: rain water temperature
   icon: mdi:thermometer-water
   update_interval: 1s
   filters:
    - sliding_window_moving_average:
         window_size: 256
         send_every: 16

 - platform: dallas_temp
   address: 0xe36168730a646128
   name: main pipe temperature
   update_interval: 1s
   filters:
    - sliding_window_moving_average:
         window_size: 256
         send_every: 16

 - platform: dallas_temp
   address: 0x2a4361700a646128
   name: tank air temperature
   id: tank_air_temperature
   update_interval: 1s
   filters:
    - sliding_window_moving_average:
         window_size: 256
         send_every: 16

Had quick look to source and seems to me there is no first reading throw nor scratchpad 0x0c test.
Also upon datasheet for parasitic power there should be “strong pull up” during measurement what could be done by GPIO set OUTPUT an HIGH.

18

This is a great find. Apparently the developer of the ESPHome component did not know this. Did you consider opening a ticket or even to work on a PR?

19

Issue #6207 opened…

20
21

Quite frankly, when using $2 sensors instead of genuine $10 sensors, it might be worth simply implementing filters to throw out the “power-on” state.
How often is it really going to read 85.0 or 25.0 exactly? Not often, I’d think, especially if the sensor normally returns decimals values to at least one place…

  - platform: dallas
    address: 0xd4000000108b9b28
    filters:
      - filter_out: 85.0  # 25.0 for some sensors
      - offset: +0.3

Edited because I actually realized some sensors have a different number to toss.

22

There is no doubt about this workaround. However, if you check the linked ticket, there is actually a technically clean way to filter those states correctly. Be my guest to post a agreeing response, hopefully someone will work on the esphome improvement soon.