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 -- 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/CAA1SM23Sy%3DZv7Ykxg2UnMZSUY7mwvL7Kt42j_UFERpatLVZTsA%40mail.gmail.com.
