2008/4/8, Jean Delvare <[EMAIL PROTECTED]>: > On Tue, 8 Apr 2008 11:23:33 +0200, Arnaud Quette wrote: > > 2008/4/4, Jean Delvare <[EMAIL PROTECTED]>: > > > > * 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/ _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
