Hi Christopher,
2011/10/31 Christopher Newcombe
> Hi all, just installed the nut package from apt on Ubuntu. Here's what I
> got.
>
> Network UPS Tools - UPS driver controller 2.4.3
> Network UPS Tools - Generic HID driver 0.34 (2.4.3)
> USB communication driver 0.31
> This APC device (051d:00
On Oct 31, 2011, at 4:14 PM, Christopher Newcombe wrote:
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
This APC device (051d:0003) is not (or perhaps not yet) supported
by usbhid-ups. Please make sure you have an
Citeren Kevin :
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.retur
On 08/02/2011 16:48, Arjen de Korte wrote:
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.APCGeneralC
Citeren Kevin :
On power:
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 closur
On 08/02/2011 15:50, Arjen de Korte wrote:
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 08/02/2011 16:09, Kevin wrote:
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.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists
Citeren 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?
Would you like me to prov
On 08/02/2011 14:55, Arjen de Korte wrote:
{ "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 outp
Citeren Kevin :
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
on 07/02/2011 22:04 Arjen de Korte wrote:
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. B
Citeren 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
on 07/02/2011 20:58 Arjen de Korte wrote:
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,
on 07/02/2011 20:46 Arjen de Korte wrote:
Citeren Kevin :
This is not *my* code. I'm just trying to help here.
As am I.
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.
Exactly. I am beginning to see a 'broken fir
Citeren 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 orig
Citeren 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
on 07/02/2011 15:36 Arjen de Korte wrote:
Citeren Kevin :
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.
I did this with the old working modified hidups drive
on 07/02/2011 18:46 Arjen de Korte wrote:
Citeren Kevin :
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
Citeren Kevin :
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"
2011/2/7 Kevin
> On 06/02/2011 21:42, Kevin wrote:
>
> on 06/02/2011 21:06 Charles Lepple wrote:
>
>
> 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
Citeren Kevin :
On 06/02/2011 21:42, Kevin wrote:
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.
I did this with the old workin
on 06/02/2011 21:06 Charles Lepple wrote:
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 t
On Sun, Feb 6, 2011 at 8:29 AM, Kevin wrote:
> 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"); */
on 06/02/2011 18:19 Arjen de Korte wrote:
Citeren 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.
You could
try if changing
>
{ "shutdown
Citeren 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
{
on 25/01/2011 03:58 Arjen de Korte wrote:
Citeren 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
Citeren 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 p
Citeren Kevin :
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
Here it is.
Much better, thanks! Could you do the same for the CS
Citeren Kevin :
./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK
# ./clients/upsc apc1500
[...]
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 post
Citeren Kevin :
Different
# ./clients/upsc apc1500
[...]
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...
./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500
OK
# ./client
on 23/01/2011 16:16 Arjen de Korte wrote:
Citeren Kevin :
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 ab
Citeren 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 occure
on 23/01/2011 03:41 Arjen de Korte wrote:
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"
Citeren Kevin :
[...]
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.
on 22/01/2011 15:35 Arjen de Korte wrote:
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|
Citeren 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
patched driver. I don't know, but these lines may be significant:
# grep "Value: 90" APC-1000.patched.txt
1.397898 Path: UPS.Output.AP
Arjen de Korte de-korte.org> writes:
> 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 a
37 matches
Mail list logo
