Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPS: patch HID Report Descriptor to fix "output.voltage" #439

Closed
clepple opened this issue Jun 4, 2017 · 68 comments
Closed

CPS: patch HID Report Descriptor to fix "output.voltage" #439

clepple opened this issue Jun 4, 2017 · 68 comments
Labels
CyberPower (CPS) feature USB USB-HID encoding/LogMin/LogMax Issues and solutions (PRs) specifically about incorrect values in bitstream

Comments

@clepple
Copy link
Member

clepple commented Jun 4, 2017

Observed in issue #337 (comment)
and on nut-upsuser.

Report ID 18 seems to be inheriting Logical Minimum/Logical Maximum from Report ID 16:

Collection(Physical)
    Report ID(16)
        Usage(LowVoltageTransfer)
        Logical Minimum(97)
        Logical Maximum(103)
        Feature(Data,Variable,Absolute)

        Usage(LowVoltageTransfer)
        Input(Constant,Variable,Absolute)

        Usage(HighVoltageTransfer)
        Logical Minimum(136)
        Logical Maximum(142)
        Feature(Data,Variable,Absolute)

        Usage(HighVoltageTransfer)
        Input(Constant,Variable,Absolute)

    Report ID(18)
        Usage(Voltage)
        Feature(Constant,Variable,Absolute)

        Report Size(8)
        Logical Minimum(0)
        Logical Maximum(255)
        Unit(SI Linear: ...)
        Unit Exponent(0)

I'm pretty sure this is not a bug in the NUT HID parser, but feel free to correct me. (There are other places in the CPS HID Report Descriptor that seem to mix up the locations of the parser tokens relative to Input/Output/Feature.)

@clepple clepple added the feature label Jun 4, 2017
@clepple
Copy link
Member Author

clepple commented Jun 4, 2017

Original HID Report Descriptor patcher issue is #169

clepple added a commit to networkupstools/nut-ddl that referenced this issue Aug 26, 2017
networkupstools/nut#439 is the likely culprit when
`output.voltage` is very close to `input.transfer.high`.
@csurf
Copy link

csurf commented Oct 29, 2020

what's the status of this issue? I'm experiencing the same thing for a CyberPower CP1000PFCLCD UPS. Both the output voltage & battery voltage are incorrect.

@CorvetteCole
Copy link

I would also love to hear if anyone has looked in to this further

@serfriz
Copy link

serfriz commented Apr 28, 2021

Any update on this? My CyberPower CP1500PFCLCD shows an output.voltage of 142.0

@arlenarlenarlen
Copy link

👋🏼 having the same issue here with my CP1500PFCLCD
Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 136

@slyticoon
Copy link

Having this issue with CP1500AVRLCD. Any updates or workarounds?

@ArcticZero
Copy link

ArcticZero commented Sep 16, 2021

Chiming in to say I'm experiencing the same with my CP1500EPFLCD. Output voltage shows a frightening 263.0-264.0v, but is actually 230ish volts. Hope there is some workaround for this for now.

  45.871994     Report[buf]: (3 bytes) => 12 e6 00
  45.872006     Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 262

@wmigas
Copy link

wmigas commented Nov 9, 2021

I have the same issue, with my CP1300EPFCLCD
I was comparing some value, it looks like output.voltage = input.voltage+32 in my case

input.voltage.nominal: 230
output.voltage: 265.0
input.voltage.nominal: 230
output.voltage: 266.0

when I run /lib/nut/usbhid-ups -DDD -a cyberpower1500
I get one value which match 32. It is Path: UPS.ff0100ba.ff0100bc
see Path: UPS.ff0100ba.ff0100bc, Type: Feature, ReportID: 0x1c, Offset: 16, Size: 8, Value: 32```
can some one check if value reported by Path: UPS.ff0100ba.ff0100bc match diff between display output voltage and value reported by NUT?

@spootle
Copy link

spootle commented Nov 9, 2021

@wmigas I have a CP1500EPFCLCD - it's not always input + 32, sometimes it drops to a hard 260v
image

e: the lowest input.voltage i've ever recorded (other than when unplugged) is 225 and output.voltage didn't drop below 260 then either so it seems to have that as a min (here's a screenshot of both random drops to 260 and a spot where it's +32 right until that would drop it below 260
image

@wmigas
Copy link

wmigas commented Nov 9, 2021

@spootle thank you for confirming it. I will try to play with it and check usb data which are send from USB but as clepple has mentioned probably the limit is linked to the broken HID Report Descrptor

@badrpc
Copy link

badrpc commented Nov 10, 2021

I have CP1500EPFCLCD and I don't know if this will help in any way but I have noticed that what currently see as the output voltage follows the formula (you can see it on the graph):

  • input <= 238 => output = input + 32
  • 238 < input < 245 => output = 260
  • 245 <= input => output = input + 16

260 has also happens to match the high transfer point but that can also be just a coincidence.

image

@badrpc
Copy link

badrpc commented Nov 10, 2021

Looking at the second graph on #439 (comment) it seems that

  • input < 229 results in output = 260
  • 229 <= input <= 238 results in output = input + 32

@badrpc
Copy link

badrpc commented Nov 10, 2021

I have no knowledge of USB HID devices. So please excuse my stupid question. Running usbhid-ups -DDD -a core I got this:

   0.099763     Report[get]: (3 bytes) => 0f f2 00
   0.099791     Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 242

   0.105764     Report[get]: (3 bytes) => 12 f2 00
   0.105793     Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 260

Shouldn't value for UPS.Output.Voltage be 242? 0x00f2 is 242. I'll try to cut the input power later today and will check what I see in UPS.Output.Voltage

@wmigas
Copy link

wmigas commented Nov 10, 2021

@bardpc I'm not an expert and I started reading documentation couple days ago, but it look like, that HID Report Descriptor which describes data structure is broken. If you run your command with more "D" letters you will see more debug data like this

   0.368509     Report[get]: (3 bytes) => 12 e0 00
   0.368540     PhyMax = 0, PhyMin = 0, LogMax = 270, LogMin = 260
   0.368543     Unit = 00f0d121, UnitExp = 7
   0.368549     Exponent = 0
   0.368556     hid_lookup_path: 00840004 -> UPS
   0.368560     hid_lookup_path: 0084001c -> Output
   0.368566     hid_lookup_path: 00840030 -> Voltage
   0.368574     Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 260

I get e0 which is 224, but I returns 260.
assuming that it adds to each reading 32, then you get 224+32= 256
but there is magic line PhyMax = 0, PhyMin = 0, LogMax = 270, LogMin = 260 which set min and max value, that's why the lowest value is 260.

in case e5 which is 229
I get 261 which match 229+32 and is more than logmin value

@flashydave
Copy link
Contributor

Has anybody compared the results with Cyberpower's own Linux based software?
Maybe that might help determine where the problem lies.
I have a CP900EFPCLCD arriving shortly so can give you another test result and maybe help with the debug effort.

@flashydave
Copy link
Contributor

flashydave commented Nov 12, 2021

I see the same problem with my CP900EPFCLCD running firmware CRIB101#7F1 with self compiled nut driver.version: 2.7.4-2486-gaa0b3d1(which is quite old).

   2.160392     [D3] Report[buf]: (3 bytes) => 12 f3 00
   2.160671     [D5] PhyMax = 0, PhyMin = 0, LogMax = 270, LogMin = 260
   2.160898     [D5] Unit = 00f0d121, UnitExp = 7
   2.161479     [D5] Exponent = 0
   2.161794     [D2] Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 260
   2.170607     [D5] send_to_all: SETINFO output.voltage "260.0"

f3 is 243v which is what the front panel was showing but upsc is reporting 260v as above.

The pwrstat utility from CyberPower shows the correct voltage (for the measurement time) so doesnt exhibit the same fault:

pwrstat -status

The UPS information shows as following:

        Properties:
                Model Name................... CP900EPFCLCD
                Firmware Number.............. CRIB101#7F1
                Rating Voltage............... 230 V
                Rating Power................. 540 Watt

        Current UPS status:
                State........................ Normal
                Power Supply by.............. Utility Power
                Utility Voltage.............. 239 V
                Output Voltage............... 239 V
                Battery Capacity............. 100 %
                Remaining Runtime............ 130 min.
                Load......................... 0 Watt(0 %)
                Line Interaction............. None
                Test Result.................. Unknown
                Last Power Event............. None

I also have a problem with the Battery voltage which is showing as 24v when it contains only 1 12v lead acid cell. The serial # of the UPS is showing 000000000 as well.

I have capture the USB traffic when running pwrstat as raw hex but trying to work out what its actually doing might prove difficult.

@flashydave
Copy link
Contributor

Looking a little further (at least on my CP900EPFCLCD) the output voltage issue could be fixed by overriding the logic in libhid.c where the usbhid defined LogMax or LogMin limits are applied. This would expose the value rather than masking it.

I guess a driver config option could be introduced to make it generally configurable. Is that an acceptable approach? If so I could write the code.

In my case the value is correct at but I would suggest external programs (like graphing applications) could apply any arithmetic fixes needed for other models.

Regarding the battery voltages reading 24v not 12v I havent seen any values change yet (a little suspicious given the 0.1v resolution*) but it does look like the UPS is simply mis-reporting the value via the usbhid protocol based on it's incorrect notion of the battery fitted.

realpower.nominal is also a factor of 2 in error compared with the front panel display.

Not a lot can be done to fix these other than applying the corrections externally.

*Does anyone else see battery.voltage values changing?

@spootle
Copy link

spootle commented Nov 13, 2021

I have seen mention elsewhere there are no battery voltage sensors installed in these units so it never changes (same reason pwrstat doesn't report any value)

@flashydave
Copy link
Contributor

flashydave commented Nov 13, 2021

I saw that but then wondered why they bother to render it on the unit LCD if that was the case. Internally they must measure the voltage to determine the state of charge (or discharge for updating the remaining run time and declaring LB). I know it's a domestic class product (not a professional system like I am used to) but even so I would have thought they would add features where it is trivial to do.

@wmigas
Copy link

wmigas commented Dec 21, 2021

there was bug in hid parser which return incorrect value in my case 0xea (234) to 0x10A (266) I've tracked the issues, but it looks like it has been fixed in #1040.
I've checked branched 2.4.7 instead of master :-)
current master branch return correct value 0x104 (260) which is logical min.

to fix output value, there are only 2 options:

  1. force CPS to fix HID report descriptor
  2. implement HID Report Descriptor patcher #169

@flashydave
Copy link
Contributor

I have a fix as per your option 1 above which works with my CPS900EPFCLCD. I will be submitting this as a pull request very shortly.

@wmigas
Copy link

wmigas commented Dec 24, 2021

I've made fix which works for me and I would like to create PR, but I was thinking about more general solution. I've asked cleepple about his thought, see #169. It is not full solution, but at list on the subdriver level we will be able to fix Report descriptor. see changes in my fork wmigas@8af66bd

@flashydave
Copy link
Contributor

flashydave commented Dec 24, 2021 via email

@flashydave
Copy link
Contributor

flashydave commented Jan 16, 2022

Can I suggest we move the build problem discussion to a new created issue as it is not related to the CyberPower UPS or the voltage reporting issue. In this way we can move on and close this ticket whilst dealing with the build problem separately. It also means others experiencing the issue might see it and contribute.

To that end maybe you can summarize what you have found so far and comment on my above question as to whether configure.ac also contains the corruption.

@5ft24dave
Copy link

we can ignore the issue. its evidently part of one of the other software packages associated with Octoprint that is causing the sudo make install to fail. I just flashed the same rpi4 with a fresh install of only raspberrypiOS Bullseye, and it builds without any complaints. Flashed it fresh with the Octopi bullseye nightly image and tried the build again and it has the issue.
Problem solved.

@flashydave
Copy link
Contributor

Incidentally with the offending section extracted as a separate Makefile and put in a git repo to exercise the path through the shell commands you are utilising I have tested it using Make 4.2.1 on two rpi's running buster and it works as expected on both.

@flashydave
Copy link
Contributor

flashydave commented Jan 16, 2022 via email

@5ft24dave
Copy link

yes, fixes it nicely. What I did was install the deb packages for nut, then deleted the files from those and copied the files from the compiled nut to those directories since the sudo make install wouldn't do it for me. works like a champ.
Now just waiting for MODBUS over USB for the APC Back-UPS I have in another room LOL

@flashydave
Copy link
Contributor

flashydave commented Jan 17, 2022 via email

@badrpc
Copy link

badrpc commented Jan 17, 2022

Just another data point: I have built NUT from https://github.com/flashydave/nut/commits/issue439 (FreeBSD, RPi 3B) and reported values now match what I expect - output == input when UPS is online and output == nominal when on battery:
image

Thank you so much @flashydave !

@nesanakin
Copy link

nesanakin commented Jun 24, 2022

I have a CP1500PFCLCD and I'm still having this issue. The fix in #1245 seems to only apply to the CP*EPFCLCD series (looks like the EU model?) with productID 0x0501. The US CP*PFCLCD series with productID 0x0601 still reports the output voltage as 136V all the time. Would that fix work for this model as well? Seem like it would just take modifying a single conditional if so.

Edit: Looks like I'm wrong about the differentiation in productID between those two product lines–nonetheless, the current model of CP1500PFCLCD that I have has a productID of 0x0601, so that fix doesn't currently apply.

@5ft24dave
Copy link

5ft24dave commented Jun 24, 2022 via email

@rapirent
Copy link

rapirent commented Jul 8, 2022

I have same problem with my CP1000PFCLCD (vendor#: 0x0601) in 2.8.0, and its voltage output is wrong (it displays 135v and seldomly varies but not match the lcd panel)

@flashydave
Copy link
Contributor

flashydave commented Jul 8, 2022 via email

@rapirent
Copy link

rapirent commented Jul 9, 2022

ths for the reply! Should I start with another issues?
I ran the lsusb and upsc. Could you provide the exact command you want me to run if you want a further infomations?
And I wanna correct details about my problem, it seems like it always displays "135v" for output.voltage.

the debug message:

[root@localhost ~]# lsusb -v -s 001

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            5.10
  iManufacturer           3 Linux 5.10.23-v8.1.1.el8 dwc_otg_hcd
  iProduct                2 DWC OTG Controller
  iSerial                 1 3f980000.usb
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0019
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x0008
    Ganged power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered
[root@localhost ~]# upsc -l
cyberups1000v
[root@localhost ~]# upsc cyberups1000v
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1550
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 13.8
battery.voltage.nominal: 12
device.mfr: CPS
device.model: CP1000PFCLCDa
device.serial: CX3LT2000019
device.type: ups
driver.name: usbhid-ups
driver.parameter.bus: 001
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: CP1000PFCLCDa
driver.parameter.productid: 0601
driver.parameter.serial: CX3LT2000019
driver.parameter.synchronous: auto
driver.parameter.vendor: CPS
driver.parameter.vendorid: 0764
driver.version: 2.8.0
driver.version.data: CyberPower HID 0.6
driver.version.internal: 0.47
driver.version.usb: libusb-1.0.23 (API: 0x1000107)
input.voltage: 114.0
input.voltage.nominal: 120
output.voltage: 135.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 23
ups.mfr: CPS
ups.model: CP1000PFCLCDa
ups.productid: 0601
ups.realpower.nominal: 600
ups.serial: CX3LT2000019
ups.status: OL
ups.test.result: Done and passed
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764

The product ID for cyberpower is 0x0764. Did you mean product ID? if so the fix will not be applied as it only addresses models with productID 0x0501. It may be the same issue. Please can you run the driver under debug and report back the logs during the HID parsing process?

On 08:57, Fri 08 Jul 22, Kuo-Teng Ding wrote: I have same problem with my CP1000PFCLCD (vendor#: 0x0601) in 2.8.0, and its voltage output is wrong (it displays 135v and seldomly varies but not match the lcd panel) -- Reply to this email directly or view it on GitHub: #439 (comment) You are receiving this because you were mentioned. Message ID: @.***>

@flashydave
Copy link
Contributor

flashydave commented Jul 9, 2022 via email

@rapirent
Copy link

there is it, ths anyway :)

[root@localhost ~]# /lib/nut/usbhid-ups -DDDDD -a cyberups1000v 2>&1 | tee /root/cyberpower.log
   0.000000	[D3] main_arg: var='driver' val='usbhid-ups'
   0.000133	[D3] main_arg: var='port' val='auto'
   0.000182	[D5] send_to_all: SETINFO driver.parameter.port "auto"
   0.001131	[D3] main_arg: var='vendorid' val='0764'
   0.001714	[D5] send_to_all: SETINFO driver.parameter.vendorid "0764"
   0.002020	[D3] main_arg: var='productid' val='0601'
   0.002523	[D5] send_to_all: SETINFO driver.parameter.productid "0601"
   0.003044	[D3] main_arg: var='product' val='CP1000PFCLCDa'
   0.003483	[D5] send_to_all: SETINFO driver.parameter.product "CP1000PFCLCDa"
   0.003837	[D3] main_arg: var='desc' val='CP UPS'
   0.003877	[D3] main_arg: var='serial' val='CX3LT2000019'
   0.004140	[D5] send_to_all: SETINFO driver.parameter.serial "CX3LT2000019"
   0.004460	[D3] main_arg: var='vendor' val='CPS'
   0.005149	[D5] send_to_all: SETINFO driver.parameter.vendor "CPS"
   0.005195	[D3] main_arg: var='bus' val='001'
   0.005590	[D5] send_to_all: SETINFO driver.parameter.bus "001"
   0.006212	[D1] debug level is '5'
   0.024243	[D5] send_to_all: SETINFO device.type "ups"
   0.024325	[D2] Initializing an USB-connected UPS with library libusb-1.0.23 (API: 0x1000107) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.43')
   0.024347	[D1] upsdrv_initups (non-SHUT)...
   0.042954	[D2] Checking device 1 of 4 (0764/0601)
   0.046592	[D2] - VendorID: 0764
   0.046643	[D2] - ProductID: 0601
   0.046661	[D2] - Manufacturer: CPS
   0.046679	[D2] - Product: CP1000PFCLCDa
   0.046697	[D2] - Serial Number: CX3LT2000019
   0.046714	[D2] - Bus: 001
   0.046732	[D2] - Device: unknown
   0.046750	[D2] - Device release number: 0200
   0.046767	[D2] Trying to match device
   0.046793	[D2] match_function_subdriver (non-SHUT mode): matching a device...
   0.047096	[D3] match_function_regex: matching a device...
   0.047536	[D2] Device matches
   0.047573	[D2] Reading first configuration descriptor
   0.047639	[D3] libusb_kernel_driver_active() returned 0
   0.047677	[D2] failed to claim USB device: Resource busy
   0.047706	[D2] Kernel driver already detached
   0.047732	[D2] failed to claim USB device: Resource busy
   0.047761	[D2] Kernel driver already detached
   0.047785	[D2] failed to claim USB device: Resource busy
   0.047810	[D2] Kernel driver already detached
   0.047842	[D2] failed to claim USB device: Resource busy
   0.047867	[D2] Kernel driver already detached
   0.047897	Can't claim USB device [0764:0601]@0/0: Entity not found
Network UPS Tools - Generic HID driver 0.47 (2.8.0)
USB communication driver (libusb 1.0) 0.43

Stop nut then run /lib/nut/usbhid-ups -DDDDD -a cyberpower 2>&1 | tee /root/cyberpower.log for about 15 seconds then ctrl-c This should show the HID being parsed enough for us to check to see if it is the same firmware issue as on the other models. if so the fix is easy vy simply extending to cover your product. regards Dave

On 10:24, Sat 09 Jul 22, Kuo-Teng Ding wrote: ths for the reply! Should I start with another issues? I ran the lsusb and upsc. Could you provide the exact command you want me to run if you want a further infomations? And I wanna correct details about my problem, it seems like it always displays "135v" for output.voltage. the debug message: sh ***@***.*** ~]# lsusb -v -s 001 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 5.10 iManufacturer 3 Linux 5.10.23-v8.1.1.el8 dwc_otg_hcd iProduct 2 DWC OTG Controller iSerial 1 3f980000.usb bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x0008 Ganged power switching Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0503 highspeed power enable connect can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered sh ***@***.*** ~]# upsc -l cyberups1000v ***@***.*** ~]# upsc cyberups1000v battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1550 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 13.8 battery.voltage.nominal: 12 device.mfr: CPS device.model: CP1000PFCLCDa device.serial: CX3LT2000019 device.type: ups driver.name: usbhid-ups driver.parameter.bus: 001 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.product: CP1000PFCLCDa driver.parameter.productid: 0601 driver.parameter.serial: CX3LT2000019 driver.parameter.synchronous: auto driver.parameter.vendor: CPS driver.parameter.vendorid: 0764 driver.version: 2.8.0 driver.version.data: CyberPower HID 0.6 driver.version.internal: 0.47 driver.version.usb: libusb-1.0.23 (API: 0x1000107) input.voltage: 114.0 input.voltage.nominal: 120 output.voltage: 135.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 23 ups.mfr: CPS ups.model: CP1000PFCLCDa ups.productid: 0601 ups.realpower.nominal: 600 ups.serial: CX3LT2000019 ups.status: OL ups.test.result: Done and passed ups.timer.shutdown: -60 ups.timer.start: -60 ups.vendorid: 0764 > The product ID for cyberpower is 0x0764. Did you mean product ID? if so the fix will not be applied as it only addresses models with productID 0x0501. It may be the same issue. Please can you run the driver under debug and report back the logs during the HID parsing process? > > On 08:57, Fri 08 Jul 22, Kuo-Teng Ding wrote: I have same problem with my CP1000PFCLCD (vendor#: 0x0601) in 2.8.0, and its voltage output is wrong (it displays 135v and seldomly varies but not match the lcd panel) -- Reply to this email directly or view it on GitHub: [#439 (comment)](#439 (comment)) You are receiving this because you were mentioned. Message ID: @.> -- Reply to this email directly or view it on GitHub: #439 (comment) You are receiving this because you were mentioned. Message ID: @.>

@flashydave
Copy link
Contributor

flashydave commented Jul 10, 2022 via email

@rapirent
Copy link

rapirent commented Jul 10, 2022

oops...sorry
I killed all the nut related process and got the file

cyberpower.log

Looks like nut oe something similar still running....?

On 05:43, Sun 10 Jul 22, Kuo-Teng Ding wrote: there is it, ths anyway :) sh ***@***.*** ~]# /lib/nut/usbhid-ups -DDDDD -a cyberups1000v 2>&1 | tee /root/cyberpower.log 0.000000 [D3] main_arg: var='driver' val='usbhid-ups' 0.000133 [D3] main_arg: var='port' val='auto' 0.000182 [D5] send_to_all: SETINFO driver.parameter.port "auto" 0.001131 [D3] main_arg: var='vendorid' val='0764' 0.001714 [D5] send_to_all: SETINFO driver.parameter.vendorid "0764" 0.002020 [D3] main_arg: var='productid' val='0601' 0.002523 [D5] send_to_all: SETINFO driver.parameter.productid "0601" 0.003044 [D3] main_arg: var='product' val='CP1000PFCLCDa' 0.003483 [D5] send_to_all: SETINFO driver.parameter.product "CP1000PFCLCDa" 0.003837 [D3] main_arg: var='desc' val='CP UPS' 0.003877 [D3] main_arg: var='serial' val='CX3LT2000019' 0.004140 [D5] send_to_all: SETINFO driver.parameter.serial "CX3LT2000019" 0.004460 [D3] main_arg: var='vendor' val='CPS' 0.005149 [D5] send_to_all: SETINFO driver.parameter.vendor "CPS" 0.005195 [D3] main_arg: var='bus' val='001' 0.005590 [D5] send_to_all: SETINFO driver.parameter.bus "001" 0.006212 [D1] debug level is '5' 0.024243 [D5] send_to_all: SETINFO device.type "ups" 0.024325 [D2] Initializing an USB-connected UPS with library libusb-1.0.23 (API: 0x1000107) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.43') 0.024347 [D1] upsdrv_initups (non-SHUT)... 0.042954 [D2] Checking device 1 of 4 (0764/0601) 0.046592 [D2] - VendorID: 0764 0.046643 [D2] - ProductID: 0601 0.046661 [D2] - Manufacturer: CPS 0.046679 [D2] - Product: CP1000PFCLCDa 0.046697 [D2] - Serial Number: CX3LT2000019 0.046714 [D2] - Bus: 001 0.046732 [D2] - Device: unknown 0.046750 [D2] - Device release number: 0200 0.046767 [D2] Trying to match device 0.046793 [D2] match_function_subdriver (non-SHUT mode): matching a device... 0.047096 [D3] match_function_regex: matching a device... 0.047536 [D2] Device matches 0.047573 [D2] Reading first configuration descriptor 0.047639 [D3] libusb_kernel_driver_active() returned 0 0.047677 [D2] failed to claim USB device: Resource busy 0.047706 [D2] Kernel driver already detached 0.047732 [D2] failed to claim USB device: Resource busy 0.047761 [D2] Kernel driver already detached 0.047785 [D2] failed to claim USB device: Resource busy 0.047810 [D2] Kernel driver already detached 0.047842 [D2] failed to claim USB device: Resource busy 0.047867 [D2] Kernel driver already detached 0.047897 Can't claim USB device ***@***.***/0: Entity not found Network UPS Tools - Generic HID driver 0.47 (2.8.0) USB communication driver (libusb 1.0) 0.43 > Stop nut then run /lib/nut/usbhid-ups -DDDDD -a cyberpower 2>&1 | tee /root/cyberpower.log for about 15 seconds then ctrl-c This should show the HID being parsed enough for us to check to see if it is the same firmware issue as on the other models. if so the fix is easy vy simply extending to cover your product. regards Dave > > On 10:24, Sat 09 Jul 22, Kuo-Teng Ding wrote: ths for the reply! Should I start with another issues? I ran the lsusb and upsc. Could you provide the exact command you want me to run if you want a further infomations? And I wanna correct details about my problem, it seems like it always displays "135v" for output.voltage. the debug message: sh ***@***.*** ~]# lsusb -v -s 001 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 5.10 iManufacturer 3 Linux 5.10.23-v8.1.1.el8 dwc_otg_hcd iProduct 2 DWC OTG Controller iSerial 1 3f980000.usb bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x0008 Ganged power switching Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0503 highspeed power enable connect can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0001 Self Powered sh ***@***.*** ~]# upsc -l cyberups1000v ***@***.*** ~]# upsc cyberups1000v battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1550 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 13.8 battery.voltage.nominal: 12 device.mfr: CPS device.model: CP1000PFCLCDa device.serial: CX3LT2000019 device.type: ups driver.name: usbhid-ups driver.parameter.bus: 001 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.product: CP1000PFCLCDa driver.parameter.productid: 0601 driver.parameter.serial: CX3LT2000019 driver.parameter.synchronous: auto driver.parameter.vendor: CPS driver.parameter.vendorid: 0764 driver.version: 2.8.0 driver.version.data: CyberPower HID 0.6 driver.version.internal: 0.47 driver.version.usb: libusb-1.0.23 (API: 0x1000107) input.voltage: 114.0 input.voltage.nominal: 120 output.voltage: 135.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 23 ups.mfr: CPS ups.model: CP1000PFCLCDa ups.productid: 0601 ups.realpower.nominal: 600 ups.serial: CX3LT2000019 ups.status: OL ups.test.result: Done and passed ups.timer.shutdown: -60 ups.timer.start: -60 ups.vendorid: 0764 > The product ID for cyberpower is 0x0764. Did you mean product ID? if so the fix will not be applied as it only addresses models with productID 0x0501. It may be the same issue. Please can you run the driver under debug and report back the logs during the HID parsing process? > > On 08:57, Fri 08 Jul 22, Kuo-Teng Ding wrote: I have same problem with my CP1000PFCLCD (vendor#: 0x0601) in 2.8.0, and its voltage output is wrong (it displays 135v and seldomly varies but not match the lcd panel) -- Reply to this email directly or view it on GitHub: [#439 (comment)]([#439 (comment)](#439 (comment))) You are receiving this because you were mentioned. Message ID: @.> -- Reply to this email directly or view it on GitHub: [#439 (comment)](#439 (comment)) You are receiving this because you were mentioned. Message ID: @.> -- Reply to this email directly or view it on GitHub: #439 (comment) You are receiving this because you were mentioned. Message ID: @.***>

@flashydave
Copy link
Contributor

flashydave commented Jul 10, 2022 via email

@docop
Copy link

docop commented Aug 10, 2022

Hi just to add here over an install with the CP1500PFCLCD , vendorid = 0764 / prodid:0501 , i also got the issues of wrong output voltage as being : 136v. It's a fully working unit and confirm a steady 120v and also via the cyberpower app. Is there a fix plan as a new release ?
-ref; using nut linux version or linux over debian same.

@jimklimov
Copy link
Member

jimklimov commented Aug 12, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CyberPower (CPS) feature USB USB-HID encoding/LogMin/LogMax Issues and solutions (PRs) specifically about incorrect values in bitstream
Projects
None yet
Development

No branches or pull requests