This website uses cookies to improve your user experience, personalize content and ads, and analyze website traffic. By continuing to use this website, you consent to our use of cookies. Please see our Privacy Policy to learn more about cookies and how to change your settings.
Since I am in the USA, where we generally use inches of mercury (inHg) to characterize barometric pressure, the conversion to inHg requires the pascal reading from the bmp085 pressure driver to be divided by 3386. Since we are dividing a uint32 value, the remainder gets truncated to maintain a uint32 result, 29 inHg.
I have corrected this in my code by casting the value returned from the bmp085 to a float:
bp = (float) bmp.readPressure() / 3386;
I tested this code correction using a separate ESP8266 setup.
It did fix the truncation.
Now I am waiting for an opportunity to update the ESP8266 firmware on the device that is reporting reading for this channel.
You see, this ESP8266 system has now been running continuously without any glitches for over 5 days now. And I do not want to disturb the system with a flash update to correct the barometric pressure readings.
This update will be done at a convenient time, after a system reset occurs. And I am hoping that it will be a long time before I'll be able to update the code.
I'd much rather experience exceptional stability and reset free operation of this ESP8266 setup.
We shall see how long it runs without a reset...
Yep, finally got the SDK web server working properly. I was using SDK version 1.0, and that did not support mDNS. mDNS, introduced in the 24 April release of version 1.01 of the SDK, was the missing feature needed for network access outside my LAN.
June 2, 2015: I averaged the difference in readings taken each hour over the past week between my sensor and the on-line weather web site. This value (0.72 inHg) is now added to the reading from my sensor. The resulting pressure hovers around 30 inHg, which correlates nicely with the local weather website readings...
Just added a counter to the code to identify how many times the WIFI connection was lost and had to be re-established so the sytem keeps operating as desired. It has only been 18 hours since the counter has been in place and 40 WIFI restarts have occurred. This confirms that:
1. A "WIFI connected?" check is needed in my loop() function.
2. The WIFI restart is working, and the system recovers with no loss of data collection.
My system has cumulatively run for about 6 weeks now with it recovering from the resets (2 have occurred in that time-frame). After each of these resets, the system resumed normal operation.
This is providing me with a building confidence with the passing of time that my software structure is robust enough to tolerate disturbances (loss of WIFI and system resets), recovering to function normally for an indefinite period of time.
Currently it has been over 5 days since the last reset, and 139 WIFI drops and restarts have occurred. On average, that is about 28 per day, a bit more than 1 WIFI dropout per hour.
The great news is that the ESP8266 has always managed to reconnect. No downtime...
Here http://wp.me/p5NRQ8-ab is a link to a post I wrote which describes what was added to the sketch to count WIFI dropouts.
The essence....
This check is made each iteration of loop():
if (WiFi.status() != WL_CONNECTED) {
//Increment WIFI droupout count here
//Reconnect to WIFI here
}