Arjen de Korte ha scritto:
Yes, that's what I'm intending to do (and what I have already done for a
large part already by the way). This will reduce the latency for changes
in the power state to essentially zero. At the same time, we can
increase the pollinterval to something like 60+ seconds or so. Receiving
an alarm will then trigger a poll of the summary and/or get_object
pages, to get all available data.
What about including these ideas and functions into the netxml-ups
driver maintaining the backward compatibility? We can create a single
subscription connection, from which we only need to read the
BelowRemainingCapacityLimit flag (to allow the use of the testing
button) and the DelayBeforeShutdown value (about the outlet used by the
system). An alarm message reception can then trigger a summary page scan
(no need to set timings) while the get_object page, with extended data,
can be read every "pollinterval" (the user can choose whether to have it
low and stress the NMC or not).
We can also lower the summary page scans, reading more data from the
alarms, for example:
- alarm level == 1 -> update data using this alarm and read the summary
page every "pollinterval"
- alarm level == 2 -> read the summary page immediately
Does it sound reasonable?
Moreover reading the summary page we also know when to start the
shutdown procedure on every outlet, so we have every kind of information
we need/want, with just a single subscription.
As far as I can see, the above value is not client specific. It would
have been nice if it was (since that would allow us to easily see that
the specific outlet was about to be shutdown), but as far as I can see,
this is the global one (not outlet/client specific). What I'm not sure
about, is what happens when you sent this via the UPS Controls page for
a simulated shutdown event. It could very well be that this would be
client specific in that case, but in practice this will be of little use
for us. During an actual mains failure, it would only be raised when the
batteries are almost flat. Since we would like to shed some loads on the
two switchable outlets long before that (the whole point of this
exercise), we probably can't use that.
Right. Alarm messages are certainly outlet specific.
Best regards,
Marco
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
