On Sep 21, 2010, at 1:16 PM, Will Cooke wrote:
On 19 September 2010 22:16, Charles Lepple <[email protected]> wrote:
Remember when I said you were really close? Apparently, now that
we've
figured out that it isn't really "0.000000" for both cases, I think
you just
need to multiply the value by 1e7 in that function, sort of the
same way
that some Tripplite voltages are multiplied by 10:
http://trac.networkupstools.org/projects/nut/browser/trunk/drivers/tripplite-hid.c#L155
This function multiplies by the variable "battery_scale" because some
Tripp-Lite product IDs get this right, and others don't - so the
scale
factor is set at initialization time. You might want to try a similar
approach, just in case a new model comes out.
The input and output voltages look like they need a similar
adjustment, and
the frequency probably needs to be divided by 10. Actually, this was
mentioned in another email thread in July:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-July/006104.html
... and that seems to indicate that BatteryPresent and maybe other
booleans
need a scale factor, too.
Hi again,
I've made some progress with the sub-driver!
In order to work support for Vendor ID 10af probably needs to be
removed from the Belkin HID driver which tries to support the
LiebertPSP at the moment.
I've attached my efforts thus far.
The problem is that there is a Liebert PowerSure PSA which uses the
same vendor and product ID:
http://thread.gmane.org/gmane.comp.monitoring.nut.devel/4232
Please remember, I'm not a programmer - so please feel free to point
out my glaring mistakes. A lot of the new functions have been
borrowed wholesale from other functions and random web pages without
really understanding how they work.
What it does now that it didn't do before:
Report OL instead of OB when on AC
Report corrected values for voltages & frequency
Cool! Can you please send the output of "upsc your-
u...@localhost" (adjusting the second argument for your configuration)?
I expect that the values for things like "NeedReplacement" will also
need converting, but I haven't checked yet.
Also, some of the names (first column in the tables) are not quite the
standard NUT names.
What are the next steps? Obviously I will check those other values
(NeedReplacement etc) and pass them through the conversion if
required, but what about other metrics? Are ALL the features of the
UPS automatically added to the stub driver? If not, how would I go
about discovering them. For example, let's imagine the UPS could
report an estimated "time remaining", how would one discover this
feature, or is it impossible without a data sheet?
Which file did you adapt for this? belkin-hid.c?
Basically, the "feature discovery" happens when you run the usbhid-ups
driver in "explore" mode, and you might not have the same set of HID
Usages.
Details on how to run this against your UPS are here: http://buildbot.networkupstools.org/~buildbot/docs/latest/website/developer-guide.html#hid-subdrivers
(under "4.21.3. Writing a subdriver").
You can then compare the created files with the ones you just posted,
and see what pops up.
Actually, if you wouldn't mind, can you post the output of running the
driver in explore mode with "-DD"? (gzipped again, please)
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
