[Nut-upsuser] Microdowell (cpsups) driver segfault

[Arjen de Korte]

varain at flashmail.com wrote:
> Hello Arjen,
> 
> Sunday, June 24, 2007, 8:44:04 PM, you wrote:
> 
>>>> What I would like to know, is what is read from the UPS. The output of
>>>> 'upsc' can help here.
>>> Let me know if you need any other data.  IIRC, it sends that info back
>>> everytime the ups is polled.
> 
>> I meant the readings from the UPS Varain has, to see if the reading of
>> 'output.voltage' when on battery is approximately the same as
>> 'input.voltage.nominal'. If they are (almost) the same, this is an
>> indication that the input voltage to the UPS is low. If it is around 208V,
>> that probably means that we need to convert the values.
> 
>> We know the readings from your UPS are close enough, to assume that it
>> measures them directly, so we don't need a correction factor and/or
>> offset.
> 
>> Best regards, Arjen
> 
> Well, it might not be what you expected, but I have a new problem :
> 
> I did something like this :
> 
> # upscmd ups1 at localhost test.battery.start
> 
> (some time later... )
> 
> # upscmd ups1 at localhost test.battery.stop
> (ups1 is the MicroDowell )
> 
> there were no messages , but asking for parameters got me this ...
> # upsc ups1 at localhost
> battery.capacity: 7
> battery.charge: 0.0
> battery.charge.low: 20
> battery.packs: 2
> battery.voltage.nominal: 12
> driver.name: powerpanel
> driver.parameter.port: /dev/ttyS0
> driver.version: 2.0.5
> driver.version.internal: 0.12
> input.frequency: 0
> input.frequency.high: 63
> input.frequency.low: 47
> input.transfer.high: 272
> input.transfer.low: 180
> input.voltage: 0
> input.voltage.nominal: 230
> output.voltage: 0
> ups.firmware: 2.107
> ups.load: 0
> ups.mfr: CYBER POWER
> ups.model: 1000VA
> ups.power.nominal: 1000
> ups.realpower.nominal: 700
> ups.serial: 000000000000
> ups.status: OFF
> ups.temperature: 0

The fact that many readings are zero, is due to a bug in the nut-2.0.5
powerpanel driver. It should not parse the data from the UPS if the
reply it gets is shorter than expected. Instead, You'll probably see in
the logs 'Status read failed!' while the driver was still running and
after that should tell that the data is stale.

> Obviously, the ups is still providing power(it's the only power source for this computer).
> I've tried to restart the driver and got this :
> 
> Network UPS Tools - UPS driver controller 2.0.5
> Network UPS Tools -  CyberPower text protocol UPS driver 0.12 (2.0.5)
> Warning: This is an experimental driver.
> Some features may not function correctly.
> 
> warning: sent "\r", expected "#2\r" but got ""
> warning: sent "P4\r", expected "#<something>" but got ""
> warning: sent "\r", expected "#2\r" but got ""
> warning: sent "P4\r", expected "#<something>" but got ""
> warning: sent "\r", expected "#2\r" but got ""
> warning: sent "P4\r", expected "#<something>" but got ""
> warning: sent "\r", expected "#2\r" but got ""
> warning: sent "P4\r", expected "#<something>" but got ""
> warning: sent "\r", expected "#2\r" but got ""
> warning: sent "P4\r", expected "#<something>" but got ""
> Unable to detect a CyberPower text protocol UPS
> Driver failed to start (exit status=1)

Well, apparently the UPS is not talking to us anymore. That's strange.

> I'm not sure what the problem is ...
> as for solving it, the "windows solution" of restarting the whole thing (ups+computer) would probably work,
> but it's not pretty ... (not to mention inconvenient , as the system is in a remote site, with no easy access)

That's really weird. I don't have a Cyber Power UPS available for
testing here, bug maybe Doug can try out this command and see what happens.

As always, testing experimental drivers is risky when the system you're
working on is remote, but that warning comes too late now.

Best regards, Arjen