Back to topic: I'm using https://github.com/bellrichm/WeeWX-MQTTSubscribe/ for getting the extra readings into weewx. It's configured as a service, so every loop interval the MQTT messages in the queue will be integrated into the loop package, when I'm correct. When it comes to loop data, depending on the loop interval and the MQTT sensors interval, there are loop packages that don't contain messages from the ESP/SHT because the queue is empty. This leads to a mix of readings. The other thing is, that the archive value also contains this mix as an average of all the values during the archive interval, because ws28xx driver doesn't support hardware record generation, I guess. I probably have to ensure that the MQTT interval is set to a value that at least one message is in the queue every loop interval or I could do this every archive interval using something like this: https://github.com/mKainzbauer/weewx_extensions/blob/master/fronius.py, just in a more simple way that only extraHumid1 overwrites outHumidity when not None.
[email protected] schrieb am Sonntag, 27. Dezember 2020 um 19:25:48 UTC+1: > > correction: the panel shoulndn't exceed 3.6V... > [email protected] schrieb am Sonntag, 27. Dezember 2020 um 19:17:11 > UTC+1: > >> @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/83465fa8-b53e-420b-a347-d3d8b05aada2n%40googlegroups.com.
