Nut upsuser - Dec 2007 - APC smartups 1500 is broken with usbhid-ups

I'm trying to setup a server controlling 8 ups, 6 APC Smartups 1500  
and two 1000. Because of the number of ups, i connected them using usb  
cables.

I'm using Debian Etch AMD64 and nut 2.2.0 from testing (already tried  
2.0 from stable, but had problems reading the ups serials and all the  
following problems of 2.2).

This is my ups.conf:
[ups2]
     driver = usbhid-ups
     port =  auto
     vendorid = 051d
     serial = AS0413113031
     offdelay=5
     ondelay=30
     sdorder = 4

The output of "upsrw ups2 at localhost":
[battery.charge.low]
Remaining battery level when UPS switches to LB (percent)
Type: STRING
Value: 10

[battery.runtime.low]
Remaining battery runtime when UPS switches to LB (seconds)
Type: STRING
Value: 120

[ups.beeper.status]
UPS beeper status
Type: STRING
Value: enabled

[ups.delay.restart]
Description unavailable
Type: STRING
Value: -1

[ups.delay.shutdown]
Interval to wait after shutdown with delay command (seconds)
Type: STRING
Value: -1

After running "upsrw -u someuser -p somepass -s ups.delay.restart=60  
ups2 at localhost" the value of "ups.delay.restart" is 180. I
tried all
the values in APC manual, but the value stored in the variable is  
never the one i specified. "ups.delay.shutdown" has the same
behaviour.

Now, the big problem: if i test a ups shutdown without setting a value  
(could be anything) to "ups.delay.restart", the ups shutdowns  
completely, and it doesn't return when i plug in the power cord. If i  
set something first, the ups goes to standby mode (as it should), and  
when i plug the power, the ups restarts powering up the servers, but  
it powers immediately after i plug the power cord... without any kind  
of delay.

After 2 days of testing, frustrated, i tried to setup a new nut  
server. Different machine,  same hardware and same software. This time  
i used a serial cable and apcsmart driver. Everything just worked!

My new ups.conf:
[ups3]
     driver = apcsmart
     port =  /dev/ttyS0

The relevant output of "upsrw ups3 at localhost":
[ups.delay.shutdown]
Interval to wait after shutdown with delay command (seconds)
Type: ENUM
Option: "090" SELECTED
Option: "180"
Option: "270"
Option: "360"
Option: "450"
Option: "540"
Option: "630"
Option: "000"

[ups.delay.start]
Interval to wait before (re)starting the load (seconds)
Type: ENUM
Option: "000"
Option: "060" SELECTED
Option: "120"
Option: "180"
Option: "240"
Option: "300"
Option: "360"
Option: "420"

The variables keep the exact values that i set with upsrw, and the ups  
behaviour is the one expected. It standbys when i do a power test, and  
it powers up the servers respecting the exact delays i set in the  
variables.

Due to hardware limitations (too much ups, too few serial ports) i  
cannot connect all the ups with serial cables, and i cannot use usb  
cables because all these problems.

Am i doing something wrong? What can i do to help? I can post all the  
command output you want.

Thanks.

---
Francisco Castanheiro
Departamento de Inform?tica
Faculdade de Ci?ncias e Tecnologia - UNL
E-mail: fdsc at di.fct.unl.pt

> I'm trying to setup a server controlling 8 ups, 6 APC Smartups 1500
> and two 1000. Because of the number of ups, i connected them using usb
> cables.
>
> I'm using Debian Etch AMD64 and nut 2.2.0 from testing (already tried
> 2.0 from stable, but had problems reading the ups serials and all the
> following problems of 2.2).
I'm a bit confused here. Do you mean the version from Debian testing, or
the version from NUT SVN Testing? My guess is the first (which would
explain your observations) but it's better to be sure. So what version is
reported on startup of the drivers?
> This is my ups.conf:
> [ups2]
>      driver = usbhid-ups
>      port =  auto
>      vendorid = 051d
>      serial = AS0413113031
>      offdelay=5
>      ondelay=30
>      sdorder = 4
It's better not to override the built-in defaults for 'offdelay' and
'ondelay' while testing.
> The output of "upsrw ups2 at localhost":
> [battery.charge.low]
> Remaining battery level when UPS switches to LB (percent)
> Type: STRING
> Value: 10
>
> [battery.runtime.low]
> Remaining battery runtime when UPS switches to LB (seconds)
> Type: STRING
> Value: 120
>
> [ups.beeper.status]
> UPS beeper status
> Type: STRING
> Value: enabled
>
> [ups.delay.restart]
> Description unavailable
> Type: STRING
> Value: -1
>
> [ups.delay.shutdown]
> Interval to wait after shutdown with delay command (seconds)
> Type: STRING
> Value: -1
This all looks good.
> After running "upsrw -u someuser -p somepass -s ups.delay.restart=60
> ups2 at localhost" the value of "ups.delay.restart" is 180.
I tried all
> the values in APC manual, but the value stored in the variable is
> never the one i specified. "ups.delay.shutdown" has the same
behaviour.
The fact that the driver made these values writable, was a mistake. These
should be read-only. Since setting these values will start a timer
immediately, they should be changed through 'upscmd'. This was corrected
in the latest version available through SVN in either the 'trunk' or
'branches/Testing'.
> Now, the big problem: if i test a ups shutdown without setting a value
> (could be anything) to "ups.delay.restart", the ups shutdowns
> completely, and it doesn't return when i plug in the power cord.
That's another thing that is broken in the latest stable version
(nut-2.2.0). Again, fixed in the above mentioned versions.
> If i set something first, the ups goes to standby mode (as it should), and
> when i plug the power, the ups restarts powering up the servers, but
> it powers immediately after i plug the power cord... without any kind
> of delay.
That is not the meaning of the 'ups.delay.start'. This will only delay
startup if mains power is uninterrupted and you command the UPS to
shutdown with a delay and back on again with a delay. Broken in your
version.

[...]
> Am i doing something wrong? What can i do to help? I can post all the
> command output you want.
You're not doing something wrong, it is the driver that is misbehaving.
The next stable version was scheduled for realease a couple of weeks ago.
Unfortunately, this has been delayed for lack of time to do this.

For now the best advice I can give you, is to pull the version from
'branches/Testing' and run that. The above mentioned problems should be
fixed in that version. If that's still causing problems, posting the
output of the first 30 seconds of the output from the following command

    <path>/usbhid-ups -DD -a ups2

might provide a clue what is going on.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57