similar to: need help [usb_submit_urb; Linux kernel]

I'm trying to get a CyberPower PP1100 working with NUT on a Fedora 16 system and not having much luck. Kernel: 3.4.4-4.fc16.x86_64 #1 SMP Thu Jul 5 20:01:38 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux NUT (installed from Fedora RPM): nut-client-2.6.4-1.fc16.x86_64 nut-2.6.4-1.fc16.x86_64 libusb: libusb-devel-0.1.3-9.fc16.x86_64 libusb1-1.0.9-0.6.rc1.fc16.x86_64

OS name and version, *CentOS release 6.10 (Final) Linux 2.6.32-754.3.5.el6.centos.plus.x86_64 #1 SMP Wed Aug 15 02:28:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux* exact NUT version Name : nut Arch : x86_64 Version : 2.6.5 Release : 2.el6 Size : 4.2 M Repo : installed >From repo : epel Summary : Network UPS Tools URL :

Hi everybody, I installed and configured Nut 2.4.3 on Debian Squeeze, using package. It monitors an MGE Pulsar 1500 UPS in standalone mode. Here are parts of upsmon.conf : SHUTDOWNCMD "/bin/bash /root/extinction.sh >> /var/log/ups/ups.log 2>>&1" NOTIFYCMD "/bin/bash /usr/sbin/alerte.sh" [...] NOTIFYFLAG ONBATT SYSLOG+EXEC At startup, driver, upsd and upsmon

Update from my end: I found the old thread where I posted a possible resolution for a similar issue on CentOS 7.6 with the same protocol (2012): https://alioth-lists.debian.net/pipermail/nut-upsuser/2019-June/011451.html https://alioth-lists.debian.net/pipermail/nut-upsdev/2019-June/007440.html Some of my initial steps were probably unnecessary, but through a combination of configuration tweaks

Maybe a kernel USB issue, but people on this list may have encountered this issue. I am testing a new UPS (EATON 5E 1500iUSB) and am having a problem with the USB connection failing. My old UPS (EATON Ellipse MAX 1500) works just fine with the latest f30. Both devices identify as ID 0463:ffff MGE UPS Systems UPS To narrow the focus I booted recent live CDs on a PC that has no other USB devices

Hi Klaus, Thanks for your much appreciated feedback. Klaus Holler wrote: > Hello, > >I just wanted to report that the Back-UPS RS 800 works with the >Network UPS Tools. Currently I use the following (Ubuntu breezy) >debian packages on kernel 2.4.31: >ii nut 2.0.2-1build1 >ii nut-usb 2.0.2-1build1 > >lsusb reports: >ID 051d:0002 American Power Conversion Back-UPS Pro

Sergey, I?m no expert on this but I have been reading the driver code, trying to sort out bigger problems with the OpenUPS driver! I can make 2 observations that I can?t check out myself : ?beeper.disable? was previously ?beeper off? - and ?beeper.enable? was ?beeper.on?. Not sure if it?s worth trying the old versions? If your UPS doesn?t wait for LB, could this be because there is another

Hi Philip, I've updated NUT to 2.7.3 and finally found the root cause for the unexpected shutdown: It is recommended to increase pollinterval to 10 seconds in ups.conf for usbhid-ups driver due to a known issue: http://www.networkupstools.org/docs/man/usbhid-ups.html Default DEADTIME=15 in upsmon.conf was triggering shutdown. Increasing the value to 30 seconds resolved the issue. Now when

I'm trying to get nut to work with a Cyberpower 900AVR. There are many different products known by this name, but this one has the extra name 'BC900D'. I am told by a cyberpower tech that this one should talk exactly the same USB protocol as the 685AVR, which was recently made to work with newhidups. Unfortunately, when I run the SVN checkout (trunk) of nut-2.1, I get: sstreet

On 10/07/15 14:30, paul at paulcarmichael.org wrote: > On 10/07/15 04:26, Charles Lepple wrote: >> On Jul 9, 2015, at 9:43 AM, paul at paulcarmichael.org wrote: >> >>> Is there currently a way of implementing NUT with an Ovislink Chrome 1500 UPS? >> >> Not sure. There was a thread in February talking about an Ovislink Chrome 1000, but I >> don't think

On 9/23/2020 1:09 PM, Stuart D. Gathman wrote: > I solved this problem a few years back. > > https://github.com/sdgathman/trippfix > > The short answer is USB is broken on the model (but the power management > is excellent, handling switchover to generator power without a hitch). > > The workaround is to do a usb port power off when the Tripplite USB > hangs.  But hubs

Please, can you tell me if you know how can i use the library Igraph in C# ? Thanks Nadifi Taoufik ************************************************************************* This message and any attachments (the "message") are con...{{dropped:15}}

Attached is the first 32 seconds of the driver output after applying the patch which fixes the battery scaling problem for this UPS. Matthew Stapleton Email: matthew4196 at gmail.com On 10/08/14 01:27, Charles Lepple wrote: > On Aug 8, 2014, at 9:15 AM, Charles Lepple <clepple at gmail.com> wrote: > >> On Aug 7, 2014, at 10:52 PM, Charles Lepple <clepple at gmail.com>

Sorry for the bad formatting of the previous message...I tried to use plus signs as bullet points, and that caused a problem somehow. Ok...I discovered that if I do the autoreconf after the first failed make (and the autoreconf still gives that error message), and then do make again...it builds. Conclusions: 1) Autoreconf *must* be run, and not ./configure? I had thought that putting in my *.c

Also, just in case - are you in a virtualized environment? Is there (intentional or not) USB pass-through to the UPSes? My hint is, we had cases where a host or guest grabbed the device but it was not apparent from the part of system running NUT. Jim On Fri, Mar 24, 2023, 23:23 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Sounds like some other program is holding the port. Have

Sounds like some other program is holding the port. Have you stopped other NUT drivers for the device (e.g. via auto-resuscitating services) before starting this one? Does udev, ugen or similar facility have the configuration to hand off this device to NUT run-time user? (BTW, if you are now testing a custom build - was it configured to use same accounts as pre-packaged variant)? On Fri, Mar 24,

Updates on this: 1) Making progress in the related Dev list thread here: https://alioth-lists.debian.net/pipermail/nut-upsdev/2019-June/007440.html I’ll keep that thread up to date with progress as I go. But if there are specific things it would make sense to test here, just let me know. Otherwise, I figure reducing redundancy makes sense? 2) I tried disabling usbcore.autosuspend, but

Some of my messages never went through since I hit a message size limit. I'm resending them in the hopes they are under the limit. Charles, The lsusb command did not trigger a disconnect. The output of that command is below. I ran "usbhid-ups -a upsunit -DDD &> output.log" and I have attached the /var/log/messages and output.log to this email. Before running this test

I?m making some progress I believe? I switched off and switched on the UPS further to the laptop having started the daemon and I?m not getting the same error message which is probably due to the server working in the background still locking the device I think the daemon starts but gets into an infinite loop and doesn?t finish and hand back control. Here are the updated traces I got by

Looks very great, thanks for writing this! I gather you'd port this to the Wiki page you've started, too? A couple of comments: > So I run a NUT server on a Raspberry PI which is connected via USB to my DIY-NAS Arduino. DIY-UPS? > See drivers/arduino-hid.c for the list of supported IDs... Since NUT v2.8.1 [PR #1369], the `usbhid-ups` driver allows the user to specify a