Carlos Rodrigues wrote:
If the driver fails to get any data in the current polling cycle, it
declares the data as stale until the next cycle. It tried to read the
data, it got nothing, ergo the current data is stale.
That's a bit too harsh. Even serial communication is sometimes plagued
by
I have discovered that if you build a custom cable you can use the
genericups driver (tha cable supplied with the UPS does not work)...
How is that one wired?
I have build a normal RS232 DTE-DCE cable (I have connected pin 1 with
pin 1, pin 2 with pin 2, and so on... using two DB-9
I have a Riello Dialog Plus UPS...
someone knows how to configure nut for this UPS?
[...]
All messages start with a STX and end with a ETX; all the messages
from the application start with a STX SPACE ! and the response
from the UPS with a STX ! SPACE
It doesn't look like anything
@Huge: Could you post a diff for the change you made?
Not the biggest change in the world
I didn't expect it to be, but it is better to be sure.
[EMAIL PROTECTED] ~/Prog/nut/nut-2.2.1/clients]: diff upsmon.c upsmon.c.orig
125c125
wf = popen(wall -a, w);
---
wf =
Anyway, I've modified upsmon to call wall -a instead of wall and it
now does what I want.
Do you (or anyone else running Solaris) know if this behavior changed
in Solaris 10?
I've traced back the man page for the 'wall' command back to Solaris 2.4
(the oldest I could find online [1994]).
Charles Lepple wrote:
Actually, it's getting that from the same place as last time.
Apparently the --without-snmp switch doesn't turn off Net-SNMP
detection, it just controls which drivers are built. (And IMHO the
Net-SNMP flags shouldn't be used in anything other than the NUT SNMP
driver,
Seann Clark wrote:
I know others have seen this before, I just never saw any real
resolution to it. I am not a programmer, or at the least a very bad one,
so I don't think this is something I can do properly myself.
I have a Cyberpower 1500 AVR rack mount that worked good, except for the
Usually drivers attempt to determine if a command is valid, before
registering it.
So, there is a big set of NUT commands, like shutdown.stayoff and others,
and driver for specific device supports some subset of them and this
subset i can see in 'upsmcd -l output' ?
Yes. See
[...]
I can now see what is in buffer and it looks like just a few leading
characters might just be missing!
So now I am at a loss of how to resolve this problem!
This could be due to some data remaining in the buffers. The megatec
driver doesn't flush the buffers, so if the UPS sends
After updating from 2.2.0 to 2.2.1, the following command
seems to go into loop and becomes unresponsive except for a
kill -9:
/lib/nut/usbhid-ups -u root -DDD -a trippy
Running the driver in debug mode has always prevented it from
backgrounding, so nut-2.2.0 would also require a 'kill -9'
Does the following error message have a specific meaning:
usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2
ret -75
[...]
Can't retrieve Report 49 (75): Value too large for defined data type
The UPS is sending us here more data than we expect. The size of reports
Using subdriver: TrippLite HID 0.2 (experimental)
Startup timer elapsed, continuing...
===
Is this an error ? Shouldn't the driver usbhid-ups be referenced here
when my conf file is:
That is the output of usbhid-ups (starting from the line
[...]
Is there an equivalent to -x wait when using the same UPS with the
'usbhid-ups' driver?
I don't think this will be needed with the usbhid-ups. Why don't you just
try this out? Pull the mains plug from the UPS (it will now run on
batteries) and type
# upsmon -c fsd
This will force
Please tell me if u have any method to increase the charging current of
APC smart 1000/1400VA with and without external battery bank option. I
am using externally 40 and 80 Amp lead acid batteries but charging time
is too long. Please help me ASAP.
You would have to ask APC for that. Since
Apologies for the number of emails; I just tried starting as user root and
the error message changes but the outcome is the same:
---
[EMAIL PROTECTED] drivers]# /sbin/upsdrvctl -u root -D start
Network UPS Tools - UPS driver controller 2.2.0-
Starting UPS: unial1200
exec:
Is there something I am doing wrong right off the bat? If not, is there
anything I can do to debug this, or help this UPS get supported?
[...]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
You could search the mailinglist archives for instance, we've had quite
some discussions
Is there any driver that does have any kind of support for my UPS over
USB? In the archives I can't find anything else.
As far as I know, no. It is reported to work with the 'genericups
upstype=7' driver over the RS232 interface (contact closure). If you don't
have serial ports available,
I also discovered that the log file is getting filled up with these
errors:
-
Jan 2 22:38:19 www kernel: usb 1-2: usbfs: process 24538 (megatec_usb)
did
not claim interface 0 before use
Jan 2 22:38:19 www kernel: usb 1-2: usbfs: process 24538 (megatec_usb)
did
not
Joseph Borg wrote:
The strange thing is that this fails really fast...it's as though it's
not even trying to detect the ups
No, it won't. You need to pass the '-u root' option, since the
hotplug/udev rules are not setup for this VID:PID combination. Until
then, you'll have to tell the
Le samedi 29 décembre 2007 01:10, John L. Korpi a écrit :
I had the same problem with the 2.2.0 on Gentoo (kernel 2.2.23) until I
turned this on and built a new kernel:
CONFIG_USB_DEVICE_CLASS=y
John
[EMAIL PROTECTED] 22:43:19 /boot] cat config-2.6.22.13-0.3-default |grep
Thanks for your quick reply and sorry for my late reply because i could
not access the concerned computer since then.
To answer your question :
$ rpm -q nut
nut-2.2.0-20.2
That should be the most recent version.
The system is up to date and there is still nothing new. Or is there any
[snip] Either way, I'll know
what's needed, if an option to interpret the OFF bit the other way
around, or just ignore it.
I've just commited a workaround for this in the development trunk.
Just add ignoreoff to your ups.conf and it should do the trick.
Still I think the 'megatec' driver
Carlos Rodrigues wrote:
Therefor, I propose to relax the interpretation of the status bits in the
'megatec' driver, to allow the interpretation of 'OL' and 'OB', even if we
already think/know the output is switched off.
No problem by me, but should I keep the OFF status together with
Is there a chance you can try this with the latest release (2.2.1),
which has some patches suggested by RedHat to improve IPv6 support?
The changes in nut-2.2.1 (and nut-2.2.0 also) are *very* loosy based on
suggestions made by Dan Kopecek, who wasn't working for RedHat at the time
he submitted
[...]
What suprised me was this table entry from APC ASTE-6YWRZE_R0_EN.pdf
Smart-UPS 2200/3000 VA 100/120/230 VAC Tower User Manual Page 9
] Function: Automatic Self-Test
] Factory Default:Every 14 days (336 hours)
] User Selectable Choices: Every 7 days (168 hours);
]
http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-September/003137.html
http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-July/003014.html
http://permalink.gmane.org/gmane.comp.monitoring.nut.user/2552
I still have this problem:
$ dpkg -l | grep -i nut
ii nut
For any who don't know:
Voltage is an insufficient indicator of { health, time to support
load, of if batteries will even support the load at all } . Internal
resistance is important to calculate, but imperils load while
testing to calculate (***).
Thanks for the reminder.
I
Is this available in unstable (the dev-version with the fix/if not what is
the ETA and also the ETA for 2.2.1 in testing)?
You can download a tarball (both for 'development' and 'testing') from
http://buildbot.ghz.cc/public/nut/
The ETA for nut-2.2.1 (stable) is 'shortly', I really don't
[...]
What does the battery.runtime represent? It was my understanding that
this was in minutes, but this cannot be the case.
VARDESC battery.runtime Battery runtime (seconds).
It is in seconds and without load, some devices report ridiculous long
times here. Complain to APC if you don't
Arjen de Korte wrote:
That's great! It doesn't look like we have an active maintainer for this
subdriver at the moment, so I'll commit a change to the development
version of the 'tripplite-hid' driver later today. It probably is a bug in
the UPS firmware that is quite specific to this model
[...]
When I run the command
# ../bin/usbhid-ups -a igor -DD -u root
it produces the long output which is attached below.
Then the machine crashes. I think the UPS just turns off
the power. The log file contains the line
Dec 4 16:05:26 computer kernel: usb 2-2: USB disconnect, address 2
I'm trying to setup a server controlling 8 ups, 6 APC Smartups 1500
and two 1000. Because of the number of ups, i connected them using usb
cables.
I'm using Debian Etch AMD64 and nut 2.2.0 from testing (already tried
2.0 from stable, but had problems reading the ups serials and all the
[EMAIL PROTECTED] /]# belkinunv -u root - -a BelkinSer
Network UPS Tools - Belkin 'Universal UPS' driver 0.06 (2.2.0-)
debug level is '8'
No response from UPS
No response from UPS
No response from UPS
No response from UPS
No response from UPS
No response from UPS
No response
Here's what I got from powerpanel:
./powerpanel - -a cyberups
Network UPS Tools - CyberPower text/binary protocol UPS driver 0.22
(2.2.0)
Warning: This is an experimental driver.
Some features may not function correctly.
debug level is '8'
Trying binary protocol...
send: (2
One thing to check is that if a UPS is equipped with both a serial and USB
interface, you can usually only use one at a time. Many use share the same
hardware for both interfaces, so when not in use, you should not plug in
anything to these ports. Switching between these may require switching off
I guess you are right that we learned something from running the driver
stand alone - but the debug level didn't seem to add as much verbosity
as it did with other drivers. I have checked on your suggestions:
Older drivers generally are less verbose than newer ones. Over time, we
have found
A big issue with auto-discovery is trust. You wouldn't want someone to
be able to randomly shut down machines on your network just by
starting a rogue copy of NUT.
Another problem is when you discover multiple UPS'es, which one you're
connected to? In a desktop system with only one UPS
Carlos Rodrigues wrote:
When you have only one UPS in your network, this might work. Otherwise,
one UPS going offline might cause all clients to shutdown. This is
probably not very desireable.
What I had in mind was more of a centrally managed configuration, than
no configuration. For
Richard Chapman wrote:
I have changed the driver in my ups.conf to usbhid-ups, and based on
other literature I have read - I set the port to auto, but at startup
i get the error:
Starting UPS driver controller: Network UPS Tools: 0.28 USB communication
driver 0.28 - core 0.30 (2.2.0-)
Richard Chapman wrote:
Also for Tomas Smetana of the epel repository
I think we are getting somewhere - but not quite to the final goal...
If I run:
/sbin/usbhid-ups -u root -D -a BelkinUps
as suggested it all works fine - and finds the UPS on the USB port. It
still does so if I
Tomáš Smetana wrote:
The drivers are supposed to run under user nut group uucp. Your
problem seems to be somewhere in the udev rules provided with the rpm
package -- they should change the ownership and permissions of the
appropriate USB devices.
Euhm, the settings in these files depend on
Could you post the output of 'upsc upsname' here? We're working on
extending the support for the powerpanel driver, but in order to do
that, we need some information on what is reported by devices that are
supported already. Thanks in advance.
powerpanel driver:
After following your advice, I got this:
Please state exactly how you started this driver (startup command line and
contents of 'ups.conf' so that people that find this thread, can easily
duplicate what you did.
Serial-over-USB transport layer for Megatec protocol driver
[megatec_usb]
First, I have taken this discussion from the 'nut-packaging' mailing list
to 'nut-upsuser'. Please don't reply in 'nut-packaging', since this is
off-topic there (sorry for the duplicate, this should be the correct
mailing list address).
The model of UPS I have is included in the supported models
I'm having a hard time configuring a Mustek Powermust 600VA ups to
work via USB with nut. I read somewhere that nut works OK via the
rs232 cable, but unfortunately I don't have a COM port in my computer.
The kernel detects the ups as an Xbox pad :) and loads the xpad
module. I tried
I was able to use megatec_usb with a Powermust 1000VA USB with the hal
driver activated (hald-addon-megatec_usb). If you are lucky, megatec_usb
will be able to recognize your ups if you force the agiler subdriver
in your ups.conf.
Here is my config:
sys-power/nut-2.2.0 with both hal and
Krzysztof Sasiak wrote:
I modified your config accordingly and now I get the following message:
Serial-over-USB transport layer for Megatec protocol driver
[megatec_usb]
debug level is '3'
Checking device (06DA/0003) (002/002)
- VendorID: 06da
- ProductID: 0003
- Manufacturer: unknown
Jimmy Jazz wrote:
I will follow your advice but i'm not sure the maintainer would agree.
That feature is deactivated in the package itself :)
That's OK. If NUT is compiled without HAL support, that's fine too.
To get out of trouble, how do i prevent hal to exclusively and
automatically
The best answer we can offer here, is to just try it out on your
specific kind of hardware. The proof of the pudding is in the eating.
Of course. The shortcoming being that running the UPS down that far would
take a few hours - at which point I start thinking asking around might be
more
You trimmed off the initial (and most interesting) part of the startup
of this driver. Don't do that, unless we ask you to do so.
Okay..
Here is the output. I saved it to a file for better readability.
That is a lot more informative, thanks.
That is a lot more informative, thanks.
http://www.uno-code.com/files/nut.output.txt
Ouch, this really sucks! It looks like the feature reports for this UPS
are completely bogus and that we should only use the reports we get on the
interrupt pipeline for this unit (which seem to be
hanji wrote:
Thanks for replying to my email. I updated to 2.2.0, and I'm running
into the same problem, but also encountered other issues. After
upgrading to 2.2.0 and using the usbhid-ups driver, I was not able to
get a clean restart of upsd.
/etc/init.d/upsd restart
* Stopping upsd
hanji wrote:
Strange. Looks like my init script already does this:
start() {
ebegin Starting upsd
# clean up first
pkill -u root -x upsd
sleep 1s
rm -f ${pidfile}
# now start up
start-stop-daemon --start --quiet --exec
You have been busy i see. OK it is possible to set the 9120 to requsted
mode only, and this is done by the serial driver part. And it should
remain so after power cycling.
How is this accomplished? Any chance of a step by step tutorial?
This is done through the initialization of the bcmxcp
I have a PW9120 hooked up via a serial cable running NUT 2.0.4.
When running upsc I cant see any parameter that looks like it would
trigger a shutdown. Theres is
nothing like battery.charge.low: 30 or battery.charge.warning: 30.
The UPS may not support reporting and/or changing this value.
In general, shutdown will be triggered when the UPS is both on battery
*and* reporting low battery. The latter may or may not be user
configurable. In your case, it looks like the driver has no way of
changing this level, so when this actually happens depends on the UPS.
So, for testing I
I have updated to nut 2.2.0-1 as suggested. Unfortunately I still get the
same type of errors:
Network UPS Tools - UPS driver controller 2.2.0-
Network UPS Tools - BCMXCP UPS driver 0.11 (2.2.0-)
Warning: This is an experimental driver.
Some features may not function correctly.
Model =
Have you tried the serial connection?
No, there is no serial port on my machine.
If you have one, a serial-to-USB converter is a cheap solution to add one.
Many (not all) are supported by recent kernels.
1) Apparently, this UPS needs to be told only to reply to specific
requests and not send
Well, I can tell you that the frequency should in fact be close to 50Hz
(well, in theory it should be exactly, but we don't live in a perfect
world).
One way to get at least the nominal value correct, is by averaging the
measured frequency (one reading every minute) over several days. That
Hi guys,
We've got a BNT-1000AP (powercom) BlackKnight UPS that works with the
KIN1500AP model in the powercom driver. Well, almost. It seems the
input frequency and the battery charge is swapped around:
# upsc [EMAIL PROTECTED]
battery.charge: 46.5
driver.name: powercom
Aurélien Croc wrote:
You're not providing a lot of information to work with. If you're not
using the latest stable version (nut-2.2.0) and the 'nitram' driver,
change that first. If you're already using these, we want to know more
about the system you're using and preferably some debug
Aurélien Croc wrote:
I recently bought a Nitram Elite 2005 UPS and i installed nut to monitor it.
This question isn't related to development, so I'll answer this in the
nut-user mailing list.
Unfortunatly, i often have timeout errors (20 timeout per days):
Broadcast Message from [EMAIL
The 'ondelay' timer will be started at the same time as the 'offdelay'
timer and is really only meant to provide a means to prevent a deadlock
when the power returns before the UPS shuts down. The better solution is
documented in 'docs/shutdown.txt' which you have been told to read on
several
Using ondelay = 30 in ups.conf I have managed to wait more time after
the line power is back - other question why this so unreliable:( I have
measured time at 16 min upto 32 min (ondelay = 30 should give 30x10sec = 5
min) - but I do not care it is not so important for me.
This is not what
This is not what 'ondelay' is meant to do. Please checkout 'man 8
mge-shut' for a description of what the function of this is.
May I missing some thing? I read this carefully:
http://web.iesrodeira.com/cgi-bin/man/man2html?mge-shut+8
The 'ondelay' timer will be started at the same time as
[...]
I managed to set the low battery level OK though (and then shut my PC
down by mistake :) so I can actually set values.. Is it just that
usbhid-ups doesn't support outlet switching? (yet hopefully :)
Outlet switching is supported, only you need to use 'upscmd' for that (see
the man
Usuallly I'm using for this kind of controll strongly ASCII coding,
at least intel hexa (simple memory dump), but when so small amount of
information in could be more readable, not only for beauty but
debugging purposes. In this case you can use a simple terminal
application
Rózsa Gábor wrote:
Its became more difficult!
#upsdrvctl shutdown myups- does not work for me!?
#upsrw -s ups.delay.shutdown=5 -u monmaster -p blah myups- working
well, ups switch off after 5 sec of the command:)
#upsdrv -s ups.delay.start=5 -u monmaster -öp blah myups -
1) Does the shutdown sequence take too long?
Is it about 15 - 20 seconds (from usual system message about shutdown).
That's not an inordinate long time, so this should not be a problem.
2) How old are the batteries? Could it be they are already worn out (you
can expect this after 3-5 years
tovis wrote:
upsmon.conf using NOTIFCMD and NOTIFYFLG is working well, it is calling my
script notify on requested events (ONBATTERY,LOWBATTERY and ONLINE).
Command
#upsmon -c fsd -u monmaster [EMAIL PROTECTED]
gracefully shutdown my box and after several seconds switch off the ups's
tovis wrote:
For now I think that my box does not recognize signal about low battery -
I'm only started to read SHUT protocoll of MGE, and do not understand that
is this signal a result of some kind of status request from my box to UPS
or UPS send this signal unsolicited - I supose the last
Arjen de Korte wrote:
what am i doing wrong, and why the hell does /etc/init.d/upsd change the
permissions on /dev/ttyS3 wrong?
What are those permissions and why are they wrong? What did you do to
make it work?
This script is not part of NUT. Please file a bugreport with openSUSE
Sorry, I should have been clearer. I replugged the UPS, but still got the
same result. I tried rebooting the system, but still got No matching HID
UPS found
Can you start the driver in debug mode?
/usr/lib/ups/driver/usbhid-ups -D -a myups
Best regards, Arjen
--
Eindhoven -
Jeffrey B. Green wrote:
Thanks much. I thought that I'd tried that driver w/o success. Probably
had something wrong in the config file. So step 1 is done. everyone
seems to be talking w/ one another now.
It looks like we need to update the drivers.list once again. Apparently,
Belkin has
Dear List, The driver usbhid-ups does not detect my MGE Ellipse 1500.
I'm running openSuSE Linux 10.3, kernel 2.6.22 with mgeups-psp-3.0.4-2,
nut-2.2.0-20 installed from MGE's rpm's. (Merci MGE!)
lsusb shows:
Bus 001 Device 004: ID 0463: MGE UPS Systems UPS
/etc/ups/ups.conf says:
This is a known problem with the new kernel in openSUSE 10.3:
https://bugzilla.novell.com/show_bug.cgi?id=331749
Unfortunately, this is apparently not very high on the list of
priorities.
So for now, I suggest to apply the changes by hand. :-(
I applied the change, and the head of file
hello,
at first I'm sorry my english isn't perfect but I tried to be clear
I work with mandriva 2007 and with nut 2.0.1 installed with urpmi
my UPS is a MGE Evolution 2200 connected with RS232
First of all, upgrade to nut-2.2.0. The version you have now is well past
its 'use by' date.
in
Being supported (serial) means full support? That is, I can connect to
the UPS, read all values and do a shutdown in case of low battery?
If Mustek has not changed the internals of this device since the last
report we got, yes.
Best regards, Arjen
some months ago I bought an SBS GC400 UPS.
I came with a kit RS232 + UPSmart CDROM that works only with RedHat
7.0-7.3.
As I use Debian I tried alien with no success.
Can you please provide me with any hint to understand if my UPS can
be managed by NUT?
Can a driver be
Derk-Jan Hartman wrote:
This is not directly NUT related, but i don't know where else I can
still ask this.
I have been using a pretty decent 2nd hand MGE ellipse premium 1200VA
for a while now at home. http://www.mgeups.com/download/doc_intl/
small/premium/389uk.pdf
It's been working
Any help or guidance would be appreciated. If I need to patch the
source to add support for the ES 550, I can do that, with a little
guidance.
There is nothing we can do about this. According to the output you
attached (which is great, thanks), the UPS is reporting this.
Path:
I'm looking for a UPS that the beeper can be silenced with nut
via ups.beeper.status variable for a HTPC close to bedrooms.
You should not be looking for the 'ups.beeper.status' variable, this is
supposed to be read-only (although it not always is, for all drivers).
Instead, you want to lookup
As for trying the usbhid-ups driver, I am for sure trying to run it as
root but still having problem, this is the output:
[EMAIL PROTECTED]:/usr/local/ups/bin# ./usbhid-ups -u root -D -D -D -D -a
chuma_ups
Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.2.0-)
debug
Charles Lepple wrote:
The above two lines should also be displayed by usbhid-ups in the
'Manufacturer' and 'Product' strings upon startup with the -DD option. As
long as that's not happening, it can't attach to the port because of a
permissions problem and/or another driver being attached to
i use nut with mge comet ex 7 rt (mge-shut driver).
The mge-shut driver is no longer being actively maintained and has been
replaced by the newmge-shut driver. If you're using nut-2.2.0 or newer,
please make the switch.
Is ist possible, that upsmon loses states?
I obtain onbatt and online
i just wonder, if it is posible to read the values for all the three
phases of a mge galaxy 6000 ups?
From looking at the mgemib part of the snmp-ups it doesn't read the
data of all 3 phases (yet). Though this should be fairly easy to add.
I have added this in my local copy for the MGE MIB,
I just tried using the upsmon -c fsd while running the development
NUT package. It caused the package to send the 'shutdown' command to
the PC, which caused the PC to shutdown (gracefully), but the UPS
never killed the power to the PC.
Perhaps I misunderstood, but I thought the sequence of
Hi all,
I know there are some howto's about Powerware 5115 and Ubuntu, but I can't
still get that thing working.
Can someone give some light...
1. Powerware 5115, serial port (ttyS0)
2. Ubuntu 6.06.1 as LTSP-server
As reference:
http://gentoo-wiki.com/HOWTO_NUT
I just got NUT 2.0.1 running on my Debian system at home.
No, you have nut-2.0.4 running according to upsc. :-) The newhidups driver
in nut-2.0.1 only supported MGE devices.
I have a new CPS UPS connected via USB. Everything is working fine,
except the UPS is showing a value of 120%
Go for the development version. That has a much improved usbhid-ups
driver, which also allows for better debugging.
I went looking for the Development version, and I'm afraid I'm a little
confused. On the NUT site, it says the latest development version is
2.1, but the release I'm running is
Mark E. Hansen wrote:
Thanks for the help in getting the current development sources (to Charles
Lepple as well). I've downloaded and configured/installed nut-2.3.0-r1114.
However, I don't see any difference in how the setting of some variables
appears to be ignored.
In that case, chances
Mark E. Hansen wrote:
I assume you have read and understood the reasons in the FAQ
why we generally recommend against doing that.
I've read the FAQ and I'm sure I found the entires to which you refer.
However,
what those entries don't consider is the primary problem with waiting until
the
Mark Hansen wrote:
I'm running Network UPS Tools 2.2.0 on a Linux machine, running
CentOS 4.5 (RedHat Enterprise Linux 4.5), with a kernel version
2.6.9.
I believe I have the software setup and configured properly. I
can access the UPS via the upsc (client) tool, upscmd, upsmon,
etc. Even
Instant commands supported on UPS [myupsname]:
load.off - Turn off the load immediately
load.on - Turn on the load immediately
shutdown.stop - Stop a shutdown in progress
beeper.on - Enable the UPS beeper
beeper.off - Temporarily mute the UPS beeper
Can anyone please tell me what I'm
Mark E. Hansen wrote:
Apparently, the granualarity on you UPS is 1 minute and it will report the
final time as -60 seconds. This is odd and violates the HID Power Devices
specification. Having said that, it will probably also violate this with
regard to the fact that a zero delay is a valid
That of course, is also a possibility. In which case, there is probably
nothing we can *ever* do about this. If everything looks normal before
the
tests, but the UPS fails during the test, we're toast. There can be a
number of failures for this, not limited to the battery alone (a relay
On Mon, Sep 10, 2007 at 09:12:36PM +0200, Arjen de Korte wrote:
My MGE Pulsar Evolution 800 had some hardware troubles (it may be the
batteries according to the manual). The fault was not detected so the
power was cut to the load and nothing appears in the log files.
Please
I would have liked to fine something in my log files. I know the
problem occured between 14:15 and 14:29 but not much :(
I guess it was a power outage and the battery failed the moment it
really had to provide power. Regarding the age of the battery, this is
quite a likely failure mode.
I
My MGE Pulsar Evolution 800 had some hardware troubles (it may be the
batteries according to the manual). The fault was not detected so the
power was cut to the load and nothing appears in the log files.
Please be as specific as possible to describing what kind of problem you
had. Which
Justin Piszcz wrote:
I've not had time (nor will have) to digg all the thread on the nut
ml, so can you update me about the status of the below one please.
Yeah basically any version newer than 2.0.4 says the battery is low
(which is incorrect) so for now I set it to hold at that version,
501 - 600 of 770 matches
Mail list logo
