Not found the Dallas sensors after uprade to ESPHOME v2022.3

[itanczos]

The problem

Not available the Dallas sensors after uprade to ESPHOME v2022.3

Which version of ESPHome has the issue?

2022.3

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.3.5

What platform are you using?

ESP8266

Board

sonoff basic

Component causing the issue

dallas

Example YAML snippet

esphome:
  name: sonoffkazan
  platform: ESP8266
  board: sonoff_basic

# Enable logging
logger:
  hardware_uart: UART1
  baud_rate: 0
  esp8266_store_log_strings_in_flash: false

# Enable Home Assistant API
api:

ota:
  password: "xxxxxx"

wifi:
  networks:
    - ssid: "xxxxxxx"
      password: "yyyyyyyyyyyyyyyy"
    - ssid: "zzzzzzzz"
      password: "aaaaaaaaaaaaaaa"
  domain: '.lan'
#  fast_connect: true
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Sonoffkazan Fallback Hotspot"
    password: "asasasas"

# Sets time from Homeassistant
time:
  - platform: homeassistant
    id: homeassistant_time

captive_portal:

#web_server:
#  port: 80
#  auth:
#    username: user
#    password: password

dallas:
  pin: GPIO14
  update_interval: 30s

sensor:
  - platform: dallas
    address: 0x840118xxxxxxx
    name: "Pince hőmérséklete"

  - platform: dallas
    address: 0xE7012xxxxxxxx
    name: "Fűtési kör elmenő"

  - platform: dallas
    address: 0x4D01xxxxxxxxx
    name: "Fűtési kör visszatérő"

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode: INPUT_PULLUP
      inverted: true
    name: "Kazán gomb"
    on_press:
      - switch.toggle: relay_1

  - platform: gpio
    pin:
      number: GPIO3
      mode: INPUT_PULLUP
      inverted: true
    name: "Fűtés kapcsoló"
    device_class: heat
    on_press:
      then:
        - switch.turn_on: relay_1
    on_release:
      then:
        - delay: 5min
        - switch.turn_off: relay_1
    filters:
      - delayed_on_off: 1000ms

  - platform: status
    name: Kazán relé státusz

switch:
  - platform: gpio
    pin: GPIO12
    id: relay_1
    name: "Kazán relé"
    on_turn_on:
      - light.turn_on: led
    on_turn_off:
      - light.turn_off: led

button:
  - platform: restart
    name: "Kazán Restart"

light:
- platform: status_led
  pin: 
    number: GPIO13
    inverted: true
  internal: true
#  name: "LED"
  id: "led"

Anything in the logs that might be useful for us?

[03:29:41][C][dallas.sensor:076]:   Pin: GPIO14
[03:29:41][C][dallas.sensor:077]:   Update Interval: 30.0s
[03:29:41][W][dallas.sensor:080]:   Found no sensors!

Additional information

Works with version 2022.2.6.

[peterfortuin]

I'm also using the dallas sensors with Esphome 2022.3 and it seems to be working fine. Don't see anything weird in your config.

[powercolorsky]

I have same issues. after updating firmware, my ESP lost all dallas sensors

[sophof]

For some reason my esphomes with dallas sensors can not connect to the wifi anymore unless they have a high signal strength. Before the update the connection was rock-solid however.

I'm assuming it is somehow related (although I wouldn't know how).

[DannyJ83]

I'm also having this same issue, was working fine before updating, afterwards sensors are showing bad checksum constantly, weirdly another esp8266 with d18b20 sensors connected to it is working perfectly, same setup on both, both running most up to date firmware etc.

[AssortedMapTacks]

I am also having the same issue. I am using GPIO00 on an ESP-01 board. Worked fine until updating to 2022.3.0. Four sensors connected to bus, none are found now.

[23:32:19][C][dallas.sensor:076]: Pin: GPIO0 [23:32:19][C][dallas.sensor:077]: Update Interval: 5.0s [23:32:19][W][dallas.sensor:080]: Found no sensors!

Edit: After rolling back to 2022.2.6, everything is working again.

[nagyrobi]

This is not new...

I have a 5 devices, all the same, based on Geeklink IR Bridge This has been exended with a Dallas temp sensor. It's connected to the GPIO0 pin of the ESP8266 inside (2AL3B-ESP-F) The symptom is that the last ESPHome build which is able to read temps on these devices is 2021.10.3. If I upgrade to any higher version, I get Scratch pad checksum invalid! in the log. Luckily I have a copy of the binaries saved. If I simply downgrade from the web interface to the 2021.10.3 binary, everything works, temperature is correctly read any idea what could have been changed since? There's someting related only to these units as with other modules (Wemos D1, or other ESP32s) the Dallas sensors work fine. I just don't see what could be the problem with these specifics.

Tried altering settings for pin in various ways. Everytime I flash back the binary from 2021.10.3 the sensor magically works. Thus I would exclude any kind of hardware issue.

https://discord.com/channels/429907082951524364/943861928177045534

[zechnkaas]

Same here using ESP32 with some Dallas on GPIO14 after 2022.3.0 no more Sensor found. Switching back to 2022.2.6 resolves the issue.

[DannyJ83]

I'm also having this same issue, was working fine before updating, afterwards sensors are showing bad checksum constantly, weirdly another esp8266 with d18b20 sensors connected to it is working perfectly, same setup on both, both running most up to date firmware etc.

So after trying several things I took a new wemos D1 mini and flashed the exact same file on to it that the old one had, plugged it into the circuit and turned it on, all sensors working again, I deleted the unit from home assistant, restarted home assistant and added the new unit back into esphome and everything is working again.

[powercolorsky]

I am change pins and found

dallas:

• id: "dallas_hub_1" pin: 16
• id: "dallas_hub_2" pin: 0

Only Pin 0 works fine, others not works... On Pin 0 all sensors added and works correct...

---

[22:29:26][C][dallas.sensor:076]: Pin: GPIO16 [22:29:26][C][dallas.sensor:077]: Update Interval: 60.0s [22:29:26][W][dallas.sensor:080]: Found no sensors!

[22:29:26][C][dallas.sensor:089]: Device Class: 'temperature' [22:29:26][C][dallas.sensor:089]: State Class: 'measurement' [22:29:26][C][dallas.sensor:089]: Unit of Measurement: '°C' [22:29:26][C][dallas.sensor:097]: Address: 0xcaa3d1231e64ff28 [22:29:26][C][dallas.sensor:098]: Resolution: 12

[22:29:26][C][dallas.sensor:089]: Device Class: 'temperature' [22:29:26][C][dallas.sensor:089]: State Class: 'measurement' [22:29:26][C][dallas.sensor:089]: Unit of Measurement: '°C' [22:29:26][C][dallas.sensor:089]: Accuracy Decimals: 1 [22:29:26][C][dallas.sensor:097]: Address: 0x12bac45b1e64ff28 [22:29:26][C][dallas.sensor:098]: Resolution: 12

[22:29:26][C][dallas.sensor:076]: Pin: GPIO0 [22:29:26][C][dallas.sensor:077]: Update Interval: 60.0s [22:29:26][D][dallas.sensor:082]: Found sensors:

[westwoodx]

I too have had the 'No sensors found' since updating to 2022.3. The 5 ds18b20 were reading reliably until the update. I have since rolled back the version for now, and normal service has been resumed.

[nagyrobi]

Try with power_save_mode: LIGHT added to the wifi section of the config if you have ESP8266.

[jesserockz]

I just tried this with 5 dallas sensors on GPIO14 and it works fine for me on the latest dev branch and beta

[edenhaus]

Maybe this issue is related to #3165 and I have also problems with my dallas sensors since 2022.2.6. In https://github.com/esphome/issues/issues/3165#issuecomment-1102367861 I have started a analysis and found a PR, which introduced the problems for me. Maybe someone can test it with my custom docker image, to identify, that this PR is also the source of your problems.

[edenhaus]

My solution was to decrease the pullup resistor as 4.7K was not anymore sufficient with the improved timing in PR #3181 and my sensors are 20-30m away

[mbrunton77]

I am having the same issue with my sonoff basic and temperature sensor after upgrading. Any potential fixes in a future release?

[pmoneill]

To restate, the problem caused by version 2022.3.1 is that only sensors on one Dallas 1-Wire bus are recognized; a second bus is ignored. I am using two buses (pins), one per sensor. Why? Because my wires are so long that the ESP cannot drive multiple sensors per my experience and Dallas's recommendation. Is anybody working on a solution to this? Home Assistant/Nabu Casa emphasized their commitment to backward compatibility and continuity after their latest big release so I keep hoping that each ESPHome update will address this but no such luck for months now.

[nagyrobi]

Did you try to adjust pullup resistors as described above?

[pmoneill]

Did you try to adjust pullup resistors as described above?

Not yet becasue it's not very accessible. After proving my configuration in a breadboard, I soldered the 4.7K pull-up resistors and ESD protection diodes between the ESP and an I/O terminal block on a perf board for robust, permanent installation where it worked fine until the 2022.3.1 firmware update. GPIO13 1-Wire bus now fails to recognize a sensor whereas 1-Wire bus on GPIO12 still works even when connecting the sensor wire from GPIO13. I'm in the process of building up an ESP breadboard to conduct many experiments with the assignment and number of GPIO pins for Dallas 1-Wire temperature sensors and pull-up resistors to understand what is happening. I'll post the results here. I didn't expect that a firmware update would require hardware modification.

[edenhaus]

I had connected an oscilloscope and there you saw that it take some nanoseconds to pull up the signal with a 4k7 resistor. The pull up resistor was to big and therefore the signal was not immediately (without delay) pulled up. (Sorry I don‘t have saved the screenshots)

As written in the docs you need to change the resistor when you have long wires.

Older firmwares were more tolerant if the signal had some “noise”, but at the end we all used the wrong pull up resistor. As Otto improved the performance of the sensor by shorten the timings (which is spec conform) the esp expects a clear signal, which can be achieved by using the correct pull up resistor.

[nagyrobi]

That's a very clear explanation thank you.

A trick related to wiring: if using CAT cables (twisted pairs) for 1-wire or I2C never use a twisted pair for data and ground. Capacitance accumulates over the long cable. For I2C I use SDA and GND with one twisted pair and SCL and VCC on another one, that allows for lengths over 6m. 1-wire similarly, I use GND and VCC on a pair, and data on another independent wire, that allows for 40m distances safely.

[pmoneill]

edenhaus, your explanation of this as a timing issue gave me the confidence that modifying my circuit board was the solution, not merely another possible thing to try. Indeed my addition of a Zener diode and MOV for ESD/surge protection to make this a robust installation added too much capacitance to work with your corrected serial bus timing. Removing these protection devices fixed the issue. I'm interested in anybody's experience with and view on the need for and implementation of I/O protecion on long sensor wires connected to a microcontroller. My HA system is more than a hobby, it seriously runs my house. nagyrobi, thanks for your advice on the use of twisted pair for One-Wire. Indeed, I'm using an existing CAT5 cable and puzzled how best to configure it since One-Wire is single ended while twisted pair naturally fits differential signaling. I chose to pair data with ground to shield it from noise not knowing that the bigger issue is reducing capacitance by pairing data with a floating conductor.

[nagyrobi]

My 40 meters cable with a Dallas sensor on its end runs mostly under the yard ground in a plastic pipe, no special protection added, it's been like that for 3 years now, zero issues. Worked with Tasmota for 2.5 years, and moved to ESPHome 6 months ago.

[Proche72]

I had connected an oscilloscope and there you saw that it take some nanoseconds to pull up the signal with a 4k7 resistor. The pull up resistor was to big and therefore the signal was not immediately (without delay) pulled up. (Sorry I don‘t have saved the screenshots)

As written in the docs you need to change the resistor when you have long wires.

Older firmwares were more tolerant if the signal had some “noise”, but at the end we all used the wrong pull up resistor. As Otto improved the performance of the sensor by shorten the timings (which is spec conform) the esp expects a clear signal, which can be achieved by using the correct pull up resistor.

Hi, quite noob question but which pull up to use with the dallas 3m long? I had 4,7k but suddenly it shows me no sensor found (after working perfectly over month now).

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ssieb]

Try something lower.

[artmdv]

Kind of silly of changing code so stuff that worked no longer works and say its a feature that it doesnt and now everyone needs to change hardware to make something work that worked without changes. Very very annoying and disappointing.

[Skottelbraai]

Hello, I have the same issue, Not found: Dallas sensor. This happened after an update. Pleace repair in the next update.

[szaszgyozo]

For me this is the second time that my ESP drops all Dallas sensors after an update, first it happened at the 2022.03 update, now it happened at the 2022.12 update. Both times it was solved by getting a smaller resistor. I started with a 4.7k, then I switched to 3.3, now its 2.2. Thats the only way i could solve the issue both times.

[dartfrogdk]

i got this problem with 23023.4

[zechnkaas]

i got this problem with 23023.4

Hi, was also affected back then, but i had not installed a pullup resistor. (as it was workingout before without such)

After adding one i hab no issues since then.

hope this helps