ESPHome - device does not boot up when configuring I2C

ESPHome
1

Hey ho,

I am trying to configure a Grove Water Level Sensor using this GitHub link. I am using a Wemos Mini D1.

Now the thing is - as soon as I add I2C and the water sensor, the device randomly does not boot up anymore - actually it more often does not boot than it boots. With not booting I mean that I don’t see the device as connected in ESPHome - when trying to get logs via USB I just see an empty black box where the logs should be, completely no output.

This somehow happens no matter whether the I2C device is attached or not.

Now I am wondering:

  • Does the device only boot when it has found an I2C device? Can I change this?
  • Am I just being stupid and there is something I am completely doing wrong? By now I already tried two sensors, both with the same outcome. Also changing GPIO ports does not help, the outcome seems to be always the same.
  • Why does it sometimes work and sometimes not?

Does anyone maybe have an idea what I could try to solve this issue?

Thank you so much :slight_smile:
Matthias

Configuration:

esphome:
  name: my-wemos
  friendly_name: Test Device
  includes:
    - grove_water_level_sensor.h

debug:
  update_interval: 5s
  
esp8266:
  board: esp01_1m

# Enable logging
logger:
  level: DEBUG

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

ota:
  password: "..."

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "..."
    password: ".."

captive_portal:

i2c:
  sda: 15
  scl: 13
  scan: True
  id: bus_a

sensor:
  - platform: custom
    lambda: |-
      auto my_sensor = new WaterLevelSensor();
      App.register_component(my_sensor);
      return {my_sensor};
    sensors:
      name: "water"
      id: "water"
      unit_of_measurement: "%"
2

That’s the wrong board definition for a Wemos D1 mini. Use:

esp8266:
  board: d1_mini

Also you can’t use GPIO15 as an input. See the table on this page:

1 Like
3

Thank you so much - that sounds exactly like the issue :slight_smile: Will try it out and report back!

4

Thanks again for the answer. I have now changed both port and the board configuration:

esp8266:
  board: d1_mini

i2c:
  sda: GPIO4
  scl: GPIO5
  scan: True
  id: bus_a

Unfortunately, the issue remains:

  • No logs via USB
  • No connection to the wireless network :frowning:

Maybe you have another idea what could be wrong?

Thanks again -.-

Matthias

P.S.: It also does not open the fallback hotspot. So it looks like it does not even get so far …

5

Do you see a serial port created when you connect the device via usb?

6

Try changing the setting to “scan: False” for testing purposes.
I had some ESP32 boards that failed to boot when I2C scan was enabled in the past.

7

Actually the log is completely empty :frowning: So also nothing about a serial port, or maybe it is at a different place?
@rudimarp: Thanks, will try :slight_smile:

8

Try to connect it via USB. Does the PC see an new serial port created?

9

Yes, a serial device appears.

> ls /dev/tty.*
/dev/tty.BLTH                    /dev/tty.BoseNC700HP
/dev/tty.Bluetooth-Incoming-Port /dev/tty.usbserial-1430

/dev/tty.usbserial-1430 seems to be the right one.

Interesting enough, when I open the logs in EspHome and then press “reset” (just discovered it), then I get log output - maybe also due to the now disabled I2C scan?:

[C][wifi:038]: Setting up WiFi...
[C][wifi:039]:   Local MAC: E0:98:06:8E:56:21
[D][wifi:387]: Starting scan...

However, this now makes even less sense. Wifi is configured like the following:

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

The credentials there exist and actually work for another EspHome device …

I am confused …

Matthias

10

More weirdness - when removing all the config it still scans I2C - so installing tells it succeeds, but it is actually still running the old version. I guess I have to reset it somehow …

Edit: And also this is not true. Trying to flash a brand new D1 Mini, I still see the artifacts of I2C. So this seems like EspHome is building something weird…
Edit2: Setting up a brand new EspHome device makes it work again - at least when its empty. As soon as I add I2C, wifi scanning breaks …
Edit3: Manual ip for the rescue. Somehow all of this is a sequence of workarounds which should not exist …

11

There is a ‘known issue’ with i2c and Wifi when using lower i2c frequencies. So add

frequency: 800kHz

to the i2c part of your yaml. The default is 50kHz and that gives a lot of troubles :frowning:

1 Like
12

Schematic?

13

I finally found a solution - I never got this to work with a Wemos D1 Mini, but the same configuration just works with an ESP32. So I will go with that one now … Thanks!

14

Hey @klassm,

I believe I have encountered a very similar issue with the same symptoms - not sure if it had the same root.

I have a “bigger” Wemos board - ESP8266 with a built-in OLED screen connected via I2C to GPIO5+GPIO4 (D1+D2 pins). Never had issues with it.

Everything “worked” on my device until I connected a second I2C device, on a different set of SDA/SCL pins (I initially planned to have 2 I2C buses before learning ESP8266 can support only one).

I assumed that I will just disable the I2C bus that handles the screen and simply assign the I2C bus to different pins in the configuration.
I have selected GPIO15+GPIO13 (D8+D7 pins).

I had failures with booting esp8266 but only when I2C device was physically connected. I managed to boot the board only when the I2C was disconnected.

Thanks to the great article linked by @tom_l (ESP8266 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials) I found out that the the GPIO15 (D8) is special - booting will fail if it is high.

I have reconnected the new I2C device to GPIO5+GPIO4 (D1+D2 pins).

I am using this combination that works for me with both the screen and device on the same bus_a (please note scan: false and frequency: 400kHz)

i2c:
  - id: bus_a
    sda: GPIO5
    scl: GPIO4
    frequency: 400kHz # Missing this causes "Component display took a long time for an operation"
    scan: false