search for: kuttnig

...upporting UPS to shutdown/start regardless of it. So similar to the clone* drivers, which seem not to have any special handling there. Thanks for the detailed responses 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. >...

...port values as inputs for its work or lack thereof. Probably "upsdrvctl shutdown realdriver" should work as it did, but "upsdrvctl shutdown failoverdriver" or "upsdrvctl shutdown" (for all UPSes) should do these tricks. Jim On Mon, May 12, 2025 at 5:25?PM Sebastian Kuttnig via Nut-upsdev < nut-upsdev at alioth-lists.debian.net> wrote: > 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...

...r lack thereof. Probably "upsdrvctl shutdown realdriver" should > work as it did, but "upsdrvctl shutdown failoverdriver" or "upsdrvctl > shutdown" (for all UPSes) should do these tricks. > > Jim > > > > On Mon, May 12, 2025 at 5:25?PM Sebastian Kuttnig via Nut-upsdev < > nut-upsdev at alioth-lists.debian.net> wrote: > >> 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.c...

...hutdown` script (or `upsdrvctl`) may need > an update to know to start those additional drivers. Or perhaps do them one > by one in case of shutdown command specifically (or any command generally), > until one succeeds. > > Jim > > > On Mon, May 12, 2025 at 3:22?PM Sebastian Kuttnig via Nut-upsdev < > nut-upsdev at alioth-lists.debian.net> wrote: > >> Hello again, >> >> I can report back that my failover driver is progressing nicely, and a >> lot of >> things seem to overlap with what could very well also be useful and maybe >> u...

...). Speaking of the latter, the `nutshutdown` script (or `upsdrvctl`) may need an update to know to start those additional drivers. Or perhaps do them one by one in case of shutdown command specifically (or any command generally), until one succeeds. Jim On Mon, May 12, 2025 at 3:22?PM Sebastian Kuttnig via Nut-upsdev < nut-upsdev at alioth-lists.debian.net> wrote: > Hello again, > > I can report back that my failover driver is progressing nicely, and a lot > of > things seem to overlap with what could very well also be useful and maybe > used > eventually for a future...

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

...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, > Jim Klimov > > > > On Fri, May 9, 2025 at 12:37?PM Sebastian Kuttnig via Nut-upsdev < > nut-upsdev at alioth-lists.debian.net> wrote: > >> 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...

Hello again, I can report back that my failover driver is progressing nicely, and a lot of things seem to overlap with what could very well also be useful and maybe used eventually for a future multiplexing driver. Basically, my failover logic takes driver names (sockets) in comma-separated form from the `port` variable and keeps track of these drivers, monitoring their information and failing