1) Does the shutdown sequence take too long?
Is it about 15 - 20 seconds (from usual system message about shutdown).
That's not an inordinate long time, so this should not be a problem.
2) How old are the batteries? Could it be they are already worn out (you
can expect this after 3-5 years
tovis wrote:
upsmon.conf using NOTIFCMD and NOTIFYFLG is working well, it is calling my
script notify on requested events (ONBATTERY,LOWBATTERY and ONLINE).
Command
#upsmon -c fsd -u monmaster [EMAIL PROTECTED]
gracefully shutdown my box and after several seconds switch off the ups's
Usuallly I'm using for this kind of controll strongly ASCII coding,
at least intel hexa (simple memory dump), but when so small amount of
information in could be more readable, not only for beauty but
debugging purposes. In this case you can use a simple terminal
application
Rózsa Gábor wrote:
Its became more difficult!
#upsdrvctl shutdown myups- does not work for me!?
#upsrw -s ups.delay.shutdown=5 -u monmaster -p blah myups- working
well, ups switch off after 5 sec of the command:)
#upsdrv -s ups.delay.start=5 -u monmaster -öp blah myups -
[...]
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
Using ondelay = 30 in ups.conf I have managed to wait more time after
the line power is back - other question why this so unreliable:( I have
measured time at 16 min upto 32 min (ondelay = 30 should give 30x10sec = 5
min) - but I do not care it is not so important for me.
This is not what
This is not what 'ondelay' is meant to do. Please checkout 'man 8
mge-shut' for a description of what the function of this is.
May I missing some thing? I read this carefully:
http://web.iesrodeira.com/cgi-bin/man/man2html?mge-shut+8
The 'ondelay' timer will be started at the same time as
The 'ondelay' timer will be started at the same time as the 'offdelay'
timer and is really only meant to provide a means to prevent a deadlock
when the power returns before the UPS shuts down. The better solution is
documented in 'docs/shutdown.txt' which you have been told to read on
several
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
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
I have updated to nut 2.2.0-1 as suggested. Unfortunately I still get the
same type of errors:
Network UPS Tools - UPS driver controller 2.2.0-
Network UPS Tools - BCMXCP UPS driver 0.11 (2.2.0-)
Warning: This is an experimental driver.
Some features may not function correctly.
Model =
Have you tried the serial connection?
No, there is no serial port on my machine.
If you have one, a serial-to-USB converter is a cheap solution to add one.
Many (not all) are supported by recent kernels.
1) Apparently, this UPS needs to be told only to reply to specific
requests and not send
You have been busy i see. OK it is possible to set the 9120 to requsted
mode only, and this is done by the serial driver part. And it should
remain so after power cycling.
How is this accomplished? Any chance of a step by step tutorial?
This is done through the initialization of the bcmxcp
I have a PW9120 hooked up via a serial cable running NUT 2.0.4.
When running upsc I cant see any parameter that looks like it would
trigger a shutdown. Theres is
nothing like battery.charge.low: 30 or battery.charge.warning: 30.
The UPS may not support reporting and/or changing this value.
In general, shutdown will be triggered when the UPS is both on battery
*and* reporting low battery. The latter may or may not be user
configurable. In your case, it looks like the driver has no way of
changing this level, so when this actually happens depends on the UPS.
So, for testing I
hanji wrote:
Thanks for replying to my email. I updated to 2.2.0, and I'm running
into the same problem, but also encountered other issues. After
upgrading to 2.2.0 and using the usbhid-ups driver, I was not able to
get a clean restart of upsd.
/etc/init.d/upsd restart
* Stopping upsd
hanji wrote:
Strange. Looks like my init script already does this:
start() {
ebegin Starting upsd
# clean up first
pkill -u root -x upsd
sleep 1s
rm -f ${pidfile}
# now start up
start-stop-daemon --start --quiet --exec
You trimmed off the initial (and most interesting) part of the startup
of this driver. Don't do that, unless we ask you to do so.
Okay..
Here is the output. I saved it to a file for better readability.
That is a lot more informative, thanks.
That is a lot more informative, thanks.
http://www.uno-code.com/files/nut.output.txt
Ouch, this really sucks! It looks like the feature reports for this UPS
are completely bogus and that we should only use the reports we get on the
interrupt pipeline for this unit (which seem to be
The best answer we can offer here, is to just try it out on your
specific kind of hardware. The proof of the pudding is in the eating.
Of course. The shortcoming being that running the UPS down that far would
take a few hours - at which point I start thinking asking around might be
more
I'm having a hard time configuring a Mustek Powermust 600VA ups to
work via USB with nut. I read somewhere that nut works OK via the
rs232 cable, but unfortunately I don't have a COM port in my computer.
The kernel detects the ups as an Xbox pad :) and loads the xpad
module. I tried
I was able to use megatec_usb with a Powermust 1000VA USB with the hal
driver activated (hald-addon-megatec_usb). If you are lucky, megatec_usb
will be able to recognize your ups if you force the agiler subdriver
in your ups.conf.
Here is my config:
sys-power/nut-2.2.0 with both hal and
Krzysztof Sasiak wrote:
I modified your config accordingly and now I get the following message:
Serial-over-USB transport layer for Megatec protocol driver
[megatec_usb]
debug level is '3'
Checking device (06DA/0003) (002/002)
- VendorID: 06da
- ProductID: 0003
- Manufacturer: unknown
Jimmy Jazz wrote:
I will follow your advice but i'm not sure the maintainer would agree.
That feature is deactivated in the package itself :)
That's OK. If NUT is compiled without HAL support, that's fine too.
To get out of trouble, how do i prevent hal to exclusively and
automatically
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
Richard Chapman wrote:
I have changed the driver in my ups.conf to usbhid-ups, and based on
other literature I have read - I set the port to auto, but at startup
i get the error:
Starting UPS driver controller: Network UPS Tools: 0.28 USB communication
driver 0.28 - core 0.30 (2.2.0-)
Richard Chapman wrote:
Also for Tomas Smetana of the epel repository
I think we are getting somewhere - but not quite to the final goal...
If I run:
/sbin/usbhid-ups -u root -D -a BelkinUps
as suggested it all works fine - and finds the UPS on the USB port. It
still does so if I
Tomáš Smetana wrote:
The drivers are supposed to run under user nut group uucp. Your
problem seems to be somewhere in the udev rules provided with the rpm
package -- they should change the ownership and permissions of the
appropriate USB devices.
Euhm, the settings in these files depend on
Could you post the output of 'upsc upsname' here? We're working on
extending the support for the powerpanel driver, but in order to do
that, we need some information on what is reported by devices that are
supported already. Thanks in advance.
powerpanel driver:
A big issue with auto-discovery is trust. You wouldn't want someone to
be able to randomly shut down machines on your network just by
starting a rogue copy of NUT.
Another problem is when you discover multiple UPS'es, which one you're
connected to? In a desktop system with only one UPS
Carlos Rodrigues wrote:
When you have only one UPS in your network, this might work. Otherwise,
one UPS going offline might cause all clients to shutdown. This is
probably not very desireable.
What I had in mind was more of a centrally managed configuration, than
no configuration. For
[EMAIL PROTECTED] /]# belkinunv -u root - -a BelkinSer
Network UPS Tools - Belkin 'Universal UPS' driver 0.06 (2.2.0-)
debug level is '8'
No response from UPS
No response from UPS
No response from UPS
No response from UPS
No response from UPS
No response from UPS
No response
Here's what I got from powerpanel:
./powerpanel - -a cyberups
Network UPS Tools - CyberPower text/binary protocol UPS driver 0.22
(2.2.0)
Warning: This is an experimental driver.
Some features may not function correctly.
debug level is '8'
Trying binary protocol...
send: (2
One thing to check is that if a UPS is equipped with both a serial and USB
interface, you can usually only use one at a time. Many use share the same
hardware for both interfaces, so when not in use, you should not plug in
anything to these ports. Switching between these may require switching off
I guess you are right that we learned something from running the driver
stand alone - but the debug level didn't seem to add as much verbosity
as it did with other drivers. I have checked on your suggestions:
Older drivers generally are less verbose than newer ones. Over time, we
have found
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
[...]
When I run the command
# ../bin/usbhid-ups -a igor -DD -u root
it produces the long output which is attached below.
Then the machine crashes. I think the UPS just turns off
the power. The log file contains the line
Dec 4 16:05:26 computer kernel: usb 2-2: USB disconnect, address 2
Arjen de Korte wrote:
That's great! It doesn't look like we have an active maintainer for this
subdriver at the moment, so I'll commit a change to the development
version of the 'tripplite-hid' driver later today. It probably is a bug in
the UPS firmware that is quite specific to this model
[...]
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
http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-September/003137.html
http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-July/003014.html
http://permalink.gmane.org/gmane.comp.monitoring.nut.user/2552
I still have this problem:
$ dpkg -l | grep -i nut
ii nut
For any who don't know:
Voltage is an insufficient indicator of { health, time to support
load, of if batteries will even support the load at all } . Internal
resistance is important to calculate, but imperils load while
testing to calculate (***).
Thanks for the reminder.
I
Is this available in unstable (the dev-version with the fix/if not what is
the ETA and also the ETA for 2.2.1 in testing)?
You can download a tarball (both for 'development' and 'testing') from
http://buildbot.ghz.cc/public/nut/
The ETA for nut-2.2.1 (stable) is 'shortly', I really don't
[...]
What 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 submitted
[snip] Either way, I'll know
what's needed, if an option to interpret the OFF bit the other way
around, or just ignore it.
I've just commited a workaround for this in the development trunk.
Just add ignoreoff to your ups.conf and it should do the trick.
Still I think the 'megatec' driver
Carlos Rodrigues wrote:
Therefor, I propose to relax the interpretation of the status bits in the
'megatec' driver, to allow the interpretation of 'OL' and 'OB', even if we
already think/know the output is switched off.
No problem by me, but should I keep the OFF status together with
Thanks for your quick reply and sorry for my late reply because i could
not access the concerned computer since then.
To answer your question :
$ rpm -q nut
nut-2.2.0-20.2
That should be the most recent version.
The system is up to date and there is still nothing new. Or is there any
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
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
I also discovered that the log file is getting filled up with these
errors:
-
Jan 2 22:38:19 www kernel: usb 1-2: usbfs: process 24538 (megatec_usb)
did
not claim interface 0 before use
Jan 2 22:38:19 www kernel: usb 1-2: usbfs: process 24538 (megatec_usb)
did
not
Is there something I am doing wrong right off the bat? If not, is there
anything I can do to debug this, or help this UPS get supported?
[...]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
You could search the mailinglist archives for instance, we've had quite
some discussions
Is there any driver that does have any kind of support for my UPS over
USB? In the archives I can't find anything else.
As far as I know, no. It is reported to work with the 'genericups
upstype=7' driver over the RS232 interface (contact closure). If you don't
have serial ports available,
Apologies for the number of emails; I just tried starting as user root and
the error message changes but the outcome is the same:
---
[EMAIL PROTECTED] drivers]# /sbin/upsdrvctl -u root -D start
Network UPS Tools - UPS driver controller 2.2.0-
Starting UPS: unial1200
exec:
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
[...]
Is there an equivalent to -x wait when using the same UPS with the
'usbhid-ups' driver?
I don't think this will be needed with the usbhid-ups. Why don't you just
try this out? Pull the mains plug from the UPS (it will now run on
batteries) and type
# upsmon -c fsd
This will force
Does the following error message have a specific meaning:
usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2
ret -75
[...]
Can't retrieve Report 49 (75): Value too large for defined data type
The UPS is sending us here more data than we expect. The size of reports
Using subdriver: TrippLite HID 0.2 (experimental)
Startup timer elapsed, continuing...
===
Is this an error ? Shouldn't the driver usbhid-ups be referenced here
when my conf file is:
That is the output of usbhid-ups (starting from the line
After updating from 2.2.0 to 2.2.1, the following command
seems to go into loop and becomes unresponsive except for a
kill -9:
/lib/nut/usbhid-ups -u root -DDD -a trippy
Running the driver in debug mode has always prevented it from
backgrounding, so nut-2.2.0 would also require a 'kill -9'
[...]
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
Seann Clark wrote:
I know others have seen this before, I just never saw any real
resolution to it. I am not a programmer, or at the least a very bad one,
so I don't think this is something I can do properly myself.
I have a Cyberpower 1500 AVR rack mount that worked good, except for the
Usually drivers attempt to determine if a command is valid, before
registering it.
So, there is a big set of NUT commands, like shutdown.stayoff and others,
and driver for specific device supports some subset of them and this
subset i can see in 'upsmcd -l output' ?
Yes. See
Charles Lepple wrote:
Actually, it's getting that from the same place as last time.
Apparently the --without-snmp switch doesn't turn off Net-SNMP
detection, it just controls which drivers are built. (And IMHO the
Net-SNMP flags shouldn't be used in anything other than the NUT SNMP
driver,
Anyway, I've modified upsmon to call wall -a instead of wall and it
now does what I want.
Do you (or anyone else running Solaris) know if this behavior changed
in Solaris 10?
I've traced back the man page for the 'wall' command back to Solaris 2.4
(the oldest I could find online [1994]).
@Huge: Could you post a diff for the change you made?
Not the biggest change in the world
I didn't expect it to be, but it is better to be sure.
[EMAIL PROTECTED] ~/Prog/nut/nut-2.2.1/clients]: diff upsmon.c upsmon.c.orig
125c125
wf = popen(wall -a, w);
---
wf =
I have a Riello Dialog Plus UPS...
someone knows how to configure nut for this UPS?
[...]
All messages start with a STX and end with a ETX; all the messages
from the application start with a STX SPACE ! and the response
from the UPS with a STX ! SPACE
It doesn't look like anything
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
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
Carlos Rodrigues wrote:
If the driver fails to get any data in the current polling cycle, it
declares the data as stale until the next cycle. It tried to read the
data, it got nothing, ergo the current data is stale.
That's a bit too harsh. Even serial communication is sometimes plagued
by
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
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
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
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
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
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
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
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
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
[...]
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,
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
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
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
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 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
201 - 300 of 770 matches
Mail list logo
