I2C bus failed on multiple devices

ESPHome
1

Hey,

I have a bunch of ESPHome devices around my house measuring the temperatures in the different rooms.
A few days ago (I think it started on 4.12.) suddenly my heating got very confused. After checking I found one of my nodes not sending temperature anymore. I checked and found that all I2C devices where missing (htu21d, bh1750, bme680, spg40).
In the logs is the this:

[10:19:52.401][C][i2c.idf:081]: I2C Bus:
[10:19:52.407][C][i2c.idf:082]:   SDA Pin: GPIO21
[10:19:52.407][C][i2c.idf:082]:   SCL Pin: GPIO22
[10:19:52.407][C][i2c.idf:082]:   Frequency: 50000 Hz
[10:19:52.409][C][i2c.idf:092]:   Recovery: bus successfully recovered
[10:19:52.410][C][i2c.idf:102]: Results from bus scan:
[10:19:52.464][C][i2c.idf:104]: Found no devices

followed by obvious communication failed for those sensors. I unmounted the sensor from the ceiling, checked all connections on the workbench and after bootup got all sensors reporting good values.
Now after another day it is again not finding anything and also a second node having the exact same problem.
I think having two nodes with exact the same hardware problem is possible, but not very likely. Does maybe someone has an idea what might be happening here?

Thanks in advance,
4nduril

For completeness the config for one of those nodes:

substitutions:
  devicename: raumthermostat-wohnzimmer
  upper_devicename: Wohnzimmer
  board: esp32dev
  pin_movement: "23"
  T_offset: "-2"

esphome:
  name: $devicename
  friendly_name: Raumthermostat Wohnzimmer

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

# Enable logging
logger:

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

ota:
  password: "XXXXX"
  platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  min_auth_mode: WPA2

  # Optional manual IP
  manual_ip:
    static_ip: 192.168.39.46
    gateway: 192.168.38.1
    subnet: 255.255.254.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Raumthermostat-Wohnzimmer"
    password: "fHxedLOTOewu"

captive_portal:


esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

i2c:
  scan: true
  
sensor:
  - platform: htu21d
    update_interval: 15s
    temperature:
      name: "Temperatur ${upper_devicename}"
      filters:
        - offset: ${T_offset}
        - or:
          - throttle: 5min
          - delta: 0.3
    humidity:
      name: "Luftfeuchtigkeit ${upper_devicename}"
      accuracy_decimals: 0
      filters:
        - or:
          - throttle: 5min
          - delta: 5.0
  - platform: bh1750
    name: "Helligkeit ${upper_devicename}"
    accuracy_decimals: 1
    update_interval: 2s
    filters:
      - or:
        - throttle: 5min
        - delta: 2.0
#  this one does not have sgp40
#  - platform: sgp4x
#    voc:
#      name: "VOC  ${upper_devicename}"
#      icon: mdi:air-filter
  - platform: bme680
    temperature:
      name: "BME680 Temperature"
      oversampling: 16x
    pressure:
      name: "BME680 Pressure"
    humidity:
      name: "BME680 Humidity"
    gas_resistance:
      name: "BME680 Gas Resistance"
    address: 0x77
    update_interval: 60s

binary_sensor:
  - platform: gpio
    pin:
      number: ${pin_movement}
      mode:
        input: true
        pulldown: true
    name: "Bewegungsmelder ${upper_devicename}"
    device_class: motion
2

I found Ic2 doesn’t work well with bluetooth proxy. I tried it on multiple esp32 and couldn’t get it stable on any. BT proxy uses alot of the resources.

3

Try to catch what you get on logs just before i2c fails.

4

Does having captive portal still cause web server also to be added in?

5

Well it was working well for many months or years and still ist on about 5 other nodes (mixed 8622 and 32). I will try without ble tracked, but that feature was the reason to use esp32 in the first place…

6

What type of 8266 have you got that uses bluetooth?

7

I don’t think so, just essential http server core.

8

The 8622 don’t have BT, that’s why I changed to use 32 because I like that BLE tracking of our phones

Deactivating BLE did not bring I2C back…

9

How are sensors wired/powered?
Any changes of oxidation on connections? Some sensor powered at 5V with pullups on board? Long sensor wiring next to power lines?

10

Yes I know 8266 don’t have BT. You introduced that you were using 8266 after the original post but included only the code for ESP32. Please understand it’s confusing/frustrating when you add in things like this afterwards.
Again you said you were going to try without BLE tracked. You didn’t make it clear if you removed bluetooth proxy lines as well. I just assumed you did.
Your log suggests Ic2 is scanning but didn’t find your BME280.
First I would say is physically check that they are in electrical connection with the ESP32 and the BME680. Loose wiring/dry solder joints are a very common problem.

Second then from the example in esphome as you are using 2 i2c devices set an id from each device.

# Example configuration entry
i2c:
  - id: bus_a
    sda: GPIOXX
    scl: GPIOXX
    scan: true
  - id: bus_b
    sda: GPIOXX
    scl: GPIOXX
    scan: true
# Sensors should be specified as follows
sensor:
  - platform: bme680
    i2c_id: bus_b
    address: 0x76
# ...

A problem I found from using BME280 that they would sometimes switch addresses and I had to solder a wire from VCC to SD0 to get the address 0x77. 280 could also change from I2c to SPI and you could prevent that by connecting CSB to VCC. Don’t know if the 680 suffer a similar problem.

11

What (if anything) changed on that day?
Did you perhaps update the devices with new firmware and/or a new version of esphome?

If nothing changed on the firmware or hardware side, that likely indicates a sensors/wiring failure.

The log is explicitly telling you it is not seeing any sensors. That can happen if the pullups stopped doing their job.

If you didn’t change the firmware and it was working fine before, it likely is the sensors or wiring.

If I were debugging this I would:

  1. Get a spare device and verify the firmware works on it for i2c with the sensors from the device that is not working.
  2. Try the bad esp with other i2c sensors to see if that works.

It does seem odd that you have temperature sensors on the ceiling. It is typically warmer there.

Lastly, you need to think about what your control system does when something it expects to be there isn’t. Or, if a sensor is returning data that is not correct. I use DS18B20 sensors in freeze protection systems. The standard libraries for them do a fine job for normal conditions, but not so good for certain HW faults. If the power pin is degraded, the sensor will return bad results (typically very high temperature). If the data pin is shorted to ground, the CRC check will not be able tell the data is bad and report 0° C. At some point, something will fail. The standard of “failure is not an option” will likely not serve you well.