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/4f559d69-6cd5-4de6-8cad-4ce57d4e6d9cn%40googlegroups.com.
