search for: cp1500

...modifying the value failed. I used the *override.ups.delay.start = -1* in nut.conf and this is now being reported. Two observations are that once a variable setting is overridden, *upsrw -w* will not show these values. Is it by design? Below is the output from *upsc *for the Cyber Power System CP1500 AVR Init SSL without certificate database battery.charge: 100 battery.charge.low: 70 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 6000 battery.runtime.low: 900 battery.type: PbAcid battery.voltage: 26.0 battery.voltage.nominal: 24 device.mfr: CPS device.model: Value2200E devic...

...hile, working find. When 2.6.0-1 just pushed through to debian, things have stopped working :( I checked what had been the usual suspects in past problems, namely permissions problems in /dev/bus/usb, but all seems in order: $ lsusb ... Bus 009 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS $ ls -l /dev/bus/usb/009/002 crw-rw-r-- 1 root nut 189, 1025 Mar 14 00:50 /dev/bus/usb/009/002 But if I run the driver with debugging enabled, it gives this: $ sudo /lib/nut/usbhid-ups -a cp1500 -D -D -D ... 0.135837 Checking device (0764/0501) (009/002) 0.158857 - VendorI...

On Mon, 4 Mar 2024, Alan C. Bonnici via Nut-upsuser wrote: > Platform: Proxmox VE 8.1.4 > NUT version: Network UPS Tools upsstats 2.8.0 > > I configured Proxmox and I can pull up the UPS stats. > Typing in `upsrw -l cyberpower at localhost` I get the following: > > [battery.charge.low] > Remaining battery level when UPS switches to LB (percent) > Type: STRING >

Thanks Charles for the clarification. If NUT cannot control it then removing it would, IMO add value. On Sun, 10 Mar 2024 at 00:14, Charles Lepple < clepple_at_gmail.com_chribonn at duck.com> wrote: > On Mar 9, 2024, at 5:16?PM, chribonn at duck.com wrote: > > > > The posting at > https://github.com/networkupstools/nut/issues/432#issuecomment-405371395 > references

Very good point. I hope to write a beginners guide -- more like adopting my notes --on NUT. I could summarise your point that technically one should only override settings that NUT can act upon (like those settings that control Low Battery or, as stated in the documentation if the reported value is known to be incorrect. Overriding a variable that is out of scope for NUT (as with

Wow :-) I'll have a read through it. On Sun, 10 Mar 2024 at 15:54, Roger Price < roger_at_rogerprice.org_chribonn at duck.com> wrote: > On Sun, 10 Mar 2024, Alan via Nut-upsuser wrote: > > > Very good point. I hope to write a beginners guide -- more like > adopting my > > notes --on NUT. > > I did the same thing, 131 pages, at >

On Mar 9, 2024, at 5:16?PM, chribonn at duck.com wrote: > > The posting at https://github.com/networkupstools/nut/issues/432#issuecomment-405371395 references ups.delay.start and suggests setting it to -1. > > upsrw -l pve1 at localhost listed this as modifiable but any attempt at modifying the value failed. I used the override.ups.delay.start = -1 in nut.conf and this is now being

*Platform: Proxmox VE 8.1.4NUT version: Network UPS Tools upsstats 2.8.0* I configured Proxmox and I can pull up the UPS stats. Typing in `*upsrw -l cyberpower at localhost*` I get the following: *[battery.charge.low]Remaining battery level when UPS switches to LB (percent)Type: STRINGMaximum length: 10Value: 10[battery.runtime.low]Remaining battery runtime

...sb_get_report: could not claim interface 0: Device or resource busy Got disconnected by another driver: Device or resource busy Can't initialize data from HID UPS Driver failed to start (exit status=1) which seems a bit better. $ lsusb Bus 002 Device 005: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The udev rule is: # Dynex DX-800U? - usbhid-ups ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="nobody"

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. Here I get the same output with, or w/o the leading sudo. Thank you. Cheers, Gene Heskett -- "There are fo...

...atest apt nut packages in the dist (2.7.x?). UPS in use: One UPS is APC, two are branded Cyber Power, one is branded Amazon Basics but lsusb matches to (and others report is built by) Cyber Power. All are "driver = usbhid-ups". Relevant lsusb lines: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS ID 051d:0002 American Power Conversion Uninterruptible Power Supply ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS (Bus/Device varies greatly, of course, so omitted) Here's my ups.conf file: <quote> [sl] driver =...

...0c45:1050 Microdia Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 003: ID 413c:3200 Dell Computer Corp. Mouse Bus 003 Device 002: ID 04f9:01a8 Brother Industries, Ltd Bus 003 Device 001: ID 0000:0000 Bus 002 Device 003: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 002 Device 001: ID 0000:0000 After reading the nut-hal.txt file I checked to see if I have the fdi file. I do have it and I did find the 0764:0501 ID in there: <!-- CyberPower --> <match key="usb_device.vendor_id" int="0x0764"> &lt...

Hi. I have this this on a Odroid-u2 backing it up. Have the USB from the CyberPower SX650G plug in the Odroid-u2 and when I do a lsusb it looks like this: Bus 001 Device 008: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The User's Manual list SE450G and SX650G. So I guess they would take the same driver. CyberPower web page has a driver but it's for i386 not ARM like what's on this Odroid-u2. The best I found was putting "driver =usbhid-ups" in the /etc/nut/ups.conf file. It loo...

...ts pretty smart. Nothing is ever done until the paper is > completed. > > Cheers, Gene Heskett Now I've got another of those WTF questions. This ups doesn't ID itself the same to an lsusb as it does to upsc. From an lsusb: Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS From a upsc: device.mfr: CPS device.model: CP625HGa ???? And while its not your problem, its keyboard and mouse goes away at random intervals, and isn't rediscovered by unplugging and replugging the hub the dongles are plugged into requireing a powerdown reboot, but the reboot isn&...

...o nut-server running, with and without LISTEN lines in upsd.conf. Since there's no issues starting the service manually after reboot, I feel like this is some kind of systemd thing as opposed to a nut config issue. Various config file contents: nut.conf MODE=netserver ups.conf maxretry = 3 [cp1500] driver = usbhid-ups port = auto vendorid = 0764 pollinterval = 5 desc = "toshiba: TV, roku, switch" upsd.conf LISTEN 0.0.0.0 3493 upsmon.conf MONITOR cp1500 at localhost 1 monuser monuserpass primary MINSUPPLIES 1 SHUTDOWNCMD "/sbin/shutdown -h +0" POLLFREQ 5 POLLFREQALERT 5...

...reated in /etc/systemd/system, then reinstalled nut. I added the two network objects to Wants and After in system.target, restored confs in /etc/ups, rebooted, and sure enough upsd and upsmon were successfully started. Only caveat was there was no driver connected when testing from remote with upsc cp1500 at host. I manually ran systemctl start nut-driver-enumerator, tested again with upsc and got expected results. Rebooted, tested again from remote and got expected results. I'm going to update the RH Bugzilla entry with these findings. Thank you all for your input and help, kudos to Tim and B...

Hi, I am studying (in a few months I might go on a TV quiz show :-) Rodger's excelent guide and wanted to confirm that all measurements in NUT are in seconds. For example, the Cyber Power System CP1500 AVR UPS returns that the **driver.parameter.pollfreq = 30**. This means that I can (maybe should) adjust the settings within NUT.CONF to match this value. Setting this value to 2 seconds gains will return the same value 14 times. Is my reasoning correct? Thanks Alan

...;s HID drivers such that the corresponding /dev/hidraw* device disappears.) You are correct that the udev rules need to change permissions on one of the UPS /dev nodes, though. From Bill's lsusb output: [root at mythtv ups]# lsusb ... Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The libusb path for this UPS would typically be /dev/bus/usb/001/004 -- Charles Lepple clepple at gmail > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/li...

On Dec 14, 2013, at 4:19 AM, David C. Rankin wrote: > lsusb shows: > > Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS I am guessing that 'ls -l /dev/bus/usb/004/002' shows that the device node is not owned by the NUT gid? > Why doesn't > "upsdrvctl start" allow nut to find the UPS when it can find it without a > problem with the options "-u root start <upsname>&...

...35b3) Dec 14 02:24:39 phoinix upsdrvctl[28629]: USB communication driver 0.32 Dec 14 02:24:39 phoinix upsdrvctl[28629]: No matching HID UPS found Dec 14 02:24:39 phoinix upsdrvctl[28629]: Driver failed to start (exit status=1) lsusb shows: Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Fudging the options for upsdrvctl and limiting the start to one ups allows upsdrvctl to find the ups device and works: /usr/sbin/upsdrvctl -u root start phoinix_ups (both -u root and the ups name are required before it will find the device) (2) Starting upsdrvctl this way creates a...