Vince Skahan <[email protected]> writes: > Is it possible to break up monolithic drivers into components that do > pieces of the puzzle ? > > Using ecowitt as an example, the vendor has been updating their gateways to > be able to publish readings to MQTT. Using Rich's mqttsubscribe as a > driver works great. > > But...some ecowitt gateways now support backfill capability from SD card, > and some backfilling via queries to the vendor's ecowitt servers also is > possible. So there are multiple backfill scenarios that are possible > (including no backfill). > > 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.
> 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 ? I am not following your discussion (but I get the goal). Personally I see live-data and backfill together as just how things ought to be, with some stations lacking a way to do backfill. As I understand it, "driver" and "service" are weewx architecture terms for code that can be hooked in via weewx APIs and a driver provides the single "weather station" that is the base of the weewx setup a service provides data, but it is somehow extra and that's the only distinction: one must have exactly one driver and then can have zero or more services. In the case of ecowitt stations which (existing outside of weewx) have the ability to get data as it happens and also backfill, that seems to me to be exactly like a Davis VP2 data logger. Except that the protocol details on the driver/hardware side are totally different. Thinking about your modularity comments, I think they're really about letting different aspects be maintained separately, perhaps by different people. Whether they are plugged into weewx via a common driver or not is not really the big concern. This discussion makes me think of the common idiom in Home Assistant (HA), where there is A python (async) module to talk to some kind of device in python. This has nothing to do with HA, and can be used in any python program. Examples are aioshelly, aioesphomeapi, aiounifi and many more. However, often it is motivated by HA where one wants to write an integration also. An "integration" which interfaces to HA APIs (about how to create automation objects, report their status, and accept commands) and to the device by making calls into the async module. This code does not have any details of the protocol to talk to the device. But it will be affected by the semantics of what you can do. Usually the same aiofoo can be used by other home automation systems. I would suggest that the way forward is to create python modules that turn the ecowitt API into something pythonic, perhaps with a backfill module that augments the main one, or something, and then to have a driver that uses this module. This is likely more refactoring than anything else. I would expect, without any more than gut feel basis, that such a python module would not be really enormous. While I've mentioned async, that's only because architecturally HA is async. weewx is not; at least "egre -R async ." turns up empty :-) This great python traditional/async dichotomy has led to there being both py-foo and py-aiofoo for many values of foo. -- 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/rmi5x91wgv2.fsf%40s1.lexort.com.
