[Nut-upsdev] [PATCH][RFC] OpenUPS driver

[Arnaud Quette]

2012/11/29 Nicu Pavel <npavel at mini-box.com>

> Hi,
>

Hi


> On Wed, Nov 28, 2012 at 11:46 PM, Arnaud Quette <aquette.dev at gmail.com>wrote:
>
>>
>>
>> 2012/11/28 Nicu Pavel <npavel at mini-box.com>
>>
>>> Hi,
>>
>>
>> Hi
>>
>> thanks for your patches.
>> though I've started to process your 1rst patch 6 days ago, my current
>> latency should push me in acknowledging first...
>> note that I've discarded your 2nd patch, since the issue was already well
>> addressed.
>>
>
> Thanks. Did you have a change to look at the issue with parsing the 16
> bits report taking just 1 byte from report ?:
>
> Report[get]: (5 bytes) => 20 99 01 1a 03
> Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x20,
> Offset: 0, Size: 16, Value: 153
>
> I tried different things in firmware and there is always a 16bit size
> report that gets truncated.
>

at first sight, no idea, and I really don't have time to play with the
report dump.
try using the driver with debug level 5, and post back the trace excerpt.
we'll see more details


>
>> [...]
>>>
>>
>> - I've commented the "battery.cell<n>.voltage" variables.
>> As stated in docs/nut-names.txt (aka "NUT command and variable naming
>> scheme"):
>> "If you need a new variable or command name, contact the Development Team
>> first."
>> This will need a dedicated discussion, still on -upsdev
>>
>> - I've moved "therm_tbl & size" from openups-hid.h to .c
>>
>> - BTW, there are some non-compliance such as with Usage IDs for "Cell?"
>> (0x0000000?):
>> as per the HID/PDC spec<http://www.usb.org/developers/devclass_docs/pdcv10.pdf>,
>> § 4:
>> "Usage pages xFF00 to xFFFF are reserved by HID for vendor-specific
>> implementation."
>>
>
> Yes I used them since I thought these cellX.voltage aren't standard but
> they are important for us to list.
> 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.
> ATM I'm not sure I can make them into standard HID UPS path.
>

as told, simply map the correct values for Usage Page and Usage ID.


>
>
>>
>> - battery.capacity is in Ah!
>>
>
> 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.
>

that's what caught my attention: it's not open as in opensource but open as
in plug-anything-you-want.


>
> and you'll have to actually fill in your (FW) string descriptor ;)
>>
>
> 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.
>

you already have some that are done fine (iName, iProduct, ...)
but some others are wrong (iDeviceChemistry, ...). all Usage strings
starting with an "i" belong to the string table.

cheers,
Arnaud
-- 
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121203/570d1cc1/attachment.html>