Nut upsdev - Jul 2005 - Some newhidups questions

Gentlemen,

I have done some experiments with an APC Back-UPS ES 650, to identify the
currently specified items that are not available with this device, and to 
find out what non-standard items the device provides. Of the currently 
specified items, the following are not available:
	UPS.Battery.Temperature
	UPS.Output.PercentLoad
	UPS.PowerSummary.DelayBeforeShutdown
	UPS.Battery.Test
	UPS.Input.Voltage
	UPS.Output.Voltage
	UPS.Output.ConfigVoltage
	UPS.BatterySystem.Battery.Test
	UPS.PowerSummary.DelayBeforeShutdown
	UPS.PowerSummary.DelayBeforeStartup

It would be helpful to get some indication as to which of the above items 
will limit operations the most. I have appended a list of the non-standard 
items that are available with the device, and I would like to ask for your 
guidance as to which items might be of interest to be added to the list of 
currently supported items, for what nut elements, and what tests I might 
perform to get more information about some attractive items.

However, the major issue that I am confronting is that the current item
for shutdown.return, does not have the effect that I think it should have
(I am using upsmon -c fsd to attempt the shutdown, with the system not
using the UPS),
1) the proper final "Executing automatic power-fail shutdown" messages
are
   issued, and the upsmon processes terminate, 
2) but even under battery operation, the device does not shed the load, 
3) the driver stays up, and upsd reports "Host 127.0.0.1 disconnected 
   (read failure)", but while the device seems to have disconnected from 
   the USB line, the driver is still attached to it,
4) I presume that if I would let the battery really go to empty, things
   would get cleaned up, and under those conditions, things might start
   cleanly, but that is not what I would like to have happen, and in any
   case, if the power were to come back before the battery is empty, the
   only possible recovery seems to be to kill everything by some other means.
Yes, I know, Arnaud hinted at this, but I wanted to see where I am at,
and now I can see clearly where I need help!

Thanks, AG

------------------------------------------------------------------------------
  UPS.PowerSummary.APCStatusFlag        (2 bytes) => 06 08              == 8
  UPS.Battery.APCBattReplaceDate        (4 bytes) => 1C 00 00 00        == 0
  UPS.Battery.APC860024                 (5 bytes) => 28 06 96 0C 8C     == ??
  UPS.APC860018.Input                   (2 bytes) => 30 78              ==
120
  UPS.APC860018.ConfigVoltage           (2 bytes) => 31 74              ==
116
  UPS.APC860018.Voltage                 (2 bytes) => 32 58              == 88
  UPS.APC860018.LowVoltageTransfer      (2 bytes) => 33 8B              ==
139
  UPS.APC860018.HighVoltageTransfer     (2 bytes) => 34 B1              ==
177
  UPS.APC860018.APC860024               (2 bytes) => 35 02              == 2
  UPS.APC860018.APC860061               (2 bytes) => 36 00              == 0
  UPS.APC860052.APCGeneralCollection    (2 bytes) => 40 00              == 0
  UPS.APC860052.APCForceShutdown        (3 bytes) => 41 FF FF           == ??
  /* { "APCDelayBeforeShutdown", 0xff86007d }, Doesn't seem to
make sense */
  UPS.APC86007d.PowerConverter          (2 bytes) => 50 04              == 4
  UPS.APC86007d.PercentLoad             (2 bytes) => 51 76              ==
118
  /* How come 0xff860024 is used both as terminal and as path ?? */
  UPS.APC860024.APC860001               (3 bytes) => 60 00 00           == 0
  UPS.APC860024.APC860023               (2 bytes) => 61 0C              ==
127
  UPS.APC860024.APC860026               (5 bytes) => 62 00 00 00 00     == 0
  UPS.APC860025                         (2 bytes) => 7F 06              == 6
  UPS.APC_UPS_FirmwareRevision          (2 bytes) => 7D 02              == 2
  UPS.APCPanelTest                      (2 bytes) => 79 00              == 0
  UPS.APC860029                         (2 bytes) => 75 43              == 67
  UPS.APC86002a                         (5 bytes) => 74 A5 06 64 64     == ??
------------------------------------------------------------------------------

-- 
 ----------------------------------------------------------------------
   Alfred Ganz					alfred-ganz@agci.com
   AG Consulting, Inc.				(203) 624-9667
   440 Prospect Street # 11
   New Haven, CT 06511
 ----------------------------------------------------------------------

[don't cc me, I'm already driving these list...]
> It would be helpful to get some indication as to which of the above items
> will limit operations the most. I have appended a list of the non-standard
> items that are available with the device, and I would like to ask for your
> guidance as to which items might be of interest to be added to the list of
> currently supported items, for what nut elements, and what tests I might
> perform to get more information about some attractive items.
>
> However, the major issue that I am confronting is that the current item
> for shutdown.return, does not have the effect that I think it should have
> (I am using upsmon -c fsd to attempt the shutdown, with the system not
> using the UPS),
>
> 1) the proper final "Executing automatic power-fail shutdown"
messages are
   > issued, and the upsmon processes terminate,

   this only means that upsmon is exiting for power fail.
   it then calls the shutdown command, which by side effect calls
   the nut init.d script with the powerdown param. This last call
   upsdrvctl shutdown, which calls the driver with "-k" (killpower).
   And this last action simply ask the driver to execute the
"upsdrv_shutdown()" function... (see below)
> 2) but even under battery operation, the device does not shed the load,
> 3) the driver stays up, and upsd reports "Host 127.0.0.1 disconnected
   > (read failure)", but while the device seems to have disconnected
from
   > the USB line, the driver is still attached to it,

the hosts disconnexion is about upsmon.
upsdrv_shutdown() has to be completed for APC, according to:
http://cvs.sourceforge.net/viewcvs.py/apcupsd/apcupsd/src/drivers/usb/usb.c?rev=1.6.2.2&view=markup
search for usb_ups_kill_power(), but other things like
s_known_info known_info should be interesting too...
> 4) I presume that if I would let the battery really go to empty, things
   > would get cleaned up, and under those conditions, things might start
   > cleanly, but that is not what I would like to have happen, and in any
   > case, if the power were to come back before the battery is empty, the
   > only possible recovery seems to be to kill everything by some other
means.

yep, but that's not a good option
> Yes, I know, Arnaud hinted at this, but I wanted to see where I am at,
> and now I can see clearly where I need help!
Another point would be to ask APC for some info about their usage name
(ie what is APC8600?? ...)

When you have studied the above, get back so we can check to
add this in newhidups.

Arnaud