similar to: Developing the UPS side of the UPS-NUT equation (via usbhid)

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

My company is developing a new UPS, with smarts provided by a PIC32 Microchip micro-controller. The controller comes with a demo for a USBHID-UPS, and after some tweaking, I was able to get NUT to recognize it and start showing some reasonable values. To make this UPS as easy to use as possible for the end-user who chooses Linux, I figured I would just completely implement the official USB HID

On Mar 6, 2014, at 3:55 PM, Rob Groner wrote: > To make this UPS as easy to use as possible for the end-user who chooses Linux, I figured I would just completely implement the official USB HID UPS spec. That way no subdriver would be needed, or at least very little. At the moment, we use USB VID and PID to select which HID-to-NUT tables to consult (since some vendors have "custom"

Tim, The UPS will be a PC104 device (www.rtd.com to give you a quick visual of what that is), which means it will actually be physically stacked together with the power supply it is supporting. So cable length won't be an issue, as it will be communicating through USB in the PCIe bus to the CPU. Rob -----Original Message----- From: Nut-upsdev [mailto:nut-upsdev-bounces+rgroner=rtd.com at

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

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:

Charles, Thank you so much for the information. I'm trying to digest it along with the other docs I have, the example code from Microchip, and a USB HID tutorial I found online. So, if I understand correctly.... When the device first connects, it sends a huge dump of data (which the usbhid driver shows when you use the debug option) which fully describes the data it is capable of sending.

On Mar 7, 2014, at 11:24 AM, Rob Groner wrote: > Charles, > > Thank you so much for the information. I'm trying to digest it along with the other docs I have, the example code from Microchip, and a USB HID tutorial I found online. I realize that some of the descriptions can be a bit vague, so if you want to post a link to the HID tutorial, I can try to describe what is going on

Rob - Just out of curiosity, will this device also have any network monitoring connectivity, or just USB? Not sure what market you are targeting, but even as a small business/home compute user, I find that the distance limitations of USB often cause me grief, and myself, I would love to see a network alternative as well . . . Perhaps support for a network dongle on the USB port? More

On Mar 13, 2014, at 10:27 AM, Rob Groner wrote: > 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

Things are going along well, but there is one remaining area of confusion...."units". I understand exponents now...it's basically how you pass decimal values. That's easy enough. But "units"....in other words, I have a voltage I want to put in a report. If I include in the report descriptor the fact that it is actually a voltage, with units of "volts",

I'm doing testing of the UPS-side code, including being able to tell the UPS to shutdown and then come back up after a while (if power has returned). I'm trying to use upscmd so that I don't have to do an actual shutdown, but when I have it list the commands for my UPS, I just see 4 commands, and they're not the ones I thought I had specified. load.on load.off shutdown.return

Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically: + I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info. + I put them in the drivers subdir + I added the include line (#include rtd-hid.h) in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section) + I added &rtd_subdriver, to the subdriver_list in usbhid-ups.c

Hi Rob I still have an unset draft answer to your previous mail... but you seem to have progressed... 2015-03-20 16:32 GMT+01:00 Rob Groner <rgroner at rtd.com>: > I?m doing testing of the UPS-side code, including being able to tell the > UPS to shutdown and then come back up after a while (if power has returned). > > > > I?m trying to use upscmd so that I don?t have to

Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid driver, I'll revisit writing our own. Thanks for the helps. Sincerely,

On Mar 2, 2015, at 12:49 PM, Rob Groner <rgroner at RTD.com> wrote: > Well, having spent a decent amount of time trying to get my driver file added into the Makefile build system (and failing), I've decided that for now, simply adding that one line to the openups-hid.c file and recompiling is the best route to go. When I can no longer live with the limited nature of the openups-hid

On Sep 9, 2015, at 9:40 AM, Rob Groner <rgroner at RTD.com> wrote: > > I'm not sure which USB lib it compiled against. What does this return? ldd /path/to/driver -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150909/ba08f4c0/attachment.html>

I think I had a misconception about something.. My goal was that someone could use our UPS with the "default" UPS driver in NUT right out of the box, so they wouldn't have to alter any NUT code to get it working. NUT config files, yes, but not NUT code. I thought that if I put in the ups.conf file that I wanted to use the usbhid-ups driver, and then put our vendor and product ID,

Thank you all for the help! I followed the log messages and found where it had created the udev rule...as Charles said, in /lib/udev/rules.d. It is named 52-nut-xxxx and there is nothing else that starts with 52 in /lib/udev/rules.d or /etc/udev/rules.d. I looked at the file and saw how it was laid out...basically an ATTR for every known USB UPS. Well, since mine is not a known UPS, I had to

On Fri, 4 Sep 2015, Rob Groner wrote: > Well, I tried the same script method with openSUSE 13.2, and it still did not execute. > > So I tried the system method, and it worked 1 time out of 3 attempts. I captured the last failure: > 2015-09-04T11:43:38.825317-04:00 linux-5048 upsdrvctl[1887]: Can't claim USB device [2a37:5110]: No such file or directory >