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 ;-)<br>
<br>
So once more Peter, many kudos!<br><br><div><span class="gmail_quote">2005/10/23, Peter Selinger <<a href="mailto:selinger@mathstat.dal.ca">selinger@mathstat.dal.ca</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear Scott,<br><br>fantastic! Thanks for that data. Indeed, the CyberPower usage tree<br>looks extremely similar to that of APC. I have added support for your<br>CyberPower device to the Development branch on CVS.<br><br>
Please test this. Run the driver as:<br><br>drivers/newhidups -DD -u root -x vendorid=0764 auto<br><br>(without the -x generic option from last time, as your model is now<br>supported).<br><br>I am particularly interested in the following variables:
<br><br>* ups.power.nominal<br> (this should report ca. 550VA. The device reports this as 390W, but<br> NUT requires power to be reported in VA (not Watts), so I have<br> converted the value. Arnaud: is this the correct thing to do?)
</blockquote><div><br>
perfect<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* ups.delay.shutdown<br> (this should report -1. This variables is writable to initiate a
<br> timed shutdown. It would be great if you could test this. Be careful<br> to disconnect any equipment before testing.)</blockquote><div><br>
A note I might not have yet given about the "-1" value:<br>
- 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.<br>
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.<br>
<br>
- 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)<br>
</div>...<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* ups.test.result<br> (this should report "passed" or similar. The main interest of this
<br> variable is what happens when writing to it. Writing "1", "2", or<br> "3", respectively, should initiate up to three different types of<br> tests. Writing "0" should abort a test in progress. It would be
<br> great if you could report back what kind of test these actions<br> perform.)<br><br>Please also check the values of the remaining variables to see that<br>they make sense. It would be great if you could post the output of
<br>"upsc upsname@localhost" back to the list.<br>
</blockquote></div><br>
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...<br><br>
see you,<br clear="all">Arnaud<br>-- <br>Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt<br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/">http://www.networkupstools.org/</a><br>Debian Developer -
<a href="http://people.debian.org/~aquette/">http://people.debian.org/~aquette/</a><br>OpenSource Developer - <a href="http://arnaud.quette.free.fr/">http://arnaud.quette.free.fr/</a>