feature request for mqtt publisher

[Greg Troxel]

I'm writing about the MQTT publishing extension, described at
https://github.com/weewx/weewx/wiki/mqtt

(In what follows, there is some complicated MQTT bridging going on and a
number of Home Assistant (HA) instances, but that part works right and
it is not relevant to my question so I've left it out; assume this is
all on the same broker.)

On WEEWX1, I'm successfully using the mqtt extension to publish archive
records in the aggregate form, so that a json dictionary
"weather/foo/loop" is published every 5 minutes, and successfully
ingesting some variables (temps, humidities, pressure, rain - nothing
funny) into HA1.

Someone else with an independent weewx instance WEEWX2 is publishing to
mqtt, but using loop records to individual topics. These are ingested
to HA2, and working as desired.

The problem is that I want to display temperature etc. from WEEWX2 in
HA1 also. It's available, but there are updates every few seconds.
This leads to frequent database writes and faster growth, and I think
means more data downloaded for HA users to see a graph. I can see why
others would want to ingest temperature every 2.5s into HA, but I don't.

There appears to be no way to configure things to make this work. It
seems obvious :-) that it would be helpful for the mqtt extension to be
able to publish to one topic for archive and one for loop, as different
users might want one or the other. It seems likely that one's
Belchertown skin wants loop, but HA wants archive.

So, I'd suggest that this work by setting TOPIC (default weather), and
having archive data posted to topics like

$TOPIC/archive aggregate (json dictionary)
$TOPIC/archive/temperature_F individual value

and loop to

$TOPIC/loop aggregate (json dictionary)
$TOPIC/loop/temperature_F individual value

Right now, it seems that if "binding" is "archive, loop", both archive
and loop records result in posting to /loop (and it's not clear if one
can or should sort those out). This is especially tricky as archive
records arrive 15s in arrears, on Davis, and thus with rapid temp change
one would have an out-of-order record, if I followed correctly.


I have a further suggestion, which is rate-limited loop, to, e.g.,
enable loop data every minute, which seems to be a reasonable tradeoff
of freshness and database writes. I would suggest

loop_ratelimit = 60 # user-configurable of course

which would publish the first loop packet and then hold off until the
time crosses the next multiple of loop_ratelimit. So for values like
15, 30, 60, 120, one would get new reports on the quarter-, half-,
whole-minute and even minutes. In this way they would be like one had
sped up the archive interval, but without perturbing weewx's and the
stations's archive notions.


I realize someone has to write code if this is to happen; right now I am
curious if others think this makes sense.

Greg