What are you talking about? You don’t have to connect physically to the devices, it’s just the wording that has changed for OverTheAir-updates in your code. 
1 Like
Thanks for the time saving information! Worked perfectly.
OTA still works, you just need to change the coding to show as per the post above from @HappilyOffensive (thanks again)
At some point in the future, we’ll have moved to code that identifies and corrects changes such as these, and we’ll reminisce about the old days where everything was coded by hand (all while trying to prevent detection from our AI overloads). 
Set up one_wire as above. Compiles and uploads, but I’m getting no data from my DS18B20 sensors after the 2024.6.1 update.
I have 4K7 pull up. Tried cold boot. Any idea what my problem can be.
See log error below.
[W][component:170]: Component dallas_temp.sensor cleared Warning flag
[20:04:39][W][dallas.temp.sensor:074]: ‘Temperature #2’ - reading scratch pad failed bus reset
[20:04:39][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed
[20:04:39][D][sensor:094]: ‘Temperature #2’: Sending state nan °C with 1 decimals of accuracy
[20:04:40][W][component:170]: Component dallas_temp.sensor cleared Warning flag
[20:04:40][W][dallas.temp.sensor:074]: ‘Geyser Temp #1’ - reading scratch pad failed bus reset
[20:04:40][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed
I can’t tell from the warnings. Upload your code? Maybe it’s real but my data looks more jittery after update.
Just looked at git and issues being reported on 1-wire/Dallas changes. Looks like it needs further updates.
Thanks for the update @Ellcon. I will wait and see if an update is released before getting up in the roof crawl space to disconnect about 18 sensors (3 x temperature) for bench testing.
I hope they get it sorted. I still think that EspHome is one of the best things ever invented.
Not sure if you have set your “update_interval:” I see that it must now go under the “- platform: dallas_temp” section in sensors.
1 Like
Thanks for warming the thread up, helped me solve my problem! Much appreciated.
Wondering why you need physical access and or bench testing? Updates are OTA and current issues are obviously software related.
I haven’t used update_interval. There are dozens of sensors in this yaml and they all update together.
True! it is a firmware issue. I remember last year where support for multiple temp sensors on the same GPIO was broken by a EspHome update. The only solutions passed around (to this day) was to lower the pull-up resistor value or put each sensor on a different GPIO etc… Some people claim to have success with these workarounds in the absence of a patch.
I read somewhere that this defaults to 1 min interval for one_wire, if not set.
Post your code. All of my DS18B20 sensors are working fine after the update (between 09:00 and 10:30 in the second day of the screenshot), although these are on ESP8266 devices:
I get this early in the boot-up log
[13:33:42][C][gpio.one_wire:017]: Pin: GPIO15
[13:33:42][W][gpio.one_wire:078]: Found no devices!
Here is my code:
esphome:
name: esphome-web-a79294
friendly_name: Roof Sensors
comment: "ESP32 Roof Sensors"
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: !secret api_encryption_key
ota:
- platform: esphome
password: !secret ota_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# ...
manual_ip:
# Set this to the IP of the ESP
static_ip: 192.168.5.22
# Set this to the IP address of the router. Often ends with .1
gateway: 192.168.5.2
# The subnet of the network. 255.255.255.0 works for most home networks.
subnet: 255.255.255.0
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "ESP32-Roof-Sensors"
password: !secret fallback_password2
captive_portal:
#Temperatur sensor pin dallas
one_wire:
- platform: gpio
pin: GPIO15
# pin: #GPIO15
# number: GPIO15
# mode:
# input: true
# pullup: true
#dallas:
# - pin:
# number: GPIO15
# mode:
# input: true
# pullup: true
# update_interval: 15s
spi:
miso_pin: GPIO19
#mosi_pin: GPIO23
clk_pin: GPIO18
#Motion Sensor:
binary_sensor:
- platform: gpio
pin: 27
name: "Kitchen Motion"
device_class: motion
- platform: gpio
pin: 12
name: "Passage Motion 1"
device_class: motion
- platform: gpio
pin: 13
name: "Passage Motion 2"
device_class: motion
- platform: gpio
pin: 16
name: "Mailbox Flap"
device_class: motion
- platform: gpio
pin: 17
name: "Mailbox Got Mail"
device_class: motion
- platform: gpio
pin: 4
name: "Mailbox Reset"
device_class: motion
- platform: gpio
pin:
number: 3
inverted: true
name: "Doorbell"
device_class: "sound"
- platform: gpio
pin:
number: 35
inverted: true
name: "Geyser Leak"
device_class: "Moisture"
# Water meter sensor
# - platform: pulse_counter
# pin: 2
# unit_of_measurement: 'Lpm'
# id: Water_flow_House
# name: 'Water Flow House'
# filters:
# - multiply: 1
# total:
# unit_of_measurement: 'l'
# name: 'Litres Water'
# filters:
# - multiply: 0.001 # (1/1000 pulses per kWh)
# Totals for water meter
# sensor:
# - platform: integration
# name: "Total Daily House Water"
# sensor: Water_flow_House
# time_unit: min
#Light sensors LDRs
sensor:
- platform: adc
pin: GPIO36 #A0
name: "Kitchen LUX"
update_interval: '1s'
unit_of_measurement: Light
filters:
- multiply: 100
- quantile:
window_size: 7
send_every: 4
send_first_at: 3
quantile: .9
- lambda: return 110.0 - x;
# - lambda: |-
# return (x / 10000.0) * 2000000.0;
- platform: adc
pin: GPIO39
name: "Passage 1 LUX"
update_interval: '1s'
unit_of_measurement: Light
filters:
- multiply: 100
- quantile:
window_size: 7
send_every: 4
send_first_at: 3
quantile: .9
- lambda: return 110.0 - x;
# - lambda: |-
# return (x / 10000.0) * 2000000.0;
- platform: adc
pin: GPIO34
name: "Passage 2 LUX"
update_interval: '1s'
unit_of_measurement: Light
filters:
- multiply: 100
- quantile:
window_size: 7
send_every: 4
send_first_at: 3
quantile: .9
- lambda: return 110.0 - x;
# - lambda: |-
# return (x / 10000.0) * 2000000.0;
- platform: adc
pin: GPIO33
name: "Outside LUX"
update_interval: '1s'
unit_of_measurement: Light
filters:
- multiply: 100
- quantile:
window_size: 7
send_every: 4
send_first_at: 3
quantile: .9
- lambda: return 110.0 - x;
# - lambda: |-
# return (x / 10000.0) * 2000000.0;
# Temerature sensors # 0x3e03009779f0ef28
- platform: dallas_temp #dallas
address: 0x5803079794181228
name: "Geyser Temp #1"
update_interval: 30s
- platform: dallas_temp #dallas
address: 0x7503009779ddd928
name: "Temperature #2"
update_interval: 30s
- platform: dallas_temp #dallas
address: 0x003c01f096c97528
name: "PCB Temperature"
update_interval: 30s
#Geyser K-Type temperature
- platform: max6675
name: "Geyser K-Type Temperature"
cs_pin: GPIO5
update_interval: 30s
3 Likes
Thank you for this post. It took me less than a minute to apply the change and the update worked.
Pointless musings:
While seeing a problem, doing a google search, reading a couple of posts, finding a promising answer, applying the change and seeing it work gives me a certain degree of satisfaction, its also the reason I find it hard to recommend HA to people who don’t enjoy these mini-quests.
I assume that every user of ESPHome will hit this breaking change eventually and will have to do the same thing. I am not sure if the error message could have had a link to article about this. It would have been helpful.
Anyway, thanks again for the very helpful post.
5 Likes
I didn’t mean to infer multiple Dallas sensors, just sensors in general. Have read about the issues but have just one outside temp sensor.
MVP answer here. Ridiculous update and the links to documentation don’t work, and when found manually they don’t really explain the new implementation.
1 Like