search for: upsdrvqueri

Cheers, With https://github.com/networkupstools/nut/pull/1906 and https://github.com/networkupstools/nut/pull/1912 (and probably some more later), I've been enhancing NUT driver framework with support for live reload of configuration, primarily to acknowledge changes to debug_min setting in ups.conf - but made in a generic fashion that specific drivers may take advantage of for their

Cheers, With https://github.com/networkupstools/nut/pull/1906 and https://github.com/networkupstools/nut/pull/1912 (and probably some more later), I've been enhancing NUT driver framework with support for live reload of configuration, primarily to acknowledge changes to debug_min setting in ups.conf - but made in a generic fashion that specific drivers may take advantage of for their

Hello Jim, I am following the direction of the `clone` drivers, although using the modern `upsdrvquery.c` API. Essentially I am parsing the protocol lines directly reading from the driver sockets, as the clone drivers do. As for ups.conf, I start up as follows without problems: [ups] driver = dummy-ups port = /etc/nut/5E.dev [ups2] driver = dummy-ups port = /etc/nut/APC.dev [failover] driver

Hi all, Yesterday?s PR #2945 got me thinking about my basic failover setup and raised some questions I didn?t want to derail the PR with?hope this is the right place to ask. Apologies if not. The PR includes this note: > NOTE: There is currently no support for "multiplexing" information or > commands for devices with multiple-media/multiple-driver access, e.g. to > gain

P.S. To articulate better what I am unclear about from your message: `nutshutdown` seems to run `@SBINDIR@/upsdrvctl shutdown`. >From my understanding, this would command - all - `ups.conf` UPS to shutdown. So this would already include the UPS monitored by any failover/multiplexing driver. In contrast, `upsdrvctl shutdown` would start up all these drivers again, respectively. What kind of

Good point, I guess I thought it knew which UPSes are getting the FSD treatment. Maybe this should also get revised eventually (e.g. a "primary" monitoring system not fed by the UPS it is wired to should never FSD itself due to the outage, but should ensure that UPS gets powered off or power-cycled when no "secondary" clients remain). Then maybe not much is needed at this

Hello Jim, Many thanks for the detailed insights?also the clarification on driver multiplexing versus failover, that was very helpful. While I don?t have much to contribute on the multiplexing front, I may take a shot at exploring the failover and proxying drivers. At the very least, it might be useful for my personal requirements; at best, perhaps to others as well, or even in support of later

Thinking of it, the service-aware nut-driver-enumerator script has ways to set dependencies of a driver on other units in the system, depending on driver type. A couple of lines added there would be useful to ensure the failover/multiplex driver(s) start after the "real" driver units they scrape data from, and it would be a "soft" dependency (real driver unit may crash without

Sounds great, thanks for the update! For communications with the other drivers (from failover or multiplexor), I suggest using the local driver socket line the clone* drivers do: this removes a dependency on `upsd` both for the service startup (no chicken-and-egg issue of drivers before upsd, but upsd before the failover driver) and for FSD end-game (after all services stopped, we just need to