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

[Arnaud Quette]

2008/4/8, Jean Delvare <khali at linux-fr.org>:
> 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?

exactly.

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

my bad, it's really too similar ;-)
and it's sad since we really lack advocates!

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

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/