Hi all,
I've more-or-less got NUT 2.0.4 working with my Powerware Prestige
1000VA UPS (serial), but unfortunately NUT is flagging LOW_BATTERY
continuously, which is a tad embarrassing when power fails ;-)
The numbers from upsc [EMAIL PROTECTED] seem reasonable:
ambient.temperature: 24.5
:
ommunications with UPS re-established
Shutdown delay = 120 seconds
Index Offset Format NUT
001561 None
0021000461 None
0023000861 None
0027001261 output.frequency
0028001661 input.frequency
0029002061 None
+ on /dev/cuaa0
Network UPS Tools - Best UPS driver 1.03 (2.0.5)
Unknown model detected - please report this ID: 'SOLA'
Detected Unknown Unknown SOLA (SOLA) on /dev/cuaa1
Starting nut.
Network UPS Tools upsd 2.0.5
Connected to UPS [mge]: mge
Connected to UPS [sola]: sola
CheckUPSII Says it should
be 27V not 2.27
if I change the last 2 in the ID to be what is ment to 20.0,27.4 i get
battery.charge: -239.6
battery.voltage: 2.27
battery.voltage.nominal: 27.4
Does any one know why it does this
regards
shane
nut
System, Inc. CP1500 AVR UPS
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
When the nut daemons start attempting to monitor the UPS, the device
begins a cycle
block the usbhid driver from connecting to the
device?
Thank You!
johnea
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
, the connection is established, and nut starts successfully at system
boot.
When the delay is unfavorable, the device is in the middle of
disconnect/reconnect when the driver checks and nut fails to connect and
start.
This would explain why some combinations of kernel, drivers, boot order, etc,
just
, it always connects to
the UPS at boot. If it's after the dhcp delay, then the UPS has dropped offline,
and the nut startup fails.
If this is correct, it seems the 'fix' would be to build a small delay, and
retry, into the initial connection code of the usbhid-ups driver. Before
giving
up on finding
the
computer to send something that only the CyberPower software knows to send.
in this case, doing an usbsnoop run is the way to go:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2010-February/004528.html
It seems the usbhid-ups driver already knows how to make the UPS happy. Once
benefit to be
gained was to improve the ability, of linux-usb and nut, to deal with such
misbehaving hardware.
So this is why I've continued to pursue this instead of just throwing these
units in the trash and buying something that works (really, it's not just to
badger you guys 8-)
What if you add
On 07/20/2011 03:33 PM, Tilman Glotzner wrote:
...
nut-2.6.1 # ./configure --host=arm-linux-gcc
I think you just want: --host=arm-linux
johnea
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin
On 07/21/2011 01:31 PM, Tilman Glotzner wrote:
That worked, and nut compiles and builds.
Awesome!
Now I need to install nut in the image to be downloaded to the embeeded board.
How can I set installation path ? Will the --prefix option for the configure
script do the trick ?
You might
On 07/24/2011 04:04 AM, Tilman Glotzner wrote:
Hello
Hey Tilman,
a) The compiler chain that came with the board uses buildroot. I tried to
integrate nut into the buildroot tool chain, but it fails building.
I'm not a buildroot expert. I've always run into quite a learning curve trying
On 08/04/2011 03:45 PM, Tilman Glotzner wrote:
Hi
Nowm it works
a) As written, I added nut as additional package to buildroot
b) I added the configfiles of to the rootfs.tar archive in outgoing/images
c) as nut runs as user nobdoy I needed to give the usb devices/serial devices
to which
Hi James,
I've worked extensively on getting a similar CyberPower UPS (same IDs) to play
well with nut.
The conclusion I ultimately came to is that if this UPS is not connected to by
it's driver within about 20sec, it drops off the USB bus and re-enumerates. This
causes an endless cycle
On 2011-10-16 12:06, Ron wrote:
Rebooting worked for me too. Wish I had read this post earlier
Hi Ron,
I've been struggling with nut and CyberPower USB devices for over a year now.
You may find connection to the UPS on boot to be unreliable, sometimes it will
connect, other times it won't
Hi Charles, merci pour ta réponse,
You are right, I'm using FreeBSD 6.1 (x86) (I didn't have the time to
upgrade yet).
I'm using libusb-0.1.
Thanks in advance for your help,
Edouard
Bonjour Edouard,
I also run nut on FreeBSD.
I don't know if it causes the specifics of your issue, but I
Hi,
I've have had some difficulties to run NUT on freebsd, but I finally managed to
have something that work reliably enough. For those who may be interested,
here is what I did.
Os: FreeBSD 6.2-RELEASE-p7, nut: 2.2.0, libusb: 0.1.12
First, I had to patch libusb with the changes submitted
Using nut v2.2.2, and the APC serial cable.
I have a client who's APC SMART-UPS 1500 (circa 2000) is always reporting LB.
The batteries were old so they were replaced two weeks ago with brand new
batteries. UPS still reported low batteries...
I ran a calibration and a test on the unit (using
Greetings everyone,
Firstly, sorry for the huge length of this message. The support page
said send debug traces, and so debug traces shall be sent.
OS name and version - Arch Linux - updated today.
exact NUT version - 2.7.4 (Network UPS Tools - Generic HID driver 0.41
(2.7.4) USB
On 17/04/2016 00:50, Charles Lepple wrote:
[as this list does not set or alter the Reply-To header, please use "reply
all". Thanks!]
On Apr 16, 2016, at 5:14 PM, Andy R - (NUT-List) wrote:
I'm currently using the usbhid-ups driver but as the ups usb-ID isn't recognised in the ude
> NUT takes charge of sending the required commands through the driver; the
> default values are load.off.delay 20 and load.on.delay 30. These values can
> be
> changed by adding lines such as
>
> offdelay = 30
> ondelay = 100
>
> to the corres
> When a UPS unit performs a delayed power off (NUT sets the delay to 20
> seconds
> by default) it deconnects its power outlets which in some UPS units produces
> an
> audible "clunk". The display of lights on the front panel changes, and the
> beeping stops
f the computer stays off, there is little hope that any software
configuration of nut will make the ups turn it back on; except perhaps for
Lee's suggestion of "turning it off but not quite". On that note, where in the
file system should I be looking for the NUT shutdown script please?
> > where in the filesystem should I be looking for the NUT shutdown script
> > please?
>
> It's the SHUTDOWNCMD in upsmon.conf
Thanks!
_______
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.o
ime, it doesn't notice and it remains
off; long off time, it does come back on. I did one minute for "long" but
didn't do binary partitioning of the interval to assess the exact threshold.___________
Nut-upsuser mailing list
Nut-upsu
Executive summary:
I am installing a UPS with NUT on Ubuntu for the first time. I could
follow the instructions up to "testing shutdowns" but on executing the
recommended command the computer shuts down and never comes back on,
contrary to what the instructions suggest.
I am a
Hi folks
First posting to this list. I discovered NUT yesterday, and as sysadmin
of a wide collection of Unix and windows boxes hanging off APC
Smart-UPSs I think it could help me a lot.
Using NUT version 2.0.4 running on HP Unix 11.00 - it compiled and
installed fine, and all the basic
against the documentation for NUT 2.0.1,
I can see the problem!
Details are in docs/protocol.txt.
If there is sufficient interest, we could use SWIG to generate
Perl/Python/language-du-jour bindings from libupsclient.
Having rewritten some chunks of it, I now have a perl module
29 matches
Mail list logo
