[Nut-upsdev] Status of the PSE NUT patches (was: NUT patches)

Fri Sep 9 14:44:51 UTC 2005

Here is the status of PSE (Peter Selinger) NUT patches
for newhidups (hidparser, apc support, ...).

For the recall, the patch tracker for this item is there:
https://alioth.debian.org/tracker/index.php?func=detail&aid=302101&group_id=30602&atid=411544

- nut-cvs-patch-PARSER-2005-08-24:
approved and applied on Development tree

- nut-cvs-patch-APC-2005-08-24:
approved and applied on Development tree, minus the
ups.test.panel (see below)

- nut-cvs-patch-REOPEN-2005-08-24:
approved and applied on Development tree
Notes: - avoid cpp style comment
            - I don't see the difference as we return when
      the driver unbind has been done. You'll only get
      again the mfr,model and serial strings! Or maybe
      that was previous to my change to it (move after
      unbind)...

- nut-cvs-patch-NUMPATH-2005-08-24:
approved and applied on Development tree

- nut-cvs-patch-DEP-2005-08-24:
not applied. I'd like to have something more generic, along
with the gendb system, that will declare some base deps
(ie "main.h dstate.h serial.h" for serial drivers), and a @.h
one (need to have a .h for every driver). Then, there will
be the special cases (usb, snmp, ... drivers)

Peter wrote:
> From: arnaud.quette at mgeups.com
> >
> > Side notes:
> > -  there are few new variables that need to be added to the
> > naming scheme. These are consistant with the current naming,
> > so no problem. But we need to document these a bit:
> > Name / Description / Typical value
>
> Here are the variables that I have added, that were not already in
> docs/new-names.txt:
>
> * battery.charge.warning / Battery level when UPS switches to "Warning" / 50
>
  > This is similar to battery.charge.low. I don't actually know what happens
  > when this warning level is reached; perhaps it is just informational.

  maybe an (pre)alarm, as the low level indicates the need to shutdown...
  => ok for that one

> * battery.mfr.date / Date when the battery was manufactured / 2005/04/02
>
  > This is similar to ups.mfr.date.
  => ok for that one too, but I wonder if it wouldn't be better to have
      battery.date.change (which is currently battery.date)
      battery.date.mfr

> * ups.beeper.status / State of the beeper: enabled, disabled, or muted / enabled
>
  > The belkinunv driver uses ups.beeper.enable, with values "yes" and
  > "no", but the USB-HID Usage table for power devices actually
  > specifies three states for a generic UPS beeper (see usage
  > 0084005a, AudibleAlarmControl):
  >
    > "Read or Write value:
      > 1: Disabled (Never sound)
      > 2: Enabled (Sound when an alarm is present)
      > 3: Muted (Temporarily silence the alarm)
    > This is the requested state (Write value) or the present state (Read
    > value) of the audible alarm. The Muted state (3) persists until the
    > alarm would normally stop sounding. At the end of this period the
    > value reverts to Enabled (2). Writing the value Muted (3) when the
    > audible alarm is not sounding is accepted but otherwise has no effect."
  >
  > I therefore recommend that this variable be standardized. In fact,
  > it should be writable, but I don't know how to do this.

  hid is more complete, so it's fine as you've done:
      - variable name: ups.beeper.status
      - variable values: disabled, enabled, muted
  => ok for that one too

> * ups.test.panel / Panel test / 0
>
  > My APC UPS has a "panel test" variable, which consists of a single
  > R/W bit. In write mode: setting this to 1 causes the UPS to omit one
  > long beep. Setting this to 0 has no audible or visible effect. In
  > read mode: simply returns the value of the last "write". I surmise
  > that this variable indicates that a test is "in progess", but I am
  > not sure of the test ever stops or does anything. Since NUT has
  > instant commands "test.panel.start" and "test.panel.stop", I figured
  > it might be worth having an associated variable as well. But it
  > probably cannot be given an interesting meaning until we find other
  > APC models with more interesting panels (mine has no LED's, so there
  > is not much to test except the beeper). In particular, a panel test
  > does not seem to have any interesting "result" that is reported.

  I've not kept this one. We'll have to speak / audit a bit
  more before applying...

  Considering the fact that there are several UPS variables giving
  the result for the last {battery, panel, ...} test, we need to have
  the same granularity. So the ups.test sub collection should be
  - ups.test.result: general result
      ups.test.panel.result
      ups.test.battery.result
      ups.test.failure.result

  I would have prefered a bitwised/consolidated test.result in ups.test.result,
  but it's either not possible nor
Comments?

> > - I'll forward the PARSER patch, if accepted, to the libhid project
> > (the project I've launched for the long run hid UPS support,
> > and more generally for the opensource hid support) as the
> > code base is the same (MGE HID Parser + libusb + wrapping functions)
>
> Good. This bug is quite serious. For example, look at ALfred Ganz's
> post at
> http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-August/000015.html
> - it shows the same mangled Usage tree that I got.

due to the fact that this is the _MGE_ HID Parser, so done for
MGE's HID implementation...

> > - the APC shutdown method should be matched against
> > the apcupsd method as they have already dealed with this:
> > http://cvs.sourceforge.net/viewcvs.py/apcupsd/apcupsd/src/drivers/usb/usb.c?rev=1.17&view=markup
> > => look for usb_ups_kill_power()
>
> My change in this function is just a matter of taste. When called with
> the "-k" flag, I prefer the UPS to shut down immediately, as this will
> typically happen at the end of my shutdown script when the computer is
> ready to power off. The method that was already implemented also
> works, but has a 60 second delay. The file you reference above also
> seems to prefer a delay.

I let you check as per the info I've given before (apcupsd pointer, ...)
and with the interested user.

Arnaud Quette
---
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
OpenSource Developer - http://arnaud.quette.free.fr/
Debian Developer - http://people.debian.org/~aquette/
 ... and much more ...