thanks for this update Arjen.
so there are chances that this has been backported in Testing /
2.2.2-pre1 (released today).
Can you (the bug reporters) grab this, call configure as per the
packaging/debian/rules, make and test from the build dir?
-- Arnaud
___
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
Carlos,
is this bug a known regression of 2.2.1 vs 2.2.0?
I can't find much in the ChangeLog.
https://bugs.launchpad.net/bugs/209001
thanks,
-- Arnaud
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mail
Arjen de Korte wrote:
> This is a known problem that is fixed in the development version and
> that will be fixed once nut-2.2.2 is released. Until then, don't use
> nut-2.2.0 if you experience this problem or run the development version.
> We're sorry about the inconvenience.
I has installed nut-
> We can't (and won't) reliably do that. The ranges for fixed/unfixed values
> overlap. If you conditionally adjust values based on the readings, you'd
BTW I now remeber last time I run the battery down test and at 20% of the
capacity it went down to 17.1 (unfixed) but I haven't measured the
batte
HI
I didn't know the ranges overlap :(. Maybe I can have some solution
based on remaining capacity percentage of the battery and its expected
voltage, they are somehow in correlation, I think there has to be a
way to detect wrong battery voltage automatically and reliably...
In the meantime I hav
> 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 va
Network UPS Tools version 2.2.2-pre1 has been released.
http://www.networkupstools.org/
Direct access:
- Download:
http://www.networkupstools.org/source/2.2/testing/nut-2.2.2-pre1.tar.gz
- News: http://www.networkupstools.org/source/2.2/testing/new-2.2.2-pre1.txt
- ChangeLog: http://www.network
HI
Yes, I mean this is quirk of a certain manufacturer/model
and the fix should be tied to vendor-id product-id.
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
2008/3/31, Amadeus W. M. <[EMAIL PROTECTED]>:
> I bought a new CyberPower CP850AVRLCD ups, connected it to a usb port
> and I'm trying to use it with hal. I installed
>
> [EMAIL PROTECTED] ~]# rpm -q nut nut-client
> nut-2.2.0-6.1.fc8
> nut-client-2.2.0-6.1.fc8
>
> lsusb sees it:
>
> [EMAIL P
> 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
Oh I didn't know about HID PDC spec but can only speculate
what we can do.
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 woul
> 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.
HI
Here is relevant -D dump. From unit descriptors I see only
unit exponent get_unit_expo: 00f0d121 found 7
but I don't see when the physical unit descriptor is read
(indicating unit means Volts)
hid_lookup_usage: UPS -> 00840004
hid_lookup_usage: PowerSummary -> 00840024
hid_lookup_usage: Co
HI
I will have access to many cyberpower 800E units
just when they deliver them. Also I may need access
to a voltmeter that can log to a file so we can let
battery discharge and compare upsc with the voltmeter
readings.
from there we can curve fit to get scale/offset or even
do the nonlinear calib
> 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 Vendor
I think the firmware is broken as it didn't apply correction
factor/offset to get volts in the HID diescriptors.
I haven't scanned the protocol - but *I think* in the HID
report descriptors contains fields for measured value of
the battery voltage and the physical unit (V, mV) that
describes the v
> 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
18 matches
Mail list logo
