Justin Piszcz wrote:
$ ./configure --with-user=nut --with-group=nut
--prefix=/app/nut-trunk-1091
checking sys/time.h presence... yes
checking for sys/time.h... yes
./configure: line 5460: NUT_TYPE_SOCKLEN_T: command not found
./configure: line 5461: NUT_TYPE_UINT16_T: command not found
I've having trouble understanding the NUT compatibility page.
Is it compatible with the OMNISMART300? Or the OMNI900LCD?
The compatibility page said for instance
SMART550 -- tripplite_usb
SmartUPS -- tripplite
OMNI650LCD -- usbhid_ups
so I'm not sure if an OMNISMART300 is like a
Upon upgrading to the Debian package of NUT 2.2.0 my APC Back-UPS Pro is
no longer recognized. Here is the output if I try to run the driver
manually:
---
# /lib/nut/usbhid-ups -DDD -x vendorid=051d -x productid=0002 -a
foxstarups
You don't need the 'vendorid' and 'productid'
Todd Woods wrote:
One UPS plugged into first USB port
-
[...]
-
Different UPS plugged into second USB port
--
[...]
This
Bus 003 Device 002: ID 050d:1100 Belkin Components
# /lib/nut/usbhid-ups -a belkin
Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30
(2.2.0-)
No matching HID UPS found
Hmm best to stick with 2.0.4.
No. Just run the driver in debug mode and you'll see what you
Tuc at T-B-O-H.NET wrote:
It claims there are 2 signal configurations (But nothing about
how to tell which yours has... )
Type I:
Pin 2 - AC Power Failure
Pin 4 - Common Ground of 2,5,6
Pin 5 - UPS Battery Low
Pin 6 - Turn off UPS
Type II:
Pin 2
Tuc at T-B-O-H.NET wrote:
Anyone have any experience with these ???
http://cgi.ebay.com/UPS-1000VA-Brand-New_W0QQitemZ280141461506QQihZ018QQcategoryZ99265QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
According to this website, it supports
# Interface 9Pin D-type Connector:
AC fault,
Tuc at T-B-O-H.NET wrote:
Anyone have any experience with these ???
http://cgi.ebay.com/UPS-1000VA-Brand-New_W0QQitemZ280141461506QQihZ018QQcategoryZ99265QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
According to this website, it supports
# Interface 9Pin D-type Connector:
AC fault,
Uh ho.there is a new problem with this new driver (usbhid-ups), on
power failure and battery low, with newhidups (version of debian package),
the ups shuted off after the computer, no it doesnt shut offwhere is
this parameter ?
You built from source, did you? Chances are you missed
[EMAIL PROTECTED] wrote:
Installing from debian package solved the problem !
That's good to hear. Great!
I've a little question: does the installation of MGE P2P allow you to
configure more parameters than upsrw ?
When it comes to the non-Windows version of the software, as far as I
know,
upsd[12452]: Data for UPS [tripplite] is stale - check driver
tripplite_usb[12450]: Reconnect attempt #1
tripplite_usb[12450]: Successfully reconnected
I forget how MAXAGE works, but if you can fix this by increasing
maxage, you probably want to figure out the time difference between
the
[EMAIL PROTECTED] wrote:
Hello !
I've just a problem with upsd/upsmon 2.0.4, please have a look at the
upsc command:
[...]
Look at the line output.voltage, the value is 0, i don't understand, what's
the problem ?
First of all, the 'newhidups' has seen many improvements since
Another thing I wonder about is that both UPS don't give me value for
battery.runtime.low and both give an ups.status WAIT although there
running fine.
This isn't good. :-(
The ups.status WAIT is a placeholder status that is inserted by the
server while it is still waiting for the driver to
Paul Mogren wrote:
I did not have any success with adding a delay between
startup of driver and server.
Did you add a *really* long delay, like 60-120 seconds or so?
Yes, I am using openSUSE 10.2. Thanks for the RPM
offer. I'll take you up on it; you can send it to this
email address if
Justin Piszcz wrote:
Beats me, I'm not the author of this driver. But now that nut-2.2.0 has
been released, you should first check if the problem still exists in
that version. We've had quite some changes since nut-2.0.5 came out, so
chances are the problem no longer exists.
In the mean
Justin Piszcz wrote:
# /lib/nut/newhidups -u nut - auto -x productid=1100
[...]
Checking device (050D/1100) (003/002)
- VendorID: 050d
- ProductID: 1100
- Manufacturer: Belkin
- Product: Belkin UPS
- Serial Number: unknown
- Bus: 003
Trying to match device
This particular
[...]
That works, question is, why do I have to specify a productid with the new
version when the previous previous never had this problem?
The previous version ( nut-2.0.5) would only check if the vendorid
(Belkin, 050d) matched and didn't look at all at the productid. So if you
would have
upsd appears to send the FSD command to the UPS, upsmon then runs my
NOTIFYCMD (which halts my PC) but the UPS just doesn't turn off.
Here are the /var/log/daemon.log entries:
I have seen a similar problem with usbhid-ups on an MGE Pulsar
Evolution with Ubuntu 7.04. The machine shuts down on
I am thinking about using the existing NUT software to tell the slave
servers to shutdown if the temperature in the server room becomes too
high.
If your UPS has a temperature sensor, that's possible. You could script
something that polls 'ups.temperature' every minute and call 'upsmon -c
Paul Mogren wrote:
Sorry, I forgot to CC the list.
--- Paul Mogren [EMAIL PROTECTED] wrote:
Which version of NUT is this? This shouldn't
happen
anymore with nut-2.2.0.
I'm using a SUSE-managed package which is based on
nut-2.0.4. I didn't find a 2.2 RPM for SUSE, so I
guess I'd have
I'm using NUT with an MGE Ellipse USB, which I
understand to be rather slow to respond. Every time I
start the NUT services, I get the Communications
lost notifications at first, but then it starts to
work normally.
Which version of NUT is this? This shouldn't happen anymore with nut-2.2.0.
I have a plan to do the same thing. The approach I was going to take is to
use several fake ups units that use contact closure style drivers. The use
a contact closure from the temp sensor to send the fake UPS units into LB
status. If the are fake units and all servers monitor for these in
[...]
Is the shutoff working otherwise (ie calling upsdrvctl -k (CAUTION: no
sensitive load on the UPS; only light bulbs or alike))?
We have no '-k' option in upsdrvctl. The proper command to test this is
either
upsdrvctl shutdown upsname
or
bcmxcp_usb -a upsname -k
Best regards,
Do you really need a fake thing?
No.
cant you fake it in software and once the temperature goes too high you
just run a script which hooks into NUT and sets the TemperaturUPS to NO
battery or something and shut it down using that? I was planning to use
lmsensors to monitor the temperature
If not, you could still use a 'fake' UPS that is monitored by your upsmon
master and use the NOTIFYCMD to create a flag that prevents 'upsdrvctl
shutdown' from being called.
Or even easier, by using the undocumented '-f configfile' option for
upsmon, to specify an alternate upsmon.conf file,
Alain Williams wrote:
I ran strace on the upsd process and what I get is below.
Usually, running strace is only used as a last resort, if adding the
-D option doesn't provide sufficient output. Since this is a
communications problem between the server and the client, we probably
need them
Ciprian Marius Vizitiu wrote:
I've just read the FAQ and got to the question: Q: How can I make upsmon
shut down my system after some fixed interval? Well it looked like the
question was there for me. :-)
You say:
Ask yourself this: why buy a nice big UPS with the matching battery and
[EMAIL PROTECTED] wrote:
Hello Arjen,
Sunday, June 24, 2007, 8:44:04 PM, you wrote:
What I would like to know, is what is read from the UPS. The output of
'upsc' can help here.
Let me know if you need any other data. IIRC, it sends that info back
everytime the ups is polled.
I meant
Ciprian Marius Vizitiu wrote:
SERVER=yes
MODEL=apcsmart
DEVICE=/dev/ttyS0
OPTIONS=
Please change to
MODEL=upsdrvctl
DEVICE=
OK, done. But it looks like there is a small bug in nut's FC6 init scripts
which prevents this config from working with restart.
Since
What I would like to know, is what is read from the UPS. The output of
'upsc' can help here.
Let me know if you need any other data. IIRC, it sends that info back
everytime the ups is polled.
I meant the readings from the UPS Varain has, to see if the reading of
'output.voltage' when on
Ciprian Marius Vizitiu wrote:
Hi everyone,
Here I am with my second attempt to persuade upssched to do things; for some
reasons it just won't! Or if it runs, it never runs the script.
OK, the story first: 2.0.3 (conveniently comes as RPMs by default on FC6)
running on FC6; APC Smart-UPS
after this it seems to work ok, even if it the numbers reported for
input voltage look a little low.
(205 to 211 in a country where nominal voltage is supposed to be 230).
Maybe it's just lousy power.(I have no easy way to verify)
I noticed that another (probably unrelated) driver scales the
My ups (MicroDowell BP 1000) reports something like this :
battery.capacity: 7
battery.charge: 100.0
battery.charge.low: 20
battery.packs: 2
battery.voltage.nominal: 12
driver.name: powerpanel
driver.parameter.port: /dev/ttyS0
driver.version: 2.0.5
driver.version.internal: 0.12
Thank you, but for now I'll try the powerpanel driver (as Arjen advised).
I'll let you know if things work out.
Good. Although the powerpanel driver has improved significantly between
2.0.5 and 2.2.0-pre1, I don't think it is worth the effort to switch to
the new version.
As an experiment, if
As an experiment, if I compile just the driver from 2.2.0-pre1 (with the
required options), can I expect it to work ? (assuming the problem was
solved in this version)
Assuming you're coming from version 2.0.5, this will work. It won't be
compatible with earlier versions, since we changed the
First: when I connect UPS APS Back UPS Pro 650 to the same port - nut
works.
In ups.conf:
[apc]
driver = apcsmart
port = /dev/cuaa1
desc = UPS
cable = 940-0095B
sdtype=0
Second:
[EMAIL PROTECTED]/megatec -DDD /dev/cuua1
Network UPS Tools - Megatec protocol driver 1.5 (2.0.5)
Carlos
[EMAIL PROTECTED]/usr/local/libexec/nut/megatec -a apc -k
Network UPS Tools - Megatec protocol driver 1.5 (2.0.5)
Carlos Rodrigues (c) 2003-2006
Initiating UPS shutdown
Shutting down UPS immediately.
But it still working and send current to output.
We've seen similar reports lately. My
It's strange, but I just change from /dev/ttyd1 to /dev/cuaa1 and it
continue work.
Sure. But that is not what you wrote in your example:
Second:
[EMAIL PROTECTED]/megatec -DDD /dev/cuua1
Can you see the difference?
Best regards, Arjen
--
Eindhoven - The Netherlands
Key fingerprint - 66
What makes you think these are false alarms?
I have 2 reasons for believing these are false alarms:
1) The UPS doesn't beep and none of the status leds change when this
occurs. I configured nut to page me for 'on battery' events, and while
working in the server room I witnessed how NUT
Network UPS Tools - UPS driver controller 2.0.5
Network UPS Tools - Megatec protocol driver 1.5 (2.0.5)
Carlos Rodrigues (c) 2003-2006
Megatec protocol UPS not detected.
Driver failed to start (exit status=1)
How to solve this problem ?
Maybe it's a permissions problem with /dev/cuua1?
I saw that nut runs a ups shutdown sequence before the server shuts
down.
Yes. It looks like your UPS doesn't respond to that at all.
If i run upsdrvctl shutdown nothing happens. For a moment the link with
the ups is lost but after several seconds it connects again as if
nothing happened.
I'm using the megatec driver with a noname brand of ups (it says
upguards pro 1400 on it)
The manufacturer is probably Sysgration. See the following links:
http://www.sysgration.com/ProdImage/P_49_9.pdf
http://www.sysgration.com/power/imgaes/Pro_Series.pdf
The enclosures look
If all else fails, your could use a method that is described in the FAQ.
After sending the 'upsdrvctl shutdown' command in the halt script, wait
for about 10 minutes and then reboot. If the UPS is really on battery,
this is probably sufficient to drain the batteries completely and make
it
I've installed Nut (2.0.5) on RedHat a week ago, and upsmon seems to
generate false alarms every hour:
...
Jun 8 06:10:56 nutevalserver upsmon[2849]: UPS
[EMAIL PROTECTED] on line power
Jun 8 06:35:46 nutevalserver upsmon[2849]: UPS
[EMAIL PROTECTED] on battery
Jun 8 06:35:51
Alex Girchenko wrote:
Disclaimer: I've setup APC UPS monitoring and it works...
... but when it comes to mustek powermust 600usb (connected via
com-port), I can't make it work.
Got NUT installed via aptitude in ubuntu feisty and a basic setup,
exactly the same as for the apc, except for the
Dear Network UPS Tools developers,
Sorry for this mail, but we have some question!
Maybe you can help us. Did you product NUT supported Mustek
PowerMust 800VA UPS??? We have some problem with this model. All work fine
but when we start
use upsmon it don't shutdown our server correct. First
Are you saying that an unprivileged user
cannot execute upsdrvctl shutdown ?
Yes. Even when ups.conf is readable by that user. The 'upsdrvctl' won't be
able to send a signal to another process owned by another user, if it is
not running as a privileged user ('root'). If someone manages to
FORMER 03 | Baltasar Cevc wrote:
we have three MGE UPS'. I've read all the documents I've found, but
I haven't got the information I need.
All three of them being attached to the same machine I need a way to
identify which is wich (all three use the same driver). They power
different systems
I had a brief power fluctuation earlier, which caused the UPS to power up
a few seconds. Then suddenly NUT was busy shutting down my server, after
full power had already been restored.
This is not a bug.
Here's the logs:
Jun 6 13:28:30 hell upsmon[607]: UPS [EMAIL PROTECTED] on battery
Justin Piszcz wrote:
I frequently login via upsc to check my UPS statistics, but it pollutes
syslog:
Jun 2 20:02:03 p34 upsd[3811]: Client on 127.0.0.1 logged out
Jun 2 20:05:01 p34 upsd[3811]: Connection from 127.0.0.1
Jun 2 20:05:01 p34 upsd[3811]: Client on 127.0.0.1 logged out
Jun
Here's what's happening when i try to start the ups daemon:
[EMAIL PROTECTED] log]# [EMAIL PROTECTED] all]# service ups start
Starting megatec: Network UPS Tools - Megatec protocol driver 1.5
(2.0.5)
Carlos Rodrigues (c) 2003-2006
Megatec protocol UPS detected [ Pro 1400 4.01p].
I noticed that NUT itself keeps the disks from spinning down in the NUT
server because it keeps logging the user logins and logouts to the syslog.
I'd like to request that the common logging facility be amended to include
levels of notification so I can choose to only receive errors or all
May 24 12:18:37 snark kernel: [136718.407859] usb 3-2: usbfs: process
26061 (megatec_usb) did not claim interface 0 before use
How do I troubleshoot this?
not a big trouble, but we are still having sometime such msg.
this claiming lies in drivers/libusb.c-libusb_open()
Is it easily
Arjen de Korte [EMAIL PROTECTED]:
Generally it is a good idea to run the driver in debug mode and see what
it is reporting then.
megatec_usb -u root -D -a upsname
Looks like I'm going to have to write a troubleshooting guide...
We could sure use that.
[EMAIL PROTECTED]:/home
I have a Liebert UPSTation GXT UPS and i'm trying to get it to work
with NUT(using a Multilink serial cable) but without any success so
far. I am aware about the liebert contact-closure driver but this
does not suit my needs as I need to get detailed status on the ups
(voltage levels,
Arjen de Korte [EMAIL PROTECTED]:
This looks a lot like problems with setting the access controls or on
the upsd server. Could you post the contents of 'upsd.conf' and
'upsd.users' here or in a private message? This certainly has nothing to
do with the driver.
-- upsd.conf
Eric S. Raymond wrote:
But now I've got different troubles. Trunk no longer detects the UPS.
[EMAIL PROTECTED]:/home/esr/svn/nut/trunk# /usr/bin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.1.0 (916M)
Network UPS Tools 2.1.0 (916M) - Megatec protocol driver 1.5.3
works now!
thanks a lot
Thanks for your efforts in debugging this issue. This is what we need in
order to make sure that the code we write is portable, at least for the
platforms we intend to support.
Best regards, Arjen
___
Nut-upsuser mailing
Belkin F6C1200-UNV on Ubuntu 7.04, megatec_usb driver,
Every few minutes I get a beep and a UPS not available message that
seems to be bogus; upsc reports real data, not at complaint that it's
stale.
What's in the logfiles? Is this message generated by the driver, the
server or the client?
Eric S. Raymond wrote:
Arjen de Korte [EMAIL PROTECTED]:
What's in the logfiles? Is this message generated by the driver, the
server or the client?
Which log is relevant? /var/log/messages or something else?
The syslog. Where that resides, depends on your local configuration,
although /var
Eric S. Raymond wrote:
Many repetitions of this message with different timestamps.
May 23 11:25:51 snark upsmon[26084]: Poll UPS [EMAIL PROTECTED] failed -
Write error: Bad file descriptor
May 23 11:25:56 snark upsd[26065]: Rejecting TCP connection from 192.168.1.11
May 23 11:25:56 snark
I was able to connect to upsd with telnet:
$ telnet localhost 3493
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET UPSDESC Z2UPS
UPSDESC Z2UPS z2 power
GET VAR Z2UPS UPS.STATUS
VAR Z2UPS UPS.STATUS OL CHRG
with upsc I still get an error:
#
Arjen de Korte wrote:
Could you try the version from SVN = r906 again?
That should have read SVN = 907. It's obvious that I didn't get too
much sleep last night... :-)
Best regards, Arjen
___
Nut-upsuser mailing list
Nut-upsuser
I can only suggest to try running
megatec_usb -a ups_name
(with some -D options probably) to ensure that it does the same thing as
upsdrvctl...
The worst thing is that '-D' option of upsdrvctl doesn't actually
show debug info...
That's by design. Using 'upsdrvctl' implies backgrounding
Zoltan farkas wrote:
yes IPv6 was enabled,
So I recompiled without ipv6 and now it works.
Somehow that doesn't really surprise me. What is interesting, is why the
IPv4/IPv6 code fails on your system.
here is the output with ipv6 enabled(latest revision):
Please mention the revision
Zoltan Farkas wrote:
Sorry about the truss output,
Thanks a lot for your help in resolving this matter! We really
appreciate this.
Here is the return for point 1:
# ./upsd -4 -DDD
Network UPS Tools upsd 2.1.0
listen_add: added 127.0.0.1:3493
listen_add: added 192.168.1.8:3493
# truss ./upsd
Can you try this again with -DDD? It's hard to match the system
calls to source code, and I'm not very familiar with Solaris or truss
anymore.
I forget, is IPv6 enabled in the NUT ./configure script?
It is, otherwise it wouldn't show 'setuptcp: try to bind to 0.0.0.0 port
Eric S. Raymond wrote:
The F6C1200-UNV has a serial port. The F6C550-AVR does not. I'd like
a USB solution so I can apply it to both units.
You had better checked that out *before* buying these units. :-)
Over USB, maybe they are supported by the megatec_usb driver that's
in the trunk, or
Thanks for the quick response.
I'm using the one that comes with Ubuntu Feisty: 2.0.5-1
(http://packages.ubuntu.com/feisty/admin/nut)
I'm not that familiar with Unbutu, but since you're using a fairly recent
NUT version, my guess is that the problem is in the Unbutu halt script
and/or in the
I'm looking for people that are using the 'cyberpower' driver that has
been available for some years now. It seems the overhauled 'powerpanel'
driver could support your UPS too.
The commands and status bytes used are identical, the only difference
being the way the values read for battery charge,
I've got a setup with NUT, where we've got two UPSes,
ups1 and ups2. UPS1 supports our servers, while UPS2
supports our desktop boxes. We monitor both of them
via USB on a box now called upsmon.
The interesting point comes here. We monitor both
UPSes on the upsmon box, but if UPS2 fails,
upsc:
battery.charge: 97.47
battery.runtime: 600.000
battery.voltage: 0055.20
battery.voltage.nominal: 0048.00
driver.name: upscode2
driver.parameter.port: /dev/ttyS0
driver.version: 2.0.5
driver.version.internal: 0.84
input.voltage: 0230.20
input.voltage.maximum: 0276.00
I notice from the hardware compatibility list that the XR model is
supported - what are the chances that the older R3000h models are too?
Apparently, this is a rackmount Powerware 5119 which is supported by
'genericups upstype=15' in dumb mode. Google tells that in smart mode,
this UPS speaks
The compatibility list in the SVN repository trunk mentions that the
T1500h needs the use_pre_lf option. Did you find that this was
necessary for your UPS?
No, I didn't use that option. Mind you, I have not yet fully tested
everything - I still have a few things to configure, do a complete
This list is for the Network UPS Tools (NUT) software, but this log
looks like it is from something else entirely.
The RPMs listed on rpmfind.net for RH9 seem very old, so you will
probably need to compile from source:
http://www.networkupstools.org/source.html
Then, since your UPS is not
THANKS, but the 'megatec' driver only works whith windows OS via USB,
and i need it for red hat OS with USB-serial connection...
No need to be upset, what Arjen de Korte was referring to was that the
ups use the megatec protocol.
Yes. And since you appear to be using a USB-to-serial
Tor Sjøwall wrote:
After updating from NUT 2.0.3 to 2.0.5 I got this error from upsd
during startup:
Can't connect to UPS [myups] (myups): No such file or directory
The problem was that newhidups created a pipe on
/var/run/nut/newhidups-auto while upsd was looking for
/var/run/nut/myups.
There is a memory leak in newhidups. After 23 days uptime it used 138M
memory. Apart from the memory leak, the system works ok.
Is there anything I can do to help fix this problem?
Sure. Please upgrade to the latest version and see if the problem still
exists. The version you're using now is
Theo G. Kanter wrote:
Thank you Arjen for pointing this out. After reading up on the man pages,
I also fixed the MONITOR line in upsmon.conf to pointing to [powerware] as
defined in ups.conf.
Ooops. I missed that one, but you've found that out yourself already. Good!
So I redid this having
Hello,
I installed NUT and configured it for 2 MGE UPS's connected via USB.
Debian etch NUT package:
# dpkg -l nut*|grep ^ii
ii nut 2.0.4-3The core system of the nut - Network UPS Tools
ii nut-usb 2.0.4-4USB Drivers subsystem for the nut - Network UP
Before anything else,
Hello,
I have two SAIS connected to one linux box. I want to monitorize the two
sais, but the NUT only can monitorize ONE. I configure the port in auto
in ups.conf but it only see one.
[MGE1]
driver = newhidups
port = auto
[MGE2]
driver = newhidups
port
Charles Lepple wrote:
Therefore, you might need to go to the source of the upsc output,
which involves printing the debug information from the driver (adding
-DD to the command line). You may need to wait for more specific help
from Peter or Arjen, but in the mean time, you might want to look
Charles Lepple wrote:
Arjen, could you please take a look at this?
from 'svn blame' on server/access.c:73:
737 adkorte-guestreturn (IN6_IS_ADDR_V4MAPPED(ip6)
737 adkorte-guestconst u_int32_t *)ip6)[3]
prefix) == net-s_addr));
Is there a more
Charles Lepple wrote:
I thought the error that Zoltan saw might have been due to the next
line (the const u_int32_t bit), but I don't have a Solaris box to
test.
This could also be the case. We don't use 'u_int32_t' anywhere else in
the sources, so this probably should be replaced by
Does the problem occur frequently? The more details, the better.
from there, 3 possibilities (need more details to audit):
- if the problem occurred only once, then you've seen a battery test,
- else you have some electrical problems upstream,
- else the UPS has some internal problem.
A
[EMAIL PROTECTED] wrote:
I can confirm that there is no problem with the UPS and the power line is
stable. I have attached the relevant log file for a run.
Please try if adding the following lines to 'ups.conf' make any
difference (you'd need to restart the driver in order to make these
ups.conf is:
[EMAIL PROTECTED] rules.d]# cat /etc/ups/ups.conf
# UPS Conf for NUT
[pulsar]
driver=newhidups
port=auto
desc=Pulsar M2200 RT3U
# vendorid=0463
# offdelay = 180 s
offdelay=180
# ondelay = 30 x 10 = 300 s
Marc Rechté wrote:
I checked the ups.conf and newhidups man pages and could not locate the
pollfreq parameter. Do you mean pollinterval ?
I meant just what I said. For 'newhidups' this is an undocumented
feature, while it has been documented for it's successor, 'usbhid-ups'.
Best regards,
Done. If you pull the latest version from the SVN trunk, the usbhid-ups
driver should detect your UPS. Could you let us know if everything works
as expected, so that we can add this UPS to the list of supported
devices?
# ./bin/upsc [EMAIL PROTECTED]
battery.charge: 100
Do you have a chance to switch off the mains to the UPS for a while
(without causing too much grief to the systems it is powering)
I'll be glad to test this (and post the upsc data) when I return to
work tomorrow.
These problems may actually be caused by the driver. It contains logic to
Is it possible/advisable to put NUT into production with newhidups
running in exploratory mode?
I'm probably not the most knowledgable person with regard to the newhidups
driver, but I think something in the line of
newhidups -u root -x productid=4002 -x vendorid=09ae -a tl6000
might
Kevin DeGraaf wrote:
# newhidups -DD -u root -a tl6000
Checking device (09AE/4002) (001/003)
- VendorID: 09ae
- ProductID: 4002
- Manufacturer: Tripp Lite
- Product: TRIPP LITE UPS
- Serial Number: 9533alcps585700043
- Bus: 001
It looks like your UPS is using a different product ID than
When my kernel oopses (not ups/nut related) nut is somewhat upset and
keeps complaining that power is gone, and restored, etc, etc, etc.
How can I fix this?
Which NUT version? UPS connected through serial or USB? Operating system?
What is the reason the kernel oopes? Is this a one time
When my kernel oopses (not ups/nut related) nut is somewhat upset and
keeps complaining that power is gone, and restored, etc, etc, etc.
How can I fix this?
Which NUT version? UPS connected through serial or USB? Operating
system?
What is the reason the kernel oopes? Is this a one time
Please start by providing some information. What NUT version are you
using, what driver?
The FC6 binary for 2.0.3-2.1.
I use the Mustek PowerMust driver with a Sweex UPS.
Before trying anything else, upgrade to nut-2.0.5. There have been many
bugfixes since nut-2.0.3, including problems with
Udo van den Heuvel wrote:
If I start the daemons manually, following the info at
http://www.networkupstools.org/doc/2.0.1/INSTALL.html The programs start
OK, no error there.
How can I automate this? Why don't the scripts work OK?
Which script did you use? I can only guess that the script is
If I start the daemons manually, following the info at
http://www.networkupstools.org/doc/2.0.1/INSTALL.html The programs
start
OK, no error there.
How can I automate this? Why don't the scripts work OK?
Which script did you use?
The standard scripts that come with the rpm.
We, the NUT
I tried building nut 2.0.5 pre2 from source using the user=nut and make
usb options, and got the same results.
That's an old version, please don't use that anymore. The latest stable
version is nut-2.0.5. Furthermore, you should specify the same '-u user'
for both upsdrvctl and upsd.
It
The latest version available packaged for Debian that I can find on the
Debian site is 2.0.5-3, the one I've previously had trouble with.
The problems you have don't seem to be related to the anything wrong with
the code, but rather with the configuration. So I'd go with the packaged
version
A.Lizard wrote:
Basically, you need to pass the same system user to -u on both the
driver and upsd.
How?
See 'man 3 upsd'.
Best regards, Arjen
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
601 - 700 of 770 matches
Mail list logo
