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:0003) is not (or perhaps not yet) supported
by usbhid-ups. Please
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
Hi Christopher,
2011/10/31 Christopher Newcombe cnewco...@holy-comforter.org
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
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 output?
Citeren Kevin bakd...@gmail.com:
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
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
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
Citeren Kevin bakd...@gmail.com:
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
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,
Citeren Kevin bakd...@gmail.com:
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
2011/2/7 Kevin bakd...@gmail.com
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
Citeren Kevin bakd...@gmail.com:
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 },
{
on 07/02/2011 18:46 Arjen de Korte wrote:
Citeren Kevin bakd...@gmail.com:
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
on 07/02/2011 15:36 Arjen de Korte wrote:
Citeren Kevin bakd...@gmail.com:
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
Citeren Kevin bakd...@gmail.com:
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
Citeren Kevin bakd...@gmail.com:
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
on 07/02/2011 20:46 Arjen de Korte wrote:
Citeren Kevin bakd...@gmail.com:
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
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
Citeren Kevin bakd...@gmail.com:
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
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.
Citeren Kevin bakd...@gmail.com:
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
Citeren Kevin bakd...@gmail.com:
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 },
on 06/02/2011 18:19 Arjen de Korte wrote:
Citeren Kevin bakd...@gmail.com:
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
On Sun, Feb 6, 2011 at 8:29 AM, Kevin bakd...@gmail.com 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
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
Citeren Kevin bakd...@gmail.com:
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
Citeren Kevin bakd...@gmail.com:
./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.
Citeren Kevin bakd...@gmail.com:
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 21
Here it is.
Much better, thanks! Could you do the
Citeren Kevin bakd...@gmail.com:
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
Citeren Kevin bakd...@gmail.com:
#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
on 23/01/2011 16:16 Arjen de Korte wrote:
Citeren Kevin bakd...@gmail.com:
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
Citeren Kevin bakd...@gmail.com:
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
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
Citeren Kevin bakd...@gmail.com:
[...]
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
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 bakd...@gmail.com:
[apc1500]
driver=usbhid-ups
port=auto
ondelay=200
offdelay=1
Yes.
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
Arjen de Korte nut+users at 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
37 matches
Mail list logo
