[Nut-upsdev] [nut-commits] svn commit r1765 - in trunk: . drivers man

[Arjen de Korte]

Citeren Elio Corbolante <eliocor op microdowell.com>:

>>>> 629                         dstate_setinfo("ups.realpower", "%d",
>>>> (int)((float)(p[4]*256 + p[5]) * 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  
near unity.

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[6], p[7], p[8]) ;
>>>
>>> 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