[Nut-upsdev] Joining forces with the Network UPS Tools

[Arjen de Korte]

Citeren Arnaud Quette <aquette.dev at gmail.com>:

>>> that's 1 of the 2 main use cases here.
>>> the other being that upsmon could monitor
>>> outlet.X.autoswitch.charge.low (where X is the outlet on which we
>>> subscribed the slave) against battery.charge to launch the shutdown
>>> without the need of upssched.
>>
>> I'm afraid that's something that is not very practical to use. :-)
>
> well, for the user, it simply means a small addon in upsmon.conf, like:
> MONITOR system powervalue username password type
> with system being currently:
> <upsname>[@<hostname>[:<port>]]
> transformed into:
> <upsname>[[:outlet-number]@<hostname>[:<port>]]

I understand, but still (in the context of NUT), you can't use an  
autoswitched outlet (that was my point). We need an advance warning to  
be able to shutdown clients and this is something that autoswitched  
outlets don't provide as far as I know.

> the thing is that, for that particular purpose (outlet subscription),
> we need to handle this smartly.
> we don't only want to shutdown early. But also to handle associated
> commands (off / reboot of an outlet) smartly.
> ie, the smart loads have to be instructed that they have to shutdown.
> the reboot is an extension of this case, with a sufficient delay for
> the load to shutdown.

Understood. Still I think we should either handle this in either the  
driver or maybe even the server. The latter could also add additional  
devices if it noticed that a system has multiple outlets and the provide

     upsname (default)
     upsname-0
     upsname-1
     upsname-2

for the various outlets. Basically the same idea as the chained  
approach, but with lower load on the driver (although I'm not too  
worried about that).

> The on part is then standard...

No, it isn't. That's the tricky part here. It could very well be that  
(when running on battery)  by switching off a substantial part of the  
load means the remaining runtime of a UPS goes up, higher than the  
switch-off point for that outlet. So you risk that the outputs will  
return then and the whole process starts again. Deciding when to  
switch on the loads is probably a lot more difficult than when to  
switch them off.

[...]

> interesting. don't know you if you recall, but I once talked about a
> similar approach for the composite devices (paralell/serialized UPSs,
> chained UPS and PDUs, ...) to operate some data processing.
>
> As told at the beginning of the mail, your approach fails in this
> particular case because there is no link between the real ups
> (master-ups) and the sub ones.

Sure there is, the slaves would see (almost) all the data from the  
master. To them, it is like they have a dedicated UPS with just one  
switchable outlet.

> So, what happens if you fire an outlet.1.load.off on the master?

The power to the clients on outlet 1 will be killed immediately, as  
instructed. You get what you ask for, just like what happens if you  
send the master a 'load.off' command. Whatever we do can never protect  
against operator error.

Best regards, Arjen
-- 
Please keep list traffic on the list