I started mucking about with ESPHome yesterday and setup a WROOM with an AHT22 temp/humidity sensor. Running the wizard and adding the configs is easy-peasy. I started to have issues as soon as I wanted to flash.
- If the AHT22 is plugged in, I cannot flash the device over USB.
- I can check the serial logs once the device is flashed and then plug in the AHT22 once the device is booted and get readings, but
- Once I unplug the ESP32 from the serial port and plug it into a power supply, I got nothing. No network activity at all.
- Unplug the AHT22, plug into the power source, wait a few seconds, plug in the AHT22 has seemed to work correctly this morning and HA is pulling data but I tried that last night a few times and it didn’t work – so unsure why it’s working this morning other than strange timing when I’m plugging the thing back in.
I am using the basic esp32dev
firmware, which I am assuming works because it DOES work, eventually, but I’m not confident I’m using the right base but I cannot figure out which one to use.
I don’t have an exact answer to your problem, but I do have a few ideas to think about. I’ve got a few ESP32 WROOM boards running in various applications, so I’m a bit familiar. So here’s my thoughts:
- I only plug the module into data USB (computer) for the initial firmware provisioning. After that, it’s 100% wifi and USB is only for power using a power supply, not the computer. And I do the initial provisioning with just the bare ESP32 - no breakout board, nothing plugged into GPIO. Get the device up on wifi with NO other configuration in the firmware.
- I use the “arduino” framework. I don’t know if that’s correct or really matters, I’ve heard it’s the same as “esp32dev” but I don’t really know. I use “arduino” because that’s what the examples used when I setup my first board.
- Is it possible that the sensor module/board is using the same GPIO that the USB UART uses? There is a lot of shared usage of the GPIO that you’ve got to be careful to work around. The dev tools will often catch this when you compile your firmware, but not always. Again, using wifi after the initial provisioning might be enough if it is sharing GPIO with the serial port.
- If you repower the ESP32 too many times rapidly it’ll boot into safe mode. You can change the settings on that, but you can also just work slowly - make sure the device is powered on for a few minutes to record a good boot in the flash. It outputs a message in the logs, so it’s handy to always be running the log command in a terminal while developing.
Hope that helps! They are a lot of fun to integrate with HA.
I really appreciate these tips and trick! I just started messing with ESP32s a few months ago and this is my first ESPHome project. I feel a bit of a fish out of water!
I’m glad it was helpful. They are great little controllers and ESPHome makes them so accessible for people like me who don’t really want to write code manually.
Make sure you’re not using any of the strapping pins for the interface with the AHT22 - take a look at https://esp32.com/viewtopic.php?t=5970 for a read. It basically means leaving GPIOs 12, 0, 2, 4, 15, 5 floating during boot or the esp will not boot correctly.
These pins control the boot process (like going to the boot loader instead of your code).
Patched, flashed, and didn’t crash! That also explains why WLED project switched to pin 18 or whatever by default. This is a huge fix and I really appreciate it!
I think you nailed it. It explains both the issues flashing and booting. I’ll have to muck about with other pins and see if that fixes it.
It might be a WiFi connection issue. My devices connect perfectly after I flash a new configuration, but my AP seems to reject the next few login attempts. They eventually connect, but it takes a few minutes.
This is a screenshot from the HA ESPHome add on. In the ESP32 drop-down there’s a WROOM option. Try that.
I have several chinese knockoff WROVER kits that boot to the bootloader when initially powered on. I need to press the BOOT button to get them to load the code in firmware. I was able to bypass this behavior by bridging pin 0 to VCC with a 100uF capacitor. There might also be a software setting, but I haven’t really poked at it.
The Freenove branded one doesn’t do this, though. It boots straight to the firmware.
Not sure if the WROOM kits have the same behavior, but try bumping your BOOT button and see if that wakes up.