ESPHome works completely different after initial flash vs. after reboot

ESPHome
1

It’s very weird behavior that I see.
I have an ESP32-c3, configured and all, hooked up to homeassistant.
After flash, everything works perfectly, as it is written in the yaml:

esphome_good
esphome_good508×436 20.9 KB

However, after a reboot of esp32 (nothing else changes - just that it doesn’t run the initial, first bootup of esphome), I get this in homeassistant:

esphome_kapot
esphome_kapot515×436 21.5 KB

Subsequent reboots results in the same; there seems to be no way to get the original ‘after-flash’ state back. It works all right, but RPM sensor is off, and a number of metrics is unavailable.

I’m really puzzled as it seems to indicate esphome works completely different on first bootup directly after flash.

For reference, here is the yaml config:

esphome:
  name: robi-fan

preferences:
  flash_write_interval: 5min

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf

logger:

api:
  encryption:
    key: !secret api.key

ota:
  - platform: esphome
    password: !secret ota.password

wifi:
  power_save_mode: none
  ssid: !secret wifi.guest.ssid
  password: !secret wifi.guest.password
  domain: ""
  ap:
    ssid: "Robi-Fan Fallback Hotspot"
    password: !secret wifi.ap.password

captive_portal:

sensor:
  - platform: pulse_counter
    pin:
      number: GPIO2
    name: "Robi Fan RPM"
    id: robi_fan_rpm
    unit_of_measurement: 'RPM'
    filters:
      - multiply: 0.5
    update_interval: 15s

  - platform: internal_temperature
    name: "Robi Fan ESP Temperature"

  - platform: wifi_signal
    name: Signal strength

  - platform: uptime
    name: Uptime

output:
  - platform: ledc
    id: robi_fan_pwm
    pin:
      number: GPIO21
    frequency: "40000 Hz"
    min_power: 0%
    max_power: 60%

fan:
  - platform: speed
    output: robi_fan_pwm
    name: "Robi fan"
    id: robi_fan
    restore_mode: RESTORE_DEFAULT_OFF

Any ideas how I could fix this?

2

How long did you wait before declaring it was not functional? 60 seconds is default update time of these sensors.

You can try manually setting an “update_interval” for the sensors to see if behavior changes.
You may also turn on web_server or looking at device logs in esphome to see if that data is being reported and only HA is not receiving this

3

This is just an example with hot and fresh screenshots I just made. Even if I wait weeks after flashing, it works until perfectly until the first reboot, then gives the results you can see in the above picture.

As in, it breaks on a reboot, not on time passed.

4

Gpio2 is strapping pin. Your board doesn’t boot correctly.
Neither Gpio21 is ideal, it’s default UART0 pin.

2 Likes
5

Thanks, I’m investigating that.

Couple of questions come to mind.

The idea of c3 mini boards was that I could still use these pins. If you say they influence the boot process, I can’t really connect anything to them, that defeats the purpose, doesn’t it? Is there a way to disable this ‘feature’? Either in esphome, or on hardware level?

Or is it just what it is, I got a c3-mini, “got what I paid for” ? It just seems so wasteful and stupid. :frowning:

For the UART pin, I’m surprised that I’m not even using UART. Maybe if I disable UART, I could still use that pin? That c3 mini is just connected to a 3.3V directly, no usb, no serial, I do OTA updates, but it’s in a hard to access location.

And finally, is there a schematic that shows this info? After what you wrote, I found a schematic that did show the TX/RX pins correctly, although the manufacturer still says it’s a perfectly good GPIO pin and counts it as one in the specs. :frowning: But for the gpio2 ‘strapping pin’ feature I had to google, there is not a single schematic that shows that landmine. How could n00bs like me still get an info about what to look out for?

6

After a whole 5 minutes of search, I managed to find a way to disable UART logging (which is enabled by default on esphome):

logger:
  baud_rate: 0 # disable UART
7
8

hmm, I find lots of things about strapping pins and which pins can I actually use

I am not sure what you except to see in a schematic. This is information about the boot process of the chip (varies per chip/family). It is a basic thing that many people just gloss over. It is okay to do that until you do something that causes an issue.

You can use strapping pins, but you have to make your HW design does not violate the rules. I usually just avoid using them, since many boards have more than enough pins.

9

Realize that this is a development board and can be programmed in a variety of languages- not just ESPHome (Python). If you program the board in Arduino, for example, you can use these pins.

What do your entities look like after five minutes?

10

No, it’s just limiting little bit of their use. On the moment of boot they have to be on specific state.

No, but it’s not the easiest board to do experiments, prototyping, learning…

I’m not 100% sure how Esphome use usb logging on C3, it’s not well documented. If you want to exclude doubts, add baud_rate: 0 option on logger component.

Best source of information is Espressif datasheet.
This forum is very useful also :wink:

1 Like
11

What do your entities look like after five minutes?

Uhm, not quite sure what you mean here. Note this is a fan that is generally left untouched and is turned on in the morning and off in the evening, generally 0 state changes in between, except when I flex with the homeassistant app. :smiley:

12

Thanks a lot to everyone, I learned a lot.

I feel a bit stupid now, this is just so obvious if I’d have spent the time and did some good old RTFM :expressionless:

One more question, almost forgot: I did notice esphome warning me about the usage of some pins at some point, that’s when I decided to move them to these GPIO pins. I wonder if these should be added to that warn-list? Seems unfortunate that these are not marked as ‘unsafe for n00bs’.

13

Esphome is giving a warning if you use strapping pins.

1 Like
14

Here is the code for the c3: esphome/esphome/components/esp32/gpio_esp32_c3.py at dev · esphome/esphome

_ESP32C3_STRAPPING_PINS = {2, 8, 9}


check_strapping_pin(value, _ESP32C3_STRAPPING_PINS, _LOGGER)

So you should have gotten the warning with your YAML and the use of pin 2, I don’t see a global way to turn off that warning so no explanation of why you didn’t see the message about pin 2 (looks like you should have gotten one).

This is what I see when I do it:

INFO ESPHome 2025.2.0
INFO Reading configuration .\junkc3.yaml...
WARNING GPIO2 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins

but the screen scrolls well past that and all you see is:


INFO Configuration is valid!

So, perhaps esphome config should put that warning where it will likely be seen and not missed (at least say INFO Configuration is valid (but with warnings)! (and in yellow) so you would be more tempted to look up at the rest of the log (which is what you must have done when you saw the warning about the other pins).

1 Like
15

You’re absolutely right – I do get that warning, it’s just that it’s so early in the output that it scrolled out of view very quickly.

$ esphome run robi-fan.yaml
INFO ESPHome 2025.2.2
INFO Reading configuration robi-fan.yaml...
WARNING GPIO2 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Updating https://github.com/espressif/[email protected]
INFO Compiling app...
16

Since it caused you an issue, you could create a GitHub issue, since it seems like it should be reasonably easy to fix. It probably would have saved you hours of frustration. No telling how many people a fix here would help reduce frustration.