Average values of Dallas sensors seem noisier after update to 2024.6.0 -> dropouts?

emefff commented 2 months ago

The problem

Since the update to 2024.6.x some users report dropouts of Dallas sensors. In my devices, I did not see any of the errors of the kind 'reading scratch pad failed' (--> no value is sent) or 'Found no devices!' which, of course also does not transmit any temperatures.

However, here's why I think that I also have some kind of dropout of some of my one_wire dallas_temp sensors.

In my setup I calculate an average temp value from 12 temperature sensors (average is calculated with helper), of which not all are Dallas. Updating the devices started today at 07:30 or so, device after device. The average temperature curve starts to get noisier after updating to the new 2024.6.0. I only just discovered this by accident (peak at end is from restarting HA):

Bildschirmfoto vom 2024-06-20 21-04-26

Clearly, after 08:00 the average starts getting noisier. The weird thing is, the sensors with which this average is computed do not show any of the large fluctuations. Please remember: when the average drops by, let's say 0.6°C, like at 18:00, then, if one single sensors is responsible, its value must drop roughly by 12*0.6°C (or thereabouts), which must be visible in its curve. Such a drop can't be overlooked! However, the Dallas input curves (non Dallas are not shown, they are smooth) to this average helper look like this (same time span of course):

Bildschirmfoto vom 2024-06-20 21-05-31

None of the curves show large drops at 12:00 or 18:00 where dips are visible in the average curve above.

Thus, there can only be one explanation: One or more of the Dallas show dropouts which lead to false average values. In my opinion, this is the only explanation, do you agree? Unfortunately, I cannot prove my statement at the moment.

Which version of ESPHome has the issue?

2024.6.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2024.06

What platform are you using?

ESP32

Board

esp32dev mostly

Component causing the issue

supposedly one_wire dallas_temp

Example YAML snippet

***not necessary***

Anything in the logs that might be useful for us?

unfortunately, the logs of many devices would be necessary, which I don't have at the moment. To solve this problem, possible dropouts of dallas_temp should probably surveilled over a longer period of time.

Additional information

No response

emefff commented 2 months ago

I just read issue 5947 and looking at my ESP32 uptimes, I can confirm that some of my ESPs do reset as well. As an example, one uptime curve is shown below. It runs 2024.6.0, before that it ran for hundreds of hours (I don't do every update...):

Bildschirmfoto vom 2024-06-21 10-05-14

If any info is needed, please let me know. I am currently looking at logs in realtime...

Boards seemingly unaffected: rpipicow (although this one is less stable compared to esp32dev) esp32doit-devkit-v1

emefff commented 2 months ago

My logs do not show anything specific before the loss of connection/reset. They just stop, API doesn't even say 'connection is lost' or similar (I don't remember the exact words..).

emefff commented 2 months ago

I'm switching back to dallasng. Very unprofessional rollout of one_wire: dallas_temp and handling of complaints. Issue 3909 is open since Christmas 2022 (!) with similar issues (timing issues).

emefff commented 2 months ago

Guess the time when the switch to dallasng was completed:

Bildschirmfoto vom 2024-06-21 18-25-43

tomastnc commented 2 months ago

Same issue here. More noise and errors from sensors. Discovery on the one wire bus also stopped working after the upgrade. Got discovery working again with dallasng. Is there a way to get data from the 18S20 variant with dallasng? Tried all resolutions, but only got 85C from all 18S20 sensors. They all worked fine prior to 2024.6.x

emefff commented 2 months ago

Sorry I don't know about the DS18S20 and if it works with dallasng.

pksoft585 commented 2 months ago

I tried dallasng - I have 7 Dallas thermometers connected to WT32ETH01. The results from dallasng have really less noise, there are more stable and the values seem to correspond better to reality.

emilianogetino commented 2 months ago

I tried dallasng - I have 7 Dallas thermometers connected to WT32ETH01. The results from dallasng have really less noise, there are more stable and the values seem to correspond better to reality.

Could you put your code here? , I can't get my sensors to work with dallasng and EspHopme 2024.6 thank you.

pksoft585 commented 2 months ago

I can't put the whole code here, it has over 4000 lines... So only parts:

esphome:
  name: wt32-control

esp32:
  board: esp-wrover-kit
  framework:
    type: arduino

external_components:
  - source: github://nrandell/dallasng

...

dallasng:
  - pin: GPIO15
    update_interval: 1min
    id: dallas

...

  - platform: dallasng
    address: 0xc13c88f6492ac228
    name: "Dallas - 1"
    id: dallas_temperature
    unit_of_measurement: "°C"
    device_class: "temperature"
    state_class: "measurement"
    accuracy_decimals: 1
    filters:
      - filter_out: nan
      - offset: -0.7

emilianogetino commented 2 months ago

external_components:
  - source: github://nrandell/dallasng

Thanks friend, this already works for me. All the best

tiimsvk commented 2 months ago

Hello, I have a similar problem with Dallas after updating to the one_wire platform, one of the sensors shows a problem with reading values, see photo. obrázok

It looks like the problem is rather with the connection or sensor?

Everything was working fine before the update.

EDIT: It looks like it reads the first value as bad when it wakes up. Of course, it can be solved with filters, but it would be better to look at the code which part causes it

ssieb commented 2 months ago

Unless it's an S20 sensor, then that's the value that's getting returned by the sensor. Nothing that the code can do about it.

tomastnc commented 2 months ago

The latest few updates are major improvements when reading s20 sensors. However, there are still issues that did not exist prior to 2024.6.x

Everything works fine with one sensor, but if I add more on the same bus I cannot increase the update_interval. If i change to for example 10 or 20 seconds, only one sensor reports correct values. 85C from the others. I have tried this with 3 sensors.

emefff commented 2 months ago

Just updated all my devices to 2024.6.4 and switched to one_wire dallas_temp. So far, so good.

tiimsvk commented 2 months ago

After update to 2024.6.6 without change I modified the code with a filter:

    filters:
      filter_out: 85

sakrlog commented 1 month ago

Just updated all my devices to 2024.6.4 and switched to one_wire dallas_temp. So far, so good.

Just updated mine and it didn't fix it.

sakrlog commented 1 month ago

I saw today an error that checksum is failing as if the address I have for sensor is not correct. I deleted it and deployed again to see if Dallas can detect any new address. But nofthing was found.

[15:43:16][W][gpio.one_wire:078]:   Found no devices! <---------
[15:43:16][C][libretiny.pwm:034]: PWM Output:
[15:43:16][C][libretiny.pwm:035]:   Pin 9
[15:43:16][C][libretiny.pwm:036]:   Frequency: 1000.0 Hz
[15:43:16][C][libretiny.pwm:034]: PWM Output:
[15:43:16][C][libretiny.pwm:035]:   Pin 8
[15:43:16][C][libretiny.pwm:036]:   Frequency: 1000.0 Hz
[15:43:16][C][switch.gpio:068]: GPIO Switch 'Relay 1'
[15:43:16][C][switch.gpio:090]:   Restore Mode: always OFF
[15:43:16][C][switch.gpio:031]:   Pin: 6
[15:43:16][C][switch.gpio:068]: GPIO Switch 'Relay 2'
[15:43:16][C][switch.gpio:090]:   Restore Mode: always OFF
[15:43:16][C][switch.gpio:031]:   Pin: 24
[15:43:16][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'binary_switch_all'
[15:43:16][C][gpio.binary_sensor:016]:   Pin: 1
[15:43:16][C][light:103]: Light 'light_switch_1'
[15:43:16][C][light:105]:   Default Transition Length: 1.0s
[15:43:16][C][light:106]:   Gamma Correct: 2.80
[15:43:16][C][light:103]: Light 'light_switch_2'
[15:43:16][C][light:105]:   Default Transition Length: 1.0s
[15:43:16][C][light:106]:   Gamma Correct: 2.80
[15:43:16][C][dallas.temp.sensor:029]: Dallas Temperature Sensor:
[15:43:16][W][dallas.temp.sensor:031]:   Unable to select an address < ------------

tiimsvk commented 1 month ago

After update esphome 2024.7.1 not fixed

sakrlog commented 1 month ago

I wonder if use a custom dallas component should solve the issue for now

tomastnc commented 1 month ago

Indeed. 2024.6.6 was in improvement, but 2024.7.1 brought back several issues. Once again multiple 18S20 on the same bus reports only 85C when I set an update interval. This was working (not completely, but in most cases) on 2024.6.6

ssieb commented 1 month ago

There were no 1-wire changes between those versions. Does it work if you use the sequencing method? Do you have a logic analyzer?

tomastnc commented 1 month ago

Interesting. It was very clear when looking at the statistics that the bad readings started right after the ESP reboot following the update to 2024.7.1. What is the sequencing method?

ssieb commented 1 month ago

What is the sequencing method?

https://github.com/esphome/issues/issues/5908#issuecomment-2196033203

esphome / issues