> 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/7ea110f2-5d05-4d7b-a3e3-37f3bada4478n%40googlegroups.com.
