search for: upsdrvquery

Displaying 9 results from an estimated 9 matches for "upsdrvquery".

2023 Apr 19
2
Enhanced driver troubleshooting
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
2023 Apr 19
2
Enhanced driver troubleshooting
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
2025 May 12
1
Questions about failover architecture
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 = f...
2025 May 09
2
Questions about failover architecture
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
2025 May 12
2
Questions about failover architecture
...esponses so far, I am still exploring some areas of the NUT ecosystem. :-) Sebastian Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig < sebastian.kuttnig at gmail.com>: > 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 = dumm...
2025 May 12
1
Questions about failover architecture
...> of the NUT ecosystem. :-) > > Sebastian > > Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig < > sebastian.kuttnig at gmail.com>: > >> 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 &gt...
2025 May 09
1
Questions about failover architecture
...; we need a way (automatic and/or user-tunable) to select which variant we > prefer (exclusively, or what to try first - in case of commands or > writeable settings). > * The approach of `clone*` drivers (which talk to another driver directly > over local socket) and recent advances in `upsdrvquery.{c,h}` may be more > applicable than using a `dummy-ups` driver (is a NUT networked protocol > client when going in relay/proxy mode) that I initially thought could be > useful here. > > But so far nothing has been fleshed out beyond that (AFAIK)... > > Hope this helps, > Ji...
2025 May 12
1
Questions about failover architecture
...>> Sebastian >> >> Am Mo., 12. Mai 2025 um 16:02 Uhr schrieb Sebastian Kuttnig < >> sebastian.kuttnig at gmail.com>: >> >>> 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 >&gt...
2025 May 12
1
Questions about failover architecture
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