[Nut-upsdev] [nut-commits] svn commit r1765 - in trunk: . drivers man
Arjen de Korte
nut+devel at de-korte.org
Fri Feb 6 16:38:19 UTC 2009
Citeren Elio Corbolante <eliocor op microdowell.com>:
>>>> 629 dstate_setinfo("ups.realpower", "%d",
>>>> (int)((float)(p*256 + p) * 0.6)) ;
>>> This suggests a fixed relationship between apparent and active power.
>>> This might be the case for the nominal values, but this is not true in
>>> the general case. So don't export 'ups.realpower' unless it is truly
>>> measured (which is not the case here).
>> Made a comment that it is calculated. Can this be measured?
> Yes, the relation between the VA and W is fixed as in the most UPS
> sold on the market:
For the input power and a double conversion UPS, this might be the
case, although I doubt that you'll meet the EU harmonic content
regulations easily with such a poor powerfactor.
> Very few UPS have a cos phi of 1.0.
Very few small (up to a kVa) UPSes have a (near) unity powerfactor.
Many larger units have however, since for high loads you'll also have
to pay for reactive power as well, so it pays to keep the powerfactor
I do expect however that this will change in the not so distant
future, now that it is cheaper to meet harmonic content regulations by
using active PFC. So I expect older UPS designs gradually to be
replaced by newer ones, at least for the online models. For offline /
line interactive devices this probably isn't an issue.
> This particular line of UPSs has a cos phi of 0.6 and the
> calculation of the VA value is made integrating the current
> measurement (10 samples for a half sine) so the result is very near
> to an RMS value.
Understood. But this only works if the value is measured on the input
of the UPS. Usually what is expected to be reported here (at least for
NUT), is output power (VA an W). There can never be a fixed relation
between those in the general case.
> The output in W is 0.6 * VA
This is getting confusing. Please explain what is reported here.
>>> > 645 poll_interval = 2;
>>> Any particular reason to hardcode this? This might surprise people
>>> that attempt to override this value, so unless there is a real good
>>> reason to do this, it will be confusing.
>> I leave it in. Have you any good reason to have it hardcoded Elio?
> No, there were no particular reason.
> It can be any value but I thought that 2 seconds was reasonable.
In that case, please remove it. This is a value that is set through
'ups.conf' and which happens to default to 2 seconds as well. There
can be reasons to deviate from that (usually higher values to prevent
beating a UPS to death with polls), but in that case it should be
clearly documented why.
>>> > 899 dstate_setinfo("ups.StatusUPS", "%08lX",
>>> > ups.StatusUPS) ;
>>> > 900 dstate_setinfo("ups.ShortStatus", "%04X",
>>> > ups.ShortStatus) ;
>>> > 905 dstate_setinfo("ups.time", "%02d:%02d:%02d",
>>> > p, p, p) ;
>>> The above is a waste of effort. By the time upsdrv_shutdown() runs,
>>> the server won't be listening anymore.
>> Changed the status to debug messages. And removed the ups.time her,
>> as the daemon would not get it anyway.
> The UPS timer countinue to work by itself even if the computer is
> turned off: if you need, you can program/enable up to 6 weekly
> schedules in the UPS and it will turn ON/OFF without requiring any
> attached computer to it!!!
This is not the concern here. The dstate_setinfo() function reports a
value to the upsd server. But at the time the upsdrv_shutdown()
function runs, the server isn't running anymore, so there is no one
listening to us anymore. Therefor, the dstate_setinfo() function must
not be used here.
>>> > 971 ioctl(upsfd, TIOCMBIC, &rts_bit);
>>> > 972 ioctl(upsfd, TIOCMBIC, &dtr_bit);
>>> We have library functions in serial.c to handle this. Use them.
> Unfortunately (even for the debugging functions) when I wrote the
> driver (if I remember correctly) there were NO official
> documentation on the OFFICIAL functions to be used in the
> developement of the drivers.
These functions where added in the docs/new-drivers.txt document in
June 2007. The debugging functions have existed for more than five
years already (see docs/developers.txt). The latter is mandatory
reading for developers anyway.
Best regards, Arjen
Please keep list traffic on the list
More information about the Nut-upsdev