ESPHome drops Dallas temp sensor after update

ColoradoAutomator · April 3, 2022, 4:34am

After updating ESPHome to 2022.3.1, HA to 2022.3.8, and HA OS to 7.6, one of my two Dallas 18b20 temperature sensors is no longer found. Each is on a separate pin: GPIO12, GPIO13. Both logged data up to the minute where the updates were made, then the one on GPIO13 could no longer be found. I did not touch the hardware. Numerous Adafruit Feather ESP resets (by button), power cycles, and reintalls of ESPHome firmware had no effect.

ESPHome log follows:

INFO Starting log output from central-esp.local using esphome API
WARNING Can’t connect to ESPHome API for central-esp.local: Error connecting to (‘23.60.91.236’, 6053): [Errno 111] Connect call failed (‘23.60.91.236’, 6053)
INFO Trying to reconnect to central-esp.local in the background
INFO Successfully connected to central-esp.local
[21:15:58][I][app:102]: ESPHome version 2022.3.1 compiled on Apr 2 2022, 21:15:04
[21:15:58][C][wifi:491]: WiFi:
[21:15:58][C][wifi:353]: Local MAC: E8:DB:84:94:D9:93
[21:15:58][C][wifi:354]: SSID: ‘ONeill’[redacted]
[21:15:58][C][wifi:355]: IP Address: 192.168.0.7
[21:15:58][C][wifi:356]: BSSID: 84:E8:92:6B:11:93[redacted]
[21:15:58][C][wifi:358]: Hostname: ‘central-esp’
[21:15:58][C][wifi:360]: Signal strength: -32 dB ▂▄▆█
[21:15:58][C][wifi:364]: Channel: 1
[21:15:58][C][wifi:365]: Subnet: 255.255.255.0
[21:15:58][C][wifi:366]: Gateway: 192.168.0.1
[21:15:58][C][wifi:367]: DNS1: 192.168.0.1
[21:15:58][C][wifi:368]: DNS2: 205.171.3.25
[21:15:59][C][logger:233]: Logger:
[21:15:59][C][logger:234]: Level: DEBUG
[21:15:59][C][logger:235]: Log Baud Rate: 115200
[21:15:59][C][logger:236]: Hardware UART: UART0
[21:15:59][C][switch.gpio:050]: GPIO Switch ‘Car Door Move’
[21:15:59][C][switch.gpio:051]: Pin: GPIO14
[21:15:59][C][switch.gpio:073]: Restore Mode: Restore (Defaults to OFF)
[21:15:59][C][gpio.binary_sensor:015]: GPIO Binary Sensor ‘Car Door Position’
[21:15:59][C][gpio.binary_sensor:016]: Pin: GPIO4
[21:15:59][C][dallas.sensor:075]: DallasComponent:
[21:15:59][C][dallas.sensor:076]: Pin: GPIO12
[21:15:59][C][dallas.sensor:077]: Update Interval: 60.0s
[21:15:59][D][dallas.sensor:082]: Found sensors:
[21:15:59][D][dallas.sensor:084]: 0x77012058fecd1328
[21:15:59][C][dallas.sensor:089]: Device ‘Garage Temperature’
[21:15:59][C][dallas.sensor:089]: Device Class: ‘temperature’
[21:15:59][C][dallas.sensor:089]: State Class: ‘measurement’
[21:15:59][C][dallas.sensor:089]: Unit of Measurement: ‘°C’
[21:15:59][C][dallas.sensor:089]: Accuracy Decimals: 1
[21:15:59][C][dallas.sensor:097]: Address: 0x77012058fecd1328
[21:15:59][C][dallas.sensor:098]: Resolution: 12
[21:15:59][C][dallas.sensor:075]: DallasComponent:
[21:15:59][C][dallas.sensor:076]: Pin: GPIO13
[21:15:59][C][dallas.sensor:077]: Update Interval: 60.0s
[21:15:59][W][dallas.sensor:080]: Found no sensors!
[21:15:59][C][dallas.sensor:089]: Device ‘Outside Temperature’
[21:15:59][C][dallas.sensor:089]: Device Class: ‘temperature’
[21:15:59][C][dallas.sensor:089]: State Class: ‘measurement’
[21:15:59][C][dallas.sensor:089]: Unit of Measurement: ‘°C’
[21:15:59][C][dallas.sensor:089]: Accuracy Decimals: 1
[21:15:59][C][dallas.sensor:097]: Address: 0xbf00000000384228
[21:15:59][C][dallas.sensor:098]: Resolution: 12
[21:15:59][C][captive_portal:088]: Captive Portal:
[21:15:59][C][mdns:084]: mDNS:
[21:15:59][C][mdns:085]: Hostname: central-esp
[21:15:59][C][ota:085]: Over-The-Air Updates:
[21:15:59][C][ota:086]: Address: central-esp.local:8266
[21:15:59][C][ota:089]: Using Password.
[21:15:59][C][api:138]: API Server:
[21:15:59][C][api:139]: Address: central-esp.local:6053
[21:15:59][C][api:143]: Using noise encryption: NO

Firmware follows:

captive_portal:

# Digital Outputs
switch:
  - platform: gpio
    pin: 14
    name: "Car Door Move"
    
# Dallas/Maxim One-Wire Sensors
dallas:
  - id: "dallas_garage"
    pin: 12
  - id: "dallas_outside"
    pin: 13
  
# 18b20 Temperature Sensor
sensor:
  - platform: dallas
    address: 0x77012058FECD1328
    name: "Garage Temperature"
    dallas_id: "dallas_garage"
  - platform: dallas
    address: 0xBF00000000384228
    name: "Outside Temperature"
    dallas_id: "dallas_outside"
    
# Binary Sensors
binary_sensor:
  - platform: gpio
    pin:
      number: 4
      mode: INPUT_PULLUP
    name: "Car Door Position"
    filters:
      - delayed_on: 10ms

tom_l · April 3, 2022, 4:49am

There is an open issue:

github.com/esphome/issues

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

opened 02:31AM - 18 Mar 22 UTC

itanczos

integration: dallas

### 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 ```yaml 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? ```txt [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.

ColoradoAutomator · May 25, 2022, 12:55am

I have followed the discussion on GitHub without resolution. 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.

tom_l · May 25, 2022, 1:03am

Posting this in the issue (as you did):

Will help them narrow down the possible issue. From the original issue post it was not made clear that it was a second bus that was the issue. In fact that is probably a separate issue. However you might want to be a little bit less demanding and passive aggressive. This won’t win you any friends:

ColoradoAutomator · May 25, 2022, 4:39am

After further experiments, I have found that ESPHome 2022.3.1 will recognize and measure a Dallas 18b20 temperature sensor on GPIO12 but NOT on GPIO13 regardless of whether one or two 1-Wire busses are defined on these two pins or if their order of definition is swapped. So the problem appears to be with the particular pins used and perhaps not with the number of 1-Wire busses. Again, in the prior version I was able to measure one sensor on a separate 1-Wire bus in each of these two pins. I haven’t tried other GPIOs.

I have been on a muliple year quest to do what I first thought would be trivial: use outdoor temperature to assist in timing setpoint changes for my thermostat. Certainly, as a software project, Home Assistant is not responsible for providing a weatherproof outdoor temperature sensor but I was disappointed that the only such devices in the supported hardware ecosystem were full weather stations. I spent $200 for an ethernet adapter for my Davis weather station only to find that it was too old to work with the current integration. There were no commercial weathertight Z-Wave or Wi-Fi temperature sensors while wired sensors seem to be scorned. (Hopefully some manufacturers will recognize this business opportunity!) So I was overjoyed to learn about ESPHome and how easy it made using the wired and weathertight Dallas temperature sensor and relay output and switch contact input. ESPHome is a great project that I’m counting on and I appreciate your contributions. I even use it to read the low state of charge indicator light on my solar battery with a phototransistor to trigger a line charger.

ColoradoAutomator · May 27, 2022, 2:33am

Resolved.
The developers on GitHub made it clear that this was a timing issue caused by the capacitance I added with ESD/surge protection devices and their tightening of the serial I/O timing to better comply with the 1-Wire spec. Though things orginally worked with my protection devices, they didn not work with the corrected timing in ESPHome 2022.3.1. Removing a Zener dioded and MOV fixed the problem. They also pointed out that when running 1-Wire over twisted pair, e.g. the CAT5 I used, that the data (DQ) line should be paired with a floating (unconnected) conductor while Vcc and Gnd should go on another pair. I had paired DQ with Gnd to reduce noise but that increased capacitance, slowing the timing.

stevemann · May 27, 2022, 2:54am

Cable capacitance is the killer for oneWire data bus.

tom_l · May 27, 2022, 3:20am

You can add a small (pF) capacitor in series with your zenner to reduce the capacitance:

C_tot = 1 / (1/C_S + 1/C_Z)

It wont clamp DC but it will still clamp transient spikes that have very high frequency components.

nrandell · June 28, 2022, 10:10am

I’ve been having the same issues, but tried something different. There’s a newer library out there called OneWireNg that appears to be more stable. I’ve created a sort of dallas clone and now have it working on a number of projects.

You can see it at https://github.com/nrandell/dallasng

I’m using it with some esp32 on pretty new versions of libraries where the Dallas in esphome just didn’t work at all.

Excerpt from my configuration is

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

esp32:
  board: um_feathers3
  variant: esp32s3
  framework:
    type: arduino
    version: 2.0.3
    platform_version: 4.3.0

dallasng:
  - pin: GPIO6
    update_interval: 3s

sensor:
  - platform: dallasng
    name: ${fullname} Temperature
    index: 0
    resolution: 12
    filters:
      - filter_out: NAN

insipiens · February 27, 2023, 11:23pm

Nice work, solved it for me!

ajouwens · April 10, 2023, 6:38pm

Great, thank you a lot. This fixed it for me.

blueskiestailwinds · April 26, 2023, 8:32pm

Just a thank you to whoever fixed the Dallas sensor null value issue. I chose to wait on a software fix instead of messing with resistor values and as of 4/26/23 (ESPHome version 2023.4.1), I no longer have intermittent null values. The difference in the history graph is obvious.

andrefvdm · May 9, 2023, 5:51am

Dallas in ESPHOME works in the log, and in MQTT. Correct values for multiple sensors are displayed in the log, and sent to MQTT. However, the issue is that the entities are not created correctly in HA. It seems there is a problem transferring the entity info through the API process. I have tested it on various pins, on several processors, using several ESPHOME programs. The problem persists.
In every case I have checked the log file, and the MQTT publishing , that worked every time.
So the problem lies with the Dallas - API interface between ESPHOME and HomeAssistant

andrefvdm · May 10, 2023, 8:15am

Unfortunately the problem persists. ESPHOME does not create a Dallas sensor in HA.
My workaround is to create a template entity, which ESPHOME then creates in HA. Code below:

dallas:
  - pin: 32
    update_interval: 10s


captive_portal:

# Individual sensors
sensor:
  - platform: dallas
    address: < my sensor 1-wire address >
    #index: 0
    name: "Fish-water-temperature"
    id: "temperatureWaterFish"
    #filters:
    #  - or:
    #    - delta: 0.1
    #    - heartbeat: 300s
  - platform: template
    name: FishWaterTemp
    lambda: |-
      return id(temperatureWaterFish).state;
    update_interval: 60s
    unit_of_measurement: "°C"
    device_class: "temperature"
    state_class: "measurement"
    accuracy_decimals: 1
  - platform: dallas
    address: < my sensor 1-wire address >
    #index: 1
    name: "Hothouse-air-temperature"
    id: "temperatureAirHothouse"
    #filters:
    #  - or:
    #    - delta: 0.6
    #    - heartbeat: 300s
  - platform: template
    name: HothouseAirTemp
    lambda: |-
      return id(temperatureAirHothouse).state;
    update_interval: 60s
    unit_of_measurement: "°C"
    device_class: "temperature"
    state_class: "measurement"
    accuracy_decimals: 1

guni12 · July 21, 2023, 8:59am

andrefvdm:

- platform: template
    name: FishWaterTemp
    lambda: |-
      return id(temperatureWaterFish).state;
    update_interval: 60s
    unit_of_measurement: "°C"
    device_class: "temperature"
    state_class: "measurement"
    accuracy_decimals: 1

This really saved me. A million thanks!