search for: nut01

Bill S wrote, On 4/15/2014 11:18 AM: > The problem is that when I run upsset.cgi I first get a prompt for > user name and password. I then enter the same username and password > as I established in upsd.users and it seems to accept it. upsset.cgi doesn't check that user/password is valid, it just tries it when doing a command. I just tested it, it is working for me on a remote and

Dmitri Stepanov wrote on 7/14/2016 5:18 AM: > All the hosts are installed together in one rack and have fed from one > UPS (only I am remote from the system :) and I haven't ability to > connect to it. Some of hosts haven't NUT for a number of reasons. I > don't need to inform not-NUT hosts about any UPS events, heartbeat, > etc... but only shutdown all the hosts

Since there is apparently no immediate solution to upsstats.cgi not reading the output voltage correctly, I have moved on to trying to use upsset.cgi. To recap the UPS is a CyberPower CyberPower CP1500PFCLCD UPS running on a headless server running Slackware 14.1 with the 3.10.7 kernel. The version of NUT is 2.71 and I am using usbhid-ups for communication with the UPS The problem is that when

I fixed a couple issues in the RedHat init script provided in the scripts directory. There are some other things about it that could use updating, but first I checked out the one included with the RPM (https://admin.fedoraproject.org/pkgdb/acls/name/nut). That one looks pretty good, maybe it should replace the included scripts if permission is given by mhlavink? -------------- next part

Roger Price wrote, On 12/4/2013 12:35 PM: > I would like nut to become more loquacious, and to log a much more > complete report of its activity. At present nut reports that its > components have started operation but does not automatically log their > activity when UPS's switch between OB and OL. I believe that this > under-reporting of important facts is too minimalist -

Angel Tsankov wrote, On 12/6/2013 12:31 PM: > Hello, Ren?. > >> You can change the parameter >> ups.delay.start into your UPS to set the "Interval to wait before >> (re)starting the load (seconds)" >> >> use upsset to change the value. > > So far, the ups.delay.start parameter in my MGE Protection Center 675 > has always been equal to the

Angel Tsankov wrote, On 12/25/2013 12:16 AM: > > What did you mean by "load.on.delay"? > upscmd -l <ups> load.on.delay - Turn on the load with a delay (seconds) ---- ups.timer.shutdown: 0 ups.timer.start: 0 are my upsc values. I'll have to pay more attention to those next time I test.

Windows 7 Pro x64, NUT 2.6.5-4 (interim release) Product: Back-UPS RS 1200 FW:8.g3 .D USB FW:g3 Setting UPS values can be confusing. For example, battery.charge.low and battery.runtime.low. Using upsrw, the values will be retained after restarting the OS, but not if the UPS is turned off/restarted. In the driver log (below), it looks like the values are obtained from the UPS, but if I set

Charles Lepple wrote, On 7/31/2013 6:04 AM: > On Jul 30, 2013, at 1:36 PM, Kris Jordan wrote: > >> upsd removes its pid files when it's stopped, upsmon does not. > Hmm, interesting observation. Offhand, I think both should remove the PID files, but the way that upsmon drops root privileges might make this difficult. Makes sense. The manual says, --with-pidpath=PATH Changes the

Centos5 NUT 2.6.5, compiled from source I was reminded by a previous thread about a message I get when starting NUT... Starting upsd: fopen /var/run/nut/upsd.pid: No such file or directory Starting upsmon: kill: No such process upsd removes its pid files when it's stopped, upsmon does not. If I remove upsmon's manually after stopping it, I get a different message for it when I start

If there is a next Windows release, perhaps the default NOTIFYFLAG's should be adjusted? NOTIFYFLAG ONLINE SYSLOG NOTIFYFLAG ONBATT SYSLOG NOTIFYFLAG LOWBATT SYSLOG NOTIFYFLAG FSD SYSLOG NOTIFYFLAG COMMOK SYSLOG NOTIFYFLAG COMMBAD SYSLOG NOTIFYFLAG SHUTDOWN SYSLOG NOTIFYFLAG REPLBATT SYSLOG NOTIFYFLAG NOCOMM SYSLOG NOTIFYFLAG NOPARENT SYSLOG The 'wall'

Linux NUT 2.7.1 Eaton 5PX usbhid-ups It would appear that interrupts are not actually working on my 5PX using the usbhid-ups driver. I will be trying the serial mge-shut driver next. It just seemed like it was working before because of the default pollinterval of 2 seconds. The status update comes in during the pollinterval no matter what I have pollfreq set to. And I can set pollonly and

Charles Lepple wrote, On 12/4/2013 4:11 PM: > On Dec 4, 2013, at 3:52 PM, Kris Jordan wrote: > >> Roger Price wrote, On 12/4/2013 12:35 PM: >>> I would like nut to become more loquacious, and to log a much more complete report of its activity. At present nut reports that its components have started operation but does not automatically log their activity when UPS's switch

Matt Ivie wrote, On 7/31/2013 8:14 AM: > On Wed, 2013-07-17 at 23:33 -0400, Charles Lepple wrote: >> On Jul 17, 2013, at 11:27 AM, Matt Ivie wrote: >> >>> I'm really just looking for a UPS that might run a couple of small >>> servers and other small devices(routers or switches). >> Good call on including the network gear in the power budget. NUT isn't

Luke-Jr wrote, On 9/18/2013 1:02 PM: > I wanted to suggest some rating for functionality. I got the UPS available > that seemed to have the best possible rating from NUT's list (Eaton Powerware > UPS 1500), and found out it doesn't support telling me battery level or > runtime! :/ I'm avoiding Eaton/Powerware because the lack of usbhid support, the bcmxcp driver

John Morris wrote, On 9/21/2013 11:28 AM: > Hi list, > > UPS is a Smart-UPS 3000 RM (SU3000RM3U, ups.firmware 92.11.D, > ups.mfr.date 12/14/99) with brand-new batteries. NUT is 2.6.5 running > on SL6 (RHEL6 clone) from EPEL packages. 'upsc' output pasted at bottom. > > I'm not very familiar with UPSs in general or this model in particular, > and it's doing

Angel Tsankov wrote, On 12/24/2013 1:22 AM: > On 12/06/2013 10:57 PM, Kris Jordan wrote: > > [...] >> (*) Some UPS's do provide extra options to determine when they will >> restore power to load. > > That would be a nice feature. > > Anyway, it is a strange thing that I can set the waiting time for > power to be restored if main power comes back before