[Nut-upsdev] CyberPower PR3000E works with powerpanel driver

[Arjen de Korte]

Citeren Laurent Léonard <laurent op open-minds.org>:

> debian:~# upsc ups
> battery.charge: 100
> battery.charge.low: 45
> driver.name: powerpanel
> driver.parameter.pollinterval: 2
> driver.parameter.port: /dev/ttyS0
> driver.version: 2.2.2
> driver.version.internal: 0.23
> input.frequency: 20.0

Working back from the driver, the UPS is reporting '50'. The  
conversion the driver does (dividing by 2.5 is apparently wrong). I  
was unsure about the logic behind this. A PR2200 running 120 V / 60 Hz  
was showing '150'. Apparently, we need to find the correct algorithm  
here.

> input.frequency.nominal: 50
> input.transfer.high: 147

Here the UPS protocol reports '0', which is an offset to the default  
transfer level that is configured for this UPS. This is now table  
based, but this is wrong. The UPS probably has two defaults (for 120 V  
and 230 V nominal respectively).

> input.transfer.low: 88

Same as for the 'input.transfer.high'.

> input.voltage: 176

This is shown as is, so apparently we need to apply a scaling and/or  
offset to get the correct reading (the protocol is only able to report  
values in the 0..255 range). I suspect that it will be the first  
(since this is easier to do in hardware), so this factor is likely  
close to (4/3) which would result in a corrected voltage of 234 V.

> input.voltage.nominal: 230
> output.voltage: 176

Same as for the 'input.voltage'.

> output.voltage.nominal: 120

Here the UPS protocol reports '0', which is an offset to the default  
output voltage that is configured for this UPS. Most likely, this  
offset should be added to the 'input.voltage.nominal' value. Now it is  
value from a lookup table, which is quite wrong (you can probably set  
the output to 220, 230 and 240 V).

> ups.beeper.status: enabled
> ups.firmware: 1.100
> ups.load: 24
> ups.mfr: CyberPower
> ups.model: PR3000E
> ups.serial: [unknown]
> ups.start.battery: yes
> ups.status: OL
> ups.temperature: 41

All in all it doesn't look too bad. There are a couple of readings  
that need correcting however, so the support status would be  
'experimental' for now.

> debian:~# upsrw -s input.transfer.high=129 -u local ups
> Password:
> Unexpected response from upsd: ERR ACCESS-DENIED
> - I always get the following message when I try to use upsrw:
> Unexpected response from upsd: ERR ACCESS-DENIED
> - Tested values: "input.transfer.high" and "battery.charge.low"

This is unrelated to the driver. The user 'local' apparently has not  
been given access to change variables. See 'man 5 upsd.users' and 'man  
5 upsd.conf' to give the user 'local' rights to do so.

> debian:~# upscmd -u local ups test.failure.start
> Password:
> - upscmd seems to have no effect and doesn't return something...
> - Tested values: "test.failure.start" and "test.failure.stop"

Same here as the above.

> I tested manual failure test mode (directly with the button on the hardware)
> and I also simulated a line failure and everything worked as expected (master
> and slaves machines shutdown and UPS shutdown).

The above means that the driver is useable with the PR3000E but  
support is basic for now.

There should be a Linux driver available from CyberPower. This would  
help us in finding the correct defaults for the  
'input.transfer.(high|low)'. Could you run that and post your findings  
here?

Best regards, Arjen
-- 
Please keep list traffic on the list