<div dir="ltr"><div dir="ltr">Hello again,<br><br>I can report back that my failover driver is progressing nicely, and a lot of<br>things seem to overlap with what could very well also be useful and maybe used<br>eventually for a future multiplexing driver.<br><br>Basically, my failover logic takes driver names (sockets) in comma-separated<br>form from the `port` variable and keeps track of these drivers, monitoring<br>their information and failing over where necessary. Basic configuration looks<br>like:<br><br> [failover]<br> driver = failover<br> port = dummy-ups-ups,dummy-ups-ups2<br><br>I could well picture a multiplexing driver accepting a similar format, merging<br>variables of both drivers and resolving conflicts by port argument order<br>(`dummy-ups-ups`, then `dummy-ups-ups2`) in its most basic form.<br><br>Additionally, this could be extended with preference arguments, such as:<br><br> prefer.ups.status = dummy-ups-ups<br> prefer.battery.voltage.nominal = dummy-ups-ups2<br><br>Such definitions would take precedence over the port argument order, for more<br>granular control. This could be similar to what is used in `ups.conf` for<br>`default.<variable>` or `override.<variable>`, format-wise.<br><br>If either driver were to drop offline, the other driver could take over with<br>its full set of variables, regardless of other set preferences.<br><br>Just a rough sketch of what I have in my mind. Time permitting, I'll start<br>working on this at some point after I finish my failover explorations.<br><br>Sebastian<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Am Mo., 12. Mai 2025 um 14:16 Uhr schrieb Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wow, that's quite the tale!<br>
<br>
I take away from this:<br>
<br>
There is a real example of wanting to merge two information sources.<br>
<br>
It's very complicated.<br>
<br>
Anybody wishing to succeed in a very complicated situation needs to<br>
really pay attention, to twice as many things as they thought when<br>
they started.<br>
<br>
It's unclear how to generalize from this to a solution that will work<br>
for the next person.<br>
<br>
but if someone wants to write soemthing that is an aggregating driver<br>
(looks like a driver, talks to N driver), and do so in a way that<br>
doesn't cause any significant pain for others that seems like a fine<br>
thing for them to do.<br>
<br>
I would suggest having some sort of config file that for each variable<br>
says which driver to prefer, and some kind of timeout for not available<br>
to flip to the backup. I guess for starters, one could configure two<br>
drivers in "fancier/less-reliable" and "old-school" slots, and prefer<br>
fancier for all except shutdown and status.<br>
<br>
I fear that the next layer is merging status from two where they don't<br>
quite match.<br>
<br>
<br>
<br>
_______________________________________________<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></div>