<div dir="ltr"><div>Hello, and thanks for raising this discussion.</div><div><br></div><div>FWIW, the idea is (very) slowly brewing for at least a decade - backlogged since <a href="https://github.com/networkupstools/nut/issues/273">https://github.com/networkupstools/nut/issues/273</a> (which proposes to implement this over dummy-ups or clone drivers as they already have ways to talk to other NUT drivers to represent them for various purposes).</div><div><br></div><div>There is a little collection of related tickets seen by GitHub tag: <a href="https://github.com/networkupstools/nut/issues?q=state%3Aopen%20label%3A%22Data%20multipathing%22">https://github.com/networkupstools/nut/issues?q=state%3Aopen%20label%3A%22Data%20multipathing%22</a></div><div><br></div><div>General thoughts collected so far are that:</div><div>* Failover differs from multiplexing :) (Using one driver at a time or several at once)</div><div>* Practical goals may include having best info about the device, with each single driver/protocol only offering a partial aspect, and the redundancy against loss of one of the connections (e.g. serial/USB + SNMP).</div><div>* Different drivers (or even e.g. SNMP mappings to numerous served MIBs in the same driver, see <a href="https://github.com/networkupstools/nut/issues/2036">https://github.com/networkupstools/nut/issues/2036</a>) can offer different insights into the device - sets of named data points, their precision, setable 
variables and instant commands. When multiplexing, 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).</div><div>* 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.</div><div><br></div><div>But so far nothing has been fleshed out beyond that (AFAIK)...</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, May 9, 2025 at 12:37 PM Sebastian Kuttnig via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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><tbody><tr><td>> 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>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>