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/b5a14bc0-4069-4cba-a72c-4366980fbea2n%40googlegroups.com.
