Hi all, I have had an ms5611 baro sensor installed on a bare esp8266 setup for several years without issue. Probably doesn’t matter, but it was using mqtt to talk to ha. A couple days ago I decided to swap out my DIY firmware with esphome. All seemed to be going fine until yesterday, when I observed a sudden jump in pressure values. The pic below shows the problem:
The initial jump in the line was when I noticed the problem (~30hPa too high). I then used a template to bring it down to actual pressure (first step down). Then in the middle of the night it drops about 10hPa. This morning, I got rid of the template offset and started playing with i2c speeds, with no good result… pressure still reads ~30hPa too high. Severall reboots of the device didn’t work, and neither did trying to let the sensor cool off for 10min.
I suspect my ms5611 may be near it’s EOL, and it was just a coincidence it happened a day after switching to esphome. I figured I should ask here first, before I just go order a replacement sensor. Has anyone else seen this with i2c sensors on esphome? I have read about a possibility that the esp could be reading the PROM calibraiton incorrectly, but I doubt it since it seems to be working well otherwise (smooth curve changing properly relative to actual pressure).
[edit: Just now, it jumped up another 10hPa… reading almost 1060, actual is ~1020.]
…pfft, pretty sure the sensor is just toast. All that noise since my last post has nothing to do with with templates. It’s jumping all over, and at just 50k i2c speed too.
So I scoped data and scl lines at the esp (only inches from the sensor anyways), and got rise times of 300/350ns for data/scl, which is well within spec for 50kHz i2c (<=1000ns… but not quite there for 400kHz which needs <= 300ns). So it’s more than likely a bad ms5611 chip… replacement going in today.
I replaced the baro, and added an m1750 lum sensor to the i2c line 2 days ago. The data looked fine until a couple hours ago, when it jumped up 10hpa and down about 30hpa all of a sudden (fwiw, the lum data looks fine). So now I am leaning towards a bug in esphome, because there is near zero chance the new baro has the same issue.
Does anyone know what ms5611 library it uses?
Is anyone else running an ms5611 with esphome without issue, or with issues?
Any ideas what I could do next to troubleshoot this (I already scoped and verified rise times are good)?
I think I need to make an issue report on github for this… updating libs was trivial with pio… as convenient as esphome is overall, these kinds of problems can be deal breakers. I am not even sure how to go about compiling esphome in pio (I tried but get errors).
Cross referencing a thread I created later on, that is relevant to this discussion:
So I’m back to fixing the esphome ms5611 library, since working around that with a custom component was a fools errand. Since this topic is a better match to that mission, I’ll be continuing work here instead of the other thread.
In a nutshell, there are some differences in delays between i2c commands that could be the problem. ms5xxx delays only 3ms between reset and prom read, esphome delays 100ms here. Also, ms5xxx has different delays between convert and reading that depend on resolution; 10ms delay is for 4k, shorter delays for lower res. ESPhome uses 10ms, but not sure if it’s using 4k res or not? This could be another issue that needs to be addressed. I haven’t looked much outside of the i2c command parts of both libraries, since that seems the most likely place where this error would come from.
I’m working on my lacking HA skills to move forward… my esphome/device/src/esphome folder (where the offending ms5611.cpp resides) keeps getting overwritten during compile. The readme mentions using custom component folders for this… more learning for me to do.
