Citeren John Bayly <[email protected]>:
I'll look into how that works, thanks. These look like they do
exactly the job for specifying the delays for the switched outlets
(outlet.1.delay.start).
I don't think so. Why don't you just use 'upsrw' to change these
values? These are supposed to be R/W values in the UPS.
Is there any reason why they're a "hidden feature"?
Well, basically because we have not taken the time to document them.
Part of the reason why this is so tricky, is that you'll also have to
be careful when to use them. Note that these values only change the
way how variables are stored internally in the dstate variable tree.
If a driver doesn't use that tree to base decision on, you'll only
change the reported values (upsc) and the driver will still use the
actual values from the UPS. That will make for some interesting
debugging...
Should I rely on this remaining?
I use it (need it, see below) so it probably will stay with us for
quite some time. :-)
Is it driver specific?
It is not driver specific, but really only meant to provide values for
variables the UPS doesn't report, but which we really want it to
report (default) or for values that are obviously wrong (override).
For instance, my MGE Evolution 650 happily reports
battery.voltage = 13.0
battery.voltage.nominal = 24
while it actually uses a 12 V battery system (unlike it's bigger
siblings, which indeed have a 24 V battery). In order correctly
display the battery voltage meter in the CGI scripts, I use
override.battery.voltage.nominal = 12
in my ups.conf to correct this. Obviously, this only works for
(semi)static values, you can't use this for dynamic things like input
voltage or temperature (you could actually, but it wouldn't make sense).
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
