[Nut-upsdev] Developing the UPS side of the UPS-NUT equation (via usbhid)
Rob Groner
rgroner at RTD.com
Wed Mar 12 21:18:02 UTC 2014
So, going with the proposed initial design, I created a report descriptor to describe the battery. I thought that I'd then see how NUT responded to it. The good news is that the descriptor showed up and all of the paths were correct. Unfortunately, after that, nothing happened...no reports were requested, and it just kept timing out. Is there some minimum amount of functionality I need to provide in this report descriptor in order for NUT to work correctly? I assume it's not requesting reports because there is nothing it wants to know about.
Here is what I have so far:
USAGE_PAGE (Power Device)
USAGE (UPS)
COLLECTION (Application)
USAGE (BatterySystem)
COLLECTION (Physical)
REPORT_ID (1)
USAGE (Voltage)
REPORT_SIZE (8)
REPORT_COUNT (1)
UNIT (SI Lin:Volts)
LOGICAL_MINIMUM (0)
LOGICAL_MAXIMUM (255)
FEATURE (Data,Var,Abs)
REPORT_ID (2)
USAGE (Temperature)
REPORT_SIZE (8)
REPORT_COUNT (1)
LOGICAL_MINIMUM (0)
LOGICAL_MAXIMUM (255)
UNIT (SI Lin:Temperature)
FEATURE (Data,Var,Abs)
USAGE_PAGE (Battery System)
REPORT_ID (3)
USAGE (RemainingCapacity)
REPORT_SIZE (8)
REPORT_COUNT (1)
LOGICAL_MINIMUM (0)
LOGICAL_MAXIMUM (100)
FEATURE (Data,Var,Abs)
END_COLLECTION
END_COLLECTION
From: Nut-upsdev [mailto:nut-upsdev-bounces+rgroner=rtd.com at lists.alioth.debian.org] On Behalf Of Rob Groner
Sent: Wednesday, March 12, 2014 10:48 AM
To: nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] Developing the UPS side of the UPS-NUT equation (via usbhid)
The syntax is beginning (just beginning) to make sense to me now, so I'm looking now to try and implement just a few items in the report descriptor, and then I figured I can progress from there if all goes well.
The power HID docs seem to encourage drawing out your system first, and then letting the report descriptor flow from there. So, my very simplified system goes like this:
[Battery]===DC Flow ==>[Power Summary]
All of the drawings seem to end in a power summary, and the doc seemed to stress that it was essential to power management software being able to effectively use it, so I'll include it.
I think I understand how the usages work now....they're basically like establishing the namespace (like com.java.class, etc). I had been confused before when I would see multiple usage() statements all following each other, but seeing it in the nut output as the path makes it more clear.
So, pretty much everything should be under the UPS usage. Then I would define things under the battery usage, then the flow usage, and then the power summary usage...right?
Where I'm still foggy is two things....first collections. I'm pretty sure there's supposed to be an application collection, and then I usually see a physical collection, but I'm still not completely understanding what their purpose is.
The second thing I still don't understand is the minimum/maximum descriptors. Ok, Logical min/max I get...that's just the range of the actual value in the report...basically a way to indicate if it is unsigned or signed. If you only have an 8 bit value specified, then I'd guess you can't have a logical max greater than 255. But physical min/max are a bit confusing. Is it just a means of scaling or offsetting the logical value?
So, for instance temperature. Our UPS has a temperature monitor on it, but HID temperature values are in Kelvin. I could define an 8-bit temperature field, with a logical min/max of 0/100, and a physical min/max of 273/373. So if I pass 50 as a value, then it gets read as 323 on the PC side? And if the physical range is much greater than the logical range, then it just scales it?
The other min/max I don't quite understand is usage min/max. I'm thinking they have something to do with the usages "OutputID", "FlowID", etc.
Thank you for the help so far. I really wish there were better learning docs out there for the un-initiated.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20140312/f157144e/attachment.html>
More information about the Nut-upsdev
mailing list