Success! Turns out NUT was looking for some pretty specific paths, which I printed out to the screen as it looked for them. Once I added some bits in UPS.PowerSummary.PresentStatus.*, then it started checking for those and getting reports.
I think I'm finally starting to get it....If I want this UPS to use just the generic usbhid-ups driver, then I'm going to have to structure my reports descriptor to match what it's looking for. Otherwise, I can go off on my own and structure my reports any way I want...but then I'll have to write my own NUT driver to look for those specific values (paths). I may end up having to do that anyway depending on what else we want our UPS to be able to do, but at this point I don't see why I shouldn't just write our firmware to work with the usbhid-ups directly. -----Original Message----- From: Nut-upsdev [mailto:[email protected]] On Behalf Of Rob Groner Sent: Thursday, March 13, 2014 9:44 AM To: [email protected] Developers Subject: Re: [Nut-upsdev] Developing the UPS side of the UPS-NUT equation (via usbhid) Hmm...well, after it gets the report descriptor, NUT then gets each of the reports defined in there, so that's good. But after that, there are no more messages (no more reports being requested...the NUT debug info just shows "libusb_get_interrupt: Connection timed out" repeatedly). I put in some enticing values into the report descriptor, like shutdownimminent and discharging and charging, hoping that would get NUT interested enough to ask for those status, but not so far. I'm missing something obvious. I'm going to dig into NUT to see if I can find where it decides what reports to get during the "Quick update". _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
