On Friday, March 24, 2017 at 10:42:36 AM UTC-4, Thomas Carlin wrote:
>
> RE: the units, how does the rest of Weewx handle those? is it done by the
> driver, or the engine, or the device? I would like to stay consistent with
> the rest of the software. Since this is really only accessing a simple web
> page that looks like this
> extraTemp1,75
> extraHumid1,38
> someOtherData,125
> etc...
>
the driver should capture/parse/decode the values and designate the unit
system. it does this in genLoopPackets - just yield a dict with the
values, and usUnits set to the appropriate unit system.
it is ok for each packet to have a different unit system, as long as all
observations within a single packet have the units appropriate for the unit
system of that packet.
for example, the driver could yield the following:
{dateTime: x, temperature: 24.5, humidity: 30, usUnits: 0x10, id: 0x11} #
metric unit system from sensor 0x11
{dateTime: y, temperature: 60.5, humidity: 30, usUnits: 0x01, id: 0x12} #
imperial unit system from sensor 0x12
> I would like to make it available to others that want to collect data from
> web connected devices. As an aside, is there a 'better', more consistent,
> or otherwise cleaner way to pass this data to the driver?
>
the config file weewx.conf is the preferred mechanism.
> The issues with IP address change is easily addressed, either with DNS,
> static IP's or DHCP reservations, so I'm not concerned about that at this
> time.
>
you will have better results if you identify by an absolute reference such
as MAC address. IP address is too fungible - all it takes is a
misconfigured router and your database will end up with corrupt data from
mixed sensors.
use IP address to find/communicate, but use MAC address or serial number or
some other unchanging, unique property to identify.
> In the customization docs, there is a variable that is passed that
> contains a dictionary of the config file `config_dict`, and that works
> great inside the __init__ and the other functions, but I would like to use
> it for modifying the schemas. In the examples, that happens outside the
> function, and this variable is not accessable .... This will search the
> schema for each type being used, if it does not exist, will add it to a
> dictionary, and then append that to the schema, so it can be used by
> wee_databae --reconfigure. The problem that I'm running into is the lack
> of config_dict. Can this little code block be functionalized and have that
> passed, or is there a way to create that dictionary on the fly, and have
> this process work, or is it going to be one of those things that is more
> trouble than it is worth?
>
you are overthinking it.
the driver should just emit packets. any fields that are not in the schema
will not be saved to the database, but they could be used in a report.
the driver should *not* mess with the schema, i.e., the driver should not
modify, and probably has no need to query, the schema. use weewx.conf to
make the driver deal with different schemas, but implement a default
mapping that works with the default (wview) schema.
notice that weewx uses a fixed schema, defined in the [DataBindings]
stanza. that schema is used only when the database is created.
if you want a dynamic schema, then send your data to a system with a
flexible schema, such as influx (use the weewx-influx uploader, available
on the wiki) or mqtt (use the weewx-mqtt uploader, available on the wiki).
in this case weewx would simply collect and relay the data, not retain it.
m
