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,
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
# 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
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
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
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
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
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,
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
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].
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
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
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
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
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
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?
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
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
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
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
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
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
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,
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
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
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
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
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
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,
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,
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
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
Todd Woods wrote:
One UPS plugged into first USB port
-
[...]
-
Different UPS plugged into second USB port
--
[...]
This
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'
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
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,
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
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
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
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
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
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
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%
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 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
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'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
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:
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
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
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
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
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
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
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
101 - 200 of 770 matches
Mail list logo
