Hi, Before you start looking into software record generation you might want to consider the software record generation capabilities already built in to WeeWX. WeeWX can handle two broad groups of data, archive data (aka archive records) and loop data (aka loop packets). You might want to read Loop packets vs. archive records <http://weewx.com/docs/customizing.htm#_____________LOOP_packets_vs._archive_records_> in the Customization Guide <http://weewx.com/docs/customizing.htm>. In a nutshell the driver can generate an archive record and pass it to WeeWX (this is hardware record generation) or WeeWX can synthesise an archive record from accumulated loop data (this is software record generation). You might want to read about the record_generation config option under [StdArchive] <http://weewx.com/docs/usersguide.htm#StdArchive> in the User's Guide <http://weewx.com/docs/usersguide.htm>.
If you are receiving frequent data packets in your queue you could bind to NEW_LOOP_PACKET instead of NEW_ARCHIVE_RECORD and add you data to the loop packet. Provided you are using software record generation WeeWX will then accumulate your loop data (along with all the rest of the loop data) and synthesise an archive record at the end of the archive period. One thing you would need to be careful of is your existing driver, if you select software record generation then it is one in, all in. In other words if you are presently using hardware record generation then when you change to software record generation hardware generated archive records will no longer be produced by the driver only loop packets. Though this should not be a problem in the vast majority of cases. Gary On Wednesday, 10 April 2019 06:45:51 UTC+10, bell...@gmail.com wrote: > > To further my WeeWX/MQTT/Python knowledge, I have written a WeeWX > multi-threaded service. One thread receives the MQTT messages and puts them > on a queue. In the other thread, when a NEW_ARCHIVE_RECORD event is > received, it process the queue and updates the archive record with the data. > Currently, processing of the queue means - take the last element and use > its data to update the archive record. My next big education will be to > develop some type of accumulation of these (essentially software > generation). > Also, the MQTT payload is expected to be json. I am hoping that other > formats can easily be supported by creating a subclass and overriding the > function that maps the MQTT payload to a WeeWX like dictionary. > Being a proof of concept, documentation is lacking, error handling is > minimal, limited functionality, no install support, etc. But, I thought > even in this form it might be useful/educational. > If interested, it can be found here, > https://github.com/bellrichm/weewx-addons/blob/master/user/MQTTSubscribeService.py > - Rich > > -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
