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/rmi4ii91sjy.fsf%40s1.lexort.com.
