> I am running openSUSE 10.3 with nut-2.2.0-20 installed. I have
> configured it as mentioned in /usr/share/doc/packages/nut/README.SUSE.
> on starting nut using "rcupsd start" i get following:
> #
> Starting NUT UPS monitor
> done
>
> Broadcast Message from [EMAIL PROTECTED]
> (somewhere)
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 bugrepor
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 l
>> 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
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'
>> Please upgrade to a more recent version first. I have to dig deep into
>> the old sources to help here, which is taking me too much time. If you
>> need more help, I suggest you first upgrade to at least nut-2.2.0.
> OK
> That mean I need to build from sources and somehow make it Debian
> compa
> Thanks for suggetions and keep me indumb about making of Debian packages:D
> I will try this package "nut_2.2.0-2_i386.deb"
> One little questionm, shoud I use newmge-shut driver? - my ups is quite
> old - more then 3 years, connected through serial cable.
Yes. The 'mge-shut' driver is schedule
>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
>applicat
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
Charles has answered most other questions, so I'll skip those.
> But when I run:
>
> upsd -u root
>
>
>
> I get:
>
> Network UPS Tools upsd 2.2.0-
>
> not listening on 192.168.0.20 port 3493
You apparently have configured a LISTEN address in 'upsd.conf'. Unless you
know exactly what you're doing,
[...]
> 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 pag
> 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 wha
>> 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
>> 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
>
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
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
> 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
> driv
> 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
s
> 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.
>
>> 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 no
> Hello all.
>
> I have now connected the UPS via a serial-cable to a PC running Debian
> Etch and Nut 2.0.4.
>
> When running "upsdrvctl -u root start" I get:
> Communications with UPS lost: Error executing command
> Communications with UPS lost: Error executing command
> Communications with UPS
>>> Adding 'baudrate = 9600' to the 'ups.conf' entry for this UPS should
>>> fix this.
>> Strange, it tells me this is not supported. I'm on 2.0.4.
> Ahh... It goes in the global section. Sorry.
No, it should be in the UPS section since it is a driver specific thing.
That is, if you fix the typo I
>> 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 bcm
>> This is done through the initialization of the bcmxcp driver. It doesn't
>> require you to do anything, other than running this driver at least once
>> with the UPS. After that, the UPS should remember this setting.
> This does not seem to be the case. Switching the UPS back to the machine
> set
> 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
>> 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 testi
> I just discoverd NUT and I'm lovin' it. I was very successful getting
> nut to monitor a CyberPower UPS along with having a Linux slave for a
> friend of mine. I've come to a snag on my personal system though. I
> currently have two Back-UPS XS 1200 APC UPSs, and I'm seeing
> notifications of lo
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 u
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 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.
> http://www.uno-code.com/files/nut.
> 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
> Now looking at the FAQ again, it offers the same snippet of code as the
> Install doc, but implies that it isn't needed just in case the bios - as
> mine does - has an "always power on when power's restored" option.
>
> If that implication is right, then does that mean that soon after the UPS
>
>> 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
> mor
>> 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 t
> 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
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
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 a
> Recently i bought a MicroDoWell BP50, and with it followed a USB 2
> serial converter. When i plug it into my 2.6.19 kernel, dmesg shows
>
> hiddev96: USB HID v1.10 Device [Cyber Power System CPS RS232 USB
> BRIDGE for UPS] on usb-:00:04.2-2
> usbcore: registered new interface driver usbhid
>> I believe there has been a regression with respect to nut and the
>> Tripplite SU1000RTXL2U. I can't get recent versions of nut to work with
>> this UPS, either the debian etch package--the host is running debian
>> etch--or a locally compiled version of the latest stable version of nut
>> (2.2
> 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
> On the bottom of the Belkin UPS unit - is the model number: F6C120auUNV
> The "au" is for Australia I think.
It probably is. We've seen other combinations here, like 'eu', 'uk' and so
on.
> "man belkinunv" states that F6C120-UNV is supported - and I assumed that
> the "au" would not prevent th
[EMAIL PROTECTED] wrote:
> Forgive me if this has been answered, but I searched the list, and the
> compatibility page on the nut site is unclear to me.
>
> Is the APC Back-UPS ES 500 compatible with nut?
According to the compatibility page, it looks like it is supported
through the 'usbhid-ups
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
Jon Bendtsen wrote:
> I gave up on using the USB converter and used a regular serial
> cable, it works fine using both the powerpanel and the cpsups
> driver. I prefer the powerpanel because the name is slightly nicer
> in the cgi.
Could you post the output of 'upsc ' here? We're working on
exten
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 s
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 dep
>> Could you post the output of 'upsc ' 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:
> ---
> I note though - that in my system - the usb device number seems rather
> erratic. Over the past day or so - the usb device number of the UPS has
> been increasing (possibly whenever I kill the processes trying to attach
> to it??) I am confident that i have not removed the connector or
> rebooted
> 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 atta
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.
> [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 re
> 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...
> s
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
t
> 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
> 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
>>> The output of "upsrw [EMAIL PROTECTED]":
>>> [battery.charge.low]
>>> Remaining battery level when UPS switches to LB (percent)
>>> Type: STRING
>>> Value: 10
>>>
>>> [battery.runtime.low]
>>> Remaining battery runtime when UPS switches to LB (seconds)
>>> Type: STRING
>>> Value: 120
>>>
>>> [
[...]
> 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, addre
>> The safest way to verify the above assumption, is to run the UPS without
>> load and see if it shuts off if you attempt to run it with an unmodified
>> 'usbhid-ups' driver. If it still does, comment out the line 117 as
>> follows in 'drivers/tripplite-hid.c' and build the driver again.
> I repea
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 fi
[...]
> 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 l
> 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.
> 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 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);
> 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 submitte
> On opensuse 10.3, i installed nut and configured my ups.conf like i did it
> on opensuse 10.2 by putting (10.3 , nut 2.2.0):
>
> [MGEpc675]
> driver = usbhid-ups
> port = auto
> desc = "MGEpc675"
>
> instead of (10.2 , nut 2.0.4) :
>
> [MGEpc675]
> driver = newhid
>> [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 'meg
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
> 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 a
> 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
Arjen de Korte wrote:
> # useradd -G uucp upsd
# usermod -G uucp upsd
Sorry about that... :-(
Best regards, Arjen
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/
>> # usermod -G uucp upsd
[...]
> Do you think i shall file a bug report about that ? Or is it a known bug
> about to be solved ?
I think this is a new one, so please file a bugreport. It probably won't
surface on older installations (like mine) where 'upsd' is already a
member of 'uucp'.
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 dri
> 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)
> di
> 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 discussion
> 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, you'
> 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
> 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
[...]
> Now that is a bit closer to the normal portion of what I should see. I
> am not sure if anyone out there in the group has seen the powerpanel for
> Linux stuff before, but using that as a baseline of the results from the
> reads on the binary stream back may be a way of tuning the driver.
[...]
> 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 forc
> 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 repor
>> 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
>>> 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 (startin
> Running usbhid-ups -DDD -a SMART1000LCD seems
> to go into an infinite loop unless the driver is supposed to
> send requests to the ups continuously.
The driver doesn't background when running in debug mode, so yes, this
loop will seem to be infinite.
> The values returned
> from the USB report
> 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
> The previous driver would stop by typing a CTRL-C when
> running interactively in debug mode. The new driver will not
> respond to a CTRL-C. It does not respond to a "kill -1",
> "kill -2" or a "kill -15" either (Which may or may not be
> OK).
It *will* respond to CTRL-C, but due to the increase
> I'm using nut 2.2.0 on FreeBSD 7.0-RC1. I've got two UPSes (Back-UPS RS
> 1500) connected to the host, and I often see them to go away. All the
> system logs are full of "Poll UPS [EMAIL PROTECTED] failed - Data
> stale".
First of all, it helps if you post the *full* line from the logs and also
[...]
> 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 s
Vladimir Stavrinov wrote:
> I have simple configuration: one master with one UPS connected
> via serial port, and five slaves. When battery is low and master
> set FSD on UPS, then after few seconds it get from all slaves:
> "disconnected (read failure)" and start shutdown and power off
> before s
> 1. Does upscmd provide only device-specific commands?
Usually, yes. See also 'man 8 upscmd'.
> Or commands
> like shutdown.stayoff are general and good for all ups models?
No.
> When i see output of 'upscmd -l' - is this general commands
> that supported by given device or this is unique comm
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
>> 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 'data/cmd
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
> drive
>> 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 [19
>> @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");
> ---
>>
> I have a Riello Dialog Plus UPS...
> someone knows how to configure nut for this UPS?
[...]
> All messages start with a and end with a ; all the messages
> from the application start with aand the response
> from the UPS with a
It doesn't look like anything familiar, so I don't think
> 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 con
> 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 ha
[...]
> 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 f
301 - 400 of 1026 matches
Mail list logo
