On Friday, May 8, 2020 at 6:09:47 AM UTC-7, Greg Troxel wrote:
>
> Till Maas <[email protected] <javascript:>> writes:
>
> > A weewx weather station consists of one driver and possibly multiple
> > services. It supports multiple temperature/humidity sensors but only one
> > rain/wind sensor.
>
> I don't think that's quite right. "weather station" there means "pile
> of stuff that weewx gets data from". The driver/service distinction is
> an arbitrary software thing and I think we shouldn't give it too much
> architectural weight.
>
>
>
Terminology is hard and English is an inexact language.
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.
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.
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.
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.
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.
example here:
- 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 using temperature as an example:
- vp2 temperature is in influxdb topic vp2/loop and field outTemp
- wf data is in influxdb topic sensors/AR-00013349/wf/obs_air and field
temperature
- tempest data is in topic sensors/ST-00006021/wf/obs_st and field
temperature
- the inside arduino is in topic esp/obs/4535161 field degF
- the second arduino is in topic esp/obs/<itsHardwareID> field degF
- the third arduino is in topic esp/obs/<itsHardwareID> field degF
- the fourth arduino is in topic esp/obs/<itsHardwareID> field degF
- and so on
So the map of field name to what the heck it 'is' still has to exist. It's
in my grafana dashboard config. And it's a pain to keep track of.
I at least settled on a naming convention that works enough for my needs:
- vp2/loop for the vantage, matching weewx's MQTT extension terminology
- sensors/<id>/wf/obs_air for WeatherFlow Air, matching its terminology
- sensors/<id>/wf/obs_sky for WeatherFlow Sky, matching its terminology
- sensors/<id>/wf/obs_st for WeatherFlow Tempest, matching its
terminology
- esp/obs/<id>/degF for arduino temperature sensors
Using the hardware <id> lets me support multiple instances of the same
hardware, as long as I can keep track of *'which room has arduino 1345631
in it*' so the dashboard is user friendly enough. Keeping track of that
mapping is a royal pain. Figuring out what database and which element to
store whatever in was a pain too at the time.
It's a hard problem to make things infinitely configurable and flexible,
yet not require some kind of map 'someplace' to either get data into the
database(s), or get and display data out of them. If you have a better way,
please let us know.
And give Matthew's links in his reply a read. It does a nice job
explaining some possible options. I picked/cobbled-together a variant that
works for me well enough for my needs, but everybody's needs differ.
--
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/06b04adb-b85f-4c0f-8285-f84c7af6b5f0%40googlegroups.com.
