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/b03060c6-2ec2-4365-8d87-f7f0ec5bc6cen%40googlegroups.com.
