I tried. Since it didn't work out that way I wrote my extension and for viewing "live" values in the browser I chose to view "extraHumid1" and don't care if there are no values for some reason.
[email protected] schrieb am Montag, 28. Dezember 2020 um 21:48:28 UTC+1: > No, the cache is only for archive records. > So, if it is In at least one loop packet, it should be in the archive > record. So are trying to 'fill in' loop packets? > > On Monday, 28 December 2020 at 15:05:15 UTC-5 [email protected] wrote: > >> Is this also the case with loop values? The MQTT sensor doesn't send a >> value each loop interval, but several times an archive interval. >> >> [email protected] schrieb am Montag, 28. Dezember 2020 um 19:01:09 UTC+1: >> >>> Just making sure I understand this. Currently sometimes a loop packet >>> has an extraHumid1 value and sometimes it doesn't. As long as extrahumid1 >>> is in at least one loop packet, the archive record has what you want, the >>> average of all the extaHumid1 loop packet values. The problem is when no >>> loop packets have a value for extaHumid1. >>> If so, I think the expires_after option might be what you want. See, >>> https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring---additional-options#expires_after >>> rich >>> >>> On Monday, 28 December 2020 at 10:39:54 UTC-5 [email protected] wrote: >>> >>>> > So I think MQTTSubscribe should perhaps be changed to have a stale >>>> > interval, keep the most recent value for each input, and if its >>>> arrival >>>> > time is within the stale interval, use it, and otherwise not. >>>> >>>> That was my first thought as well, when I observed what was happening. >>>> But for the moment, things are implemented that way. >>>> >>>> So this is my current approach: >>>> https://github.com/mKainzbauer/weewx_extensions/blob/master/usePreferred.py >>>> >>>> Greg Troxel schrieb am Montag, 28. Dezember 2020 um 14:48:28 UTC+1: >>>> >>>>> >>>>> "[email protected]" <[email protected]> writes: >>>>> >>>>> > 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. >>>>> >>>>> I think this needs more sophisticated handling. The archive/loop is >>>>> as I understand it due to the Davis design, and other things are >>>>> adjusted to that. >>>>> >>>>> As a side comment, I use MQTT sensors that report at 1 minute >>>>> intervals. >>>>> I don't see any value in more frequent measurements, usually, and I >>>>> picked 1 min because I track them with Home Assistant not weewx and I >>>>> don't want every-second readings in my database. >>>>> >>>>> Overall, I would suggest that it's an architectural bug to have to set >>>>> the MQTT update interval to exceed a loop interval. THe real question >>>>> is what you or some default says is stale vs fresh for an MQTT >>>>> reading. >>>>> >>>>> So I think MQTTSubscribe should perhaps be changed to have a stale >>>>> interval, keep the most recent value for each input, and if its >>>>> arrival >>>>> time is within the stale interval, use it, and otherwise not. That >>>>> way, >>>>> that sensor will reliably work at update rates that someone might >>>>> reasonably choose. >>>>> >>>>> Another way to think about this, probably better, is that it's ok for >>>>> some loop packets to be missing an observation. With that view, then >>>>> there should be processing of both sensors independently and them some >>>>> fused sensor, an that fused sensor should have this stale notion, but >>>>> instead of MQTT arrival, have presence in loop instead. I think this >>>>> is where you are headed with only using the preferred sensor for >>>>> archive >>>>> generation if it had any reports in the interval. >>>>> >>>> -- 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/801e1cf9-dc6c-496e-ab47-23c5db74395cn%40googlegroups.com.
