> On Jan 16, 2026, at 11:37, Vince Skahan <[email protected]> wrote:
>
> What I'm wondering is if it possible to have a two-component driver
> notionally. One piece that would handle backfilling on weewx startup and
> then exit. A second that would then take over and do the continual readings
> after that.
that already exists in a weewx driver. one function that gets historical data,
and another that gets 'live' data.
> In other words, follow the unix philosophy of having small utilities that do
> one thing well.
>
> Is that kind of pluggable setup possible (or crazy), or would the weewx way
> be to have a driver that 'only' does backfill and a service that does the
> realtime readings to the db ?
this really depends on the hardware. in most cases, there is one way to query
the hardware for historical data (if it is supported) and a different way to
query for 'live' data. i think only ecowitt has different protocols for
talking to the same hardware device.
i think that grouping based on backfill and realtime is not as useful as
providing a generic python interface to the hardware. the problem is, there is
no generic interface.
weewx defines a very simple interface with functions to get historical data,
get live data, set/get the time, etc., with no-ops when the hardware does not
support the functionality.
it is nice to have *everything* about a single type of hardware in a single
python file. the plumbing to initiate communication, handle errors, etc is
going to be the same whether you are doing historical reads or live reads.
i often wish that a driver could be standalone, i.e., not require weewx in
order to run, test, and do useful things. we typically write drivers now so
that they have *some* of this independence, e.g., a hardware abstraction that
talks to the driver and does things without weewx, even though weewx is
required to actually load the driver file (because of the python dependencies).
maybe weewx could use the home assistant interface for its drivers instead of
the weewx api? or maybe someone has defined a better, more generic way to talk
to hardware?
in most cases, the driver code never changes. only when the hardware gets
firmware updates does the driver software have to change.
m
--
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 visit
https://groups.google.com/d/msgid/weewx-development/CE66B009-63A1-4D85-9354-AC8721E28189%40gmail.com.
