<div dir="ltr">Hi all,<br><br>Yesterday’s PR #2945 got me thinking about my basic failover setup and raised<br>some questions I didn’t want to derail the PR with—hope this is the right place<br>to ask. Apologies if not.<br><br>The PR includes this note:<br><br>
<table class="gmail-diff-table gmail-tab-size gmail-soft-wrap gmail-js-diff-table"><tbody><tr><td class="gmail-blob-code gmail-blob-code-addition">> NOTE: There is currently no support for "multiplexing" information or <br>> commands for devices with multiple-media/multiple-driver access, e.g. to <br>> gain redundant connection or a better data collection than any one driver <br>> provides. For some devices it may be possible to run several drivers <br>> independently (probably for your monitoring system to cherry-pick data <br>> points from one driver or another), while others might only enable any one <br>> link exclusively.</td></tr><tr></tr></tbody></table><br>That raised a few questions:<br><br>- Is there any recommended or emerging approach for UPS failover using<br>  multiple devices or drivers? From the note, it sounds like this isn’t widely<br>  supported yet.<br><br>- Would there be interest in developing a driver (or utility) specifically aimed<br>  at supporting failover logic within NUT?<br><br>For context: I currently use a custom NUT driver that polls an HTTP(S) endpoint<br>which aggregates `upsc` dumps and handles failover logic outside of NUT. The<br>driver itself is simple—it just reports what it gets, much like `upsc`.<br><br>This setup works, but may be heavier than needed for basic failover use cases.<br>I’ve been thinking about splitting the responsibilities into two drivers:<br><br>- `http-ups` (or `clone-http`): polls an HTTP(S) endpoint and reports<br>  `upsc`-style data; maybe useful for development or external handling.<br><br>- `failover`: monitors the sockets of other local drivers and promotes a<br>  primary according to some logic, if the current one fails; basic internal handling.<br><br>Does this approach make sense in the broader NUT architecture? Would this be<br>something worth developing or upstreaming?<br><br>Thanks!</div>