Vince Skahan <[email protected]> writes: > Just reading between the historical lines a little, my interpretation has > always been that a driver 'interfaces' weewx with a weather station console > or equivalent, while a service 'extends' weewx to do something it doesn't > do in the core software.
That's true, but I see it a bit more abstractly, that there must be one driver which is the main thing, and services can be extra. Do you think there are some schema columns which can be written only by drivers, and other columns which are the domain of services? Or is it simply a notion of main vs not main? > So starting back with its Davis-centric lineage, the Vantage 'driver' is > what talked serial/usb to the Vantage console where the loop packets come > from. Fast forward to 2018 and consider the WeatherFlow stations that emit > loop packet equivalents via UDP broadcast. The WeatherFlowUDP 'driver' > grabs that raw data off the network just like as if it had been physically > connected to the weewx system. Same definition applies. sure > For myself, I wrote a 'service' that looks up data from a raspi on my > network via http GET and adds that data as a new element in my weewx db. > For historical reasons, I used the available extraTempNNN fields for that. > So I 'extended' weewx to do something it didn't do in its core. You did, but getting extraTemp from your stuff instead of extra davis sensors is more or less the same concept. > As people got more creative, folks wanted to use code that was typically an > extension (example - MQTT subscribing and saving to the db) as a 'driver' > (making that how weewx gets its data in all case, using weewx as a general > purpose db and graphing engine so to speak). Some such extensions can be > run either way....as an extension (integrate multiple sources of data) and > as a service (be 'the' way weewx gets its data). It's actually pretty > flexible that way. > > The db schema is where it gets rough, as there are infinite needs as the > community gets more creative. What do you call the element for 'how much > battery life is left on your UPS' versus 'how much power is coming out of > your 4th solar panel' and the like. completely agreed > Weewx v4 'does' have the very extended schema as the default, so there are > 'many' new elements pre-defined for folks to pick from. Certainly the > intent to cover almost all people's needs was there, even if we can > infinitely argue over the precise field names in the v4-default bigger > schema. > > If you want infinite flexibility in database element names, just go with > influxdb and get it over with...but with great flexibility comes great > confusion sometimes. At some point you'll need to write your skins and > cheetah is not so flexible. You're going to eventually need a mapping of > your database element names somewhere in the actual code that runs. when you talk about influxdb, do you mean still using weewx to get data from station put into influxdb get from influxdb and make graphs, as in skins ? > - I have multiple weewx stations feeding influxdb > - a VP2 feeding it via MQTT > - a WeatherFlow SmartWeather station feeding it via some python code > I wrote (one 'Air' and two 'Sky' sensor suites) > - a WeatherFlow Tempest station feeding it via the same python code I > wrote > - I have multiple arduino temperature sensor rigs feeding influxdb as > well > - each write to influxdb individually over the network > - the dashboard is grafana which picks the right data elements from > influxdb and displays it So here you are using weewx as a driver, and influxdb/grafana as your main weather storage/display software? -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/rmiv9l65l0v.fsf%40s1.lexort.com.
