[Nut-upsuser] APC smartups 1500 is broken with usbhid-ups

[Arjen de Korte]

> 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