similar to: LiebertPSP again

Hi, I posted about this to the list earlier this week, but it seems to have got combined with a previous thread and lost, at least that's what it looks like in the archive (and I didn't receive a copy as I would have expected). So forgive me if you've already seen this, but: I've got a couple of LiebertPSP's connected to my equipment and I'd like to use NUT to keep an

Hi, I posted about this to the list earlier this week, but it seems to have got combined with a previous thread and lost, at least that's what it looks like in the archive (and I didn't receive a copy as I would have expected). So forgive me if you've already seen this, but: I've got a couple of LiebertPSP's connected to my equipment and I'd like to use NUT to keep an

Gentlemen, Please note that what follows pre-dates the latest changes from Arnaud (just thought someone might want to look at these before I can test the latest!). When running newhidups with -D -D -D I saw messages that looked like errors, and it took me a while to understand that they were not really errors. I therefore added two new entries in apc-hid.h, and I modified a couple of diagnistic

Charles Lepple wrote: > > would you mind forwarding (to either me, or the list) the .txt file > showing the hidparser bug? I am trying to revamp libhid's hidparser, > and it would be helpful to have the descriptor. The text file is contained in the tarball on the patch tracker, at

Gentlemen, I have a new HID USB device, that seems to be quite similar to the currently supported APC HID UPS. I append the dump-tree output, and would much appreciate advice on how to proceed. Certain entries for the current device are not available, but maybe there are some replacements that could be used. This may of course require a new table in apc-hid.h, and I would prefer not to do this

Hello. Not listed as supported, so here is some info, [root at vhost ~]# /usr/sbin/usbhid-ups -DD -a powercom Network UPS Tools - Generic HID driver 0.38 (2.7.2) USB communication driver 0.32 0.000000 debug level is '2' 0.001318 upsdrv_initups... 0.074753 Checking device (0529/0001) (003/002) 0.074835 Failed to open device, skipping. (Permission denied)

Thanks for the reply. However these two FAQ are unfortunately not describing the situation. - The first issue is that NUT switches off the UPS upon reboot on low battery (not that it dies because of low battery) - The second issue is that the UPS does not recognise being online again (not that the PC does not restart) Sent from my iPhone > On 11 Jun 2019, at 02:03, Charles Lepple <clepple

Apologies for resurrecting an old thread and likely poor formatting - I wasn't subscribed to the list at the time and have copied it out of the archives (http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-July/006104.html). I've been unable to locate any further progress on this UPS (Liebert 10af:0001) - a thread from 2009

On 10/01/2015 00:45, Charles Lepple wrote: > On Jan 8, 2015, at 11:43 PM, Graham Menhennitt > <graham at menhennitt.com.au <mailto:graham at menhennitt.com.au>> wrote: > >> Hello Nutters, >> >> I'm running nut 2.7.2 on FreeBSD 10-stable (via the FreeBSD port) >> with an APC Back-UPS CS 350 connected via USB. I get persistent >> (every few

Hello, I have been using NUT for a short period of time and have some questions regarding the UPS reboot signal that I can't figure out. Have tried some googling and reading the DOCs but I am struggling to understand how some variables / things are supposed to work, so would appreciate any help with any of the following questions. I am running NUT on standalone mode on a linux machine

On Jun 10, 2019, at 2:32 PM, Marc Finns wrote: > > Hello, I read all FAQ and other sources but I could not find this situation, so I thought of asking the experts. > I successfully configured a Raspberry NUT server to control my UPS that powers several devices (NUC with ESXI VMs, Synology NAS etc). > All works well in principle, but I have the following behaviours that I could not

OS name and version: FreeBSD 9.0-RELEASE amd64 exact NUT version: 2.6.1 NUT installation method: >From ports collection (cd /usr/ports/sysutils/nut; make install) Exact device name and related information: American Power Conversion/Back-UPS ES 525 FW:851.t2.I USB FW:t2 Complete problem description: /usr/local/etc/rc.d/nut start Network UPS Tools - UPS driver controller 2.6.1 Network UPS

Hi, I'm trying to generate a skeleton driver with usbhid-ups and gen-usbhid-subdriver but the output seems to be incorrect. Same behavior with stable 2.6.5, so I guess there is something wrong with data coming out of device. I attached the output of usbhid-ups and gen-usbhid-subdriver from the commands: drivers/usbhid-ups -DD -u root -x explore -x vendorid=04d8 -a openups >&

This took a long time because I had problems with my system. After I reloaded my operating system several times I found I had a bad memory module. Here is the output from newhidups for my Geek Squad GS1285U. It just kept repeating until I hit ctl-z. I think that this means nut will work for this ups. My computer is not powered by the ups yet. I did not want it to be powered down by accident.

I'm trying to set up nut-2.6 with a SMX1000 ups unit from APC on a CentOS 4.8 server. It's connected via USB, and Linux has detected it as a HID device. Nut was built from source code. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 21 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=051d ProdID=0003 Rev= 1.06 S: Manufacturer=American Power

I tested your fix (newhidups -DDD /dev/null) using both and APC Back-UPS 350 an APC Smart-UPS RT 2000 XL. No more segmentation fault due to the fixed-size array. ~Jacob -----Original Message----- From: nut-upsdev-bounces@lists.alioth.debian.org [mailto:nut-upsdev-bounces@lists.alioth.debian.org] On Behalf Of Peter Selinger Sent: Monday, October 16, 2006 12:12 PM To: Schmier, Jacob Cc: NUT

> On Sep 11, 2016, at 3:37 PM, Jeff Bowman <jeff.bowman at intexx.com> wrote: > > > > Using subdriver: APC HID 0.95 > > > > ...and then hangs for 45 seconds before returning to a command prompt. No > UPS hardware information is printed. > > It can take about that long to read the descriptors. The non-Windows NUT > drivers will print that message,

Charles Lepple wrote: > On 8/2/06, Didrik Pinte <dpinte@itae.be> wrote: > > Le mercredi 02 ao=FBt 2006 =E0 08:08 -0400, Charles Lepple a =E9crit : > > > On 8/2/06, Didrik Pinte <dpinte@itae.be> wrote: > > > > Can you start the driver like this: "/sw/bin/newhidups -u root -DDD" > > > and paste some of the output? > > > > Here

Hi Patrick, I didn't get further bug reports from you, so I have now listed your device as "supported" by newhidups. Last I saw as of your below message, the driver was working as expected. If there are any future problems, let me know! -- Peter Patrick Nolan wrote: > > Remember me? Back in May we exchanged some messages about my Tripp-Lite > UPS. My boss has gone on

Hi Patrick, Patrick Nolan wrote: > > Remember me? Back in May we exchanged some messages about my Tripp-Lite > UPS. My boss has gone on vacation, so I finally got a chance to take a > look at this. > > Peter Selinger wrote: > ... > > In case you feel like experimenting with this, I am attaching a patch > > that *might* enable this device to be supported by the