similar to: A "standard" serial protocol?

On Mar 9, 2015, at 9:09 AM, Rob Groner <rgroner at RTD.com> wrote: > I don?t have any problem with pointing customers to a branch they can clone via git and compile. I know this sounds pedantic, but while the snapshots correspond to specific branches and commits in git, they are simpler for end users to build than the git branches, since they include the ./configure script and a few

We're wrapping up our first version of the UPS we're making, and so I'm going over the USB code and came across one loose end. The serial number of the unit (iSerialNumber according to the USB HID doc) is a constant, but it's of course a different constant for each UPS. Right now we store that value in the Flash on the device, but the only way I've seen to pass the serial

Is there a specific file with the version number in it that I would modify, or do you just mean the file names? Sincerely, Rob Groner From: Charles Lepple [mailto:clepple at gmail.com] Sent: Monday, March 09, 2015 9:23 AM To: Rob Groner Cc: nut-upsdev at lists.alioth.debian.org Subject: Re: [Nut-upsdev] New sub-driver submission process timeframe? On Mar 9, 2015, at 9:09 AM, Rob Groner

I don't have any problem with pointing customers to a branch they can clone via git and compile. But until that's available, I will do what you suggested (and what my boss has been suggesting for a while) which is to take 2.7.2 and put our driver in it nice and happy and then package that up for our customer to use. That will be a more than sufficient means to get our UPS working until

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

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>

> On Sep 9, 2015, at 10:12 AM, Rob Groner <rgroner at RTD.com> wrote: > > linux-5048:/home/rtd # ldd /usr/local/ups/bin/usbhid-ups > linux-vdso.so.1 (0x00007fff403fc000) > libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f7c34b56000) The last line seems to indicate that it is the real libusb-0.1, not -compat. What kernel version on openSUSE? --

Rob, My suggestion is using the SEC2400 protocol. It's very simple, complete and based in text using using the idea of requesting and responsing. In the NUT software the name of the driver that manage this protocol is "gamatronic". Below the documentation: http://networkupstools.org/protocols/sec.html http://networkupstools.org/protocols/sec-protocol.html

On Sep 10, 2015, at 8:49 AM, Rob Groner <rgroner at RTD.com> wrote: > > Charles, > > 3.16.6.-2-desktop I think that corresponds to this file: http://lxr.free-electrons.com/source/drivers/usb/core/devio.c?v=3.16 (but I don't see anything obvious there) What does "lsusb -vvv -d 2a37:" return? Usually I'd say run that as root when the driver isn't running,

Having dealt with the USB portion of our UPS, I'm now reviewing our serial port communication. I've looked over some of the drivers in NUT to see how they handle it so I can get an idea of what the "standard" is for how to accomplish it. I'd like to do something simple and human readable. It seems like most data is gathered from a query and a response. Is that typical? I

For fun, if you want to see where the system thinks it is linking a library from, you can use "ldconfig -p" and it will give you a path to all known libraries that it can find. If you have one loaded, and it can't find it (odd directory, etc.) you can always amend "LD_LIBRARY_PATH" the same way as PKG_CONFIG_PATH I mentioned earlier . . . . PKG . . . is for the build

On Mar 9, 2015, at 12:00 PM, Rob Groner <rgroner at RTD.com> wrote: > 1) Autoreconf *must* be run, and not ./configure? I had thought that putting in my *.c and *.h files and making the makefile changes and then executing ./configure for the first time would be enough. Each tool serves a different purpose. autoreconf (and NUT's autogen.sh, by inclusion) generates the ./configure

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

I wasn't clear. battery.runtime.low is not a counter, but a value estimated in seconds that is decreasing conforming the battery is discharging. It's mean: How much time (in seconds) will be necessary until the battery achieve the depleted status ( http://www.networkupstools.org/protocols/sec.html#Estimated_Minutes ) . If the UPS don't have a load, this value will be higher than the

On Sep 18, 2015, at 2:45 PM, Rob Groner <rgroner at RTD.com> wrote: > > Well, I've spent a couple hours on this, unable to figure it out. I removed the libusb-compat-devel package using zypper. And I've downloaded, built, and installed libusb from sourceforge. But trying to configure nut now I get "USB drivers requested, but libusb not found", no matter what I put

Rob - Just stepping in from the sidelines . . . with a few tidbits. Nut uses pkgconfig to find and identify stuff as part of it's build . . . So, depending on where your libusb install went, if it wasn't in the default "PKG_CONFIG_PATH" setting, it won't be found. Much like other shell variables, you can adjust that setting to find anything you like . . . IE

On Sep 21, 2015, at 9:39 AM, Rob Groner <rgroner at RTD.com> wrote: > > I didn't think to look for a log (attached), but now looking in it, I don't see anything more than I already thought I knew. It's as cryptic as configure itself. > > It does reference the line in the configure where the test for USB failed, but I'd already been looking in there. I

On Sep 8, 2015, at 4:48 PM, Rob Groner <rgroner at RTD.com> wrote: > > 0.005927 Device matches > 0.005940 failed to claim USB device: Device or resource busy > 0.005954 failed to detach kernel driver from USB device: No such file or directory Rob, this is a bit of a tough one to track down. The "Device or resource busy" message can either come from a kernel

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 9, 2015, at 9:55 AM, Rob Groner <rgroner at RTD.com> wrote: > Is there a specific file with the version number in it that I would modify, or do you just mean the file names? The canonical place is in configure.ac, and everything else gets regenerated if you rerun autogren.sh That script, by the way, calls "autoreconf -i" which includes the --add-missing flag that I