[Nut-upsdev] Driver for Cyberpower PR2200

[Russ Romano]

> > The updated spreadsheet can be found here: 
> > http://www.lvahs.com/pr2200.xls
> 
> I was able to decode quite a few things from this. At least 
> the 'F' command and 'D' command and their results are more or 
> less clear. However, it appears that there are some registers 
> that can be set, possibly some levels where the UPS switches 
> to battery and when to raise the low battery alarm. It 
> appears that whatever is set, can be read through the 
> 'R<command>\r' command, which probably responds with the 
> current setting. So far I have seen the commands 2, 4, 8, 15, 
> 24, 41, 43, 61.

There are definitely registers to set, and there are clear ways to set
them in the PowerPanel Plus software.

> What we need you to do, is play around with the settings a 
> little, while recording what is sent to the UPS. Change a 
> value, wait a couple of seconds and go to the next one for 
> that parameter. Start with the default value and sequentially 
> move through the list twice. The latter is important, since 
> we also want to know how to go back to the default value once 
> that has changed.
>
> From the list you sent earlier, I estimate that you will be 
> able to set the following values in the UPS (the others 
> appear to be done by the software on the host):
> 
> buzzer : [on],off
> cold start : on,[off]
> high input voltage : [138],139,140,141,142,143,144,145,146,147
> low input voltage : 88,89,90,91,92,93,94,95,96,[97]
> battery critical capacity : [25],30,35,40,45,50,55,60
> battery mode output voltage configuration : 110,[120],130
> 

I believe I can vary each of these in the PowerPanel Plus software.

> Make a separate sheet for each of the commands, so that we 
> don't mix them up.
> 
> I'll probably write a new driver for this, based on the 
> powerpanel driver. Since the command set looks quite similar 
> (short of the fact that values are binary, rather than in 
> text mode), they will be merged in one driver eventually. 
> I'll just need to find a neat way to autodetect the different 
> versions.
> 
> One thing I particularly don't like about the current 
> cyberpower driver, is that the driver attempts to 'correct' 
> the readings from the UPS. I don't think this is a good idea, 
> since you'll have to convert back and forth between UPS and 
> NUT representation when setting the parameters mentioned 
> above. You'll end up with a complex driver, that is optimized 
> for one single device (the one you used to calibrate the 
> readings), but can be way off for others.

Can you elaborate on this a little?  Are you saying that the temperature
reported by the UPS is not the temperature displayed in powerpanel?
This might explain the offsets between the values reported in the OEM
linux software and what the existing powerpanel driver reported for
charge, temp, etc.

> Best regards, Arjen
> 
> PS  Please don't record the time in PortMon, this makes the 
> output very hard to read, since a lot of junk lines will be 
> inserted. From what we know from the protocol already, we can 
> keep track of what is happening. Just don't turn all the 
> knobs at the same time. :-)

I will eliminate the time from portmon.  When the data is logged to the
screen it doesn't clutter anything or add extra lines.  I wanted to have
it in there because it provided a clear map between the status reports
in portmon and the status lines from the powerpanel log.  Unfortunately,
portmon makes a mess of things when it logs to a file.

> PPS  One way to make sure that you capture all data when 
> draining the battery completely, is to not power the system 
> from the UPS.

As Doug noted... This doesn't help.  I captured this data on a laptop
and it wasn't plugged into the UPS.  Unfortunately, powerpanel doesn't
have an option to control the UPS, but not be dependent on it, so it
forces the machine to shut down... and it takes portmon with it.  That's
why I logged to a file, hoping to get that final communication from the
PC to the UPS that says, "I'm shutting down now, and you should shut
down after x seconds".  Not sure how complete the log file was in this
regard.

Thanks!
-Russ