ESPHome drops Dallas temp sensor after update

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

There is an open issue:

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.

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:

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.

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.

Cable capacitance is the killer for oneWire data bus.

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

Ctot = 1 / (1/CS + 1/CZ)

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

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
1 Like

Nice work, solved it for me!

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

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.

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

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
2 Likes

This really saved me. A million thanks!