@mwall: the diagrams are awesome. what I had in mind is approach 3 or 4. ill look for some uploader code and see how its implemented.
@thomas: the template might be the best approach. create a dead simple template and just put the values separated by comma.. then have the 'aggregator' to pull the data from there and other non-weewx sensors and send via http. this project of mine is gonna get turned over to a bunch of people. thats why im avoiding over complicating things.. i had to explain to them what an http requests is, so i dont want to burden myself of explaining what mqtt is. lol. On Mon, Jan 8, 2018 at 1:14 AM, mwall <[email protected]> wrote: > alan, > > maybe this wiki page will help clarify the options (now with yummy > diagrams!): > > https://github.com/weewx/weewx/wiki/dashboards > > just to be clear about the MQTT and HTTP options: > > 3) HTTP as transport. write your own uploading service that sends data to > your servers on each LOOP packet or archive record. this would require > some python coding. the code is really simple, and there are many existing > uploaders that you could adapt or from which you could derive. > > 4) MQTT as transport. use the weewx-mqtt extension on each weewx instance > to feed data to a single MQTT broker. optionally connect an influx server > to the broker so that you get centralized data retention. then your server > subscribes to the broker to get the data from all of the stations and/or > the influx server for historical data. or you can skip the MQTT transport > and go right to influx. either way, you'll have to write some server-side > code, but that can be any language you want with any framework you want. > > the MQTT/influx option is not as complicated as you might think. the > result is far more robust than most methods, and much easier to > manage/maintain. if you're aggregating data from a bunch of > sensors/stations, don't reinvent the wheel! using MQTT/influx lets you > focus on the value you provide with your servers/systems instead of mucking > around with "do i need a timestamp?" or "should i use GET or PUT or POST?" > or "how do i handle three different types of weather stations?" > > btw, the reliability of the 'wee_device --current' approach is going to > vary a lot, depending mostly on the quality of the hardware and how it is > physically wired up. for example, it will be pretty much rubbish for fine > offset stations connected directly to a raspberry pi, but it should be > almost bulletproof for a rainwise or vantage. but if you want continuous > operation, just use weewxd. > > m > > -- > You received this message because you are subscribed to a topic in the > Google Groups "weewx-user" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/weewx-user/P8L4qHt5e_o/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
