<div dir="ltr"><div>Hello Harlan,</div><div><br></div><div>  While NUT can be used to monitor and maybe manage compatible ATS/STS devices, it may be up to some other solution around it to provide a "more comprehensive operational functionality" especially for larger device population and complex topologies. It also depends on the definition of such functionality and the goals you want to achieve (yours outlined in the other thread).<br></div><div><br></div><div>  Sometimes it suffices to set up a web of `upsmon` clients to `MONITOR` UPS and ATS states, perhaps forwarding that information to `upssched` and *its* hook scripts to delay some decisions (e.g. ignore short-lived outages, or require a shutdown after some time on battery regardless of battery being full enough, or somehow aggregate knowledge that "if ATS is powered by the input coming from UPS1, we care about UPS1's alarms to gauge health of PSU2 of this bigger server"), if we stay within the NUT-provided ecosystem for this. Indeed, many users have tailored scripts and `upsmon` configurations for their set-ups, which use NUT for device interactions but logic and knowledge of who is "fed" by whom and how to react to different situations are externalized.</div><div><br></div><div>  I must acknowledge that there are also vendor-backed solutions, including some built on top of NUT, like the Eaton Intelligent Power Manager Editions (IPM2) which I used to work on some years ago (and which got me into NUT team and eventually maintainership), and is a mix of open-source core seen fresh at <a href="https://github.com/42ity">https://github.com/42ity</a> and somewhat stale at <a href="http://42ity.org/">http://42ity.org/</a>, and proprietary parts for UI and some vendor integrations, including VM engines e.g. to reduce battery power draw by shutting down lower-priority VMs and aggregate the survivors on fewer physical boxes. It does take advantage of many Eaton hardware features, some developed hand-in-hand with the software team, but remains open to working with other vendors as much as NUT supports that. It is a good example of such externalized logic and knowledge mentioned above. If you have a (small-to-medium sized?) datacenter with complex power topologies that change in real time, <a href="https://www.eaton.com/in/en-us/catalog/backup-power-ups-surge-it-power-distribution/eaton-intelligent-power-manager-.html">https://www.eaton.com/in/en-us/catalog/backup-power-ups-surge-it-power-distribution/eaton-intelligent-power-manager-.html</a> may be worth a look.</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2024 at 8:08 AM Harlan Stenn via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@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">Is there any documentation somewhere about how NUT can incorporate <br>
automatic transfer switches into its monitoring and operational <br>
framework to provide more comprehensive operational functionality?<br>
<br>
H<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>