[Nut-upsdev] Powercom support and sponsorship

[Arjen de Korte]

Citeren Morozov Alexey <morozov op pcm.ru>:

> Kindly please work out in detail your questions.

1) Value too large for defined data type

Feature reports 0x11 (UPS.PowerSummary.ConfigVoltage), 0x19  
(UPS.Battery.ConfigVoltage), 0x1c (UPS.Input.ConfigVoltage) and 0x20  
(UPS.Output.ConfigVoltage) should return an 8 bit (1 byte) value  
according to the report descriptor. When we retrieve them, we get more  
than that (probably two bytes, but the actual value can't be  
reported). Either the report descriptor needs to be fixed, or reading  
the feature report should return the correct amount of data.

-> NUT won't be able to read nominal input-, output- and battery voltage

Input reports 0x0a (UPS.PowerSummary.RemainingCapacity) and 0x15  
(UPS.Battery.Test) both return 2 bytes while the report descriptor  
says these should be 8 bit (1 byte), the same as the the corresponding  
feature reports.

-> NUT won't be able to use these reports

2) Erroneous value retrieved for report

Reports 0x12, 0x1a, 0x1d and 0x21 all return '212' as value. I very  
much doubt that UPS.PowerSummary.Voltage, UPS.Battery.Voltage,  
UPS.Input.Voltage and UPS.Output.Voltage are the same (since these  
should be measured values).

-> NUT won't read the input-, output- and battery voltage

3) Suspicious value read

The input report and feature report 0x0e  
(UPS.PowerSummary.RunTimeToEmpty) don't match (0x0e 0x64 0x10 and 0x0e  
0x80 0x09 respectively). While technically not wrong, it is doubtful  
that this really is the case.

Looking at the values read in the input reports, there might be an  
issue with ordering of data:

   [0a] 0c 10 (expected 64)
   [0e] 64 10 (expected 80 09)
   [15] 80 09 (expected 01)
   [14] 01 09 (expected 0c 10)

Looking at the actual and expected values, it looks like the data for  
the input reports is outputed with the next input report. Also, the  
number of bytes returned in the reports seems to be fixed at 2, while  
this should depend on the actual size of the reports (1 byte for 0x0a  
and 0x15 and 2 bytes for 0x0e and 0x14).

There is a small chance that this could be an issue with libusb, USB  
controller and/or operating system, so for the moment I would call  
this suspicious only. Alexander, could you post what you're using  
right now? Is this a *BSD or a Linux system?

-> NUT only uses input reports as a trigger to read feature reports,  
so if the number of bytes is correct, there would be no issue.

Best regards, Arjen

PS  It would be helpful if I could have a Powercom unit too for  
debugging the above.
-- 
Please keep list traffic on the list