[Nut-upsdev] Initialising UPS variables from ups.conf

Arjen de Korte nut+devel at de-korte.org
Mon Mar 7 13:09:28 UTC 2011


Citeren John Bayly <freebsd.ports op tipstrade.net>:

> 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)




More information about the Nut-upsdev mailing list