Hi There ! Bill, I just noticed you mentionned me :-). So, while I try to understand a bit more how to use github in a more efficient way, I build a cleaner github project. You may find the driver I use here (no changes): https://github.com/bonjour81/station_meteo/blob/master/weewx/driver/wxMesh.py
I don't have enough python knowledge to make anything fancy like a buffer, but here is the trick I try to use: - When I receive some MQTT message, I put the content in "data" and clear the MQTT receive buffer, so I'm ready to receive a new MQTT data. - Then I quickly build the loop packet with timestamp + received value (let's say for example outTemp). I just assume the loop packet building shall be fast enought that I cannot receive more than one more mqtt message during that time (finger crossed ;-)). - if some other message is received while still in the same loop interval, I will update the loop packet: timestamp update + new value added. (example, barometer) ... at the end of the loop interval, I shall have a loop packet with timestamp of last mqtt received + all (and only) measurement received (example: timestamp + outTemp + barometer) Let me know if anything is unclear. So far it works fine. Le vendredi 19 janvier 2018 16:26:17 UTC+1, Bill Morrow a écrit : > > I found a limitation in my diver which brings in data from an MQTT broker. > If the publications arrive at a higher frequency than the weewx polling > cycle, only the last one would get processed. > > So I have added a queue which buffers incoming MQTT publications, which is > then emptied in genLoopPackets. > > See https://github.com/morrowwm/weewxMQTT > > This should be portable to the forks which use different types of MQTT > messages. > > wysiwyg (Frederic) recognized this issue some time ago: > https://groups.google.com/d/msg/weewx-development/tNDnGNe9Z_M/7aBmfL5WAwAJ > and I believe fixed it in his version. >
