Is anyone seeing issues with ESPHome i2c over the last few months of releases? I’ve been having a lot of trouble with a fairly simple ESPHome device in reading from I2C. I’m running the 2022.10 docker image. I’d be assuming it was my fault, except that:
The same setup was working for many months, and then it “went bad”.
In troubleshooting, I have piece by piece replaced every physical part of the system, even including the wires.
I’ve had good luck taking ESPHome updates, so I occasionally apply updates to unchanged configurations when I notice them in the dashboard. I can’t say one way or the other if my woes started happening after such an update. Maybe; maybe not.
Here are some details:
It’s this project: The Water Watcher | Hackaday.io but I’ll describe all the pertinent details here. There are two i2c sensors on ESP32’s default GPIOs. One sensor is a TSL2591 ambient light sensor. The other is a BME280 climate sensor. The total wire length on i2c is less than a foot.
Things usually work fine. Then within a day or two of boot up, I’ll start getting failures during i2c operations. It happens at various points in the i2c conversation. It’s usually failures related to the TSL2591, but very occasionally it’s the BME280. Once it starts happening, it can log errors for a long time. Sometimes it eventually heals on its own, but usually I have to reboot the ESP32.
If it hadn’t been for the fact that it was working fine for over a year, I’d be wondering what blunder I was making. This probably worked fine with ESPHome 2022.06, but my record-keeping is not very good for when I upgraded.
Yes, major issues with BME680 sensor. When it stops working I change the i2e address and it starts working again… very frustrating. So I just swap the commented lines, upload again and it starts working again. That’s the ONLY way I can get it working once it stops communicating. I’ve swapped esp modules and bme sensors. Same issue.
I appreciate the responses, even if just to say you aren’t seeing any problems.
@jazzmonger I do occasionally see my BME280 detected with the wrong address, but for me it always resolves with restarting the ESP32. It sounds like yours might be something more frustrating.
I’m no expert but I read the address of the BME280 is determined by a jumper. Could it be that trace is not connected and builds up static, causing it to flip to the other frequency? Or that condens water connects the wrong pads?
I’ve been trying to use older versions of ESPHome to see if some software change leads to my current situation, but I’m trapped in some kind of platform.io maze. ESPHome generally makes all this stuff work so well and so seamlessly that I don’t really have a good feel for how it’s lashed together. I’m using ESPHome docker images. If I use 2022.6 or earlier, I get into a maze of platform.io errors from which I have not yet escaped. I’m currently trying 2022.7.0-dev20220621, which is the oldest version without platform.io complaints. That doesn’t yet mean anything regarding my I2C problem. It might take a day for that to show up or a couple of days without it showing up for me to believe that it’s gone.
I really think that if the bus works with the BME280 on the other address, that it is the BME280 that is the cause, as said in my earlier post. Even if a restart fixes it. ESPHome cannot force the BMe280 to another address if that address is determined by hardware.
I would agree with that, but I don’t think it’s relevant to my overall i2c problem. When this first started happening, and I was swapping out physical things, I removed the BME280 for a while and still saw the problem with the TSL2591 (which I had already swapped out). I have several ESP32 and ESP8266 devices with BME280 and BMP280 sensors, and that “wrong address” thing is something I have occasionally seen all over the place. Maybe there is something inherent in that family of Bosch sensors (or, more likely, the support circuitry on the cheap breakout boards I use).
If a BME280 is swapping between 0x76 and 0x77 it is likely a problem with a floating SDO pin. See page 32 of the datasheet (linked in the esphome docs)
Well, this is ridiculous. If I weren’t so happy with finally resolving this, I’d be pretty annoyed with myself for taking so long to figure it out.
It seems it all came down to the USB power supply. Even though I swapped that out for another as one of a zillion troubleshooting steps, I guess I just replaced one flaky power supply with another flaky power supply. When I finally got around to using an expensive, name-brand USB charger, things immediately became rock steady. The original power supply was fine for well over a year, so maybe it was marginal and degraded enough for the problem to become visible a few weeks ago.
It always amazes me how often things are something hardware related. Often the basics like connections, faulty device, power supply, usb cable.
But it sounds like you had been pretty damn thorough in checks/replacements. Not sure what more 101 stuff you could have done? Two bad power supplies is bad luck!
I recall trying a few different ESP32’s or usb cables before a bug went away in a few instances.
It’s the stuff that starts driving me to buy better quality kit.
I think it’s kind of carelessness on my part. I tend to think of ESP32 as having pretty low power requirements, so I don’t pay close attention. I just reach into my Big Box of USB Chargers and use one with the right physical connector. Some of those are pretty old, maybe from back in the days when people used phones for making phone calls.
I have definitely learned my lesson and won’t let this happen again until next time.
To lose one power supply may be regarded as a misfortune; to lose both looks like carelessness
Even a desktop level PC, if it starts having weird behaviour/reboots/PCI device failures/video glitches/crashes the first thing to check is the power supply.
This was new to me, too. The BME280 breakout boards I have seem to have pretty stable addresses, which must mean they take care of this on the board somehow. But those boards also have SPI pins exposed. I don’t know how they can pin the SDO line to ground or Vddio for I2C but still allow SPI to work. (I’ve never tried using one of these via SPI.) Does anybody understand how that works? Or maybe I have just been lucky with that potentially floating address.
The Adafruit schematic shows that they include an onboard pullUP (10k) on SDO, presumably to cover this requirememt. That sets the default address at 0x77, and it will (should) be stable.
If you need addr to be 0x76, solder the jumper pad on the back.
