DS18B20 freaking out / continuously reporting 85°C

[JiriPrchal]

The problem

More parasitic powered sensors on bus, 1k pull up. Seems like every time after reset it publishes 85. And sometimes repeated bus reset, so one of the sensors has 85˚C all the time. In older versions worked fine (don't know which but some from 2023).

Which version of ESPHome has the issue?

2024.8.0

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP8266

Board

No response

Component causing the issue

No response

Example YAML snippet

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

Anything in the logs that might be useful for us?

No response

Additional information

Had quick look to source code 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.

[ThomDietrich]

This bug is also discussed here: https://community.home-assistant.io/t/ds18b20-freaking-out-continuously-reporting-85-c/346467/20

Relevant source that discusses this "feature" and presets a technical mitigation: https://github.com/cpetrich/counterfeit_DS18B20#solution-to-the-85-c-problem

[ssieb]

Parasite power is not currently supported. But it works for other people if you sequence the sensors. Disable the sensor updates and use an interval: to update the sensors individually with at least 1s delay between them.

[ssieb]

Oh, I just noticed what's in your yaml. You can't update them that fast. Each sensor needs 1s to sample and you can't do anything else on the bus during that time if you're using parasite power. The 85C is happening because the sensor is resetting before esphome reads the sampled value.

[JiriPrchal]

Parasite power is not currently supported.

Not mentioned anywhere.

But it works for other people if you sequence the sensors. Disable the sensor updates and use an interval: to update the sensors individually with at least 1s delay between them.

Could you be more specific, please.

Oh, I just noticed what's in your yaml. You can't update them that fast. Each sensor needs 1s to sample and you can't do anything else on the bus during that time if you're using parasite power. The 85C is happening because the sensor is resetting before esphome reads the sampled value.

But exactly this worked last year. May be the sequencing was done by dallas component, because the update interval was defined there, now it's at individual sensors.

[ssieb]

update_interval: never on the sensors.

interval:
    - interval: 3s
    then:
      - component.update: sensor1
      - delay: 1s
      - component.update: sensor2
      - delay: 1s
      - component.update: sensor3

If you really have to sample them every second, then either give them power or put them on separate pins.

[ssieb]

When parasite power is supported, it will be doing exactly this, but automatically, so it still won't be any faster than that.

[JiriPrchal]

never

This helps, but the first reading is still 85. Thanks

When parasite power is supported, it will be doing exactly this, but automatically, so it still won't be any faster than that.

Yes, I understand why it's impossible to start conversion at one and communicate with others.

[ssieb]

The first reading of each or just the very first reading. You could put a delay: 1s first as well if it's the second case.

[JiriPrchal]

The first reading of each or just the very first reading. You could put a delay: 1s first as well if it's the second case.

The very first.

[ThomDietrich]

Hello, just to add my two cents here: I might have misunderstood the topic of this ticket but I am interested specifically in the 85°C reading. This is my configuration:

sensor:
 - platform: dallas_temp
   ...
   filters:
    - filter_out: 85

According to the link provided above the wrongful 85°C reading can be identified and correctly ignored by leveraging the scratchpad register. Sounds like a worthy feature request, or bug mitigation if we want to be picky.

https://github.com/cpetrich/counterfeit_DS18B20#solution-to-the-85-c-problem

[JiriPrchal]

Hello, just to add my two cents here: I might have misunderstood the topic of this ticket but I am interested specifically in the 85°C reading. This is my configuration:

sensor:
 - platform: dallas_temp
   ...
   filters:
    - filter_out: 85

According to the link provided above the wrongful 85°C reading can be identified and correctly ignored by leveraging the scratchpad register. Sounds like a worthy feature request, or bug mitigation if we want to be picky.

https://github.com/cpetrich/counterfeit_DS18B20#solution-to-the-85-c-problem

And what if your measured temp would be 85?

[ThomDietrich]

If measured temperature is exactly 85.0000 then this value is ignored. Chances are high reading will be 85.1 or 84.9 a minute later. Nothing to be scared of. But more importantly, the linked article specifically mentions that there is a technical method to classify those readings and filter them correctly. This should imho be a code improvement.