Discussion:
[Nut-upsuser] Support of "shutdown.return" on a APC Back-UPS CS 500
Ritchie
2010-11-07 15:35:43 UTC
Permalink
Hi all,

I am trying to get a APC Back-UPS CS 500 running on my QNAP 419P Nas.

Since on all my work I figure out the following:

from Network UPS Tools upscmd 2.4.1
[~] # upscmd -l qnapups
Instant commands supported on UPS [qnapups]:

beeper.disable - Disable the UPS beeper
beeper.enable - Enable the UPS beeper
beeper.mute - Temporarily mute the UPS beeper
beeper.off - Obsolete (use beeper.disable or beeper.mute)
beeper.on - Obsolete (use beeper.enable)
load.off - Turn off the load immediately
load.off.delay - Turn off the load with a delay (seconds)
shutdown.reboot - Shut down the load briefly while rebooting the UPS
shutdown.stop - Stop a shutdown in progress
test.panel.start - Start testing the UPS panel
test.panel.stop - Stop a UPS panel test

I am missing the command "shutdown.return' ?
Does the ups not support this command ?

Thanks for help

Ritchie
Arjen de Korte
2010-11-07 17:48:40 UTC
Permalink
Post by Ritchie
I am trying to get a APC Back-UPS CS 500 running on my QNAP 419P Nas.
[...]
Post by Ritchie
I am missing the command "shutdown.return' ?
Does the ups not support this command ?
It might support it, but not in the USB HID PDC paths that we
recognize. If this is supported by this UPS, it is probably in a
vendor specific path. Unless someone is able to provide the mapping,
we have no idea which one.

Search the archives for more information about this issue. It has
popped up several times over past few years. Sadly nobody has reported
the solution to this and since none of the active NUT developers owns
such a device, this likely is going to stay that way.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-14 12:58:41 UTC
Permalink
Post by Arjen de Korte
Post by Ritchie
I am trying to get a APC Back-UPS CS 500 running on my QNAP 419P Nas.
[...]
Post by Ritchie
I am missing the command "shutdown.return' ?
Does the ups not support this command ?
It might support it, but not in the USB HID PDC paths that we
recognize. If this is supported by this UPS, it is probably in a
vendor specific path. Unless someone is able to provide the mapping,
we have no idea which one.
Search the archives for more information about this issue. It has
popped up several times over past few years. Sadly nobody has reported
the solution to this and since none of the active NUT developers owns
such a device, this likely is going to stay that way.
Best regards, Arjen
Arjen,

I have been using usb APC units (CS 500 and SmartUPS 1000) with nut for some 6
years. I got this to work after extensive trawling of the net and found a fix
involving changing the source and recompiling usbhid-ups (or hidups as it used
to be).

Now the bad news. Although I am still using the recompiled version of hidups and
(64 bit) usbhid-ups, I have stupidly lost the source and my notes. :-( Is it
any use to you to have the executables?

This has been driving me nuts for the last week, as I now have another CS 500 to
install, and only a 5 year old version of hidups to do it with!

Regards,
Kevin.
Arjen de Korte
2011-01-16 20:29:03 UTC
Permalink
Post by Kevin
I have been using usb APC units (CS 500 and SmartUPS 1000) with nut for some 6
years. I got this to work after extensive trawling of the net and found a fix
involving changing the source and recompiling usbhid-ups (or hidups as it used
to be).
It's sad that you never submitted these changes back to NUT, so that
other people might benefit from them.
Post by Kevin
Now the bad news. Although I am still using the recompiled version of hidups and
(64 bit) usbhid-ups, I have stupidly lost the source and my notes. :-( Is it
any use to you to have the executables?
No.
Post by Kevin
This has been driving me nuts for the last week, as I now have
another CS 500 to
install, and only a 5 year old version of hidups to do it with!
Have you tried the latest version (nut-2.6.0) that was released only a
couple of days ago? Chances are that it might just work, since we have
seen reports about people running the CS 500 in recent years.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-17 15:42:55 UTC
Permalink
Post by Arjen de Korte
It's sad that you never submitted these changes back to NUT, so that
other people might benefit from them.
Yes indeed, although I don't by any means consider myself an expert, and the
changes that I made were just cludges to get the thing working for me.
Post by Arjen de Korte
Have you tried the latest version (nut-2.6.0) that was released only a
couple of days ago? Chances are that it might just work, since we have
seen reports about people running the CS 500 in recent years.
Yes, I have now had a chance to try this version and can confirm that it does
not work on either the Smart-1000 or the CS 500. It shuts them both down, never
to start up again without operator intervention.

(I should make it clear that I only use these in a server environment, so I am
only interested in the shutdown function for the PC and the sleep/hibernate
commands for the UPS.)

I have also done some experimenting with the working executables that I have,
running them in debug mode. The output of the hidups indicated
setvalue(0xff860077c,1) so I modified the code from nut-2.0.0 as follows:

void upsdrv_shutdown(void)
{
/* XXX: replace with a proper shutdown function
fatalx("shutdown not supported"); */

/* 1) set DelayBeforeStartup */
if (getval ("ondelay"))
ondelay = atoi (getval ("ondelay"));

/* setvalue(UPS_WAKEDELAY, ondelay); */ /* commented out this line for
APC CS 500 */

/* 2) set DelayBeforeShutdown */
if (getval ("offdelay"))
offdelay = atoi (getval ("offdelay"));

/* setvalue(UPS_GRACEDELAY, offdelay); */
setvalue(0xff86007c, 1);
}

and tested it against the CS 500. This works. When the CS 500 goes into sleep
mode, the red (Overload) and the green (online) lights flash alternately for
about 10 seconds, the load is switched off, and then all the lights go out until
the power comes back.

I haven't finished testing the Smart-1000 yet. I have code that works, and
outputs the following:

Initiating UPS shutdown
upsdrv_shutdown...
instcmd(shutdown.return, [NULL])
find_nut_info: unknown info type: shutdown.return

instcmd(load.on.delay, [NULL])
find_nut_info: unknown info type: load.on.delay

instcmd: info element unavailable load.on.delay

instcmd(shutdown.reboot, [NULL])
Report[set]: (4 bytes) => 13 0a 00 00
upsdrv_cleanup...

but have yet to work out the changes that I made to bring this about. The debug
output is not as easy to work with as the old hidups driver and the code has
become much more complex.

If and when I find out more, I will post the results.
Arjen de Korte
2011-01-17 16:44:59 UTC
Permalink
Post by Kevin
Post by Arjen de Korte
Have you tried the latest version (nut-2.6.0) that was released only a
couple of days ago? Chances are that it might just work, since we have
seen reports about people running the CS 500 in recent years.
Yes, I have now had a chance to try this version and can confirm that it does
not work on either the Smart-1000 or the CS 500. It shuts them both down, never
to start up again without operator intervention.
Please post the first 30 seconds worth of

/path/to/usbhid-ups -DD -u root -a upsname > APC_CS500.txt 2>&1

here. Make sure to stop any running driver before doing so and be so
kind to zip the resulting logfile.
Post by Kevin
(I should make it clear that I only use these in a server
environment, so I am
only interested in the shutdown function for the PC and the sleep/hibernate
commands for the UPS.)
I have also done some experimenting with the working executables that I have,
running them in debug mode. The output of the hidups indicated
void upsdrv_shutdown(void)
{
/* XXX: replace with a proper shutdown function
fatalx("shutdown not supported"); */
/* 1) set DelayBeforeStartup */
if (getval ("ondelay"))
ondelay = atoi (getval ("ondelay"));
/* setvalue(UPS_WAKEDELAY, ondelay); */ /* commented out this line for
APC CS 500 */
/* 2) set DelayBeforeShutdown */
if (getval ("offdelay"))
offdelay = atoi (getval ("offdelay"));
/* setvalue(UPS_GRACEDELAY, offdelay); */
setvalue(0xff86007c, 1);
}
This version is way too old to be of any use. We already know that
0xff86007c is APCDelayBeforeReboot and we already try that after the
shutdown.return command fails. Only if that one fails too, we use
load.off.delay.
Post by Kevin
I haven't finished testing the Smart-1000 yet. I have code that works, and
Initiating UPS shutdown
upsdrv_shutdown...
instcmd(shutdown.return, [NULL])
find_nut_info: unknown info type: shutdown.return
instcmd(load.on.delay, [NULL])
find_nut_info: unknown info type: load.on.delay
instcmd: info element unavailable load.on.delay
instcmd(shutdown.reboot, [NULL])
Report[set]: (4 bytes) => 13 0a 00 00
upsdrv_cleanup...
This is what the nut-2.6.0 usbhid-ups driver will do by default, so
I'm not surprised. Double check which version of the driver you're
running in your tests (preferably by checking with 'upsc'). I will not
answer further messages unless you make clear which version of the
driver you're running and whether or not you modified it.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-18 12:55:07 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
Post by Arjen de Korte
Have you tried the latest version (nut-2.6.0) that was released only a
couple of days ago? Chances are that it might just work, since we have
seen reports about people running the CS 500 in recent years.
Yes, I have now had a chance to try this version and can confirm that it does
not work on either the Smart-1000 or the CS 500. It shuts them both down, never
to start up again without operator intervention.
Please post the first 30 seconds worth of
/path/to/usbhid-ups -DD -u root -a upsname > APC_CS500.txt 2>&1
here. Make sure to stop any running driver before doing so and be so
kind to zip the resulting logfile.
Post by Kevin
(I should make it clear that I only use these in a server
environment, so I am
only interested in the shutdown function for the PC and the sleep/hibernate
commands for the UPS.)
I have also done some experimenting with the working executables that I have,
running them in debug mode. The output of the hidups indicated
void upsdrv_shutdown(void)
{
/* XXX: replace with a proper shutdown function
fatalx("shutdown not supported"); */
/* 1) set DelayBeforeStartup */
if (getval ("ondelay"))
ondelay = atoi (getval ("ondelay"));
/* setvalue(UPS_WAKEDELAY, ondelay); */ /* commented out this line for
APC CS 500 */
/* 2) set DelayBeforeShutdown */
if (getval ("offdelay"))
offdelay = atoi (getval ("offdelay"));
/* setvalue(UPS_GRACEDELAY, offdelay); */
setvalue(0xff86007c, 1);
}
This version is way too old to be of any use. We already know that
0xff86007c is APCDelayBeforeReboot and we already try that after the
shutdown.return command fails. Only if that one fails too, we use
load.off.delay.
Post by Kevin
I haven't finished testing the Smart-1000 yet. I have code that works, and
Initiating UPS shutdown
upsdrv_shutdown...
instcmd(shutdown.return, [NULL])
find_nut_info: unknown info type: shutdown.return
instcmd(load.on.delay, [NULL])
find_nut_info: unknown info type: load.on.delay
instcmd: info element unavailable load.on.delay
instcmd(shutdown.reboot, [NULL])
Report[set]: (4 bytes) => 13 0a 00 00
upsdrv_cleanup...
This is what the nut-2.6.0 usbhid-ups driver will do by default, so
I'm not surprised. Double check which version of the driver you're
running in your tests (preferably by checking with 'upsc'). I will not
answer further messages unless you make clear which version of the
driver you're running and whether or not you modified it.
Best regards, Arjen
Hi Arjen,

I have some more results for you:

After a further day testing, I have found that the two devices behave
differently.

To avoid any confusion, I ran the following:

wget http://www.networkupstools.org/source/2.6/nut-2.6.0.tar.gz
tar xvf nut-2.6.0.tar.gz (note: despite the name, this is not a gzipped
file)
cd nut-2.6.0
./configure --prefix= --sysconfdir=/etc/ups --with-statepath=/var/run/nut --
with-user=nut --with-group=uucp --without-serial
make
cd drivers/
./usbhid-ups -DDDDD -k -a apc1500


Last few lines of output:

0.686042 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature,
ReportID: 0x14, Offset: 0, Size: 8, Value: 2
0.686059 send_to_all: ADDCMD beeper.disable
0.686075 hid_lookup_usage: UPS -> 00840004
0.686092 hid_lookup_usage: PowerSummary -> 00840024
0.686107 hid_lookup_usage: AudibleAlarmControl -> 0084005a
0.686121 string_to_path: depth = 3
0.686139 Report[buf]: (2 bytes) => 14 02
0.686154 PhyMax = 0, PhyMin = 0, LogMax = 3, LogMin = 1
0.686168 Unit = 00000000, UnitExp = 0
0.686182 Exponent = 0
0.686198 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature,
ReportID: 0x14, Offset: 0, Size: 8, Value: 2
0.686228 send_to_all: ADDCMD beeper.mute
0.686250 send_to_all: ADDCMD load.off
0.686274 send_to_all: ADDCMD load.on
0.686293 send_to_all: ADDCMD shutdown.return
0.686310 send_to_all: ADDCMD shutdown.stayoff
0.686325 Initiating UPS shutdown
0.686340 upsdrv_shutdown...
0.686365 instcmd(shutdown.return, [NULL])
0.686382 find_nut_info: unknown info type: shutdown.return
0.686398 instcmd(load.on.delay, 30)
0.686433 Unit = 00001001, UnitExp = 0
0.686450 Exponent = 0
0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.690437 Report[set]: (3 bytes) => 28 1e 00
0.690437 Set report succeeded
0.690437 instcmd: SUCCEED

0.690437 instcmd(load.off.delay, 20)
0.690437 Unit = 00001001, UnitExp = 0
0.690437 Exponent = 0
0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.695437 Report[set]: (3 bytes) => 12 14 00
0.695437 Set report succeeded
0.695437 instcmd: SUCCEED

0.695437 upsdrv_cleanup...


APC CS 500
This shuts down the APC CS 500 after 20 seconds. (and it stays shutdown)

APC Smart-UPS 1000
If the power is left on, switches to battery and back online after 2 seconds.
If the power is off, goes to sleep after 90 seconds. (and comes back on when the
power is connected)


Then I connected the Smart-UPS 1000 and ran:

(pwd; ps ax | grep usbhid; ./usbhid-ups -DD -u root -a apc1500) >
APC_Smart_UPS_1000.txt 2>&1


Then again with the CS 500 connected:

(pwd; ps ax | grep usbhid; ./usbhid-ups -DD -u root -a apc1500) > APC_CS_500.txt
2>&1

I will email the zip files to you.

Regards,
Kevin.
PS. I have also tried the 2.4.x code, which works properly with the Smart-UPS
1000, but not with the CS 500.
Arjen de Korte
2011-01-18 13:15:48 UTC
Permalink
Post by Kevin
0.686325 Initiating UPS shutdown
0.686340 upsdrv_shutdown...
0.686365 instcmd(shutdown.return, [NULL])
0.686382 find_nut_info: unknown info type: shutdown.return
This is normal. Some UPS'es (models that have a HID layer around an
essential serial interface) support a command that will result in what
NUT calls 'shutdown.return', so that's what we try first. A true HID
PDC UPS (like the APC models you have) don't, so this command is not
found. This is exactly what we expect.
Post by Kevin
0.686398 instcmd(load.on.delay, 30)
0.686433 Unit = 00001001, UnitExp = 0
0.686450 Exponent = 0
0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.690437 Report[set]: (3 bytes) => 28 1e 00
0.690437 Set report succeeded
0.690437 instcmd: SUCCEED
In a HID PDC UPS, you need to set both the timer for shutdown and
(re)start independently. They start counting down immediately after
setting the report, so we set the (re)start timer...
Post by Kevin
0.690437 instcmd(load.off.delay, 20)
0.690437 Unit = 00001001, UnitExp = 0
0.690437 Exponent = 0
0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.695437 Report[set]: (3 bytes) => 12 14 00
0.695437 Set report succeeded
0.695437 instcmd: SUCCEED
...before the stop timer, so that we don't get stuck if the power is
lost. In that case, the (re)start timer will have expired and a UPS
will not start again.
Post by Kevin
APC CS 500
This shuts down the APC CS 500 after 20 seconds. (and it stays shutdown)
This probably means the driver called 'load.off.delay 20', which is
the last resort option for the usbhid-ups. It looks like it doesn't
have a mapping for 'shutdown.reboot', which the logs you have produced
should reveal.
Post by Kevin
APC Smart-UPS 1000
If the power is left on, switches to battery and back online after 2 seconds.
Either the HID PDC implementation in this UPS is broken or what you're
seeing is 'shutdown.reboot'. The timers are in seconds and with mains
present, the UPS should stop 20 seconds after running this command and
resume again 10 (30-20) seconds later.
Post by Kevin
If the power is off, goes to sleep after 90 seconds. (and comes back
on when the power is connected)
This is broken either way. There is nothing we can do about that.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-18 15:54:01 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
0.686325 Initiating UPS shutdown
0.686340 upsdrv_shutdown...
0.686365 instcmd(shutdown.return, [NULL])
0.686382 find_nut_info: unknown info type: shutdown.return
This is normal. Some UPS'es (models that have a HID layer around an
essential serial interface) support a command that will result in what
NUT calls 'shutdown.return', so that's what we try first. A true HID
PDC UPS (like the APC models you have) don't, so this command is not
found. This is exactly what we expect.
Post by Kevin
0.686398 instcmd(load.on.delay, 30)
0.686433 Unit = 00001001, UnitExp = 0
0.686450 Exponent = 0
0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.690437 Report[set]: (3 bytes) => 28 1e 00
0.690437 Set report succeeded
0.690437 instcmd: SUCCEED
In a HID PDC UPS, you need to set both the timer for shutdown and
(re)start independently. They start counting down immediately after
setting the report, so we set the (re)start timer...
Post by Kevin
0.690437 instcmd(load.off.delay, 20)
0.690437 Unit = 00001001, UnitExp = 0
0.690437 Exponent = 0
0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.695437 Report[set]: (3 bytes) => 12 14 00
0.695437 Set report succeeded
0.695437 instcmd: SUCCEED
...before the stop timer, so that we don't get stuck if the power is
lost. In that case, the (re)start timer will have expired and a UPS
will not start again.
Post by Kevin
APC CS 500
This shuts down the APC CS 500 after 20 seconds. (and it stays shutdown)
This probably means the driver called 'load.off.delay 20', which is
the last resort option for the usbhid-ups. It looks like it doesn't
have a mapping for 'shutdown.reboot', which the logs you have produced
should reveal.
Post by Kevin
APC Smart-UPS 1000
If the power is left on, switches to battery and back online after 2 seconds.
Either the HID PDC implementation in this UPS is broken or what you're
seeing is 'shutdown.reboot'. The timers are in seconds and with mains
present, the UPS should stop 20 seconds after running this command and
resume again 10 (30-20) seconds later.
Post by Kevin
If the power is off, goes to sleep after 90 seconds. (and comes back
on when the power is connected)
This is broken either way. There is nothing we can do about that.
Best regards, Arjen
Thanks for the response.

I have to say that this is way beyond me. We know that the UPS models in
question support the function that we want (sleep/hibernate), and we know the
command that is needed to initiate that state. It's been working in previous
releases on at least the Smart-UPS 1000, and it was working with a small
amendment to the code on the old hidups module.

It's a shame that I can't seem to get the up to date releases working properly
on both of these UPS models, specially after seeing that it can be done,
apparently fairly simply, by sending the 0xff86007c code in both cases.

Anyway, at lease I have now shared the very limited knowledge that I have gained
from the exercise with the NUT user community, so maybe, hopefully, someone will
be able to benefit from it in the future.

Regards,
Kevin.
Arjen de Korte
2011-01-18 20:13:44 UTC
Permalink
Post by Kevin
It's a shame that I can't seem to get the up to date releases
working properly
on both of these UPS models, specially after seeing that it can be done,
apparently fairly simply, by sending the 0xff86007c code in both cases.
As far as I can tell from your previous message, it works (with
nut-2.6.0) for the Smart-UPS 1000, right?
Post by Kevin
Anyway, at lease I have now shared the very limited knowledge that I have gained
from the exercise with the NUT user community, so maybe, hopefully, someone will
be able to benefit from it in the future.
They won't, because you have not posted the logs I asked you about.
Only those will be able to provide us with the needed information
about how to talk to your UPSes. We don't expect you to modify the
code, but at least provide us with enough info so that one of the
developers can do it.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin Myers
2011-01-19 02:36:59 UTC
Permalink
Post by Arjen de Korte
As far as I can tell from your previous message, it works (with
nut-2.6.0) for the Smart-UPS 1000, right?
No, although it does go into sleep mode if the power is off at the right
time, it doesn't cycle the power otherwise so the load will not reboot
after the shutdown. I'll do some more testing today.
Post by Arjen de Korte
Post by Kevin
Anyway, at lease I have now shared the very limited knowledge that I have gained
from the exercise with the NUT user community, so maybe, hopefully, someone will
be able to benefit from it in the future.
They won't, because you have not posted the logs I asked you about.
Only those will be able to provide us with the needed information
about how to talk to your UPSes. We don't expect you to modify the
code, but at least provide us with enough info so that one of the
developers can do it.
Attached to this message. I was posting from the web before.so sent them
separately and apparently they didn't arrive.

Happy to give you all the information necessary in order to get this
working properly with these units.

Regards,
Kevin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC_driver_text.zip
Type: application/x-compressed
Size: 9676 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110119/1229668f/attachment-0001.bin>
Arjen de Korte
2011-01-19 08:31:05 UTC
Permalink
Post by Kevin Myers
Post by Arjen de Korte
As far as I can tell from your previous message, it works (with
nut-2.6.0) for the Smart-UPS 1000, right?
No, although it does go into sleep mode if the power is off at the
right time, it doesn't cycle the power otherwise so the load will
not reboot after the shutdown. I'll do some more testing today.
Please also post the output of 'upsc upsname' (see 'man 8 upsc') and
'upscmd -l upsname' (see 'man 8 upscmd') for both devices, so that we
can see which commands are detected.

It may be a log easier to do the testing with the upscmd
'shutdown.return' (Smart-UPS 1000) and 'shutdown.reboot' (CS-500)
while the upsd server is running. During testing, it allows you to run
an instance of upslog (see 'man 8 upslog') so that you'll be able to
see the 'ups.timer.*' variables counting down. I suspect that the
current mapping might be wrong.

Also note that the (re)start delay set in the Smart-UPS 1000 is
presently set to 180 seconds, so you may have to wait a little longer
that expected for the output to be switched on after the power returns.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-19 11:36:44 UTC
Permalink
Post by Arjen de Korte
Please also post the output of 'upsc upsname' (see 'man 8 upsc') and
'upscmd -l upsname' (see 'man 8 upscmd') for both devices, so that we
can see which commands are detected.
It may be a log easier to do the testing with the upscmd
'shutdown.return' (Smart-UPS 1000) and 'shutdown.reboot' (CS-500)
while the upsd server is running. During testing, it allows you to run
an instance of upslog (see 'man 8 upslog') so that you'll be able to
see the 'ups.timer.*' variables counting down. I suspect that the
current mapping might be wrong.
Also note that the (re)start delay set in the Smart-UPS 1000 is
presently set to 180 seconds, so you may have to wait a little longer
that expected for the output to be switched on after the power returns.
Thanks Arjen. I've spent a little more time on it today and can confirm
that shutdown.reboot works as expected with the Smart-UPS 1000. (I only
tested this by commenting out the shutdown.return code in the usbhid-ups
driver) I will try with the upscmd command tomorrow.

This matches and confirms the behaviour of the 2.4 versions.

It is easy to tell when this is working properly, as both of the units
have a flashing light sequence that signifies they are going into sleep
mode.

As an aside, I gather that all the APC units will now switch into sleep
mode automatically at a specific low battery state, so actually
switching off as a last resort may be counter productive.

I haven't been able to get the CS 500 into sleep mode at all, apart from
by using the old hidups driver that I modified to setvalue(0x86007c, 1)
The 2.6 version shutdown.reboot definitely does not work - it doesn't
seem to have any effect at all.

I will post the further information you have asked for tomorrow and also
experiment with the upslog. I haven't seen output matching 'ups.timer'
from this before, there must be a verbose command I haven't found yet.

Regards,
Kevin.
Kevin
2011-01-20 10:08:08 UTC
Permalink
Post by Kevin
Post by Arjen de Korte
Please also post the output of 'upsc upsname' (see 'man 8 upsc') and
'upscmd -l upsname' (see 'man 8 upscmd') for both devices, so that we
can see which commands are detected.
APC Smart-UPS 1000

# clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 31.5
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.4.1
driver.version.data: APC HID 0.93
driver.version.internal: 0.34
input.voltage: 224.6
output.voltage: 224.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.vendorid: 051d


# ./clients/upscmd -l apc1500
Instant commands supported on UPS [apc1500]:

beeper.disable - Description unavailable
beeper.enable - Description unavailable
beeper.mute - Description unavailable
beeper.off - Description unavailable
beeper.on - Description unavailable
load.off - Description unavailable
load.off.delay - Description unavailable
load.on - Description unavailable
load.on.delay - Description unavailable
shutdown.reboot - Description unavailable
shutdown.return - Description unavailable
shutdown.stayoff - Description unavailable
shutdown.stop - Description unavailable
test.battery.start.deep - Description unavailable
test.battery.start.quick - Description unavailable
test.battery.stop - Description unavailable
test.panel.start - Description unavailable
test.panel.stop - Description unavailable




APC CS 500

# clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2010/09/19
battery.mfr.date: 2010/09/19
battery.runtime: 3877
battery.runtime.low: 120
battery.temperature: 29.2
battery.type: PbAc
battery.voltage: 13.6
battery.voltage.nominal: 12.0
device.mfr: American Power Conversion
device.model: Back-UPS CS 500
device.serial: 4B1038P51197
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95
driver.version.internal: 0.35
input.sensitivity: medium
input.voltage: 224.0
input.voltage.nominal: 230
output.voltage: 230.0
output.voltage.nominal: 230.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 808.q10 .I
ups.firmware.aux: q10
ups.load: 0.0
ups.mfr: American Power Conversion
ups.mfr.date: 2010/09/19
ups.model: Back-UPS CS 500
ups.productid: 0002
ups.serial: 4B1038P51197
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.timer.start: 0
ups.vendorid: 051d


# ./clients/upscmd -l apc1500
Instant commands supported on UPS [apc1500]:

beeper.disable - Description unavailable
beeper.enable - Description unavailable
beeper.mute - Description unavailable
beeper.off - Description unavailable
beeper.on - Description unavailable
load.off - Description unavailable
load.off.delay - Description unavailable
load.on - Description unavailable
load.on.delay - Description unavailable
shutdown.reboot - Description unavailable
shutdown.return - Description unavailable
shutdown.stayoff - Description unavailable
shutdown.stop - Description unavailable
test.battery.start.deep - Description unavailable
test.battery.start.quick - Description unavailable
test.battery.stop - Description unavailable
test.panel.start - Description unavailable
test.panel.stop - Description unavailable
Post by Kevin
Post by Arjen de Korte
It may be a log easier to do the testing with the upscmd
'shutdown.return' (Smart-UPS 1000) and 'shutdown.reboot' (CS-500)
while the upsd server is running. During testing, it allows you to run
an instance of upslog (see 'man 8 upslog') so that you'll be able to
see the 'ups.timer.*' variables counting down. I suspect that the
current mapping might be wrong.
Also note that the (re)start delay set in the Smart-UPS 1000 is
presently set to 180 seconds, so you may have to wait a little longer
that expected for the output to be switched on after the power returns.
Thanks Arjen. I've spent a little more time on it today and can confirm
that shutdown.reboot works as expected with the Smart-UPS 1000. (I only
tested this by commenting out the shutdown.return code in the usbhid-ups
driver) I will try with the upscmd command tomorrow.
This matches and confirms the behaviour of the 2.4 versions.
On the Smart-UPS 1000, all the instant commands do more or less what you would
expect. Looking at the timers using "upsc apc1500" I now see that:

shutdown.
load.off/load.off.delay both set the shutdown timer to 90, shuts down
after 90 seconds

reboot sets the reboot timer to 90, sleeps after 90 seconds

return immediately switches to battery for a moment, sets both shutdown
and startup to 90 seconds, sleeps after 90 seconds

test.panel and beeper commands also work as expected.

So you are right, it does seem to be working on this model. I don't know why I
didn't see this when I was testing originally. Also I don't understand why the
shutdown.return, which seems to be translated to "load.on.delay, load.off.delay"
is used in preference to the "shutdown.reboot" command.
Post by Kevin
I haven't been able to get the CS 500 into sleep mode at all, apart from
by using the old hidups driver that I modified to setvalue(0x86007c, 1)
The 2.6 version shutdown.reboot definitely does not work - it doesn't
seem to have any effect at all.
On the CS 500 the load.off switches it off immediately, the load.off delay,
shutdown.return and shutdown.stayoff all switch to battery, and set the shutdown
timer to 20 seconds and then shuts down after that time. (Never restarts) The
beeper commands work, as does the shutdown.stop (sets the shutdown timer to -1)

Regards,
Kevin.
Kevin
2011-01-20 10:19:01 UTC
Permalink
Kevin <bakdong <at> gmail.com> writes:

Sorry, this is the correct output for the Smart-UPS 1000


# clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 6300
battery.runtime.low: 120
battery.temperature: 31.5
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 226.0
output.voltage: 226.0
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.2
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d
Arjen de Korte
2011-01-20 16:46:48 UTC
Permalink
Post by Kevin
On the Smart-UPS 1000, all the instant commands do more or less what you would
shutdown.
load.off/load.off.delay both set the shutdown timer to 90, shuts down
after 90 seconds
It looks like this is the minimum time the UPS allows. On almost every
other HID PDC UPS we know of, the granularity is much finer than that
(usually one to ten seconds). It is quite possible that your UPS was
originally designed with a serial interface (possibly even a dumb one)
and that the USB interface was added later on. So this may be all the
underlying hardware supports.
Post by Kevin
reboot sets the reboot timer to 90, sleeps after 90 seconds
Same here.
Post by Kevin
return immediately switches to battery for a moment, sets both shutdown
and startup to 90 seconds, sleeps after 90 seconds
That is very odd. You could try what happens if you change the
'ondelay' and 'offdelay' values in 'ups.conf'. Set offdelay to 1
second and ondelay to 100/200/400 seconds and run the shutdown.return
command again (while monitoring the 'ups.timer.shutdown' and
'ups.timer.start' through upslog or upsc.
Post by Kevin
test.panel and beeper commands also work as expected.
So you are right, it does seem to be working on this model. I don't know why I
didn't see this when I was testing originally. Also I don't
understand why the
shutdown.return, which seems to be translated to "load.on.delay, load.off.delay"
is used in preference to the "shutdown.reboot" command.
According to the USB HID PDC specifications, the 'reboot n' command
will kill the power immediately and return after 'n' seconds if power
is present or will wait until the power returns if it wasn't. We
prefer to have a little grace period, so that's why we do the two step
approach of setting both the shutdown and (re)start timers.

By setting a restart timer longer than the shutdown timer, this
effectively allows for a grace period until the UPS switches off. From
then it behaves like a reboot command. You need this grace period if
you want your system to hibernate instead of shutdown, since the Linux
kernel doesn't allow calling hooks just before it powers off the system.

Apparently, due to the dreadful granularity of your UPS hardware
timers the commands we send

load.on.delay 30
load.off.delay 20

are interpreted as setting both to 90 seconds. Worse, since the
ups.timer.start elapses before the ups.timer.shutdown, this
effectively puts the UPS to sleep.
Post by Kevin
On the CS 500 the load.off switches it off immediately, the load.off delay,
shutdown.return and shutdown.stayoff all switch to battery, and set the shutdown
timer to 20 seconds and then shuts down after that time. (Never restarts) The
beeper commands work, as does the shutdown.stop (sets the shutdown timer to -1)
This probably requires some remapping of variables. I'll see if I can
find a solution for that.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-21 04:28:33 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
return immediately switches to battery for a moment, sets both shutdown
and startup to 90 seconds, sleeps after 90 seconds
That is very odd. You could try what happens if you change the
'ondelay' and 'offdelay' values in 'ups.conf'. Set offdelay to 1
second and ondelay to 100/200/400 seconds and run the shutdown.return
command again (while monitoring the 'ups.timer.shutdown' and
'ups.timer.start' through upslog or upsc.
Like this?

[apc1500]
driver=usbhid-ups
port=auto
ondelay=200
offdelay=1

After restarting the driver, and running shutdown.return, the timers are set to
90 and 200. (the values of ups.delay.shutdown and ups.delay.start)

REBOOT:-1 SHUT:-1 START:-1
REBOOT:-1 SHUT:-1 START:-1
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:85 START:195
REBOOT:-1 SHUT:85 START:195
REBOOT:-1 SHUT:83 START:193
REBOOT:-1 SHUT:83 START:193

Using values of 250 and 1 gives:

delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244
Post by Arjen de Korte
According to the USB HID PDC specifications, the 'reboot n' command
will kill the power immediately and return after 'n' seconds if power
is present or will wait until the power returns if it wasn't. We
prefer to have a little grace period, so that's why we do the two step
approach of setting both the shutdown and (re)start timers.
By setting a restart timer longer than the shutdown timer, this
effectively allows for a grace period until the UPS switches off. From
then it behaves like a reboot command. You need this grace period if
you want your system to hibernate instead of shutdown, since the Linux
kernel doesn't allow calling hooks just before it powers off the system.
Ok, this makes sense now. The Smart-UPS 1000 apparently has some variations on
the 'standard'. The CS 500, by the way, is more compliant at least with the
reboot command using hidups, in that it actions the command straight away. I'd
be very happy if we could get the reboot command to work on this one too.
Post by Arjen de Korte
Apparently, due to the dreadful granularity of your UPS hardware
timers the commands we send
load.on.delay 30
load.off.delay 20
are interpreted as setting both to 90 seconds. Worse, since the
ups.timer.start elapses before the ups.timer.shutdown, this
effectively puts the UPS to sleep.
The default appears to be that they are both set equal (at the minimum value of
90), and so elapse at the same time.

Isn't putting the UPS to sleep the desired behaviour here, so that it wakes up
again when power returns?
Post by Arjen de Korte
Post by Kevin
On the CS 500 the load.off switches it off immediately, the load.off delay,
shutdown.return and shutdown.stayoff all switch to battery, and set the shutdown
timer to 20 seconds and then shuts down after that time. (Never restarts) The
beeper commands work, as does the shutdown.stop (sets the shutdown timer to -1)
This probably requires some remapping of variables. I'll see if I can
find a solution for that.
On the CS 500, the shutdown timer is the only one that changes at all. The
reboot and start timers stay at zero (not -1) all the time.

Regards,
Kevin.
Arjen de Korte
2011-01-21 09:11:07 UTC
Permalink
Post by Kevin
[apc1500]
driver=usbhid-ups
port=auto
ondelay=200
offdelay=1
Yes.
Post by Kevin
After restarting the driver, and running shutdown.return, the timers are set to
90 and 200. (the values of ups.delay.shutdown and ups.delay.start)
REBOOT:-1 SHUT:-1 START:-1
REBOOT:-1 SHUT:-1 START:-1
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:85 START:195
REBOOT:-1 SHUT:85 START:195
REBOOT:-1 SHUT:83 START:193
REBOOT:-1 SHUT:83 START:193
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244
This looks actually pretty promising. It looks like the UPS sets a
lower limit to the shutdown timer. I would not be surprised if this is
caused by the value that is set in the
"UPS.Output.APCShutdownAfterDelay" HID path, which is currently set at
"90".

Could you try the attached patch on the nut-2.6.0 sources, compile it
again and run the driver again? If all is well, I expect the
'ups.delay.shutdown' to be a modifiable value after that. You could
try if setting it to "20" works. If the above is the case, I expect
there might be a mapping for the 'ups.delay.start' and
'ups.delay.reboot' as well.

If the variable seems to be modifiable, try to run 'shutdown.return'
again while logging as the above.

[...]
Post by Kevin
Ok, this makes sense now. The Smart-UPS 1000 apparently has some
variations on the 'standard'.
Well, it is not the only UPS (nor vendor) that has. These so called
vendor specific HID paths are allowed by the PDC standard. The problem
is that every vendor can choose what to put in them. So you can't
refer to a standard to find the meaning of them. This is not a problem
if we have full access to the specifications (like Eaton for
instance). But if the vendor is not willing to share them with us
(like APC for instance), we need to reverse engineer them. The latter
is a long, tedious process, which requires lots of help from owners of
these devices.

[...]
Post by Kevin
Isn't putting the UPS to sleep the desired behaviour here, so that
it wakes up again when power returns?
It should wakeup if the power returns after a power outage. But if the
power happens to return between the moment NUT sees the battery is low
(and initiates the shutdown sequence on the server) and the moment it
sends the shutdown signal to the UPS, it should rather cycle the
outlet to prevent what is known as a power race (see the documentation
for more information). You don't want to see the happening when you're
not around to restart your servers by hand.

[...]
Post by Kevin
On the CS 500, the shutdown timer is the only one that changes at all. The
reboot and start timers stay at zero (not -1) all the time.
I guess this means that the existing mapping might be wrong. I suspect
that it only has 'shutdown.reboot' and that the other mappings allow
setting the delay values. Note that in the CS 500 these are all vendor
specific HID paths. I'll deal with that, after we fully understand the
operation on the Smart-UPS 1000.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apc-hid.c.diff
Type: text/x-patch
Size: 959 bytes
Desc: niet beschikbaar
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110121/11851e18/attachment.bin>
Kevin
2011-01-22 06:39:33 UTC
Permalink
Post by Arjen de Korte
This looks actually pretty promising. It looks like the UPS sets a
lower limit to the shutdown timer. I would not be surprised if this is
caused by the value that is set in the
"UPS.Output.APCShutdownAfterDelay" HID path, which is currently set at
"90".
Could you try the attached patch on the nut-2.6.0 sources, compile it
again and run the driver again? If all is well, I expect the
'ups.delay.shutdown' to be a modifiable value after that. You could
try if setting it to "20" works. If the above is the case, I expect
there might be a mapping for the 'ups.delay.start' and
'ups.delay.reboot' as well.
If the variable seems to be modifiable, try to run 'shutdown.return'
again while logging as the above.
Here is the output:

# ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
OK

delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:87 START:247
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:87 START:247
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:85 START:245

Some seconds later...

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.4
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 230.4
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 1
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: 17
ups.timer.start: 177
ups.vendorid: 051d


Contents of apc-hid.c:

[...]
{ "ups.timer.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL, "%.0f",
HU_FLAG_QUICK_POLL, NULL},
/* used by APC BackUPS ES */
{ "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.APCGeneralCollection.APCDelayBeforeStartup", NULL, DEFAULT_ONDELAY,
HU_FLAG_ABSENT, NULL},
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.APCGeneralCollection.APCDelayBeforeShutdown", NULL, DEFAULT_OFFDELAY,
HU_FLAG_ABSENT, NULL},
{ "ups.timer.start", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeStartup",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.shutdown", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeShutdown", NULL, "%.0f",
HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.reboot", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeReboot",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
[...]


I am not seeing any difference.
Post by Arjen de Korte
Post by Kevin
Isn't putting the UPS to sleep the desired behaviour here, so that
it wakes up again when power returns?
It should wakeup if the power returns after a power outage. But if the
power happens to return between the moment NUT sees the battery is low
(and initiates the shutdown sequence on the server) and the moment it
sends the shutdown signal to the UPS, it should rather cycle the
outlet to prevent what is known as a power race (see the documentation
for more information). You don't want to see the happening when you're
not around to restart your servers by hand.
That's understood, I'd have to do some more testing to try to reproduce this.
Post by Arjen de Korte
Post by Kevin
On the CS 500, the shutdown timer is the only one that changes at all. The
reboot and start timers stay at zero (not -1) all the time.
I guess this means that the existing mapping might be wrong. I suspect
that it only has 'shutdown.reboot' and that the other mappings allow
setting the delay values. Note that in the CS 500 these are all vendor
specific HID paths. I'll deal with that, after we fully understand the
operation on the Smart-UPS 1000.
Ok, and thanks for your efforts. Actually, as I have a working solution on the
Smart-UPS 1000, and not on the CS 500, it is the latter that is more critical
(as I'm currently on standby all the time for when the power goes down!)

Regards,
Kevin.
Kevin
2011-01-22 06:56:57 UTC
Permalink
Arjen,


I'm posting the debug file again in case it gives any more clues. I
modified the version number to make sure I was actually using the
patched driver. I don't know, but these lines may be significant:

# grep "Value: 90" APC-1000.patched.txt
1.397898 Path: UPS.Output.APCShutdownAfterDelay, Type: Input,
ReportID: 0x26, Offset: 0, Size: 16, Value: 90
1.397898 Path: UPS.Output.APCShutdownAfterDelay, Type: Feature,
ReportID: 0x26, Offset: 0, Size: 16, Value: 90

Does this mean the value has not changed?

Regards,
Kevin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC-1000.patched.txt.zip
Type: application/x-compressed
Size: 6470 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110122/32770939/attachment.bin>
Arjen de Korte
2011-01-22 08:35:31 UTC
Permalink
Post by Kevin
I'm posting the debug file again in case it gives any more clues. I
modified the version number to make sure I was actually using the
# grep "Value: 90" APC-1000.patched.txt
1.397898 Path: UPS.Output.APCShutdownAfterDelay, Type: Input,
ReportID: 0x26, Offset: 0, Size: 16, Value: 90
Feature, ReportID: 0x26, Offset: 0, Size: 16, Value: 90
Does this mean the value has not changed?
Sorry for the confusion. Yes the value hasn't changed, but I didn't
expect that to happen. It should however be modifiable through
'upsrw', so that you might be able to set it to a lower value.

In the usbhid-ups driver, the 'ups.delay.(start|shutdown|reboot)'
values are driver variables. They are only send to the UPS when you
initiate the corresponding command. However, on the APC it seems to be
possible (mandatory) to store them in the UPS itself.

So try if you can change this value through upsrw to something like 20
seconds and lower the 'offdelay' value to 30 seconds.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-22 09:10:01 UTC
Permalink
Post by Arjen de Korte
Sorry for the confusion. Yes the value hasn't changed, but I didn't
expect that to happen. It should however be modifiable through 'upsrw',
so that you might be able to set it to a lower value.
In the usbhid-ups driver, the 'ups.delay.(start|shutdown|reboot)' values
are driver variables. They are only send to the UPS when you initiate
the corresponding command. However, on the APC it seems to be possible
(mandatory) to store them in the UPS itself.
So try if you can change this value through upsrw to something like 20
seconds and lower the 'offdelay' value to 30 seconds.
I don't pretend to understand this fully at the moment, the
driver.parameter.offdelay is set to 1, as is the ups.delay.shutdown:

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.4
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patched
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 230.4
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 1
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d

#./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK

This sets it to 30:

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.4
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patched
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 230.4
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d

but doesn't affect the initial value of ups.timer.shutdown (90) after
the shutdown.return command:

# ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
OK

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.4
battery.type: PbAc
battery.voltage: 27.0
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patched
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 229.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: 82
ups.timer.start: 242
ups.vendorid: 051d
Arjen de Korte
2011-01-22 20:41:03 UTC
Permalink
Citeren Kevin <bakdong op gmail.com>:

[...]
Post by Kevin
but doesn't affect the initial value of ups.timer.shutdown (90)
# ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
OK
# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.4
battery.type: PbAc
battery.voltage: 27.0
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patched
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 229.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: 82
ups.timer.start: 242
ups.vendorid: 051d
Could you try this again with

{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.APCShutdownAfterDelay", NULL, "%.0f", HU_FLAG_SEMI_STATIC,
NULL },

changed to

{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.APCShutdownAfterDelay", NULL, "%.0f", HU_FLAG_QUICK_POLL,
NULL },

and run this test again? I'm not sure if the value is actually
modified in the UPS. I fear that the HU_FLAG_SEMI_STATIC flag may have
prevented the driver from reading back the value from the UPS.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-23 03:28:58 UTC
Permalink
Post by Arjen de Korte
Could you try this again with
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.APCShutdownAfterDelay", NULL, "%.0f", HU_FLAG_QUICK_POLL,
NULL },
and run this test again?
Sure...

#define APC_HID_VERSION "APC HID 0.95-patch2"
[...]
{ "ups.timer.start", 0, 0, "UPS.PowerSummary.DelayBeforeStartup",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.shutdown", 0, 0, "UPS.PowerSummary.DelayBeforeShutdown",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
/* used by APC SmartUPS RM */
{ "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_FLAG_ABSENT,
NULL},
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.APCShutdownAfterDelay", NULL, "%.0f", HU_FLAG_QUICK_POLL,
NULL },
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY,
HU_FLAG_ABSENT, NULL},
{ "ups.timer.start", 0, 0, "UPS.Output.DelayBeforeStartup", NULL,
"%.0f", HU_FLAG_QUICK_POLL, NULL},


The ups.delay.shutdown value starts at what is set in the ups.conf (1):

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.8
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patch2
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 228.9
output.voltage: 228.9
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 1
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d

And I can change what is reported by upsc with:

# ./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.8
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patch2
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 230.4
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d


But this doesn't affect the minimum timer.shutdown value:

# ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
OK

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.8
battery.type: PbAc
battery.voltage: 27.0
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patch2
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 229.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: 84
ups.timer.start: 244
ups.vendorid: 051d

Regards,
Kevin.
Arjen de Korte
2011-01-23 09:16:52 UTC
Permalink
Post by Kevin
#define APC_HID_VERSION "APC HID 0.95-patch2"
[...]
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.APCShutdownAfterDelay", NULL, "%.0f",
HU_FLAG_QUICK_POLL, NULL },
I see my error now. The above line should be moved up to before the
first occurence of { "ups.delay.shutdown", ... }. The first available
HID path that is found, will set the NUT mapping and there is one
before this line now, so the above will never be used in its present
location.
This should have tipped me off. The 'offdelay' should be ignored by
the driver if the above line is in the correct location.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-23 15:55:09 UTC
Permalink
Post by Arjen de Korte
I see my error now. The above line should be moved up to before the
first occurence of { "ups.delay.shutdown", ... }. The first available
HID path that is found, will set the NUT mapping and there is one before
this line now, so the above will never be used in its present location.
Ok, try again....

{ "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.PowerSummary.DelayBeforeStartup", NULL, DEFAULT_ONDELAY,
HU_FLAG_ABSENT, NULL},
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.APCShutdownAfterDelay", NULL, "%.0f", HU_FLAG_QUICK_POLL,
NULL },
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.PowerSummary.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY,
HU_FLAG_ABSENT, NULL},
{ "ups.timer.start", 0, 0, "UPS.PowerSummary.DelayBeforeStartup",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.shutdown", 0, 0, "UPS.PowerSummary.DelayBeforeShutdown",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL},
/* used by APC SmartUPS RM */
{ "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_FLAG_ABSENT,
NULL},
{ "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10,
"UPS.Output.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY,
HU_FLAG_ABSENT, NULL},
{ "ups.timer.start", 0, 0, "UPS.Output.DelayBeforeStartup", NULL,
"%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.shutdown", 0, 0, "UPS.Output.DelayBeforeShutdown", NULL,
"%.0f", HU_FLAG_QUICK_POLL, NULL},
{ "ups.timer.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL,
"%.0f", HU_FLAG_QUICK_POLL, NULL},


Different....

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 33.3
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patch3
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 230.4
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 90
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d


./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 33.3
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patch3
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 231.8
output.voltage: 231.8
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 051d


Sorry....

# ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
OK

# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 33.3
battery.type: PbAc
battery.voltage: 27.0
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patch3
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 231.8
output.voltage: 229.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: 88
ups.timer.start: 248
ups.vendorid: 051d


delay.start:250 delay.shutdown:30 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:30 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:30 REBOOT:-1 SHUT:88 START:248
delay.start:250 delay.shutdown:30 REBOOT:-1 SHUT:88 START:248
delay.start:250 delay.shutdown:30 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:30 REBOOT:-1 SHUT:86 START:246

Regards,
Kevin.
Arjen de Korte
2011-01-24 09:18:09 UTC
Permalink
Post by Kevin
Different....
# ./clients/upsc apc1500
[...]
Post by Kevin
ups.delay.shutdown: 90
ups.delay.start: 250
This is what I expected to happen. The value of ups.delay.shutdown is
now read from the UPS...
Post by Kevin
./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK
# ./clients/upsc apc1500
[...]
Post by Kevin
ups.delay.shutdown: 30
ups.delay.start: 250
..and apparently can be written as well.

Sadly, it looks like this value is used for a different purpose than
setting the minimum delay value before shutdown (like I expected).
Unless you're willing to dig deeper into this, I think we have to
conclude that this model doesn't allow setting the delay values lower
than 90 seconds. Using an 'ondelay' value of 100, does the UPS cycle
the output if mains is present? And does it wait until the mains
return if it is not present?

I would still like to see the full output of the below command. An
earlier version you posted was incomplete (the report descriptor was
missing, which is vital to be able to check our HID parser without
access to a specific UPS model). Could you please post the output of

/path/to/usbhid-ups -DD -a apc1500 > APC_Smart-UPS_1000.log 2>&1

here? The redirection of stderr to stdin was probably missing in your
previous post.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-24 11:25:08 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
Different....
# ./clients/upsc apc1500
[...]
Post by Kevin
ups.delay.shutdown: 90
ups.delay.start: 250
This is what I expected to happen. The value of ups.delay.shutdown is
now read from the UPS...
Understood.
Post by Arjen de Korte
Post by Kevin
./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK
# ./clients/upsc apc1500
[...]
Post by Kevin
ups.delay.shutdown: 30
ups.delay.start: 250
..and apparently can be written as well.
Yes, but this value could also be changed before the patches. (See
previous posts)
Post by Arjen de Korte
Sadly, it looks like this value is used for a different purpose than
setting the minimum delay value before shutdown (like I expected).
Unless you're willing to dig deeper into this, I think we have to
conclude that this model doesn't allow setting the delay values lower
than 90 seconds. Using an 'ondelay' value of 100, does the UPS cycle the
output if mains is present? And does it wait until the mains return if
it is not present?
Happy to dig as deep as you would like me to. (I would like to get the
CS 500 sorted out too though) I will check again with the unmodified
code, but I'm fairly sure that the output will cycle when power is
present. (even with on and offdelay values at the default 90 minimum)
Post by Arjen de Korte
I would still like to see the full output of the below command. An
earlier version you posted was incomplete (the report descriptor was
missing, which is vital to be able to check our HID parser without
access to a specific UPS model). Could you please post the output of
/path/to/usbhid-ups -DD -a apc1500 > APC_Smart-UPS_1000.log 2>&1
here? The redirection of stderr to stdin was probably missing in your
previous post.
I'll do it now and attach it here.....

Regards,
Kevin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC_Smart-UPS_1000.zip
Type: application/x-compressed
Size: 6230 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110124/94f13c37/attachment-0001.bin>
Arjen de Korte
2011-01-24 12:15:12 UTC
Permalink
Post by Kevin
Post by Arjen de Korte
Post by Kevin
./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK
# ./clients/upsc apc1500
[...]
Post by Kevin
ups.delay.shutdown: 30
ups.delay.start: 250
..and apparently can be written as well.
Yes, but this value could also be changed before the patches. (See
previous posts)
Not in the same way. I'm not really interested in what NUT thinks
about this value, it is where it is stored. Previously, this value
would be a driver side variable (without the UPS ever knowing we
changed it) while in this case, it is a value stored (and modified) in
the UPS. I was hoping that the UPS would consider this value for the
minimum shutdown delay, but apparently it doesn't. Chances are it is
something completely different... :-(
Post by Kevin
Happy to dig as deep as you would like me to. (I would like to get
the CS 500 sorted out too though) I will check again with the
unmodified code, but I'm fairly sure that the output will cycle when
power is present. (even with on and offdelay values at the default
90 minimum)
That's even weirder...
Post by Kevin
Post by Arjen de Korte
I would still like to see the full output of the below command. An
earlier version you posted was incomplete (the report descriptor
was missing, which is vital to be able to check our HID parser
without access to a specific UPS model). Could you please post the
output of
/path/to/usbhid-ups -DD -a apc1500 > APC_Smart-UPS_1000.log 2>&1
here? The redirection of stderr to stdin was probably missing in
your previous post.
I'll do it now and attach it here.....
Sorry about that, the report descriptor is only reported at debug
level 3 (or higher). So I need the output of the below command instead:

/path/to/usbhid-ups -DDD -a apc1500 > APC_Smart-UPS_1000.log 2>&1

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-01-24 13:04:27 UTC
Permalink
Sorry about that, the report descriptor is only reported at debug level
/path/to/usbhid-ups -DDD -a apc1500 > APC_Smart-UPS_1000.log 2>&1
Here it is.

Regards,
Kevin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC_Smart-UPS_1000.zip
Type: application/x-compressed
Size: 11388 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110124/b883f27f/attachment.bin>
Arjen de Korte
2011-01-24 20:45:55 UTC
Permalink
Post by Kevin
Post by Arjen de Korte
Sorry about that, the report descriptor is only reported at debug
/path/to/usbhid-ups -DDD -a apc1500 > APC_Smart-UPS_1000.log 2>&1
Here it is.
Much better, thanks! Could you do the same for the CS-500 (time permitting).

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Arjen de Korte
2011-01-24 20:58:32 UTC
Permalink
Post by Kevin
Happy to dig as deep as you would like me to. (I would like to get
the CS 500 sorted out too though)
I think the only solution I can come up with to support (?) all known
APC models, is to not map the HID paths to 'load.on.delay' and to rely
on the UPS to provide a grace period before cycling the power or
shutting down.

Can you try the attached patch on the pristine nut-2.6.0 sources and
let us know if both APC models you own, shutdown and restart properly?

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apc-hid.c.diff
Type: text/x-patch
Size: 1853 bytes
Desc: niet beschikbaar
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110124/858e2ce2/attachment.bin>
Kevin
2011-01-25 05:57:12 UTC
Permalink
Post by Arjen de Korte
I think the only solution I can come up with to support (?) all known
APC models, is to not map the HID paths to 'load.on.delay' and to rely
on the UPS to provide a grace period before cycling the power or
shutting down.
Can you try the attached patch on the pristine nut-2.6.0 sources and
let us know if both APC models you own, shutdown and restart properly?
Done that. Everything works as expected now on the Smart-UPS 1000. (-k
causes a shutdown.reboot, which sets the reboot timer to 90 and when
that reaches 0 the UPS sleeps and then powers up again either after
about 3 seconds if there is already power, otherwise when the power
returns.)

No luck, I'm afraid, with the CS 500. shutdown.reboot has apparently no
effect. The reboot timer stays at 'zero' (not -1) and nothing happens.

# ./clients/upsc apc1500
battery.charge: 87
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2010/09/19
battery.mfr.date: 2010/09/19
battery.runtime: 3412
battery.runtime.low: 120
battery.temperature: 29.2
battery.type: PbAc
battery.voltage: 12.7
battery.voltage.nominal: 12.0
device.mfr: American Power Conversion
device.model: Back-UPS CS 500
device.serial: 4B1038P51197
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-new-patch
driver.version.internal: 0.35
input.sensitivity: medium
input.transfer.reason: input voltage out of range
input.voltage: 0.0
input.voltage.nominal: 230
output.voltage: 230.0
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 1
ups.delay.start: 250
ups.firmware: 808.q10 .I
ups.firmware.aux: q10
ups.load: 0.0
ups.mfr: American Power Conversion
ups.mfr.date: 2010/09/19
ups.model: Back-UPS CS 500
ups.productid: 0002
ups.serial: 4B1038P51197
ups.status: OB DISCHRG
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.timer.start: 0
ups.vendorid: 051d


Output from ./drivers/usbhid-ups -DDD -a apc1500 > APC_UPS_CS_500.log
2>&1 attached.

Regards,
Kevin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC_UPS_CS_500.zip
Type: application/x-zip-compressed
Size: 10643 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110125/5b7abc3f/attachment-0001.bin>
Kevin
2011-01-31 15:03:25 UTC
Permalink
Not sure if this made it to the list the first time round....
Post by Arjen de Korte
I think the only solution I can come up with to support (?) all known
APC models, is to not map the HID paths to 'load.on.delay' and to rely
on the UPS to provide a grace period before cycling the power or
shutting down.
Can you try the attached patch on the pristine nut-2.6.0 sources and
let us know if both APC models you own, shutdown and restart properly?
Done that. Everything works as expected now on the Smart-UPS 1000. (-k
causes a shutdown.reboot, which sets the reboot timer to 90 and when
that reaches 0 the UPS sleeps and then powers up again either after
about 3 seconds if there is already power, otherwise when the power
returns.)

No luck, I'm afraid, with the CS 500. shutdown.reboot has apparently no
effect. The reboot timer stays at 'zero' (not -1) and nothing happens.

# ./clients/upsc apc1500
battery.charge: 87
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2010/09/19
battery.mfr.date: 2010/09/19
battery.runtime: 3412
battery.runtime.low: 120
battery.temperature: 29.2
battery.type: PbAc
battery.voltage: 12.7
battery.voltage.nominal: 12.0
device.mfr: American Power Conversion
device.model: Back-UPS CS 500
device.serial: 4B1038P51197
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-new-patch
driver.version.internal: 0.35
input.sensitivity: medium
input.transfer.reason: input voltage out of range
input.voltage: 0.0
input.voltage.nominal: 230
output.voltage: 230.0
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 1
ups.delay.start: 250
ups.firmware: 808.q10 .I
ups.firmware.aux: q10
ups.load: 0.0
ups.mfr: American Power Conversion
ups.mfr.date: 2010/09/19
ups.model: Back-UPS CS 500
ups.productid: 0002
ups.serial: 4B1038P51197
ups.status: OB DISCHRG
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.timer.start: 0
ups.vendorid: 051d


Output from ./drivers/usbhid-ups -DDD -a apc1500 > APC_UPS_CS_500.log
2>&1 attached.

Regards,
Kevin.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: APC_UPS_CS_500.zip
Type: application/x-zip-compressed
Size: 10643 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110131/a9199bcb/attachment-0001.bin>
Kevin
2011-02-03 12:00:36 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
Happy to dig as deep as you would like me to. (I would like to get the
CS 500 sorted out too though)
I think the only solution I can come up with to support (?) all known
APC models, is to not map the HID paths to 'load.on.delay' and to rely
on the UPS to provide a grace period before cycling the power or
shutting down.
Can you try the attached patch on the pristine nut-2.6.0 sources and let
us know if both APC models you own, shutdown and restart properly?
Seems to have gone a bit quiet. Are we at a dead end now?

Regards,
Kevin.
Arjen de Korte
2011-02-06 11:19:38 UTC
Permalink
Post by Kevin
Seems to have gone a bit quiet. Are we at a dead end now?
No, I just don't have a lot of spare time on my hand lately. You could
try if changing

{ "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "10",
HU_TYPE_CMD, NULL },

to

{ "shutdown.return", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1",
HU_TYPE_CMD, NULL },

helps. Looking in the apcupsd sources seems to indicate that this
isn't a timer at all, but instead just a flag that forces a reboot
cycle.

Given the brokenness of the APC HID PDC implementation (the apcupsd
project uses about half a dozen ways to shutdown), I doubt that the
support status of APC is going to improve a lot. If you have not
already tried the apcupsd project, I'd suggest to try that too. Since
NUT is not focussed on one specific make, we probably can never give
the same support. This is also due to the fact that none of the active
developers has access to one of these devices.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-06 13:29:25 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
Seems to have gone a bit quiet. Are we at a dead end now?
No, I just don't have a lot of spare time on my hand lately.
That's ok. I quite understand. Thank you for all your help so far.
Post by Arjen de Korte
You could
try if changing
{ "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "10",
HU_TYPE_CMD, NULL },
to
{ "shutdown.return", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1", HU_TYPE_CMD,
NULL },
Thank you. I will try that and see what happens.

I know it's very old code, but if it helps at all I know that this
modified shutdown function in hidups works:

void upsdrv_shutdown(void)
{
/* XXX: replace with a proper shutdown function
fatalx("shutdown not supported"); */

/* 1) set DelayBeforeStartup */
if (getval ("ondelay"))
ondelay = atoi (getval ("ondelay"));

/* setvalue(UPS_WAKEDELAY, ondelay); */ /* commented out this
line for APC CS 500 */

/* 2) set DelayBeforeShutdown */
if (getval ("offdelay"))
offdelay = atoi (getval ("offdelay"));

/* setvalue(UPS_GRACEDELAY, offdelay); */
setvalue(0xff86007c, 1); /* changed this line for APC CS 500 */
}
Post by Arjen de Korte
helps. Looking in the apcupsd sources seems to indicate that this isn't
a timer at all, but instead just a flag that forces a reboot cycle.
Given the brokenness of the APC HID PDC implementation (the apcupsd
project uses about half a dozen ways to shutdown), I doubt that the
support status of APC is going to improve a lot. If you have not already
tried the apcupsd project, I'd suggest to try that too. Since NUT is not
focussed on one specific make, we probably can never give the same
support. This is also due to the fact that none of the active developers
has access to one of these devices.
Thanks again, I will have a look.

Regards,
Kevin.
Charles Lepple
2011-02-06 14:06:57 UTC
Permalink
I know it's very old code, but if it helps at all I know that this modified
void upsdrv_shutdown(void)
{
? ? ? ?/* XXX: replace with a proper shutdown function
? ? ? ?fatalx("shutdown not supported"); */
? ? ? ?/* 1) set DelayBeforeStartup */
? ? ? ?if (getval ("ondelay"))
? ? ? ? ? ? ? ?ondelay = atoi (getval ("ondelay"));
? ? ? ?/* setvalue(UPS_WAKEDELAY, ondelay); */ /* commented out this line
for APC CS 500 */
? ? ? ?/* 2) set DelayBeforeShutdown */
? ? ? ?if (getval ("offdelay"))
? ? ? ? ? ? ? ?offdelay = atoi (getval ("offdelay"));
? ? ? ?/* setvalue(UPS_GRACEDELAY, offdelay); */
? ? ? ?setvalue(0xff86007c, 1); /* changed this line for APC CS 500 */
}
It looks like the only uncommented code which talks to the device is
the last line. (The results from the getval() calls do not seem to be
used.)

APCDelayBeforeReboot maps to 0xff86007c, so Arjen's suggestion to
change the 10 to 1 should be equivalent to the setvalue() line at the
end.
--
- Charles Lepple
Kevin
2011-02-06 14:42:42 UTC
Permalink
Post by Charles Lepple
It looks like the only uncommented code which talks to the device is
the last line. (The results from the getval() calls do not seem to be
used.)
APCDelayBeforeReboot maps to 0xff86007c, so Arjen's suggestion to
change the 10 to 1 should be equivalent to the setvalue() line at the
end.
Thanks for the input Charles. I will post back the results tomorrow.
Kevin
2011-02-07 08:20:22 UTC
Permalink
Post by Kevin
Post by Charles Lepple
It looks like the only uncommented code which talks to the device is
the last line. (The results from the getval() calls do not seem to be
used.)
APCDelayBeforeReboot maps to 0xff86007c, so Arjen's suggestion to
change the 10 to 1 should be equivalent to the setvalue() line at the
end.
Thanks for the input Charles. I will post back the results tomorrow.
Ok, I've tried that. The result of "clientcmd -u apcmon -p pass123 -a
apc1500 shutdown.reboot" is nothing. Nothing that I can see changes at all.

I did this with the old working modified hidups driver:

# ./hidups -DDD -k /dev/hiddev0
Network UPS Tools: HID UPS driver 0.13 (2.0.0)

Warning: This is an experimental driver.
Some features may not function correctly.

debug level is '3'
Detected American Power Conversion Back-UPS CS 500 FW:808.q10 .I USB FW:q10
on port /dev/hiddev0
Initiating UPS shutdown
setvalue(ff86007c, 1): obtained 0 (report 40))
setvalue(using type = feature): report sent successfully


Something must be different! Is the "type = feature" relevant at all?

There are three lines in the apc-hid.c code that reference shutdown.reboot:

1. { "shutdown.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "10", HU_TYPE_CMD, NULL },
2. { "shutdown.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL,
"10", HU_TYPE_CMD, NULL },
3. { "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1",
HU_TYPE_CMD, NULL },


I did "usbhid-ups -a apc1500 -k -DDD > CS500shutdown.txt 2>&1" and
attached the output in case it holds any clues.

Regards,
Kevin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110207/bf9287c6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CS500Shutdown.reboot.txt.zip
Type: application/x-zip-compressed
Size: 3868 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110207/bf9287c6/attachment.bin>
Arjen de Korte
2011-02-07 08:36:03 UTC
Permalink
Post by Kevin
Ok, I've tried that. The result of "clientcmd -u apcmon -p pass123
-a apc1500 shutdown.reboot" is nothing. Nothing that I can see
changes at all.
Of course. Do as I asked you and it *will* make a difference.
Post by Kevin
# ./hidups -DDD -k /dev/hiddev0
Network UPS Tools: HID UPS driver 0.13 (2.0.0)
Use nut-2.6.0 instead. The above version is too old and I have no idea
what variables it supports (and I don't want to take the time finding
out).
Post by Kevin
1. { "shutdown.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "10", HU_TYPE_CMD, NULL },
2. { "shutdown.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL,
"10", HU_TYPE_CMD, NULL },
3. { "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1",
HU_TYPE_CMD, NULL },
The name change of the command is critical here. NUT will use whatever
mapping it finds first, so that's the reason I asked you to use
'shutdown.return' for this specific HID path instead. Otherwise the
command will never be reached if you call the driver with '-k' and
when you run 'shutdown.reboot' it will probably find a different HID
path first.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-07 13:22:02 UTC
Permalink
Post by Arjen de Korte
Of course. Do as I asked you and it *will* make a difference.
You could have perhaps made a point of the sudden change to a different
command. Others also missed this subtlety.
Post by Arjen de Korte
Post by Kevin
# ./hidups -DDD -k /dev/hiddev0
Network UPS Tools: HID UPS driver 0.13 (2.0.0)
Use nut-2.6.0 instead. The above version is too old and I have no idea
what variables it supports (and I don't want to take the time finding out).
You miss the point entirely. I am giving you code that works, whereas
yours does not. Surely a programmers dream.
Post by Arjen de Korte
The name change of the command is critical here. NUT will use whatever
mapping it finds first, so that's the reason I asked you to use
'shutdown.return' for this specific HID path instead. Otherwise the
command will never be reached if you call the driver with '-k' and when
you run 'shutdown.reboot' it will probably find a different HID path first.
Ok, I'll give this a try too.
Arjen de Korte
2011-02-07 13:58:37 UTC
Permalink
Post by Kevin
You could have perhaps made a point of the sudden change to a
different command. Others also missed this subtlety.
I posted the 'old' and 'new' lines. You might have missed this on the
first look, buy after I told you the difference, you could have looked
again at the original post.
Post by Kevin
You miss the point entirely. I am giving you code that works,
whereas yours does not. Surely a programmers dream.
Not at all. As I already indicated a couple of times, APC uses a
myriad of methods to shutdown their UPSes. Have a look at the USB
apcupsd code and you'll appreciate how broken the APC software is. So
bluntly accepting your changes might have fixed you problems, but
would at the same time break it again for others. This is the problem
we're in (which you don't seem to understand).

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-07 14:56:45 UTC
Permalink
Post by Arjen de Korte
I posted the 'old' and 'new' lines. You might have missed this on the
first look, buy after I told you the difference, you could have looked
again at the original post.
Of course I saw it, after you made it so plain in such a blunt manner.
As I said, others also missed it.
Post by Arjen de Korte
Post by Kevin
You miss the point entirely. I am giving you code that works, whereas
yours does not. Surely a programmers dream.
Not at all. As I already indicated a couple of times, APC uses a myriad
of methods to shutdown their UPSes. Have a look at the USB apcupsd code
and you'll appreciate how broken the APC software is.
Again, the broken software story.
Post by Arjen de Korte
So bluntly
accepting your changes might have fixed you problems, but would at the
same time break it again for others. This is the problem we're in (which
you don't seem to understand).
No, because you seem unable even to replicate the behaviour of your
earlier versions (which I have shown to work after a small modification)
in your current versions.

It is beginning to seem as though the current code has become so complex
that no one actually understands exactly what it does any more.

As I said before, I am willing to put as much effort into this as is
required, but I am not a programmer, so please don't jump down my throat
for misreading a sentence.

I'll let you know the results tomorrow. However, it would help if you
gave me a patch to the original code so there could be no more
misunderstandings.
Kevin
2011-02-08 05:12:16 UTC
Permalink
Post by Arjen de Korte
Post by Kevin
Ok, I've tried that. The result of "clientcmd -u apcmon -p pass123 -a
apc1500 shutdown.reboot" is nothing. Nothing that I can see changes at all.
Of course. Do as I asked you and it *will* make a difference.
You are quite right! I now have this line in apc-hid.c:

{ "shutdown.return", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1", HU_TYPE_CMD,
NULL },

and get this result:

# clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
Unexpected response from upsd: ERR CMD-NOT-SUPPORTED


I have attached the output of "usbhid-ups -a apc1500 -k -DDD >
CS500shutdown.txt 2>&1" in case it is of value.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CS500Shutdown.return.txt.zip
Type: application/x-zip-compressed
Size: 3940 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110208/5e71c2ea/attachment.bin>
Arjen de Korte
2011-02-08 07:55:31 UTC
Permalink
Post by Arjen de Korte
{ "shutdown.return", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1",
HU_TYPE_CMD, NULL },
# clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
Unexpected response from upsd: ERR CMD-NOT-SUPPORTED
I have attached the output of "usbhid-ups -a apc1500 -k -DDD >
CS500shutdown.txt 2>&1" in case it is of value.
It is of value. The HID path I sent was wrong (it isn't in the above
listing, so usbhid-ups will not find it). There is no
"APCGeneralCollection" in your UPS. Instead of

{ "shutdown.return", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1",
HU_TYPE_CMD, NULL },

the correct HID path should be

{ "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot",
NULL, "1", HU_TYPE_CMD, NULL },

Sorry about that.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-08 08:10:11 UTC
Permalink
{ "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot", NULL,
"1", HU_TYPE_CMD, NULL },
Yes, that does the trick!

# clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return

has the desired effect.

Would you like me to provide any more output?
Arjen de Korte
2011-02-08 08:50:24 UTC
Permalink
Post by Kevin
Yes, that does the trick!
# clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
has the desired effect.
Good. I assume you tried this on the CS-500, right? Do you have any
idea how long the delay is before the device actually shuts down?
Post by Kevin
Would you like me to provide any more output?
It would be nice to know under what conditions you tested this
command. We would like to see what happens both with and without mains
present at the time of running this command. I both work as expected,
we may have found a workable solution. I do have to check the report
descriptors of some other APC devices, to check if we're not shooting
ourselves in the foot by adding this (to see if there may be conflicts
with other known devices).

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-08 09:09:18 UTC
Permalink
Post by Arjen de Korte
Good. I assume you tried this on the CS-500, right? Do you have any
idea how long the delay is before the device actually shuts down?
Yes, this is with the CS 500. The bad news is that the "# usbhid-ups -a
apc1500 -k -DDD" command doesn't work, producing

Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, ReportID: 0x14, Offset: 0, Size: 8, Value: 1.000000
Report[buf]: (2 bytes) => 14 01
Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, ReportID: 0x14, Offset: 0, Size: 8, Value: 1.000000
Initiating UPS shutdown
upsdrv_shutdown...
*instcmd(shutdown.return, [NULL])
find_nut_info: unknown info type: shutdown.return*

instcmd(load.on.delay, [NULL])
find_nut_info: unknown info type: load.on.delay

instcmd: info element unavailable load.on.delay

instcmd(shutdown.reboot, [NULL])
Report[set]: (4 bytes) => 13 0a 00 00
upsdrv_cleanup...


(Full output is attached) What do i have to do to get the
shutdown.return command recognised (without breaking the process for the
Smart-UPS 1000!)
Post by Arjen de Korte
Post by Kevin
Would you like me to provide any more output?
It would be nice to know under what conditions you tested this
command. We would like to see what happens both with and without mains
present at the time of running this command. I both work as expected,
we may have found a workable solution. I do have to check the report
descriptors of some other APC devices, to check if we're not shooting
ourselves in the foot by adding this (to see if there may be conflicts
with other known devices).
I have not tested this on the Smart-UPS 1000 since the new changes. That
is still on the 'to do' list. I will let you know on the power tests.


In summary, I have commented out the two lines:

/* { "load.on.delay", 0, 0, "UPS.Output.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL },*/

and

/* { "load.on.delay", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL },*/


and added this line:

{ "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot", NULL, "1", HU_TYPE_CMD, NULL },


Question:

Should the old line:

{ "shutdown.reboot", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "10", HU_TYPE_CMD, NULL },

remain, or should I comment it out too?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110208/e665bf5f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CS500Shutdown.return.txt.zip
Type: application/x-zip-compressed
Size: 3938 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110208/e665bf5f/attachment-0001.bin>
Kevin
2011-02-08 09:20:38 UTC
Permalink
The bad news is that the "# usbhid-ups -a apc1500 -k -DDD" command
doesn't work
Cancel that. I was using the wrong path. It does work fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110208/42bdba9d/attachment.htm>
Kevin
2011-02-08 09:32:42 UTC
Permalink
Do you have any idea how long the delay is before the device actually
shuts down?
*Further testing:*

When the command is issued....

On power:

Switches immediately to battery
Waits 60 seconds
Sleeps for 2 seconds, switches output power off
Restarts

On battery:
Waits 60 seconds
Sleeps

When power returns, restarts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110208/daac72e6/attachment.htm>
Arjen de Korte
2011-02-08 09:48:39 UTC
Permalink
Post by Kevin
Switches immediately to battery
Waits 60 seconds
Sleeps for 2 seconds, switches output power off
Restarts
Although it is a bit weird that the device switches to battery, this
doesn't really harm. We know such behavior from older devices with
'dumb' contact closure serial interfaces, which can only be shutdown
when running on battery.
Post by Kevin
Waits 60 seconds
Sleeps
When power returns, restarts.
That's good to know. It looks like we found the correct mapping. If
this doesn't conflict with known report descriptors, I'll add this to
the development version later today.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-08 09:58:37 UTC
Permalink
Post by Arjen de Korte
That's good to know. It looks like we found the correct mapping. If
this doesn't conflict with known report descriptors, I'll add this to
the development version later today.
For info, I added this line:

{ "shutdown.stop", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeShutdown", NULL, "-1",
HU_TYPE_CMD, NULL },
{ "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "10",
HU_TYPE_CMD, NULL },
* { "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot", NULL,
"1", HU_TYPE_CMD, NULL },*

{ "beeper.on", 0, 0, "UPS.PowerSummary.AudibleAlarmControl", NULL,
"2", HU_TYPE_CMD, NULL },


into the version 2.4.3 apc-hid.c on the other server and the CS 500 on
that is working fine too now.

Thanks for all your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110208/5ed39963/attachment.htm>
Arjen de Korte
2011-02-08 19:51:13 UTC
Permalink
Post by Kevin
{ "shutdown.stop", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeShutdown", NULL, "-1",
HU_TYPE_CMD, NULL },
{ "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "10",
HU_TYPE_CMD, NULL },
* { "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot",
NULL, "1", HU_TYPE_CMD, NULL },*
The "UPS.Output.APCDelayBeforeReboot" HID path is not present unique
for the CS 500 in the APC report descriptors I have, so it is safe to
add this (there will be no conflicts with devices we have confirmed to
be working). I just committed this to the development version so it
should be included in the released version once nut-2.6.1 hits the road.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Arnaud Quette
2011-02-07 08:36:32 UTC
Permalink
2011/2/7 Kevin <bakdong at gmail.com>
Post by Charles Lepple
It looks like the only uncommented code which talks to the device is
the last line. (The results from the getval() calls do not seem to be
used.)
APCDelayBeforeReboot maps to 0xff86007c, so Arjen's suggestion to
change the 10 to 1 should be equivalent to the setvalue() line at the
end.
Thanks for the input Charles. I will post back the results tomorrow.
Ok, I've tried that. The result of "clientcmd -u apcmon -p pass123 -a
apc1500 shutdown.reboot" is nothing. Nothing that I can see changes at all.
# ./hidups -DDD -k /dev/hiddev0
Network UPS Tools: HID UPS driver 0.13 (2.0.0)
Warning: This is an experimental driver.
Some features may not function correctly.
debug level is '3'
Detected American Power Conversion Back-UPS CS 500 FW:808.q10 .I USB FW:q10
on port /dev/hiddev0
Initiating UPS shutdown
setvalue(ff86007c, 1): obtained 0 (report 40))
setvalue(using type = feature): report sent successfully
Something must be different! Is the "type = feature" relevant at all?
1. { "shutdown.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "10", HU_TYPE_CMD, NULL },
2. { "shutdown.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL,
"10", HU_TYPE_CMD, NULL },
3. { "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1", HU_TYPE_CMD,
NULL },
I did "usbhid-ups -a apc1500 -k -DDD > CS500shutdown.txt 2>&1" and attached
the output in case it holds any clues.
according to your attached output, shutdown.reboot has been mapped on
UPS.PowerSummary.DelayBeforeReboot

You should try putting the above last line
(UPS.APCGeneralCollection.APCDelayBeforeReboot) before all the other
possible paths (ie 3 before 1 and 2 in apc-hid.c), recompile and try again
your procedure.
The rule for the generic USB/HID engine is that the first HID path that
exist is used to map the NUT variable, in case multiple HID paths can
satisfy it.

cheers,
Arnaud
--
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110207/3d2e8d94/attachment.htm>
Kevin
2011-02-07 09:30:08 UTC
Permalink
Post by Arnaud Quette
according to your attached output, shutdown.reboot has been mapped on
UPS.PowerSummary.DelayBeforeReboot
You should try putting the above last line
(UPS.APCGeneralCollection.APCDelayBeforeReboot) before all the other
possible paths (ie 3 before 1 and 2 in apc-hid.c), recompile and try
again your procedure.
The rule for the generic USB/HID engine is that the first HID path
that exist is used to map the NUT variable, in case multiple HID paths
can satisfy it.
Ok. Thanks. The order of the code is now:

{ "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1", HU_TYPE_CMD,
NULL },
{ "shutdown.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "10", HU_TYPE_CMD, NULL },
{ "shutdown.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL,
"10", HU_TYPE_CMD, NULL },

and the output of "usbhid-ups -a apc1500 -k -DDD > CS500shutdown.txt
2>&1" is attached.

(No visible change)

Regards,
Kevin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CS500Shutdown.reboot.txt.zip
Type: application/x-zip-compressed
Size: 3864 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110207/1319047d/attachment.bin>
Arjen de Korte
2011-02-07 11:46:07 UTC
Permalink
Post by Arjen de Korte
{ "shutdown.reboot", 0, 0,
"UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "1",
HU_TYPE_CMD, NULL },
{ "shutdown.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot",
NULL, "10", HU_TYPE_CMD, NULL },
{ "shutdown.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL,
"10", HU_TYPE_CMD, NULL },
and the output of "usbhid-ups -a apc1500 -k -DDD > CS500shutdown.txt
2>&1" is attached.
(No visible change)
Of course not. When do you start listening to my advice? :-(

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-07 12:58:13 UTC
Permalink
Post by Arjen de Korte
Of course not. When do you start listening to my advice? :-(
Arjen,

There is no call for language like that. I've spent a huge amount of
time in the last six weeks trying to sort this problem with your code.

I'll go and find other alternatives if you take that attitude.

Regards,
Kevin.
Arjen de Korte
2011-02-07 13:46:47 UTC
Permalink
Post by Kevin
There is no call for language like that. I've spent a huge amount of
time in the last six weeks trying to sort this problem with your code.
This is not *my* code. I'm just trying to help here. I would be more
than happy to ditch the APC support from NUT entirely, but due to
popular demand this is just not an option.
Post by Kevin
I'll go and find other alternatives if you take that attitude.
Whatever. I have better things to do too with my free time.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-07 14:44:55 UTC
Permalink
Post by Arjen de Korte
This is not *my* code. I'm just trying to help here.
As am I.

I would be more
Post by Arjen de Korte
than happy to ditch the APC support from NUT entirely, but due to
popular demand this is just not an option.
Exactly. I am beginning to see a 'broken firmware' pattern here.
Post by Arjen de Korte
Post by Kevin
I'll go and find other alternatives if you take that attitude.
Whatever. I have better things to do too with my free time.
That's fine. Maybe there is someone else on the project willing to put
in the time perhaps?
Arjen de Korte
2011-02-07 15:04:23 UTC
Permalink
Post by Kevin
Exactly. I am beginning to see a 'broken firmware' pattern here.
The above is the only reason why we need multiple HID subdrivers in
usbhid-ups. If every UPS vendor would care to implement (and properly
test!) their firmware, we would need exactly one subdriver that would
fit all USB HID Power Device Class UPS'es. But since many contain bugs
(and sometime conflicting implementations) we need one for almost
every vendor.

Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Kevin
2011-02-07 15:23:31 UTC
Permalink
Post by Arjen de Korte
The above is the only reason why we need multiple HID subdrivers in
usbhid-ups. If every UPS vendor would care to implement (and properly
test!) their firmware, we would need exactly one subdriver that would
fit all USB HID Power Device Class UPS'es. But since many contain bugs
(and sometime conflicting implementations) we need one for almost every
vendor.
Quite, but, as you so rightly say, every vendor is providing different
'standards', they are all offering 'broken' implementations, even
between models. This doesn't change things for us mere mortals trying to
do a job.

I've given you something that works in an older version, all you have to
do is translate that into the current version and then at least we will
have something to build on. At the moment, we have nothing working in
2.0.6 for the CS 500.
Loading...