<br><div class="gmail_quote">2012/11/29 Nicu Pavel <span dir="ltr"><<a href="mailto:npavel@mini-box.com" target="_blank">npavel@mini-box.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br></blockquote><div><br>Hi<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">On Wed, Nov 28, 2012 at 11:46 PM, Arnaud Quette <span dir="ltr"><<a href="mailto:aquette.dev@gmail.com" target="_blank">aquette.dev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote">2012/11/28 Nicu Pavel <span dir="ltr"><<a href="mailto:npavel@mini-box.com" target="_blank">npavel@mini-box.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi,</blockquote><div><br>Hi<br><br>thanks for your patches. <br>though I've started to process your 1rst patch 6 days ago, my current latency should push me in acknowledging first...<br>note that I've discarded your 2nd patch, since the issue was already well addressed.<br>

</div></div></blockquote><div><br></div></div><div>Thanks. Did you have a change to look at the issue with parsing the 16 bits report taking just 1 byte from report ?:</div><div class="im"><div><br></div><div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">

Report[get]: (5 bytes) => 20 99 01 1a 03</div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x20, Offset: 0, Size: 16, Value: 153</div>

</div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><br></div></div><div style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
I tried different things in firmware and there is always a 16bit size report that gets truncated.</div></div></blockquote><div><br>at first sight, no idea, and I really don't have time to play with the report dump.<br>
try using the driver with debug level 5, and post back the trace excerpt. we'll see more details<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div>
<br></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>[...]</div></blockquote></div><div class="im"><div>
<br>- I've commented the "battery.cell<n>.voltage" variables.<br>As stated in docs/nut-names.txt (aka "NUT command and variable naming scheme"):<br>"If you need a new variable or command name, contact the Development Team first."<br>


This will need a dedicated discussion, still on -upsdev<br><br>- I've moved "therm_tbl & size" from openups-hid.h to .c<br><br>- BTW, there are some non-compliance such as with Usage IDs for "Cell?" (0x0000000?):<br>


as per the <a href="http://www.usb.org/developers/devclass_docs/pdcv10.pdf" target="_blank">HID/PDC spec</a>, § 4: <br>"Usage pages xFF00 to xFFFF are reserved by HID for vendor-specific implementation."<br></div>

</div></div></blockquote><div><br></div><div>Yes I used them since I thought these cellX.voltage aren't standard but they are important for us to list.</div><div>I haven't managed to make a Battery System layout in the microchip firmware  where I could list multiple batteries with an ID and voltage for each. I didn't find deeper documentation/examples and I resorted to uglier way to make them non-standard.</div>

<div>ATM I'm not sure I can make them into standard HID UPS path.</div></div></blockquote><div><br>as told, simply map the correct values for Usage Page and Usage ID.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br>
- battery.capacity is in Ah!<br></div></div></blockquote><div><br></div></div><div>That's something I will try to fix on next firmware releases(along with battery.type). Since openUPS can be used with all kinds of batteries this  needs to be listed correctly.</div>
</div></blockquote><div><br>that's what caught my attention: it's not open as in opensource but open as in plug-anything-you-want.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
and you'll have to actually fill in your (FW) string descriptor ;)<br clear="all"></div></div></blockquote><div><br></div></div><div>As far as I've seen on firmware the strings are filled and linked into  report with STRING_INDEX(ID). I will have to check the dumps and see what's happening.</div>
</div></blockquote><br>you already have some that are done fine (iName, iProduct, ...)<br>but some others are wrong (iDeviceChemistry, ...). all Usage strings starting with an "i" belong to the string table.<br clear="all">
</div><br>cheers,<br>Arnaud<br>-- <br>NUT (Network UPS Tools) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>
Free Software Developer - <a href="http://arnaud.quette.fr" target="_blank">http://arnaud.quette.fr</a><br><br>