similar to: How do I disable messages from upsmon?

On Sep 11, 2014, at 10:38 AM, Rob Groner <rgroner at RTD.com> wrote: > I?m still getting the onbattery, online, comm good, comm bad, etc system messages. Clearly there is some default behavior going on. How do I keep these system messages from happening? From http://www.networkupstools.org/docs/man/upsmon.conf.html: "NOTIFYFLAG type flag[+flag][+flag]? By default, upsmon sends

I found something particularly strange while trying out different things: I started up upsdrvctl, upsd, and upsmon. I then stopped upsdrvctl, and tried starting the usbhid-ups driver a few times. Each time I executed the driver, it indicated an instance was already running, stopped it, and then started it again....which is what it should do. I then added -DDDD to the command....and then it

On Tue, 8 Sep 2015, Rob Groner wrote: > I executed lsusb to verify the USB device is there, and it is. I tried > the shutdown command again with debug enabled, but it didn't seem to > reveal much more: > ----------------------------------------------------------------------------------------------- > rtd at linux-5048:~> sudo /usr/local/ups/sbin/upsdrvctl -DDDDD shutdown

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 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

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 >

> 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? --

So, a while back I got around to ordering replacement batteries for my CyberPower PR3000LCDRTXL2U. When they arrived, I went to swap them in. I was horrified at the flimsiness of CyberPower's battery "trays". I've seen heavier gauge plastic on "blister" packages in the store. I ALSO discovered that the expansion unit had been shipped to me with one of its two

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,

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

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 Thu, 8 Jun 2017, Robbie van der Walle wrote: > The "upsrw" command contacts upsd, so it sounds like you should be able to add a user to upsd.users on the NAS, and then run something like > this on the Mac: > > ??upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS at synology > > Per?http://networkupstools.org/docs/man/upsd.users.html?,

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,

I am running tests on my system and UPS, making sure that it is reliably able to come up, detect power loss, shutdown safely, and then come back up when the power returns. It does that MOST of the time. However, a significant part of the time, the system comes up, and then doesn't respond to loss of power. Doing some checking, I find that the reason is because upsd never started. Capturing

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

I'm still working on the interface to the UPS we're selling. USB works great with NUT in Linux, and natively through Windows battery support. Now I'm looking over the serial protocol. I can essentially make it anything I want, and it's VERY tempting to make my own protocol that is intuitive and simple, but I have a feeling every UPS maker does that. So, before I do that...is

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