similar to: Hardware compatibility report: APC Smart-UPS_1500

On Wed, 8 Jan 2020, Gene Heskett wrote: > On Wednesday 08 January 2020 06:44:03 Roger Price wrote: >> I am surprised that there is no ups.delay.start for this UPS. > My new APC Smart-UPS_1500 doesn't have it either. Hello Gene, The NUT 2.7.2 "device dump library" entry for the APC Smart-UPS 1500 at https://networkupstools.org/ddl/APC/Smart-UPS_1500.html shows an entry

On Tue, 7 Jan 2020, Eyal Lebedinsky wrote: > On 2020-01-07 23:01, Roger Price wrote: >> There is no report for variable "ups.delay.start" in your upsc output. >> What does command "upsc <ups> ups.delay.start" report? > > $ upsc eaton ups.delay.start > Init SSL without certificate database > Error: Variable not supported by UPS I am surprised

On Wednesday 08 January 2020 15:44:10 Roger Price wrote: > Gene's posting: > https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-January/011 >654.html contains a NUT 2.7.4 update for the APC Smart-UPS_1500 device > dump at https://networkupstools.org/ddl/APC/Smart-UPS_1500.html > > Please note the changes since the 2.7.2 report, e.g. ups.delay.start > is no longer

I've drug it as far under the table as I can get it on a 30% heart. Yeah, I'm getting on, I'll be 85 in about 2 weeks. Heart surgury will be scheduled in the next few days to replace a worn out, leaky aortic valve. Piece if cake if my veins are big enough. So what driver do I use with a Smart-UPS_1500??? Never mind it was found and accessed by the bootup! upsc my usp reports:

Hi Charles; Had a fire on the mobo of my old server, replaced it all with about 10x the hardware. dmesg now says this: 71068.842780] usb 1-9: new full-speed USB device number 10 using xhci_hcd [71069.012577] usb 1-9: New USB device found, idVendor=051d, idProduct=0003 [71069.012579] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [71069.012579] usb 1-9: Product:

On 6/19/23 18:57, gene heskett wrote: > Greetings Jim & friends; > > Just installed nut 2.7.4 on a debian bullseye system.? ups is: > Bus 001 Device 006: ID 051d:0003 American Power Conversion UPS > Device Descriptor: > ? bLength??????????????? 18 > ? bDescriptorType???????? 1 > ? bcdUSB?????????????? 2.00 > ? bDeviceClass??????????? 0 > ?

Greetings Jim & friends; Just installed nut 2.7.4 on a debian bullseye system. ups is: Bus 001 Device 006: ID 051d:0003 American Power Conversion UPS Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor

On Sunday 12 January 2020 11:14:13 Charles Lepple wrote: > On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > >> Instant return, logging this: > > > > in /tmp/info > > > >> 0.000000 Error: too many non-option arguments. Try -h for > >> help. Network UPS Tools - Generic HID driver 0.41 (2.7.4) > >> USB communication driver 0.33 >

On Sunday 08 December 2019 21:48:03 Charles Lepple wrote: > On Dec 7, 2019, at 7:01 PM, Gene Heskett <gheskett at shentel.net> wrote: > > What driver do I now put in /etc/nut/ups.conf? hid-generic doesn't > > seem to want to talk to it, and the original name _(usbhid-ups) > > doesn't work from new mobo. Oh wait, I can't spell. But that didn't > >

On Tuesday 21 January 2020 19:52:01 Charles Lepple wrote: > sudo lsusb -v -d 0764:0501 copious output, containing this: idVendor 0x0764 Cyber Power System, Inc. idProduct 0x0501 CP1500 AVR UPS bcdDevice 0.01 iManufacturer 3 CPS iProduct 1 CP625HGa I take it that this is evidence they don't follow the spec to the letter.

On Tuesday 14 January 2020 00:03:09 Gene Heskett wrote: > On Monday 13 January 2020 22:42:46 Charles Lepple wrote: > > On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT > > >>> tree, which has the command line amended to not generate that > > >>> "too many non-option

On Jan 9, 2020, at 5:51 PM, Gene Heskett wrote: > > On Thursday 09 January 2020 16:59:12 Charles Lepple wrote: > >> On Jan 9, 2020, at 4:39 PM, Gene Heskett <gheskett at shentel.net> wrote: >>> So for starters, what's the best ./configure command line? >> >> There’s this page for matching the layout of an existing Debian >> install: >>

On Jan 9, 2020, at 4:39 PM, Gene Heskett <gheskett at shentel.net> wrote: > > So for starters, what's the best ./configure command line? There’s this page for matching the layout of an existing Debian install: https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu But remind me, what are you hoping to get from the later version of NUT? (We don’t

On Saturday 11 January 2020 18:43:23 Gene Heskett wrote: > On Saturday 11 January 2020 17:00:19 Charles Lepple wrote: > > On Jan 11, 2020, at 3:50 PM, Gene Heskett wrote: > > >> The problem is further downstream. Even after you map HID names > > >> to NUT names, then you run into the fact that CPS and NUT are > > >> interpreting the HID Report

On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT >>> tree, which has the command line amended to not generate that "too >>> many non-option arguments" error. Also, I wanted it to use the >>> existing cps-hid.c tables, not the generic "explore" sub-driver.) >>

We're looking at replacing some old APC SmartUPS 5000s with something that has USB so NUT can more easily talk with it (and yes, I've tried USB-RS232 adapters and every one I tried started kicking out errors within a few hours). One of the bids we have is for a "Tripp Lite UPS Smart Online 5000VA 4500W Rackmount 5kVA 200V/240V" as the potential replacement unit. I have no

On Monday 26 October 2020 09:01:31 Charles Lepple wrote: > On Oct 25, 2020, at 11:52 AM, Robert Stocker <kneadtoknow at gmail.com> wrote: > > Init SSL without certificate database > > battery.charge: 100 > > battery.charge.low: 10 > > battery.charge.warning: 20 > > battery.mfr.date: CPS > > battery.runtime: 15690 > > battery.runtime.low: 300

This was very helpful for me, thank you! On Sat, Oct 24, 2020 at 9:06 AM Charles Lepple <clepple at gmail.com> wrote: > The easiest way to tell if upsd is working is to run "upsc -l" on the same > system, which will list the NUT UPS names, and then run e.g. "upsc mge" > (replacing "mge" with the name returned by "upsc -l") > Here was the

On Friday 10 January 2020 07:52:47 Gene Heskett wrote: > > Not sure where that message is coming from, but glad it worked with > > the newer aclocal. (Did you use the release tarball, or a Git > > checkout?) > > Release 2.7.4 tarball. Docs are years out of date, man pages claim > 2.7.3 dated in 2015... But it works, and thats what counts. :) Got it wired up and

On Thursday 29 October 2020 22:12:00 Charles Lepple wrote: > On Oct 28, 2020, at 9:56 PM, Gene Heskett <gheskett at shentel.net> wrote: > > Which looks very incomplete to me. OTOH, its not a very big UPS but > > neither is the pi. I have tested that, and it shuts off long before > > it outouts a LB signal. > > Which part looks incomplete, the variables or the