@Peter Quinn, thank you. I'll check the weewx part! Just my 2 off-topic cents: using the breadboard the voltage regulator and the UART, powered by 5V ist a very inefficient way to run this sensor. The simplest approach to get more time from the solar/battery combo would be to use a 3V solar panel (which should exceed a maximum idle voltage of 3.6V) and directly charge a LiFe battery with it. If you ensure that the ESP powers off (deep sleep) at the ESP lower limit (datasheet says 2.5V, my experience says ~2.3V) the LiFe lower discharge limit (2,0V) will probably never be reached. Even with your LiPo this should be possible this way, but you can't use all capacity, since you can't charge it over 3.6V, because this would kill the esp.
In brief: - don't use such a breadboard or remove the voltage regulator and the UARTs supply - connect a LiFe directly to 3V3 and GND - connect a 3V solar panel directly to 3V3 and GND - ensure to power off the ESP when it reaches it's minimum required voltage (maybe it's never reached), either with a protection circuit (preferred) or the ESPs internal voltage measurement ability (not preferred, because ESPs sometime run into a state where they aren't really running but drawing current from the battery until the battery is flat and damaged. This will extend your runtime dramatically. Currently I'm running my sensor on a 2500mAh LTO Battery, one sample a minute with deep sleep in between gives me more than a week runtime. [email protected] schrieb am Sonntag, 27. Dezember 2020 um 18:49:54 UTC+1: > I have a secondary temperature sensor that runs on solar and a battery. > This time a year in the northern hemisphere there's not enough sunlight to > charge the battery sufficiently to make it through the night. I handled the > failover to the main thermometer in my customized driver. Details here: > https://hackaday.io/project/101680-solar-powered-wifi-temperature-sensor-for-weewx/details > > On Sun, Dec 27, 2020 at 7:53 AM [email protected] <[email protected]> > wrote: > >> The the ESP just reads the SHT35 in a given interval and publishes the >> reading, nothing else. No calibration necessary, the sensor is really as >> good as advertised in the data sheet. And only the outHumidity values of >> the station are off when humidity > 80%rh, other values are pretty much >> accurate and even outHumidity is very accurate below 80%rh. Since I don't >> attach too much importance on historical humidity readings, mixing up >> different source from time to time is no big deal for me. We're talking >> about >99% availability with the less reliable sensor. But the current >> dewpoint and windchill are interesting for me, which both require some >> realistic humidity values. >> >> "Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it >> is not the same as hardware record generation nor does ‘prefer_hardware’ >> have anything to do with corrections. ‘prefer_hardware’ is used with the >> StdCalculate service, corrections are used with the StdCalibrate service >> and hardware or software record generation is used with the StdArchive >> service." >> >> Thanks for pointing out. >> >> Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1: >> >>> >>> You may also want to think about calibration. Besides absolute >>> calibration there is going to be some offset or other more complicated >>> relationship between your two sensors. Given a "prefer precise if >>> available" this is going to cause some flipping betweeen them. I had a >>> little trouble following this thread, and perhaps StdCalibrate runs >>> before the choice. >>> >>> But if not, and maybe you want to do this anyway, basically >>> cross-correlated the data from both over a wide range, calculate a >>> mapping function, and put that in the ESP8266 code so that it emits >>> values that are consistent with your other sensor. >>> >>> I did this with an ESP8266 that is measuring a 12V lead-acid battery. >>> While I can calculate expected values from the divider resistors and the >>> data sheet, I ended up just measuring the battery and looking at the raw >>> values and figuring out a divisor, which I stored in a calibration file. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Peter Quinn > (415)794-2264 <(415)%20794-2264> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/f45acf3e-3406-4012-b91b-48e489e44fa1n%40googlegroups.com.
