similar to: Monitoring slaves via dummy-ups

On Fri, Sep 4, 2020, at 5:19 PM, Roger Price wrote: > On Fri, 4 Sep 2020, Dan Langille wrote: > > > I wondered how folks monitored slaves. > > A NUT solution is to use a "heartbeat" generated in each slave and monitored in > say the master or elsewhere. I did find this earlier today: https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-April/010590.html Is

On Fri, 4 Sep 2020, Dan Langille wrote: > I wondered how folks monitored slaves. A NUT solution is to use a "heartbeat" generated in each slave and monitored in say the master or elsewhere. > The goal: confirm the slaves have contact with the master. On your Github site: Goal: allow host to shutdown when needed. These are not the same goals In NUT, for the shutdown process,

On Fri, Sep 11, 2020, at 4:05 PM, Bartosz wrote: > Dear All, > > Could you please recommend me a UPS with 100% support of the ondelay parameter and NUT compatibility? > > 850 or 1000 VA > > I have the EATON 5E850iUSBDIN UPS and it does not support this parameter so I would like to buy another UPS that for sure will support it. > > Thank you, > Bart Can you tell

rPi3 running current Buster.  I get this far: # upsc networkups Init SSL without certificate database battery.charge: 100 battery.charge.warning: 30 battery.runtime: 2891 battery.type: PbAC device.mfr: Vertiv Co device.model: Liebert PST5 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.productid:

Laurent Taieb via Nut-upsuser wrote on 3/9/23 9:25 AM: > > Hi NUT Users, > > One of my APC UPS is having battery issue and apparently we cannot > change battery in that UPS. (not super green?) > > I have purchased an EATON UPS and added the ref in ups.conf > > When restarting the driver, I got this error > > >0.030612[D2] Checking device 2 of 10 (0463/FFFF)

On Thursday, March 9th, 2023 at 8:34 AM, Dan Langille via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> wrote: >> The UPS has been defined in ups.conf as: >> >> [myups3] >> >> driver : usbhid-ups >> >> port = auto >> >> vendorid = 0463 >> >> productid = ffff >> >> desc = "5S" >> >> bus

On Nov 25, 2007 11:50 AM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Limit detection of UPS to minimum required number of successful attempts. Flush input- and output buffers before sending any command. Can you explain the reasoning behind these changes please? The detection phase didn't stop after the minimum number of required replies to check for models that

> On Sep 14, 2020, at 9:12 PM, Joe Reid <jreid at vnet.net> wrote: > > rPi3 running current Buster. I get this far: > > # upsc networkups > Init SSL without certificate database > battery.charge: 100 > battery.charge.warning: 30 > battery.runtime: 2891 > battery.type: PbAC > device.mfr: Vertiv Co > device.model: Liebert PST5 > device.type: ups >

On 10/04/17 15.25, Jon Bendtsen wrote: > On 04/04/17 15.19, Arnaud Quette wrote: >> >> >> 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendtsen at jonix.dk >> <mailto:jon.bendtsen at jonix.dk>>: [cuuuuut] > I'd say your change is a success :-) well, almost, but maybe that is outside NUT's control. /usr/lib/nagios/plugins/check_ups -H

hi list, im running debian/testing(act. squeeze) with 2.6.26-2-amd64 kernel. first tried apcupsd what flawlessly worked but because i run nagios (needs nut running for 'check_ups'), im trying to run nut. dmesg and syslog show the device: Jul 27 00:08:06 kate kernel: [16001.477941] hiddev96hidraw0: USB HID v1.10 Device [APC Back-UPS ES 700 FW:829.D3 .I USB FW:D3 ] on usb-0000:00:1d.1-1

Thanks Larry, I tried. Got the following traces and the driver doesn?t start. 1.036797 [D2] - VendorID: 0463 1.036812 [D2] - ProductID: ffff 1.036826 [D2] - Manufacturer: unknown 1.036840 [D2] - Product: unknown 1.036872 [D2] - Serial Number: unknown 1.036912 [D2] - Bus: 002 1.036942 [D2] - Device: unknown 1.036965 [D2] - Device

But runs normally if started. On a rpi4 running an uptodate raspbian buster, how do I set it to auto start at boot time? Thanks. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D.

The "unknown" fields mean the driver did not get that piece of information from libusb. In case of Manufacturer/Product which are unknown in the later post, but known in the first, I suppose you had another driver running, or the kernel still owned it (udev misbehavior, not handing it off after reconnections, etc.) and so exclusive access was not given to the new (currently reporting)

On 07/13/2016 04:17 AM, Dmitri Stepanov wrote: > I need to shutdown a number of hosts which has not NUT from one which has it. Let's make sure you are not missing an obvious point. By "has not NUT", you might mean not running upsd. The best practice is to run upsmon on the other hosts. This does not require running NUT proper (server). Is there some reason why you can't

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,

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

Hello, Yes, "pollonly" is a driver option for certain devices (and relevant to just some drivers). Disconnects are probably relevant, at least to loss of connection (and staying that way, with less agressive retries in NUT v2.7.4 and before). There is a logged issue that "pollonly" mode might have trouble detecting a disconnection/staleness, I'm not sure there's merit

Hi NUT Users, One of my APC UPS is having battery issue and apparently we cannot change battery in that UPS. (not super green?) I have purchased an EATON UPS and added the ref in ups.conf When restarting the driver, I got this error > 0.030612 [D2] Checking device 2 of 10 (0463/FFFF) > 0.287659 [D2] - VendorID: 0463 > 0.287853 [D2] - ProductID: ffff >

On 07/13/2016 10:02 AM, Stuart Gathman wrote: > On 07/13/2016 04:17 AM, Dmitri Stepanov wrote: >> I need to shutdown a number of hosts which has not NUT from one which has it. > Let's make sure you are not missing an obvious point. By "has not NUT", > you might mean not running upsd. The best practice is to run upsmon on > the other hosts. This does not

On 10/04/17 16.39, Jon Bendtsen wrote: > On 10/04/17 15.25, Jon Bendtsen wrote: >> On 04/04/17 15.19, Arnaud Quette wrote: >>> >>> >>> 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendtsen at jonix.dk >>> <mailto:jon.bendtsen at jonix.dk>>: > > [cuuuuut] > > >> I'd say your change is a success :-) > > well,