Interesting ideas. Time to move this somewhere else. I haven’t got far on any of this, but I think being able to publish on an interval bigger than the loop interval, but smaller than the archive interval might be the most interesting/useful to start with. Leveraging WeeWX accumulators it shouldn’t be too difficult. In essence MQTTPublish would be creating its own ‘archive record’. If anyone wants to follow along, I’ve opened https://github.com/weewx-mqtt/publish/issues/28 rich
On Wednesday, 8 July 2026 at 10:10:07 UTC-4 Greg Troxel wrote: > John Smith <[email protected]> writes: > > >> But, I do see a potential need to not publish as frequently for some > MQTT > >> clients > > > > Wouldn't that just be a case of checking what's being published has > > changed? > > Perhaps, but it gets complicated. > > For me, with weewx to MQTT to Home Assistant (HA), there is a flow where > each mqtt publish results in a state update in HA which results in a > database record. Recording temperature every 15s, or whatever some > rapid LOOP does, is excessive. I have settled on every minute for a lot > of (non-weewx) temperature sensors (e.g. an Si7021 and an ESP8266 with > esphome), as a compromise between often enough and filling up the > database and making all operations slower. Probably 2 minutes would be > better. > > I also have an ancient UPS (it was shiny in 1995 :-) that is polled > every second or so over serial by ups-nut, and I wrote python to send > MQTT from that. For many things, I want a value every minute or so, to > watch trends in line voltage, power usage, temperature. But, I want > immediate alerting on things like input voltage going to zero, and > battery voltage dropping sharply. > > I wrote code to assess updates (vs the last transmitted values), and to > trigger a transmission if it had been long enough (60s), or if any > variable was different enough than the last report. The code is easy to > write and the art is picking "different enough". Surely my thresholds > are tuned to my UPS. > > I am sending a json dictionary with everything, rather than individual > topics. That's better for MQTT, and it means all values are updated at > once, but it does mean line voltage fluctuations result in updates of > values that aren't changing. > > It would be nice to have MQTTPublish/etc. be able to do this, so that > there are more rapid updates during heavy rain (every rain click feels > like news), rapid temperature drops, gusts, while not sending updates > all the time. > > It would also be nice to have "send MQTT every archive interval (5 > minutes) and every minute there isn't an archive transmission based on > LOOP, even if LOOP is more frequent, so I could keep my archive interval > at 5m and have 1m updates. > > Of coures, one can also make a good case that sending over MQTT is cheap > and that the receiver should have the filtering. One might be sending > MQTT and using it in Belchertown, where a viewer wants updates, and in > HA, where you want a reduced update frequency when that doesn't result > in substantially wrong data*. But whether it's cheap depends on the > network path, and it could be some not-fiber-optics, ham radio, LoRa, > etc. > > *By not substantially wrong data, I mean that if you do linear > interpolation between two recorded points, the data points you didn't > record will be close to that interpolated line. > > -- 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 visit https://groups.google.com/d/msgid/weewx-user/2b3fed33-5043-426e-9ac0-6740f6ed71c4n%40googlegroups.com.
