Dallas DS18b20 stops working after update of ESPHome 2022.12.0 - 14th December 2022

[emefff]

The problem

All my Dallas DS18b20 stopped working after updating to ESPHome 2022.12.0 - 14th December 2022.

Which version of ESPHome has the issue?

ESPHome 2022.12.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.12.4 (update to 12.5. does not work also!)

What platform are you using?

ESP32

Board

ESP32 nodeMCU

Component causing the issue

dallas (unsure!)

Example YAML snippet

esphome:
  name: esphome--5
  platformio_options:
    board_build.f_cpu: 80000000L 

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: REDACTED

ota:
  password: REDACTED

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true
  output_power: 15dB
  manual_ip:
    static_ip: REDACTED
    gateway: REDACTED
    subnet: REDACTED
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome--5 Fallback Hotspot"
    password: REDACTED

captive_portal:

time:
  - platform: homeassistant
    id: homeassistant_time

dallas:
  - pin: 5
i2c:
  sda: 21
  scl: 22
  scan: false #true
  id: bus_a

# Individual sensors
sensor:
  - platform: dallas
    address: 0xae00000bfeee9428
    name: "Badezimmer Kaltwasser ESP Dallas Temperature"
    accuracy_decimals: 1
    filters:
      - filter_out: nan
      - filter_out: 85.0    

##############deleted the rest#########################

Anything in the logs that might be useful for us?

INFO Reading configuration /config/esphome/esphome--5.yaml...
INFO Detected timezone 'Europe/Vienna'
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Starting log output from REDACTED using esphome API
INFO Successfully connected to REDACTED
[15:11:08][I][app:102]: ESPHome version 2022.12.0 compiled on Dec 14 2022, 15:03:34
[15:11:08][C][status_led:019]: Status LED:
[15:11:08][C][status_led:020]:   Pin: GPIO2
[15:11:08][C][wifi:504]: WiFi:
[15:11:08][C][wifi:362]:   Local MAC: REDACTED
[15:11:08][C][wifi:363]:   SSID: [redacted]
[15:11:08][C][wifi:364]:   IP Address: REDACTED
[15:11:08][C][wifi:366]:   BSSID: [redacted]
[15:11:08][C][wifi:367]:   Hostname: 'esphome--5'
[15:11:08][C][wifi:369]:   Signal strength: -57 dB ▂▄▆█
[15:11:08][C][wifi:373]:   Channel: 6
[15:11:08][C][wifi:374]:   Subnet: REDACTED
[15:11:08][C][wifi:375]:   Gateway: REDACTED
[15:11:08][C][wifi:376]:   DNS1: 0.0.0.0
[15:11:08][C][wifi:377]:   DNS2: 0.0.0.0
[15:11:08][C][logger:293]: Logger:
[15:11:08][C][logger:294]:   Level: DEBUG
[15:11:08][C][logger:295]:   Log Baud Rate: 115200
[15:11:08][C][logger:296]:   Hardware UART: UART0
[15:11:08][C][i2c.arduino:052]: I2C Bus:
[15:11:08][C][i2c.arduino:053]:   SDA Pin: GPIO21
[15:11:08][C][i2c.arduino:054]:   SCL Pin: GPIO22
[15:11:08][C][i2c.arduino:055]:   Frequency: 50000 Hz
[15:11:08][C][i2c.arduino:058]:   Recovery: bus successfully recovered
[15:11:08][C][uptime.sensor:031]: Uptime Sensor 'Badezimmer ESP Uptime'
[15:11:08][C][uptime.sensor:031]:   Device Class: 'duration'
[15:11:08][C][uptime.sensor:031]:   State Class: 'total_increasing'
[15:11:08][C][uptime.sensor:031]:   Unit of Measurement: 'h'
[15:11:08][C][uptime.sensor:031]:   Accuracy Decimals: 1
[15:11:08][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[15:11:08][C][homeassistant.time:010]: Home Assistant Time:
[15:11:08][C][homeassistant.time:011]:   Timezone: 'CET-1CEST,M3.5.0,M10.5.0/3'
[15:11:08][C][dallas.sensor:075]: DallasComponent:
[15:11:08][C][dallas.sensor:076]:   Pin: GPIO5
[15:11:08][C][dallas.sensor:077]:   Update Interval: 60.0s
[15:11:08][W][dallas.sensor:080]:   Found no sensors!
[15:11:08][C][dallas.sensor:089]:   Device 'Badezimmer Kaltwasser ESP Dallas Temperature'
[15:11:08][C][dallas.sensor:089]:     Device Class: 'temperature'
[15:11:08][C][dallas.sensor:089]:     State Class: 'measurement'
[15:11:08][C][dallas.sensor:089]:     Unit of Measurement: '°C'
[15:11:08][C][dallas.sensor:089]:     Accuracy Decimals: 1
[15:11:08][C][dallas.sensor:097]:     Address: 0xae00000bfeee9428
[15:11:08][C][dallas.sensor:098]:     Resolution: 12

############################deleted the rest######################

Additional information

Dallas was by far the most reliable component until now :-(

I will not update my other ESP32 until this is resolved.

[canuckray]

I have encountered the same issue. Upgraded to ESPHome 2022.12.0 this morning, and flashed an update to a NodeMCU-32S. Dallas is no longer working. I commented out the sensor to have the log scan and show me any available sensors, and it reports "Found no sensors!".

[09:48:16][C][dallas.sensor:076]: Pin: GPIO13 [09:48:16][C][dallas.sensor:077]: Update Interval: 60.0s [09:48:16][W][dallas.sensor:080]: Found no sensors!

[stofakiller]

I have the exact same error since the upgrade, no sensors found, i have 3 dallas on that esp. Other sensor mmwave works on that esp

[chris-nite]

Unfortunately my ESPHome flashed Yeelights are not able to connect to the wifi anymore and are offline ever since. I don't have a log yet, but something went wrong there when updating both of these lights. They were working properly before with every esphome-Update.

[edenhaus]

The bug probably exists only on the esp32 and is probably introduced by https://github.com/esphome/esphome/pull/3564/commits/8fd93122545bfbc76a2e7df66a619191e66a5b10 Where the timing of esp32 on arduino framework was reduce from 14 to 12. ~Reverting this change resolved my dallas problems. Before opening an PR can someone else please test it.~

[canuckray]

The bug probably exists only on the esp32 and is probably introduced by esphome/esphome@8fd9312 Where the timing of esp32 on arduino framework was reduce from 14 to 12. Reverting this change resolved my dallas problems. Before opening an PR can someone else please test it.

To make it easy to test include please the following in your config:

external_components:
  - source: github://edenhaus/esphome@test-dallas
    components: [ dallas ]

Sadly, this did not resolve my issue. YAML snippet, for reference:

esp32:
  board: nodemcu-32s
  framework: 
    type: arduino
    version: recommended

external_components:
  - source: github://edenhaus/esphome@test-dallas
    components: [ dallas ]

[randybb]

Never noticed any issue during betatesting. Just reflashed one device with latest dev and it is still the same - works just fine:

[17:21:53][C][dallas.sensor:075]: DallasComponent:
[17:21:53][C][dallas.sensor:076]:   Pin: GPIO32
[17:21:53][C][dallas.sensor:077]:   Update Interval: 60.0s
[17:21:53][D][dallas.sensor:082]:   Found sensors:
[17:21:53][D][dallas.sensor:084]:     0x1701143e35c5aa28
[17:21:53][D][dallas.sensor:084]:     0x7301143f7f57aa28
[17:21:53][D][dallas.sensor:084]:     0xf701143e397faa28
[17:21:53][D][dallas.sensor:084]:     0x5a041750b2c8ff28
[17:21:53][D][dallas.sensor:084]:     0xdb041750eae2ff28
[17:21:53][D][dallas.sensor:084]:     0xb2041750cf1aff28
[17:21:53][D][dallas.sensor:084]:     0x960417517301ff28

@chris-nite are these yeelights singlecore? Because on Xiaomi Mi Bedside Lamp 2 I had such issue...

[emefff]

Puuuh, glad I am not alone on this one :-)

[emefff]

It seems indeed, single-cores are not affected. The log from this updated esp32doit-devkit-v1 is alright (V1 is a SC):

logs_esphome--11_logs.txt

[emefff]

external_components:
  - source: github://edenhaus/esphome@test-dallas
    components: [ dallas ]

does not work for me (board: esp32dev)

[edenhaus]

esphome/esphome@8fd9312

This was the only change in the dallas component. So it probably has something to do with the framework update

[canuckray]

I attempted to force the previous version (2.0.4.... as current is 2.0.5) of Arduino Framework using:

esp32:
  board: nodemcu-32s
  framework: 
    type: arduino
    version: 2.0.4

It compiled and loaded fine, but sadly did not bear fruit. Unless my line of thinking and/or implementation was incorrect.

[emefff]

esp32:
  board: esp32dev
  framework:
    type: arduino
    version: 2.0.4

no luck either

[canuckray]

I tried rolling back the platform version as well...

esp32:
  board: nodemcu-32s
  framework: 
    type: arduino
    version: 2.0.4
    platform_version: 5.1.1

no dice.

[canuckray]

I have since rolled back (restored backup from last night) to ESPHome 2022.11.1 while we await a fix.

This particular ESP32 is running my 3D Enclosure Heater / Cooler (PID Climate), so.... um... temperature sensing is pretty critical.

[edenhaus]

After connecting an oscilloscope I saw that my pullup resistor was to high for a clean signal. Probably with the framework updates and the improved timing in esphome/esphome@8fd9312 the esp is checking the signal earlier than in the old version. At the moment of the signal checking, the signal is still rising and therefore it is not detected correctly.

By decreasing the pullup resistor, the signal is rising quicker and the esp is again detecting the signal correctly. Depending on the your cable length you need to adjust the resistor. (Don't ask me, which is the correct pullup resitor value as I'm not an electrician. I decreased it until the dallas sensor was working again). Similar to https://github.com/esphome/issues/issues/3153

[emefff]

Seriously, you expect people to change thousands of pullup resistors, instead of changing one number? A number that worked before? I have around 40 Dallas sensors in 15 devices. This is not acceptable for me.

[canuckray]

Seriously, you expect people to change thousands of pullup resistors, instead of changing one number? A number that worked before?

@edenhaus is kindly just offering one potential work-around... likely spurred by a desire to help understand root cause and contribute to a potential solution. I'm sure it will be fixed in due time (in code), but we may have to wait patiently. If patience are lacking, there are options - roll back, as I did, or monkey with pull-ups, as @edenhaus suggested above.

[edenhaus]

Seriously, you expect people to change thousands of pullup resistors, instead of changing one number? A number that worked before? I have around 40 Dallas sensors in 15 devices. This is not acceptable for me.

I don't expect nothing. I only are commenting my solution. Only my dallas sensor with more than 30m cable needed a pullup resistor adjustment. My other dallas sensors with 1-3m cable length are working without any problems on 2022.12. I would normaly rollback like @canuckray but I noticed that my backup was not working correctly.

[emefff]

My cable lengths are ~1cm (onboard) up to 3 or 4m. Pullup is always 4.7kohm. Both are affected. The solution must be in the code.

[canuckray]

@emefff can you try setting internal pull-up like this, and see if it works:

dallas:
  pin:
    number: GPIO13  **change to whatever your pin is**
    mode:
        input: true
        pullup: true

an internal pullup in parallel with your external pullup will effectively lower the pullup value, perhaps tipping the scale in your favor and rendering it operable again.

[stofakiller]

I move mine from gpio23 to gpio26, and they are now found and work...

[21:55:34][C][dallas.sensor:076]: Pin: GPIO26 [21:55:34][C][dallas.sensor:077]: Update Interval: 60.0s [21:55:34][D][dallas.sensor:082]: Found sensors:

[emefff]

dallas:
  pin:
    number: GPIO13  **change to whatever your pin is**
    mode:
        input: true
        pullup: true

I just tried, sensors are still not found, sorry. If I remember correctly, it is also kind of risky to use both internal and external pullups at the same time (intermediate voltages possible I think)....but thank you.

[canuckray]

Incidentally, I was able to remedy the issue on my setup by installing a 4.7k pull-up (the internal pull-up won't work because it's ~50k). Also, I used the ESPHome BETA add-on to flash the 2022.12.0 update so that I could go back to 2022.11.1 easily if I wanted.

Interestingly I DIDN'T have a pull-up in my 1-wire circuit previously, and I never had issues. But, as alluded to a few times in this thread, if overall timing has changed (improved) with 2022.12.0, I could simply have ended up on the wrong side of the train tracks here.

[grossqx]

I can confirm, also having this issue since update to 2022.12. Three sensors on one ESP32 stopped working right after flashing. I tried assembling a single sensor on a separate breadboard with a new esp32 board. Also not working. logs_dallas_upload.txt dallas.yaml.txt

[jesserockz]

@emefff I have flashed with basically the same configuration as the PR description. Added a sensor on GPIO5 with a 4.7k pullup and it reads the temperature just fine...

[17:14:37][C][dallas.sensor:075]: DallasComponent:
[17:14:37][C][dallas.sensor:076]:   Pin: GPIO5
[17:14:37][C][dallas.sensor:077]:   Update Interval: 60.0s
[17:14:37][D][dallas.sensor:082]:   Found sensors:
[17:14:37][D][dallas.sensor:084]:     0x7f3ce4f649edf328
[17:14:37][C][dallas.sensor:089]:   Device 'Test Dallas'
[17:14:37][C][dallas.sensor:089]:     Device Class: 'temperature'
[17:14:37][C][dallas.sensor:089]:     State Class: 'measurement'
[17:14:37][C][dallas.sensor:089]:     Unit of Measurement: '°C'
[17:14:37][C][dallas.sensor:089]:     Accuracy Decimals: 1
[17:14:37][C][dallas.sensor:097]:     Address: 0x7f3ce4f649edf328
[17:14:37][C][dallas.sensor:098]:     Resolution: 12

First I tested without this which worked fine...

  platformio_options:
    board_build.f_cpu: 80000000L

[17:13:13][C][dallas.sensor:032]: Setting up DallasComponent...
[17:13:13][W][dallas.sensor:261]: 'Test Dallas' - Scratch pad checksum invalid!

As soon as I added it, the sensor is no longer found.

My guess is changing the CPU speed messes with the timings required for dallas to work correctly?

---

@grossqx I have also tried the config you have posted using GPIO32 with only successful results

[17:17:25][C][dallas.sensor:075]: DallasComponent:
[17:17:25][C][dallas.sensor:076]:   Pin: GPIO32
[17:17:25][C][dallas.sensor:077]:   Update Interval: 60.0s
[17:17:25][D][dallas.sensor:082]:   Found sensors:
[17:17:25][D][dallas.sensor:084]:     0x7f3ce4f649edf328
[17:17:25][C][dallas.sensor:089]:   Device 'Test Dallas'
[17:17:25][C][dallas.sensor:089]:     Device Class: 'temperature'
[17:17:25][C][dallas.sensor:089]:     State Class: 'measurement'
[17:17:25][C][dallas.sensor:089]:     Unit of Measurement: '°C'
[17:17:25][C][dallas.sensor:089]:     Accuracy Decimals: 1
[17:17:25][C][dallas.sensor:097]:     Address: 0x7f3ce4f649edf328
[17:17:25][C][dallas.sensor:098]:     Resolution: 12

[emefff]

@jesserockz Thank you, that solved it for the already updated devices for now (no rolling back, no soldering, 160MHz also works).

Of course, the 80MHz is intentional, I use it in all my ESPs. It consumes less power, which is crucial in battery powered devices (my estimate is, with 240MHz in battery powered devices, runtime will be lowered by 30-40%). In USB-powered devices, it leads to lower MCU temps, which also influence sensors that either measure T or use T for any kind of calibration (I have 10+ USB-powered devices, so their power consumption is noticeable).

So overall, for me personally, it is not an end-all-do-all solution, because I expect Dallas DS18b20 to work with 80 MHz also (other, less popular, one-wire devices may be affected also, we do not know). If it wasn't for WiFi functionality, I would even go to lower CPU speeds in battery powered devices (could be a suggestion: 'WiFi with 40MHz'), especially in the cold weather we are having now.

Is there any chance for this timing value to be changed back to the previous value? Is a 'timing exception' (for lack of a better word) possible for the dallas component?

[jesserockz]

So, the timings were separated for Arduino and ESP-IDF. Arduino updated its GPIO code to use more of the IDF code, and at that point for ESPHome, it was the same. I ended up ripping out the code specific to the Arduino GPIO and always use the ESP-IDF functions directly.

Even if I did not do this, the Arduino timing had to change as they changed the code in the Arduino core for ESP32 and there is not much we can do with that. Unless we stayed on v1.0.6 forever, which is also not feasible.

Reverting is not really an option. Only attempting to get it working with the different CPU speed going forward.

[emefff]

Not a good solution for battery powered devices....

What about a kind of exception for the dallas component?

Is there a possibility to define the different timing in the .yaml? Perhaps in the board definition?

[emefff]

However, in the meantime I tried the following

esphome:
  name: esphome--1
  platformio_options:
    board_build.f_cpu: 81000000L #lower power consumption and less T-influence on other components, was 80MHz before
    #https://github.com/esphome/issues/issues/3909

weirdly enough, this seems to work. I do not expect the power consumption of battery powered devices to be influenced that much, frequency increase is only +1.25%. There seems to be some kind of threshold at 80MHz.

It seems, some have the issue without reduced MCU frequency?

[grossqx]

esphome:
  name: esphome--1
  platformio_options:
    board_build.f_cpu: 81000000L #lower power consumption and less T-influence on other components, was 80MHz before
    #https://github.com/esphome/issues/issues/3909

I have tried this one and it didn't solve the issue in my case. Same exact error (no sensors found, conversion error). I have also tried a totally different dev board, this time based on esp8266 and it also doesn't work.

[grossqx]

So I rolled back to 11.5, but now I can't compile the same config.

INFO Reading configuration /config/esphome/dallas.yaml... INFO Generating C++ source... INFO Compiling app... Can not remove temporary directory /data/dallas/.pioenvs. Please remove it manually to avoid build issues Processing dallas (board: esp32dev; framework: arduino; platform: platformio/espressif32 @ 5.2.0)

Error: Traceback (most recent call last): File "/usr/local/lib/python3.9/dist-packages/platformio/main.py", line 102, in main cli() # pylint: disable=no-value-for-parameter File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1130, in call return self.main(args, kwargs) File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1055, in main rv = self.invoke(ctx) File "/usr/local/lib/python3.9/dist-packages/platformio/cli.py", line 71, in invoke return super().invoke(ctx) File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1657, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1404, in invoke return ctx.invoke(self.callback, ctx.params) File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 760, in invoke return __callback(args, *kwargs) File "/usr/local/lib/python3.9/dist-packages/click/decorators.py", line 26, in new_func return f(get_current_context(), args, **kwargs) File "/usr/local/lib/python3.9/dist-packages/platformio/run/cli.py", line 144, in cli process_env( File "/usr/local/lib/python3.9/dist-packages/platformio/run/cli.py", line 201, in process_env result = {"env": name, "duration": time(), "succeeded": ep.process()} File "/usr/local/lib/python3.9/dist-packages/platformio/run/processor.py", line 83, in process install_project_env_dependencies( File "/usr/local/lib/python3.9/dist-packages/platformio/package/commands/install.py", line 131, in install_project_env_dependencies _install_project_env_platform(project_env, options), File "/usr/local/lib/python3.9/dist-packages/platformio/package/commands/install.py", line 148, in _install_project_env_platform PlatformPackageManager().install( File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/platform.py", line 50, in install pkg = super().install(spec, force=force, skip_dependencies=True) File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/_install.py", line 47, in install self.lock() File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/base.py", line 96, in lock self.ensure_dir_exists(os.path.dirname(self.package_dir)) File "/usr/local/lib/python3.9/dist-packages/platformio/package/manager/base.py", line 127, in ensure_dir_exists os.makedirs(path) File "/usr/lib/python3.9/os.py", line 215, in makedirs makedirs(head, exist_ok=exist_ok) File "/usr/lib/python3.9/os.py", line 225, in makedirs mkdir(name, mode) FileNotFoundError: [Errno 2] No such file or directory: '/data/cache'

============================================================

An unexpected error occurred. Further steps:

• Verify that you have the latest version of PlatformIO using pip install -U platformio command

• Try to find answer in FAQ Troubleshooting section https://docs.platformio.org/page/faq/index.html

• Report this problem to the developers https://github.com/platformio/platformio-core/issues

[trantoriana]

same here.

However, after some flashes with the same settings and reboots it suddenly recognized the dallas devices (i have three) and reads values... most of the time. Still gets the reading error about 50% of the time, but it seems to improve over time as per this graph:

Hope this gets resolved soon.

Trant..

BTW. did try a 2.2k resistor instead of the 4.7K I have, to no avail (I do not have a 3.7k resistor to try), also no resistor did not help.

[trantoriana]

Still a problem in 2022.12.1

[paulius2k]

I am also having issues both with Dallas and Si7021 DHT sensor (https://github.com/esphome/issues/issues/3882) on v2022.12.01

[Zoogara]

Chiming in for same issue on 2022.12.1 - existing Dallas sensor on less than 1m of cable.

[Zoogara]

So I rolled back to 11.5, but now I can't compile the same config.

@grossqx I have same issue - did you ever get a rollback to work?

[paulius2k]

So I rolled back to 11.5, but now I can't compile the same config.

@grossqx I have same issue - did you ever get a rollback to work?

@Zoogara - I can share that in my case only restoration of the standalone ESPHome backup (which I did before upgrading the ESPHome version) worked, NOT when restoring the ESPHome from a nightly partial backup.

[axlFThn]

Got same issue when updating to latest ESPHome image. v2022.12.1 on a ESP32 board, ~10 sensors.

Solution by @emefff with lower CPU clocking worked thou, thnx for that. But great if this can work out of the box, large Dallas networks and timing are difficult even without this. All your efforts highly appreciated!

Best regards, Alexander

[jedney]

Same error here on M5 Stack Pico (ESP32).

platformio_options: board_build.f_cpu: 81000000L

Didn't help.

[trantoriana]

Tested "platformio_options" on olimex esp32 POE also did not work.

[andrea-daru]

I'm experiencing the same issue with Dallas sensor after upgrading to 2022.12.1. After downgrading to 2022.11.1 in homeassistant I encounter the same issue reported by @grossqx . Are there any news?

[grossqx]

@andrea-daru @Zoogara I didn't pursue rollback option. I hope it will get noticed and fixed soon. Any reliable workaround would also be cool. I am ready to provide additional data and do more hardware tests if any new possible solutions emerge.

[logicland]

Everything was working fine till the update, now has the same issue of "Found No Sensors" after updating to v2022.12.1

Dallas cable length is 3m, pull-up is 4.7K as per Dallas Datasheet (5K recommended) this is appears to be the only valid value.

Yet to try changing the GPIO pin.

Tried both default and 80Mhz to no avail, here's the log file:-

INFO Reading configuration /config/esphome/shen-water-bed.yaml... INFO Starting log output from shen-water-bed.local using esphome API INFO Successfully connected to shen-water-bed.local [01:12:25][I][app:102]: ESPHome version 2022.12.1 compiled on Dec 19 2022, 01:06:44

[01:12:25][C][wifi:362]: Local MAC: xxxxxxxxxxxx [01:12:25][C][wifi:363]: SSID: [redacted] [01:12:25][C][wifi:364]: IP Address: xxxxxxxxxxxxx [01:12:25][C][wifi:365]: BSSID: [redacted]

[01:12:25][C][wifi:369]: Signal strength: -71 dB ▂▄▆█ [01:12:25][C][wifi:373]: Channel: 6 [01:12:25][C][wifi:374]: Subnet: 255.255.255.0 [01:12:25][C][wifi:375]: Gateway: xxxxxxxxxx [01:12:25][C][wifi:376]: DNS1: xxxxxxxxxx [01:12:25][C][wifi:377]: DNS2: 0.0.0.0

[01:12:25][C][logger:294]: Level: DEBUG [01:12:25][C][logger:295]: Log Baud Rate: 115200 [01:12:25][C][logger:296]: Hardware UART: UART0

[01:12:25][C][dallas.sensor:076]: Pin: GPIO4 [01:12:25][C][dallas.sensor:077]: Update Interval: 60.0s [01:12:25][W][dallas.sensor:080]: Found no sensors!

[01:12:25][C][dallas.sensor:089]: Device Class: 'temperature' [01:12:25][C][dallas.sensor:089]: State Class: 'measurement' [01:12:25][C][dallas.sensor:089]: Unit of Measurement: '°C' [01:12:25][C][dallas.sensor:089]: Accuracy Decimals: 1 [01:12:25][C][dallas.sensor:097]: Address: 0xf401212f5400e728 [01:12:25][C][dallas.sensor:098]: Resolution: 12 [01:12:25][C][captive_portal:088]: Captive Portal:

[01:12:25][C][mdns:104]: Hostname: shen-water-bed [01:12:25][C][ota:093]: Over-The-Air Updates: [01:12:25][C][ota:094]: Address: shen-water-bed.local:8266 [01:12:25][C][api:138]: API Server: [01:12:25][C][api:139]: Address: shen-water-bed.local:6053 [01:12:25][C][api:143]: Using noise encryption: NO [01:12:39][E][dallas.sensor:112]: Requesting conversion failed [01:12:39][D][sensor:126]: 'Water Bed Temperature': Sending state nan °C with 1 decimals of accuracy

[emefff]

Just for clarification: the 81MHz setting is the lowest frequency that works in my ESPs (I want the freq to be as low as possible for above reasons). It is very likely, that if you can't get your Dallas working with ESP32 at 240MHz (standard freq, no board_build.f_cpu option) you won't get it to work with the board_build.f_cpu option at any setting (any setting can only be with a lower freq and that will have potentially slower timings).

[logicland]

@emeff your comments on timing are accepted, to add changing GPIO# and pull-up value are probably all in vain too. People are desperate to get their devices running.

At the moment the Dallas DS18B20 support looks broken awaiting a software fix. Individual ESP's still working may be explained by hardware tolerances, i.e. timings, thresholds, voltage etc

[ToViNi]

Tried all the above suggestions with no luck. Have both version 2022.3 and 2022.12.1 and can switch between them.
Made a custom component install with the Dallas/onewire source files from 2022.3 in ESP 2022.12.1, Still won't work. That tells me that it must be something else in the framework that changed, and broke the timing, maybe a higher level interrupt?

[logicland]

A little feedback on the hardware which may help. Tried a few things:-

1, Constructed a duplicate system, new WEMOS MINI D1 new Dallas DS18B20 with 3m cable, 4K7 pull-up resistor on GPIO4, and this time the unit worked fine. A portable oscilloscope showed a 480us pulse immediately followed by "Presence Pulse" data as expected.

2, Took the faulty module and hooked up to a 300 Mhz, 100Ms/s LeCroy digital scope. The "Reset Pulse" looked good, nice clean edges, full 3.3V swing, good rise & fall times, pulse-width was on the short side = 484.5us, (spec is 480uS) given the max is 960us (500us would be better) however the sensor never ever responded.

Changing R to 1.8K which speeded-up the trailing edge to 1us, removing the resistor slowed the trailing edge from 2us to 12us (leading edge stayed the same)

3, Transplanted the same (faulty) sensor to an ESP32 (Mini ESP WROOM-32) pulse width increased slightly to 495us i.e. 10us longer, but still no "Presence Pulse" response

Conclusion Given the sensor hasn't worked in 3 different platforms, all Reset Pulses were valid but no "Presence Pulse" responses, confidence is high this sensor has failed, however coincidental this may seem.

It would have been good to re-test the faulty sensor in a known working system, but practically it was difficult to do (only had 1 spare Dallas sensor)

Bottom line, ESPHome version 2022.12.1 appears to work in this instance.

[Zoogara]

Bottom line, ESPHome version 2022.12.1 appears to work in this instance.

Given that the timing (performance) changes in 12.1 only affect ESP32 - I'm not sure what your post is telling us.

Did you test your good sensor on an ESP32? I can't actually tell reading the above.

[logicland]

@Zoogra - sorry I missed the point about only ESP32 as upgraded and a sensor stopped working at that exact same time on an ESP8266 so assumed affected both, my mistake.

No didn't try an ESP32 with a good sensor, but I will when stock arrives on Wed, I'd be happy to run some hardware timing checks again, working or not, however the Reset Pulse at least I can say is valid (PW=495us, 3V3 and edges good)

[jesserockz]

I found a very obscure bug in the ESP32 GPIO code of ESPHome from 14 months ago that went un-noticed until now. Now for some reason dallas works for some people in current ESPHome and some people not as seen in this issue.

I am releasing 2022.12.3 with a GPIO bugfix if you could please test it. If using ESPHome as a Home Assistant addon, I suggest installing the ESPHome beta addon as a second addon which will make it a lot easier to retain your current working version should you need to revert again. The add-ons can be run side-by side just fine.

Please reply back if 2022.12.3 fixes it for you.