[Nut-upsuser] Network UPS Tools version 2.2.2-pre1 released

[Jean Delvare]

On Tue, 8 Apr 2008 11:23:33 +0200, Arnaud Quette wrote:
> 2008/4/4, Jean Delvare <khali at linux-fr.org>:
> >  * battery.temperature changed from 28 degrees C to 29.2 degrees C. Note
> >   that I am a bit skeptical about the reported value though, as it
> >   basically never changed since I installed the UPS over a month ago,
> >   while the room temperature did change a lot over this period of time.
> >   I also remember that all the apcupsd reports I found for this
> >   particular UPS model had exactly 29.2 degrees C as the battery
> >   temperature. Very suspicious isn't it? FWIW, the Windows tool that
> >   comes with this UPS doesn't display any temperature value. I suspect
> >   that the UPS doesn't actually have a temperature sensor and is
> >   returning an arbitrary temperature value instead.
> 
> iirc, that's true. But we don't have much choice there.
> the thing would be to be sure that this specific value is hard coded,
> and so that we can safely ignore it.

It seems that APC used the same USB device ID for all their USB UPS, so
if at least one of them has a real thermal sensor, we can't use that.
Testing on the temperature value won't work either - the reported value
of a real thermal sensor could happen to be 29.2 degree C. Too bad that
APC exposes this attribute even when it's not really there. 

Maybe we can match the ups.model string against a table of known
has-no-sensor model names in the driver? That's just a random proposal,
I don't feel too strongly about this. Now that I know that the reported
value is fake, I just ignore it.

> >  * ups.delay.shutdown changed from -1 to 20. 3 new attributes appeared:
> >   ups.delay.start (30), ups.timer.reboot (0) and ups.timer.shutdown
> >   (-1). No idea what the last 2 are.
> 
> yep, the -1 values were inherited from my very first USB devs.
> since these are mapped to HID values (in the UPS) and are in fact
> timers, -1 means that these are inactive. So the right values for the
> ups.delay.* are the real values (default or settings) used for the
> various shutdown sequences.
> Now, the previous ones (used for ups.delay.*) have moved to
> ups.timer.* which makes more sense.
> 
> >  * 3 new commands appeared: load.off.delay, load.on, and shutdown.return.
> >   I didn't try them, as I'm not sure I understand what "load" means in
> >   this context, and I wouldn't want to accidentally kill my server.
> 
> this is due to the rework on the shutdown handling in usbhid-ups.
> there were some wrong things that have been addressed. the result is
> that some new commands appeared. The "load" notion is linked to the
> devices wired on the UPS' output (and which sums up in the ups.load
> field).
> 
> I hope to have answered your questions.

Almost, thank you. I'm just not sure what would really happen if I were
to tun the load.off command. All devices connected to the UPS would die
in the instant?

> btw, you might be our news relay for NUT on LinuxFr ;-)
> NUT really needs some advert and promotion...
> I would also be glad to see you promoting the FLOSS/NUT friendly
> manufacturer(s) ^_^

linuxfr.org != linux-fr.org. I am in no way affiliated to the
linuxfr.org news site, sorry.

> thanks for your feedback,

You're welcome. I'll test all pre-versions until nut 2.2.2 final is
released, I'll let you know if I find any problem.

-- 
Jean Delvare