Arjen de Korte
2007-Dec-29 21:44 UTC
[Nut-upsdev] [nut-commits] svn commit r1204 - in trunk: . drivers
Carlos Rodrigues wrote:> Author: carlosefr-guest > Date: Sat Dec 29 20:17:01 2007 > New Revision: 1204 > > Log: > - drivers/megatec.c: detect OB status while OFF.You've changed a bit more than this line suggests. [...]> @@ -565,10 +575,16 @@ > dstate_setinfo("input.voltage.fault", "%.1f", query.fvolt); > dstate_setinfo("output.voltage", "%.1f", query.ovolt); > dstate_setinfo("ups.load", "%.1f", query.load); > - dstate_setinfo("input.frequency", "%.1f", query.freq); > dstate_setinfo("battery.voltage", "%.2f", query.battvolt); > dstate_setinfo("ups.temperature", "%.1f", query.temp); > > + /* > + * The specification states this must be the input frequency, but > + * some vendors use it as the output frequency. The safest bet is > + * to just show the value without context and let the user decide. > + */ > + dstate_setinfo("frequency", "%.1f", query.freq); > + > charge = get_battery_charge(query.battvolt); > if (charge >= 0) { > dstate_setinfo("battery.charge", "%.1f", charge);If the specification says 'input frequency', that's what it is. If some vendors don't follow this, that's their problem. In any case I'm very much against breaking the NUT variable naming convention for something like this. If this really is a consern (which I very much doubt), I suggest to either drop this variable completely or reverse this change and put a note in the man page that some devices don't follow the specification here. Best regards, Arjen
Carlos Rodrigues
2007-Dec-29 22:12 UTC
[Nut-upsdev] [nut-commits] svn commit r1204 - in trunk: . drivers
On Dec 29, 2007 9:44 PM, Arjen de Korte <nut+devel at de-korte.org> wrote:> If the specification says 'input frequency', that's what it is. If some > vendors don't follow this, that's their problem. In any case I'm very > much against breaking the NUT variable naming convention for something > like this.According to "new-drivers.txt", I'm not breaking the variable convention at all. And it was after reading that part of the documentation that I thought this might make sense instead of keep providing a variable with dubious/false meaning. The problem with the specs, is that the only ones available seem to be from specific vendors, so there isn't actually a "right" or "wrong". There is no standard (see the problem with some models having the OFF flag enabled).> If this really is a consern (which I very much doubt), I suggest to > either drop this variable completely or reverse this change and put a > note in the man page that some devices don't follow the specification here.Dropping this variable is not very nice, since the frequency is a very good indicator of power quality. And there's something more to this than a reverse of meaning from some vendors. My UPS (a standby model) seems to be showing input frequency while there is line power, but then it keeps showing a value even on battery. If you think about it, it actually makes (some) sense. While on line power this is the frequency directly from the input, but while on battery it is the output frequency from the inverter. Ratings information also avoids defining nominal frequency and voltage as either input or output. Again, I'd like to hear from whomever wrote that bit in new-drivers.txt what the intention was. If I'm interpreting it wrong, I'll do the appropriate changes, no problems whatsoever. -- Carlos Rodrigues
Reasonably Related Threads
- fentonups driver patch for Effekta MHD3000 UPS
- [nut-commits] svn commit r1502 - in trunk: . drivers man
- [nut-commits] svn commit r1765 - in trunk: . drivers man
- Re: [nut-commits] svn commit r430 - in branches/Testing: . docs drivers man
- Re: About blazer, powermust and mustek