Citeren Tuc at T-B-O-H.NET [EMAIL PROTECTED]:
Trying to rotate the ups.log on a FreeBSD 7.0 system
and its not being nice about it.
I tried the quick and dirty way by doing :
mv /var/log/ups.log ${DATEDDIRECTORY}/ups.log
kill -1 `cat /var/db/nut/upslog.pid`
This is
Citeren Tuc at T-B-O-H.NET [EMAIL PROTECTED]:
Sep 17 10:59:48 valhalla upslog[82020]: Signal 1: reopening log file
Sep 17 10:59:48 valhalla upslog[82020]: could not reopen logfile
/var/log/ups.log: Permission denied
Well, that last line pretty much says what is wrong, doesn't it?
Why
Citeren tarbeite [EMAIL PROTECTED]:
Running opensuse 11 with two ups that can be seen via web interface and post
messages on the console.
Please post the contents of /etc/ups/upssched.conf here. Also make
sure that the directory mentioned in PIPEFN and LOCKFN exists and is
writeable by the
Citeren Kenneth R Litko [EMAIL PROTECTED]:
OK... Thank you Arjen.
I've killed the extra processes... But have some new problems. And I still
cannot connect to the device.
If I run upsdrvctl start (with or without '-u root'):
--
[EMAIL PROTECTED]:/etc/nut$ sudo upsdrvctl start
Citeren Kenneth R Litko [EMAIL PROTECTED]:
Got it working Arjen... I had to compile 2.2.2 and install from source. It
must have been with the current version of NUT packaged with Ubuntu Server
8.04.
Good to hear that!
The only remaining weirdness is upsc reports the battery (either 0 or
Citeren Kenneth R Litko [EMAIL PROTECTED]:
Sep 8 13:58:48 bigdog kernel: [ 4460.019306] usb 7-3: new low speed USB
device using ohci_hcd and address 5
Sep 8 13:58:48 bigdog kernel: [ 4460.524141] usb 7-3: configuration #1
chosen from 1 choice
Sep 8 13:58:50 bigdog kernel: [ 4461.867256]
Hi to everybody. Some days ago, I bought an UPS by Forza Power
Technologies,
model SL-1001. This Forza SL-1001 is line-interactive, has 14,4 A/h
charge
and is rated at 1000VA. Before, I had a TrippLite Omni 500 (or something
like that), a simple contact-closure UPS, and I used nut
Are the 'usbhid-ups' (driver) and 'upsd' (server) also running as
'nutmon'? We recommend that they run as a different user than the
'upsmon' (client).
They are running as the same user.. It shouldn't stop it working though,
right?
No, it's just a matter of securing things. There is a
I have this in devfs.rules -
add path 'ugen*' group operator mode 660
And I have a devd file in /usr/local/etc/devd/nut.conf with..
attach 100 {
device-name ugen[0-9]+;
match vendor 0x0463;
match product 0x;
action chown nutmon: /dev/${device-name}*;
Hi,
I have an MGE Ellipse UPS connected to a FreeBSD 7.0 system and it works
OK
to begin with but after an hour or so it dies, eg..
Starts out OK..
debug level is '2'
upsdrv_initups...
Checking device (0463/) (/dev/usb2//dev/ugen0)
- VendorID: 0463
- ProductID:
-
iMac:~ mihailartuhov$ sudo upsmon
Password:
Network UPS Tools upsmon 2.2.2
UPS: [EMAIL PROTECTED] (master) (power value 1)
Using power down flag file /etc/killpower
Broadcast Message from [EMAIL PROTECTED]
(no tty) at 9:53 JST...
Communications with UPS [EMAIL PROTECTED] lost
Hi, Arjen !
That is what happened:
iMac:~ mihailartuhov$ sudo /sw/lib/nut/usbhid-ups -DDD -u root -a CS_650
Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2)
[...]
This is all looking good. The question here is, are the 'upsd' server and
'upsmon' client able to read this
Now :
input.voltage is changing (Ok!):
input.voltage: 214.0
Although this looks a little low for a 230V (nominal) system, this is what
the device reports, so there is little we can do about it.
and power unplug and replug:
Broadcast Message from [EMAIL PROTECTED]
(no tty) at
I have iMac24 computer powered by Back-UPS CS650IE. (USB)
I Installing NUT using Fink packages from source.
Configuring NUT :
1. /sw/etc/nut/ups.conf
[CS_650]
driver = newhidups
port = /dev/ttyS1
The above (although not incorrect) is confusing. Change to 'port = auto'
in
I installed nut-2.2.2 via FinkCommander !
but now :
Last login: Mon Aug 18 22:40:42 on ttys001
iMac:~ mihailartuhov$ sudo /sw/lib/nut/upsdrvctl start
Password:
Network UPS Tools - UPS driver controller 2.2.2
Can't start /sw/lib/nut/newhidups: No such file or directory
iMac:~
Geraint Evans wrote:
I have been trying to get Nut working on a system with Fedora 8 i86_64
installed and an APC
Smart-UPS USB.
The 2.2.0 rpm does not seem to like the USB on this UPS. I have tried
compiling the 2.2.2 version,
from source, but am getting warnings. I have tried
It is currently not possible for me to reach the ups, but as far as I
remember the vendorid was 0x051d.
That is not surprising, since this is the vendorid of APC.
-D or more didn't bring up anything interesting.
I beg to differ here. If the UPS would be recognised by the kernel (which
is
Kovacs Gabor wrote:
has anybody experience with CyberPower Smart/Sine wave series (especially
PR2200SWRM2U) in NUT? I couldn't match model numbers on NUT hardware
compatibility list.
Well, the CyberPower PR2200 is mentioned in the compatibility list. If
you search the CyberPower Systems
I'm currently trying to install a APC Back-UPS ES 700 on FreeBSD. This
UPS has a usb connection to the PC and is recognized as:
[...]
Anyone has an idea what to try next? Maybe there is just some usb id
missing in the driver so it will recognize this ups?
You could start with providing some
Arnaud Quette wrote:
reported through launchpad: https://bugs.launchpad.net/bugs/253999
the possible regression is between nut 2.0.1 (sarge) and 2.2.1
(confirmed Jamie?)
@Arjen: it may be related to some of your changes there...
No way. If you don't override in- or output signals, the
I moved everything to localhost, now upsmon refuses to start because the
powervalue is insufficient, 1 vs 0.
The answer is in 'man 5 upsmon.conf'. Please read this first, especially
the part about MINSUPPLIES and the reference to 'man 8 upsmon'. If
anything is still unclear afterwards, feel
orangevixen wrote:
It's a serial cable that came with my old UPS (an IBM UPS) which has
since died. My new UPS (the Cyberpower CP550SL one) did not come with
one so I'm using that old serial cable. I wrote to Cyberpower to get a
new one but I'm not sure if they're going to send one or not.
DTR appears to dicrate the OB/OL status, however the driver won't let
me set that:
# /usr/lib/nut/drivers/genericups -a cyberpower
Network UPS Tools - Generic UPS driver 1.34 (2.2.2)
UPS type: CyberPower Power99
Can't override input with DTR (not an input)
Chances are you need a special
I'm new to this list and I have a question concerning using the genericups
driver
(type 22) with the Cyberpower 485 in serial mode.
When running the driver in debug mode:
genericups -a myupsname_genericups22 -DD
I observe the following statuses as the mains power dies, switching
[...]
Asking for UPS status [Q1]...
get_data_agiler: raw dump: (0 bytes) =
get_data_agiler: raw dump: (0 bytes) =
Q1 = FAILED [short read]
Q1 detail: (0 bytes) =
5 out of 5 detection attempts failed (minimum failures: 2).
Megatec protocol UPS not
Ok referencing that table against my 1250 the 8TI is spot on
(SmartUPS1250, Standalone 230V).
However comparing the interpretation of the New Firmware against the
SmartsUPS 1400 (ups.firmware: 70.9.I) It may be a little inaccurate.
No, it isn't. We only use the (old) 'V' command if the
I've modified the apcsmart driver source briefly tested against
the 1250 with no issues noted yet.
I've attached a patchfile for apcsmart.c apcsmart.h with the
extra bits I've added.
thanks for testing that. I just committed that to the SVN trunk, so
it should be part of the next release
Jul 2 22:58:53 alcor upsd[5353]: Can't connect to UPS
[powerman] (megatec-powerman): No such file or directory
The driver couldn't detect the UPS. The above message is due to a broken
startup script, since the upsd should not be started if drivers failed to
start.
2) When it starts properly
Arjen: looks like you added some identifiers to this list previously.
Would you have any objection to moving the upsdebugx() line up so that
the firmware version gets printed before firmware_table_lookup()
exits?
No objections here. It probably is worthwhile to check the value of 'ret'
before
Asking for UPS status [Q1]...
Q1 = OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 ]
Calculated battery charge: 100.0%
Asking for UPS status [Q1]...
Q1 = OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 ]
Calculated battery charge: 100.0%
*** stack smashing detected ***: megatec
quite right about the outdated packages links.
wouldn't this one be more useful for nut:
http://packages.opensuse-community.org/index.jsp?searchTerm=nut
I don't think so. It is much more convenient to add the OSS repository
(the link can be found in the page I mentioned) than directing people
[...]
Jun 27 17:03:10 [EMAIL PROTECTED] upsd[14891]: Host 1.2.3.4
disconnected (read failure)
Jun 28 08:31:00 [EMAIL PROTECTED] upsmon[2327]: Startup successful
Ok, We can see a serious issue there... My UPS shut down everything, due
to failures with the drivers.
No. Whatever the problem
Please keep the mailinglist posted. Many developers won't reply to
questions unless they are (also) directed to the mailinglist.
In addition to Q1, it also looks like [I] isn't being parsed correctly,
or the unit did not understand the query. no model information,
serial #, etc.
We don't need this, since there would be no way to autodetect this UPS
anyway.
IMHO, it would be very useful to still gather this information from
people and create
a database of such UPS on website/wiki or even in configs, so people could
just
peek them and use, without doing all this
Well.. lets try. I believe there must the way through. As a last resort
it should be possible to allow user select concrete model or parameter
set by hands..
Not with the existing HAL interface, or we should somehow hardcode a path
to a configuration file.
I haven't dealt with hal drivers
I hadn't previously looked into libusb, but is there a reason why the
filename
member of usb_device is't matched on? On linux, they may not be unique or
deterministic in theory --- but in practice they are, particularly for
servers where you're not constantly plugging in and out devices.
Am I missing something in the logic, or do I just have an unusual
case?
Neither. These devices are just not suitable for use with NUT as long as
the libusb library doesn't expose the physical ports the UPS is attached
to.
that will be fixed with the new libusb 1.0 project.
I haven't looked
It also requires us to rewrite some
stuff, since the library is incompatible with libusb-0.1.
iirc, a transition compat layer is scheduled.
Yes, but that will only allow us to use the 'old' commands, which can't
handle multiple identically looking devices. In order to address this,
we'll
I'm setting up a cluster with multiple ups's using nut 2.2. The ups's are
Belkin 1500 (ID 050d:0751) which don't appear to report a serial number.
Is there any other way I can setup ups.conf with multiple of these ups
over usb on Linux?
If I just setup the vendor and product id's, every
The end of the trace shows that the driver is killed by signal 15.
This is *not* caused by the driver itself, but by another process.
Yes, I rebooted that machine to connect it back on the ups power.
But during the attached trace the UPS rebooted it's output, right? It
doesn't look like
Arjen pointed out what is the most likely cause of the segfault (our
reconnection code has changed a bit since the driver was first
written), but the problem is that I won't have time to work on that
for a week or so.
Would it behoove me to downgrade nut?
No, just remove (or comment out)
I just booted into a non-xen kernel (linux-image-2.6.24-17-server).
Ran /lib/nut/usbhid-ups -a mgeups.
The UPS shut down again and so did my entire network...
The error message is still the same. So I don't think my problem is xen
related?
I don't know. If NUT and the UPS are working on your
I spent half the night getting this to work... and only got a little
further. The only difference I found is:
On my Desktop with psp installed, but not running:
[EMAIL PROTECTED]:~$ sudo /lib/nut/usbhid-ups -a mgeups
Network UPS Tools: 0.29 USB communication driver - core 0.32 (2.2.1-)
The apparent maximum voltage of the battery is 12.8v.
Is this the value reported by the UPS or did you measure it with an
external measuring instrument? A UPS is not a calibrated measuring
instrument and the values reported by some models are way off the 'real'
values. In other words, the
Please keep the mailinglist posted. I won't reply to messages sent to me
in private, unless a consulting fee is involved.
How can I make sure that a machine was ready when the power was
cut? I
have been getting messages about corrupt databases on return from a
power out.
The latter could
Please keep the mailinglist posted.
If I shutdown with upsmon -c fsd the databases are shut down
correctly.
That is bad. It means that the system shutdown sequence takes longer than
the remaining runtime on batteries after reporting 'battery low'. In other
words, the UPS is powering off
Please keep the mailinglist posted.
I was under the impression that the ability of the machine to restart on
return of power depended on the power beeing cut while the system is
running. Is that not how it works?
That depends on your system. Some will 'remember' the last status before
the
The openSUSE distribution (formerly, SuSE) already has such a tag,
'smartups'. This is used for both NUT and 'apcupsd'. Basically, both add
UPS monitoring capabilities.
Actually, I think that nut obsoletes smartups.
Well, the present version as provided by openSUSE both 'provides' and
I also come to the conclusion that we won't be able to have a uniform
implementation (ie the same packages split) on all supported systems.
I'm afraid we won't. This shouldn't be too bad, provided we have list
of people that run as many platforms that we know of.
not sure to understand the
Jean Delvare wrote:
You might be able to solve this problem with rpm tags such as:
Provides:nut:one key file which moved from nut to nut-server
The openSUSE distribution (formerly, SuSE) already has such a tag,
'smartups'. This is used for both NUT and 'apcupsd'. Basically, both add
well, that's the biggest problematic of packaging.
none of the solutions are perfect, and both have big pros and cons.
there are still many rooms for improvement there...
Indeed. In the mean time, I have divided the main 'nut' package in the
following sub packages:
- nut (client applications)
I loaded g++ which had not been asked for; it requires package
gcc42-c++. The build then went much further, ending in
/usr/lib64/libupsclient.so: undefined reference to `select_read'
/usr/lib64/libupsclient.so: undefined reference to `select_write'
collect2: ld returned 1 exit status
Arnaud Quette wrote:
In the mean time, I have divided the main 'nut' package in the
following sub packages:
- nut (client applications)
- nut-server (drivers and upsd server, requires 'nut')
- nut-snmp (net-snmp based SNMP driver, requires 'nut-server')
- nut-xml (neon based XML
Roger Price wrote:
The better strategy would be to start a upssched timer (I'll call this
'powerout') as soon as the power is lost. If the power returns, cancel the
timer and it is business as usual. When the 'powerout' timer elapses after
two minutes, you start a second timer (I'll call this
John Darrah wrote:
I have determined that the the socket is never created because the program
never reaches dstate_init().
It *must* reach this, otherwise it would never reach the part where it
continuously loops through upsdrv_updateinfo().
[...]
The following is a section of
Arnaud Quette wrote:
I previously splitted the Debian packages in nut, nut-usb, nut-cgi,
nut-snmp, nut-dev, nut-doc (empty ATM) and now nut-hal-drivers. I've
then re-integrated the USB part into the core package since it's usual
to have libusb, even on headless server (and USB tend to become
Arnaud Quette wrote:
No, and that's because I doubt that openSUSE will follow this approach.
Historically, there hasn't been too much interest in splitting packages,
since SuSE (now openSUSE) attempts to create a working configuration out of
the box. Therefor, it made little sense to split
Roger Price wrote:
No surprise here, it's just more n00b fumbling. The correct answer, which
is provided by the rpm but which I wrongly ignored, is:
# /etc/ups/upssched.conf
CMDSCRIPT /usr/sbin/upssched-cmd
PIPEFN /var/lib/ups/upssched/upssched.pipe
LOCKFN
Arnaud Quette wrote:
There is no /var/state in openSUSE 10.3, so I changed PIPEFN and LOCKFN to
/var/run and defined directory /var/run/ups.
We need a pre3 to fix this since this has been a long standing bug. This
path is hardcoded in the example configuration, where running
I'll try them tomorrow; meanwhile, another n00bie question : What does
nut-hal do? Do I need it?
The nut-hal package is a package that contains the hal drivers and fdi
file udev rules.
As you are using a usb ups, you may use this instead of the nut package.
If you install it, the ups
Roger Price wrote:
My 64 bit rpm's are available at
http://rogerprice.org/nut-2.2.2/nut-2.2.2-pre2.x86_64.rpm
http://rogerprice.org/nut-2.2.2/nut-devel-2.2.2-pre2.x86_64.rpm
http://rogerprice.org/nut-2.2.2/nut-hal-2.2.2-pre2.x86_64.rpm
Great, thanks for that!
The nut-hal package is a
Arjen de Korte wrote:
# /etc/ups/upssched.conf
CMDSCRIPT /usr/sbin/upssched-cmd
#PIPEFN /var/state/ups/upssched.pipe
#LOCKFN /var/state/ups/upssched.lock
PIPEFN /var/run/ups/upssched.pipe
LOCKFN /var/run/ups/upssched.lock
AT ONBATT * START-TIMER ups-on-battery-timer 121
AT ONLINE * CANCEL
Hello Arjen, I live in the Alpes Maritimes in the south of France. This
is an area with frequent electrical storms, plenty of lightning and it is
common to have several short power cuts in succession during a storm. My
strategy is to tolerate short power cuts, up to 120 seconds, but if the
You'll want to rebuild this based on the bundled .spec file, something
like
rpmbuild -ba nut.spec
This will handle the configuration stuff for you.
I've been looking at
/usr/src/packages/SOURCES/nut-2.2.2/packaging/madriva/nut.spec which even
though at version 2.0.1 is probably the
You're making this far more complex than needed. With the RPMs I sent you,
I also included the source RPM for nut (which was built on openSUSE 10.3
by the way). Extract that with
rpm -Uvh nut-2.2.2-pre2.src.rpm
and then rebuild the lot with
rpmbuild -ba
Roger,
Do you have libtool installed?
No, it wasn't asked for.
Hence, my question to Arjen about whether autoreconf needs to be
called (it uses libtool, but the spec file shouldn't need to call
autoreconf in the first place).
I built the RPMs in a hurry. Usually, this .spec file is
The libraries are present, yes, but they are 64bit and you are trying
to install a 32bit rpm. You can either install the 32bit versions of
those libraries, or try rebuilding the rpm to obtain a 64bit one.
Aha! I installed the source rpm, read the README, created group nut and
user ups, made
I've just installed a new UPS 'INVERTER Atlantic Star T3' and their
documentation speaks of megatec.
So I tried it. And I get lots of wonderful information I'm not used to
seeing.
# upsc [EMAIL PROTECTED]
battery.charge: 100.0
battery.voltage: 2.31
battery.voltage.nominal: 96.0
[...]
So everybody can calibrate his own ups battery measurement
make the polynomial fit and just enter the coefficients in
ups.conf or just use recommended values for some models
that are know to have systematic error
what do you say?
I don't think this is a good idea. A UPS is not a
IMHO everything that measures something should be subjected
to periodic calibration being it a 5-digit precision laboratory voltmeter
or cheap piece of junk like ups, both can benefit from being
calibrated with higher precision instrument (not only to improve
measured values but also to
I had poor results with both drivers, but I got farther with usbhid-ups
using -x productid=1007. It looks like that driver retrieved some info
and
then went into an infinite loop (all details attached in uncompressed
files).
Well, what else do you expect?
maroon:/var/log#
There is many (20 per day on average) messages like:
kernel: usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt
161 rq 1 len 2 ret -110
usbhid-ups[6768]: HIDGetDataValue: Connection timed out
What can be done do correct that problem?
This is a message that is logged at the level
I just got reply from Cyberpower RD department about the battery
voltage correction formulae
responsibility of the vendor (CyberPower). If someone provides me with
the
correct conversion values, I'm willing to include this in the subdriver.
Our software group provided the following
Franck Hamelin wrote:
There is many (20 per day on average) messages like:
kernel: usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161
rq 1 len 2 ret -110
usbhid-ups[6768]: HIDGetDataValue: Connection timed out
What can be done do correct that problem?
This is a message that
I have cyberpower value 800E connected via usb.
In the status battery voltage is too high 20V - 21V
while measurement at the battery terminals gives 13.6V
This value is reported by the UPS in 'UPS.PowerSummary.Voltage' and we
display it 'as is'. It could be that the measuring circuit in your
I think the firmware is broken as it didn't apply correction
factor/offset to get volts in the HID diescriptors.
In that case, there is little we can do, unless we have a way to find the
correct coefficients and also are sure that these are applicable for *all*
devices that use the same
Because HID descriptors allow units of length, mass, time, temperature,
CURRENT (A), luminous intensity but doesn't allow the VOLTAGE (V)
(whoever invented this HID standard should be more grateful with
units to choose from)
Please read the HID PDC specification first, lsusb is wrong here. To
So if we see battery voltage 12V and PbAcid chemistry and
nonsense PhyMin and PhyMax in respect to current voltage,
we might do the heuristic decision to set those values
to 9.8 and 14.4 as you suggested and everything would
look good?
First of all, you'd get the same result for 7 and 15 for
My proposal is to even when we see product/vendor id, we make
extra sanit(ar)y checks before fixing values just to make
sure cyberpower haven't fixed them in some newer firmware
and we do fix already fixed values
[...]
We can't (and won't) reliably do that. The ranges for fixed/unfixed
Arnaud Quette wrote:
is this bug a known regression of 2.2.1 vs 2.2.0?
I can't find much in the ChangeLog.
I believe this has been fixed in the trunk for quite a while already
(also some additional devices are supported now).
Best regards, Arjen
Oksenchuk Dmitry wrote:
We have two upses: MGE Pulsar M 3000 and MGE Pulsar EXtreme 3200C. They
connect to server by USB. EXtreme works good with usbhid-ups (nut 2.2.1) and
newhidups (nut 2.0.5). But Pulsar M doesn't want to work with usbhid-ups.
This is a known problem that is fixed in the
The only reference to /var/run/nut in the strace is a
chdir(/var/run/nut).
That's where the driver has just dropped priviledges (line 537 in
drivers/main.c) and just before it sets up the signals (line 540).
Does it create the socket after this this chdir?
Yes, but *way* after that in
[...]
A brief examination of the NUT source code indicates that a system
write statement is being used to communicate across the network with
the upsd process of the master. We think that this system function
blocks by default. Maybe the default blocking settings are in use. We
don't know,
By browsing on the net I found http://www.usb-server.com/
it's a USB sharing over ethernet. It could be a viable solution
that on one PC I have USB hub and this software (and somehow
configure it to be hubbed-port distinguishable) and via
ethernet distribute USB ports to the master NUT server
Charles Lepple wrote:
usbhid-ups is capable to distinguish devices from the Bus
they are connected to, but as all are at the same hub the bus
is the same. I'd like if usbhid-ups could distinguish them from
the hubbed port they are plugged in.
I forget how the bus numbering goes, but what
My problem is that sometimes the UPS is running OK, but when the
message UPS is trimming incoming voltage appears on knutclient (i.e.
OL TRIM in nut), I have something like
Input Voltage
241.1
Output Voltage
202.0
nominal 220.0 ???
This output voltage is too low! I
[EMAIL PROTECTED] wrote:
Do you mean the computer's power supply? But it is supposed to run on
220-230V not on 202V! Isn't this a problem?
No. The mains voltage is specified within a 230V -15/+10%, since the
voltage was harmonized within the EU. So a mains voltage of anything
between 196 and
The drivers starts but is not connecting.
Upon exiting upsdrvctl with the output I already copied, upsd is not
able to connect to the device:
That's different from what you told before. You wrote you had a problem
with 'upsdrvctl'. In this case, you need to run the driver with debug
level 2
Ariel Dembling wrote:
a) The battery.type attribute is indeed a string, as Charles Lepple
guessed in the commented-out code (PbAc = lead acid).
I think I added that line in r1043. We'll uncomment it... :-)
b) The voltage (both nominal and real) is wrong, but not by a factor of
10 as
BREZINA Oti wrote:
I use Debian testing and after update nut to 2.2.1-2 (from 2.2.0 - not
sure) (and yes I read update notes-nothing found) I have problem with
communication with MGE PULSAR 2200.
Communication is opened and data are received, but it show that my UPS
is on BATTERY, what is
BREZINA Oti wrote:
We would like you to run the usbhid-ups driver in debug mode and post
the results here.
path/usbhid-ups -DD -a MGEPULSAR
The first 30 seconds of output are what we are interested in. After
that, terminate the driver (it will stay in the foreground until you
kill
Aaron J. Grier wrote:
this FAQ addresses the [OB DISCHRG] condition, which NUT correctly
recognizes as critical. I ran into an extended [OL DISCHRG] condition,
which NUT does not recognize as critical.
Because it isn't. If a UPS is reporting that the line voltage is
present, it can't be
Well, I can help testing the connector on a separate system and seeing
how that CyberPower supplied driver plays with it, since I do have quite
a few systems in that network to work on, aside from my NUT master
server. I am more than happy to test with it all, and get it working as
best as I
First of all, it helps if you post the *full* line from the logs and
also show some context (how often these messages occur).
That was the *full* line from the logs, except the syslog timestamp.
But I hardly think the timestamp and the hostname could be at any use
here.
We need the timestamp
Before all, upgrade to nut-2.2.1.
Now, I've done the upgrade, after a few adjustments to the ports
Makefile I will submit the patches to the FreeBSD ports collection, so
everyone can make use of 2.2.1.
I don't know if you mentioned this before, but FreeBSD might be part of
the problem here.
Jean Delvare wrote:
Everything looks OK as far as I can tell, except for battery.date. If
the string is returned directly be the UPS then I guess there's not
much that can be done though.
This is the date read from the UPS and as far as I can see, it is
read-only. Maybe it's writeable, but
Massimiliano Giorgi wrote:
when genericups start it write
parse_output_signals: SD overriden with ST
so I suppose that this setting was in use but (you are right) probably
is inefective
The above line was executed in the wrong place. We never get there when
commanding the UPS to
Seann Clark wrote:
[...]
output.voltage: 0
Apparently, the UPS is not reporting the output voltage when on line.
Does this change if you pull the plug? If so, we can probaly work around
that easily. In reality, the UPS is probably reporting the
'output.voltage', which will be identical to the
Or, if you don't have all of the prerequisite packages (autoconf,
automake, libtool, etc.) needed for building straight from SVN, you
can download an SVN tarball from our Buildbot page.
http://buildbot.ghz.cc/public/nut/
Check the first column for the [tarball] link - that should have a
[...]
Asking for UPS status [Q1]...
get_data_krauler: index [03], prefix [(]
- String: UPS No Ack (len = 10/128)
get_data_krauler: retry [UPS No Ack]
- String: UPS No Ack (len = 10/128)
get_data_krauler: retry [UPS No Ack]
- Unable to fetch string 3
get_data_krauler: connection failure
401 - 500 of 770 matches
Mail list logo
