[Nut-upsdev] Re: CyberPower 685AVR and newhidups

[Arnaud Quette]

I took the occasion to congrats Peter for his excellent work on the
newhidups subject. As for most of my tasks, I've generally little time to
start things, and then about no time to follow on (I really have tons of
things in mind for nut to reach its best). But generally, my aim is to show
the way, make the basis, suppress barriers and hope some manpower will come
to continue ;-)

So once more Peter, many kudos!

2005/10/23, Peter Selinger <selinger at mathstat.dal.ca>:
>
> Dear Scott,
>
> fantastic! Thanks for that data. Indeed, the CyberPower usage tree
> looks extremely similar to that of APC. I have added support for your
> CyberPower device to the Development branch on CVS.
>
> Please test this. Run the driver as:
>
> drivers/newhidups -DD -u root -x vendorid=0764 auto
>
> (without the -x generic option from last time, as your model is now
> supported).
>
> I am particularly interested in the following variables:
>
> * ups.power.nominal
> (this should report ca. 550VA. The device reports this as 390W, but
> NUT requires power to be reported in VA (not Watts), so I have
> converted the value. Arnaud: is this the correct thing to do?)


perfect

* ups.delay.shutdown
> (this should report -1. This variables is writable to initiate a
> timed shutdown. It would be great if you could test this. Be careful
> to disconnect any equipment before testing.)


A note I might not have yet given about the "-1" value:
- most UPS previously defined some startup / shutdown timer, exposing the
real value of the delays in ups.delay.* and using some other data to start
the poweroff sequence.
This is not the case with newhidups / USB because these are "instant
timers". This mean that if you put some value in it, the timer will start
immediately and ie poweroff your unit! Thus the "-1" value means "no timer
initiated", which is not so meaningful for users.

- I'm so thinking for some time about an internal newhidups flag that would
only propagate the value setting to the device when it's needed (ie at
shutdown time in our case) and so being able to expose the configured values
(and not only in the driver.* collection)
...

* ups.test.result
> (this should report "passed" or similar. The main interest of this
> variable is what happens when writing to it. Writing "1", "2", or
> "3", respectively, should initiate up to three different types of
> tests. Writing "0" should abort a test in progress. It would be
> great if you could report back what kind of test these actions
> perform.)
>
> Please also check the values of the remaining variables to see that
> they make sense. It would be great if you could post the output of
> "upsc upsname at localhost" back to the list.
>

and one more idea linked to the QA thought: making a tester/feedback helper
(the "upstest" thing I've mentionned in some areas). This would be
particularly usefull for development, but also for validating the compat for
the list, and some other things...

see you,
Arnaud
--
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20051024/d0eaf36c/attachment.html