[Nut-upsdev] Questions about failover architecture

[Sebastian Kuttnig]

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 redundant connection or a better data collection than any one driver
> provides. For some devices it may be possible to run several drivers
> independently (probably for your monitoring system to cherry-pick data
> points from one driver or another), while others might only enable any
one
> link exclusively.

That raised a few questions:

- Is there any recommended or emerging approach for UPS failover using
  multiple devices or drivers? From the note, it sounds like this isn’t
widely
  supported yet.

- Would there be interest in developing a driver (or utility) specifically
aimed
  at supporting failover logic within NUT?

For context: I currently use a custom NUT driver that polls an HTTP(S)
endpoint
which aggregates `upsc` dumps and handles failover logic outside of NUT. The
driver itself is simple—it just reports what it gets, much like `upsc`.

This setup works, but may be heavier than needed for basic failover use
cases.
I’ve been thinking about splitting the responsibilities into two drivers:

- `http-ups` (or `clone-http`): polls an HTTP(S) endpoint and reports
  `upsc`-style data; maybe useful for development or external handling.

- `failover`: monitors the sockets of other local drivers and promotes a
  primary according to some logic, if the current one fails; basic internal
handling.

Does this approach make sense in the broader NUT architecture? Would this be
something worth developing or upstreaming?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250509/136125c9/attachment.htm>