SHT3xD failed communication when I2C frequency >50-100kHz using esp-idf but works well over this frequency with arduino framework

[alexruffell]

The problem

I am converting all my ESP nodes from Arduino to ESP-IDF and ran into an unexpected issue with the SHT3xD sensor. The issue is present on all my nodes that use that sensor and across multiple brands and implementations of the sensor thus likely excluding a hardware issue.

With the default Arduino framework, I can set the i2c frequency to 400khz (to eliminate warnings of a blocking component) and the SHT3xD sensor works perfectly. If I change the framework to esp-idf, the sensor fails to communicate unless the frequency is at the default 50khz, but in a few cases I have been able to set it to 100khz, even 150khz, but it fails at 200khz. The exact cutoff may depend on what else is happening on the i2c bus, or the combination of other devices on the bus. On the 2 nodes I used for testing, I verified the pullup resistors to be appropriate (measured both connected and disconnected).

I have verified this issue with all esphome releases going back to 2023.7 (latest for each month) and it persists.

Which version of ESPHome has the issue?

2023.12.5

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

No response

Component causing the issue

SHT3xD / i2c

Example YAML snippet

This is a work in progress on a project I just started but easier to share than the node I discovered this issue with that has many more sensors, including an OLED display which was the main reason I really needed the 400khz i2c frequency. Either way, the issue shows up with this simpler node as well:

substitutions:
  devicename: downstairs-hvac
  devicename_no_dashes: downstairs_hvac
  friendly_devicename: "Downstairs HVAC"
  device_description: "Downstairs HVAC"
  update_interval_s: "20s"
  update_interval_wifi: "120s"
  temperature_calibration: "0.0"
  humidity_calibration: "0.0"

esphome:
  name: ${devicename}
  comment: ${device_description}
  friendly_name: ${friendly_devicename}

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

wifi:
  ssid: !secret iot_wifi_ssid
  password: !secret iot_wifi_password
  power_save_mode: none

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${devicename}"
    password: !secret iot_wifi_password

#Faster than DHCP. Also use if can't reach because of name change
  manual_ip:
    static_ip: 10.1.3.202
    gateway: 10.1.2.1
    subnet: 255.255.254.0
    dns1: 10.1.0.50
    dns2: 10.1.0.51

#Manually override what address to use to connect to the ESP.
#Defaults to auto-generated value. Example, if you have changed your
#static IP and want to flash OTA to the previously configured IP address.
  use_address: 10.1.3.202

logger:
#    baud_rate: 0 #disabled

# Enable Home Assistant API
api:
  encryption:
    key: "redacted"

ota:

web_server:
  port: 80
  include_internal: true

# Sync time with Home Assistant
time:
  - platform: homeassistant
    id: ha_time

i2c:
  - id: bus_a
    sda: 21
    scl: 22
    scan: true
    frequency: 400khz

#Configuration entry for 18B20 sensor
dallas:
  - pin: 27
    update_interval: ${update_interval_s}

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "IP"
      icon: "mdi:ip-outline"
      update_interval: ${update_interval_wifi}
    ssid:
      name: "SSID"
      icon: "mdi:wifi-settings"
      update_interval: ${update_interval_wifi}
    bssid:
      name: "BSSID"
      icon: "mdi:wifi-settings"
      update_interval: ${update_interval_wifi}
    mac_address:
      name: "MAC"
      icon: "mdi:network-outline"
    scan_results:
      name: "Wifi Scan"
      icon: "mdi:wifi-refresh"
      disabled_by_default: true

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: ${update_interval_wifi}
    device_class: signal_strength

  - platform: sht3xd
    i2c_id: bus_a
    address: 0x45
    temperature:
      id: temp
      name: "Temperature"
      filters:
        - lambda: return x + ${temperature_calibration};
    humidity:
      id: humidity
      name: "Humidity"
      filters:
        - lambda: return x + ${humidity_calibration};
    update_interval: ${update_interval_s}

  - platform: dallas
    address: 0xd9000000176c9b28
    name: "Return Air Temperature"
    id: return_air
    accuracy_decimals: 1

  - platform: dallas
    address: 0x6600000016695728
    name: "Supply Air Temperature"
    id: supply_air
    accuracy_decimals: 1

  - platform: template
    name: "Air Temperature Delta"
    id: air_temperature_delta
    lambda: 'return (id(supply_air).state - id(return_air).state);'
    device_class: temperature
    unit_of_measurement: "°C"
    state_class: "measurement"
    accuracy_decimals: 1

binary_sensor:
  - platform: status
    name: "Connection Status"
    id: connection_status
    entity_category: diagnostic

  - platform: gpio
    pin:
      number: 13
      inverted: true
      mode:
        input: true
        pullup: true
    name: "Water Sensor"
    id: water_sensor

switch:
  - platform: restart
    name: "Restart"

button:
  - platform: safe_mode
    name: "Restart (Safe Mode)"

### Anything in the logs that might be useful for us?

_No response_

### Additional information

_No response_

[ronnieSVK]

Same issue here. I would like to migrate with all my devices to esp-idf framework, but i encontered this issue also. Was hoping that todays update 2024.4 fixes this issue, but sadly not. Waiting for solution

[Sandman224]

Mine just stopped working with the 2024.4 update. Super strange.

[mrtoy-me]

@alexruffell @ronnieSVK @Sandman224 sorry to ping you direct but trying to fix issue with 2024.4.0 and might help with this issue - works fine on my sensor on idf and arduino with default i2c frequency.

Does anyone you have time to test this on your sensor... before I submit PR Use following yaml to reference my proposed change:

external_components: source: type: git url: https://github.com/mrtoy-me/esphome-my-components ref: main components: [ sht3xd ]

[ronnieSVK]

Hi @mrtoy-me ,

thank you for you willingness and contribution. Before i rework my code, i just want to tell, that "default" frequency is not what makes us issues. The problem is with frequency anything higher then the default (50khz), which we (of course) would like to use if the end device supports it. In this case i2c SHT3xD support speeds above what ESP32 is capable of, so we would like to set a 400-800khz bus speed. Are those settings please also allright for your external component ?

Thank you very much !

[mrtoy-me]

@ronnieSVK Sorry I mis-read the original post... I just tried SHT31D on the my updated SHT3xD component, same issue - works ok at 50kHz and 100kHz but at 200kHz it fails to read serial number (I added some error codes so know where it is failing). Interestingly, I also tested a SHT85 using same component and it worked up to 200KHz. If I connect both sensors, only works up to 100kHz. I suspect the limitation is related to either i2c or sensirion_common components that look after the i2c comms.

[ronnieSVK]

Hi @mrtoy-me ,

thank you for your quick response. Honestly, im unable to determine so deeply what the issue really is, but at least we have couple of informations collected. Also, one of the most important thing is, that is related to FRAMEWORK. With "arduino", you can config for topic related devices "whatever you want" and it works. Since ESPHome is and will be now more focused to esp-idf, i made this change also and encountered the mentioned issues. Sadly im unable to debug or correct those issues, but i can at least provide feedback :/

Once again, thank you very much for your activities, well appreciated !

[alexruffell]

@mrtoy-me I tested your external component with the arduino framework and the SHT31-F works fine at 400kHz just as it does without your component. I then tested your external component with the esp-idf framework and it failed, just as it does without the external component. In other words, your external component does not appear to affect this issue. I did see the error stating that it failed to read the serial number. This system has another i2c device (sdp3x) that keeps working even when the SHT31-F fails.

I then checked another node that uses the SHT31-F sensor and it was compiled using the esp-idf framework and the i2c bus was set at 200kHz. I tried increasing the bus speed to 400kHz and surprisingly it still works. This node only has one i2c sensor. The two nodes use different ESP32 boards... this one is a lolin_s2_mini and the one above is a nodemcu-32s. I am wondering whether hardware capability, pins used, MCU generation have something to do with the issue... but how does that reconcile with the fact both work on the arduino framework at the higher i2c bus frequency?

[ronnieSVK]

Hey guys,

just to add, im running also NODEMCU-32 or correctly "DEV-KIT-1". Made couple of projects using this board, so i dont think it has something to do with HW, especially if (as you mentioned also) with arduino framework works everything great. I switched via recommended way (cable) from arduino to esp.idf because of different partitions, and the issue immediately appeared. Since this is a test device, i can try anything. I have attached two devices to i2c (display and sht), tested only with one device, tested with two separate i2c buses, default i2c pins, custom,..etc. :/

[alexruffell]

@ronnieSVK I can't figure out what it is, but when I do my tests the results seem similar but not fully consistent. Also, at times I see the sensor work then once I reset it, it no longer works. To try to minimize compiler related issues, I always click on "Clean Build Files" then I compile and install.

@mrtoy-me Did you just make changes to the component? It is now working on my nodemcu-32s node with i2c frequency set to 400kHz and esp-idf framework. If you did not make changes, then it is another case of inconsistent results between tests...

Edit: Github shows a commit 2hrs ago, and my post above stating it did not work was 2hrs ago so there is a chance I was testing with the version you committed prior to that, and now I am testing with your latest version. I'll repeat my tests to see if all systems work with your component enabled.

[ronnieSVK]

Im back with another strange behaviour and knowledges: Just to let you know - to understand, im testing a multifunctional device, which involves besides other components also : THERMOSTAT = SHT for measuring, DISPLAY to show values, ROTATE ENCODER to set the values

First step : ill added custom component from @mrtoy-me (which seems to be really updated after our last discussion here, as you @alexruffell wrote ) , flashed into ESP32 with i2c bus set to 400/800khz, the device booted, and everything SEEMS to be worked ! No error messages in logs, no "component took too long to respond..." messages, values from SHT was visible in logs, also on display Next step : ESP32 power ON/OFF, SHT Error

[sht3xd:055]:   Error reading serial number
[E][sht3xd:064]:   Communication with SHT3xD failed!
[E][component:082]:   Component sht3xd.sensor is marked FAILED

Second step : removed the custom component, and flashed back the previous - initial code. The result was exactly the same as in FIRST STEP ! So it worked "for the eye". Next step : i would like to add web_server, to toggle the thermostat manually, just to see how it behaves, but after restart ive got again, different error message as with custom component :

[E][sht3xd:040]:   Communication with SHT3xD failed!
[E][component:082]:   Component sht3xd.sensor is marked FAILED

Honestly, i never encountered with ESPHome such mystery !

[mrtoy-me]

Hi @ronnieSVK and @alexruffell

I may have a solution for you - not sure the cause but it seems like a timing issue with esp-idf (maybe it is faster than arduino). The errors occur in setup - primarily reading serial number. I think that is fixed but I have made it a warning now rather than failing the component. Failure to setup the heater though will still fail the component but I have added quite a bit of new debug messages and also confirm the heater was set.

My SHT31D (newer adafruit board) and SHT85 are working fine on esp-idf with i2c 800kHz both on the same i2c bus.

If it works ok in your tests, it would need to do more refinement (and maybe testing) before I submit a PR and I will not have a chance to get back to it for several weeks.

You can try it out with the following yaml:

external_components:
   - source:
        type: git
        url: https://github.com/mrtoy-me/esphome-components-test
     components: [ sht3xd ]

[Sandman224]

Hi @ronnieSVK and @alexruffell

I may have a solution for you - not sure the cause but it seems like a timing issue with esp-idf (maybe it is faster than arduino). The errors occur in setup - primarily reading serial number. I think that is fixed but I have made it a warning now rather than failing the component. Failure to setup the heater though will still fail the component but I have added quite a bit of new debug messages and also confirm the heater was set.

My SHT31D (newer adafruit board) and SHT85 are working fine on esp-idf with i2c 800kHz both on the same i2c bus.

If it works ok in your tests, it would need to do more refinement (and maybe testing) before I submit a PR and I will not have a chance to get back to it for several weeks.

You can try it out with the following yaml:

external_components:
   - source:
        type: git
        url: https://github.com/mrtoy-me/esphome-components-test
     components: [ sht3xd ]

It seems to work perfectly for me. I have two esphome projects with the sensor that now seem to work. Ill keep you posted if there are any issues but so far it has been working for 24hrs.

[alexruffell]

I need some time to do some testing as my preliminary results are inconsistent as if the component stays regardless of me commenting it out. What I want to try is compiling and uploading from both my test and production instances of HA where the test system never downloaded any of the components. Or... I can try to delete the folder where the component is stored when compiling the version without. My issue is that whether I include the external component or not, everything seems to work at high i2c bus frequency... which should not be the case when compiling without.

[alexruffell]

@mrtoy-me - I have 5 nodes that use an SHT3XD sensor so I ran the following test:

• I configured all nodes to use the esp-idf framework
• I configured all nodes to use an 800kHz i2c bus frequency
• I compiled each node on a test system where I never downloaded your component, and without your component referenced in the YAML

Of the 5 nodes, the 2 that had more than one i2c device on the same bus failed. The remaining 3 nodes, with just the SHT3XD on the i2c bus worked even without your component.

I then added your component to the 2 that failed on my production system, compiled and they work!

I repeated the tests and they were consistent in that only the nodes with more than one i2c device failed if the i2c frequency was over ~200kHz along with using the esp-idf framework. Prior to your component, a fix was to reduce frequency even down to 50kHz and/or change to the arduino framework.

I'd say you fixed the issue! Thank you!

[paolapersico1]

external_components:

• source: type: git url: https://github.com/mrtoy-me/esphome-components-test components: [ sht3xd ]

it started working fine again with this fix also on my esp8266 esp01_1m board with sht30 sensor. Thanks @mrtoy-me!

[mrtoy-me]

@alexruffell

I repeated the tests and they were consistent in that only the nodes with more than one i2c device failed if the i2c frequency was over ~200kHz along with using the esp-idf framework. Prior to your component, a fix was to reduce frequency even down to 50kHz and/or change to the arduino framework.

For above, just confirming I understand right - you are getting issues with more than one sht3xd on i2c @800kHz esp-idf ?

could you post the logs, so I know what the failure is. Thanks a lot, for your help testing.

[alexruffell]

@mrtoy-me - No, the sht3xd was only failing on nodes that had 2 i2c devices with the bus set at 800kHz and the framework set at esp-idf. By using your component on those nodes, the problem is fixed.

On the other nodes that only had a single i2c device (the sht3xd), I had no issues using esp-idf and an i2c bus frequency of 800kHz even without your component.

Does this match all the others on this thread? Did the nodes failing have more than one i2c device on them?

[mrtoy-me]

@mrtoy-me - No, the sht3xd was only failing on nodes that had 2 i2c devices with the bus set at 800kHz and the framework set at esp-idf. By using your component on those nodes, the problem is fixed.

On the other nodes that only had a single i2c device (the sht3xd), I had no issues using esp-idf and an i2c bus frequency of 800kHz even without your component.

Does this match all the others on this thread? Did the nodes failing have more than one i2c device on them?

When you say 2 i2c devices on the bus - is that more than one sht3xd or 1 sht3xd with other i2c devices? Debug logs will show me what you mean by failed. Thanks

[ronnieSVK]

Hi guys ! Ill tested day or two ago the "latest revision" of custom component, but somehow it acts strange for me. The message about turned off "false" heater appeared-so i assume i had really the latest version of component since i didnt noticed this message till now, everything worked (same as with previous revisions), but it cannot survived reboot. So also the same as till now. Strange is, that the device behaves like this, even if a remove the custom component. So it works till first reboot. I will give tomorrow another test, just to have clear, fresh and valid results and i also backup the log outputs. Just to clarify my usecase once again, i have TWO devices (sht3x and display) on ONE i2c bus (running at 800khz).

Till tomorrow... and thank you once again for this huge and quick activity and contribution ! It is really fantastic to cooperate with such great and talented people !

[mrtoy-me]

I made a few changes to the test sht3xd component in https://github.com/mrtoy-me/esphome-components-test

1. seemed like a few people needed to reboot - so I have added some initial code to start at a known sensor state
2. I have removed all warnings and fails in setup so essentially it tries all the setup but continues to read sensor even if there are setup errors - this will help me understand what errors are occurring
3. I have added extra debug code with a setup status message giving a code number which will tell me read/writes in setup have errors.

So.... If you run the new version of test component -I really need the "Setup status code: 0x" number and any debug messages (they usually start with "Failed...". That will allow me to track down what might be going on and remedy.

I will try not to make too many updates to the test component but it a bit inevitable if there are still errors. Note I have not been able to run the new test component on a sht3xd myself but the code I have added I have used before in my testing.

Thanks again for anyone who does testing :)

[jfurtner]

@mrtoy-me Thanks for the work on this!

I made a few changes to the test sht3xd component in https://github.com/mrtoy-me/esphome-components-test

FYI this version throws compilation errors:

src/esphome/components/sht3xd/sht3xd.cpp: In member function 'virtual void esphome::sht3xd::SHT3XDComponent::setup()':
src/esphome/components/sht3xd/sht3xd.cpp:31:11: error: 'class esphome::sht3xd::SHT3XDComponent' has no member named 'error_code_'
   31 |     this->error_code_ = WRITE_BREAK_FAILED;
      |           ^~~~~~~~~~~
src/esphome/components/sht3xd/sht3xd.cpp:31:25: error: 'WRITE_BREAK_FAILED' was not declared in this scope; did you mean 'WRITE_CLEAR_FAILED'?
   31 |     this->error_code_ = WRITE_BREAK_FAILED;
      |                         ^~~~~~~~~~~~~~~~~~
      |                         WRITE_CLEAR_FAILED
src/esphome/components/sht3xd/sht3xd.cpp:38:11: error: 'class esphome::sht3xd::SHT3XDComponent' has no member named 'error_code_'
   38 |     this->error_code_ = WRITE_SOFT_RESET_FAILED;
      |           ^~~~~~~~~~~
src/esphome/components/sht3xd/sht3xd.cpp:38:25: error: 'WRITE_SOFT_RESET_FAILED' was not declared in this scope
   38 |     this->error_code_ = WRITE_SOFT_RESET_FAILED;
      |                         ^~~~~~~~~~~~~~~~~~~~~~~
*** [.pioenvs/airgradient-downstairs/src/esphome/components/sht3xd/sht3xd.cpp.o] Error 1

Reverting to the last commit works. I haven't tried to pull the component down and debug the code yet.

For anyone else - here's the external_components block with the explicit reference to the commit.

external_components:
   - source:
        type: git
        url: https://github.com/mrtoy-me/esphome-components-test
        ref: 14aeb0781eed158d6c1c58b39c4ceabd6a81797a
     components: [ sht3xd ]

[mrtoy-me]

Sorry about that - I am remote and I did compile so not sure what happened. Should be fixed now and compiled for me but could not run as I am remote.

New commit ref: 6d2d4f4673a74bb58e4f7caf1a2d22d57d916b12

Thanks

[alexruffell]

@mrtoy-me I recompiled the two nodes that have multiple i2c devices that don't run unless I use your component and they both still work perfectly. The only thing I noticed is an extra debug message stating Setup status code: 0000

[mrtoy-me]

That's great news - the error code of 0000 indicates that each read/write in the setup worked with no errors. Thanks.

[jfurtner]

Works for me too now. Thanks @mrtoy-me!

[alexruffell]

@mrtoy-me I did all my testing paying attention to immediate failures of the sensor, however I just realised that the various nodes I have been finding down were actually just sht3xd sensors that became unavailable after x amount of time. I will test your component on those too (I did test it already but did not leave it on those nodes since they were working fine immediately after boot) on a longer term basis to see 8f those nodes stop failing. My question is whether the issues you fixes only happen upon setup or could happen later during run time, in which case it may address what I am seeing.

[ronnieSVK]

Hi guys,

im sorry for the delay... Tested out today, minute ago the custom component, commit "ref:6d2d4f4673a74bb58e4f7caf1a2d22d57d916b12". I have no idea what is happening with my devices, but ill get the same results. After flashing is everything working, but it still doesnt survive the reboot for me. It acts everytime same, so with/without custom code. Can you please review the following parts of the code, since im out of ideas... Thank you !

esphome:
  name: esphome-web-95f614
  friendly_name: ESP32 Test Board

external_components:
   - source:
      type: git
      url: https://github.com/mrtoy-me/esphome-my-components
      ref: 6d2d4f4673a74bb58e4f7caf1a2d22d57d916b12
    components: [ sht3xd ]

esp32:
  board: esp32dev
  framework:
    type: esp-idf

sensor:
  - platform: sht3xd
    temperature:
      name: "ESP32_Test_Board_Temperature"
      id: internal_temperature
    humidity:
      name: "ESP32_Test_Board_Humidity"
      id: internal_humidity
    address: 0x45
    i2c_id: bus_1
    update_interval: 5s

Log output after reboot :

[21:49:11][D][sht3xd:055]: Error reading serial number [21:49:11][E][sht3xd:064]: Communication with SHT3xD failed! [21:49:11][E][component:082]: Component sht3xd.sensor is marked FAILED

[mrtoy-me]

@ronnieSVK

GitHub URL is not right one

Use: url: https://github.com/mrtoy-me/esphome-components-test

[mrtoy-me]

@alexruffell The changes I made only affect setup. I have not changed update code other than add extra debug messages. So I am interested in longer term running in what debug messages you might get. In my testing getting sensor values worked fine at 800kHz with idf.

[alexruffell]

@mrtoy-me - I found 4 more nodes that used more than one i2c sensor including the sht3xd. They were somewhat working because I either had not specified an i2c frequency or I had set it to 100kHz. Either way, every so often I would find the nodes in what appeared a crashed state (I had not put any thought into it though as clicking restart always fixed it so couldn't be crashed!). I came to realize that those nodes all use an ENV III sensor from M5Stack that includes two i2c sensors... one of which is the sht3xd so your fix should take care of the issue.

I now have a total of 6 nodes that are working thanks to your fix. I also set i2c frequency on all 6 nodes at 800kHz since it now works :). I'll keep monitoring and update you if there are any issues.

[ronnieSVK]

@mrtoy-me

GitHub URL is not right one

Use: url: https://github.com/mrtoy-me/esphome-components-test

Thanks mate, i overlooked the url... Hereby i CONFIRM that the component is WORKING, also after reboot ! i2c bus running at 800kHz, hooked SHT and SSD1306/SH1106 display on same bus, no issues so far !

[C][sht3xd:081]: SHT3xD:
[10:03:18][D][sht3xd:106]:   Setup status code: 0000
[10:03:18][D][sht3xd:109]:   Serial Number: 0x13F3C165
[10:03:18][D][sht3xd:111]:   Heater Enabled: false
[10:03:18][D][sht3xd:116]:   Heater Confirmed: DISABLED

Thank you very much !

Can i contribute further somehow ? Should i let run the device (the poject is already in testing phase so i can let it turned on and check...)

Thank once again !

[mrtoy-me]

Thanks @ronnieSVK

After you flashed the firmware - did you need to turn the power off to the SHT and then on OR did it work after flashing?

Yes if you could it running for a day or so and let me know all is ok.

When I get time to tidy up what I have done, it would be great if you could help by doing a final test before I submit the PR.

Thanks

[ronnieSVK]

@mrtoy-me Thank you mate for your work !

After you flashed the firmware - did you need to turn the power off to the SHT and then on OR did it work after flashing? NO. For me it was working immediately after compiling and flashing (as always), even with the newest revision of your custom component. The issue was after power off, when the component failed. This case is seems to be solved. Im running thermostat component on this device as mentioned above, i hear the relays "clicking" depending on thermostat values, the board works. I I let it run of course and will report if some failure appears !

Thanks for everything !

[ronnieSVK]

Update @mrtoy-me : I know such messages should be only "informative", however i think for i2c device running on 800khz bus speed shouldnt such messages appear:

[19:02:45][W][component:237]: Component sht3xd.sensor took a long time for an operation (52 ms).
[19:02:45][W][component:238]: Components should block for at most 30 ms.

Thank you !

[alexruffell]

@mrtoy-me - Is the fix for the sht3xd included in ESPHome 2024.4.2 the latest one? I was removing the external component and recompiling but the nodes are failing and I don't see the extra Setup status code: debugging message.

Edit: @mrtoy-me - Just saw your comment on #6592 stating that #5303 would likely be ready for May.

@digiblur - saw your comment on #6592 - if you are still having issues, try adding the newer component @mrtoy-me is finalizing as the one released today does not fix all of the issues. BTW, great youtube videos!

external_components:
  - source:
      type: git
      url: https://github.com/mrtoy-me/esphome-components-test
      ref: main
    components: [ sht3xd ]

[digiblur]

@digiblur - saw your comment on #6592 - if you are still having issues, try adding the newer component @mrtoy-me is finalizing as the one released today does not fix all of the issues. BTW, great youtube videos!

Thanks! Been working well in the latest stable of esphome. No sensor dropout issues anymore. Shower vent and light automation kicking right along doing all the things.

[mrtoy-me]

@alexruffell @ronnieSVK @jfurtner @paolapersico1

Ok I have something new and easy for you to try ... works on my two sensors with ESPHome 2024.4.2 IDF @800kHz Pretty happy with this solution :) Make sure you remove/comment out any external_components yaml to my github component so the ESPHome 2024.4.2 component is used. Then to your i2c yaml add "timeout: 10ms". That's it.

for example:

i2c:
  sda: 23
  scl: 22
  scan: true
  frequency: 800khz
  id: bus_a
  timeout: 10ms

Background - the i2c timeout option was added no long ago and when I read that it was created because of clock-stretching issues with a sensor running on IDF - the SHT3xd uses clock stretching register on startup and what I had seen in testing were timing issues. Then the big difference - Arduino has a default 50ms i2c timeout on esp32 and IDF has default 100us i2c timeout on esp32. So with the new timeout option - you can extend the IDF i2c timeout - nice.

Let me know how you go... if you have success I will do a PR to update the SHT3xd docs.

[alexruffell]

@mrtoy-me - I made the changes on all 6 nodes that were having the issue and a couple of those that were not (single i2c sensor) and all appear to be working fine.

[paolapersico1]

@mrtoy-me it's working fine for me as well. Thanks!