[Nut-upsdev] POWERCOM HID USB controller update

Wed Nov 12 13:39:16 UTC 2014

On Nov 12, 2014, at 3:53 AM, Maksym Bodaniuk <max.bodaniuk at gmail.com> wrote:

> Hi Charles,
> 
>> Sigh, I wish the vendors wouldn't change operation without changing identifiers.
>> 
>> Do you have any recommendations on how the driver should decide whether it is an old 0x0004 or new 0x0004 device?
> 
> No-no, there is no an old 0x0004 or new 0x0004 device, I guess that we have to handle general case for all 0d9f:0x0004 devices.

You're right, I jumped to the wrong conclusion on that one.

There was another thread about this, where it seems there are other mismatches between the report descriptor sizes, and what the UPS expects:

http://article.gmane.org/gmane.comp.monitoring.nut.user/7662

> From PCM_USB_LIST_device2014.pdf attached by Alexey Morozov:
> "(VGD, VRT, RPT, .. and new UPS etc.) - 0X04.". According to this doc we can expect that all new PowerCOM devices will be shipped with ID 0X0d9f:0X04. For example, my Imperial IMD-825AP LCD has 0x0004, but an old examples of this model have 0Xa2.
> 
> Also, lets take a look inside PCM_USB_protocol_2014.pdf:
> "16 0x8456 Delay Before Startup R/W 5 Byte"
> And old specs for BNT protocol:
> "16  8456  DelayBeforeStartup *** R/W 2 Byte"
> So, the length for DelayBeforeStartup report changed from 2 to 5 bytes.

From the 2012 thread, it looks like the DelayBeforeStartup report might be encoded as hexadecimal:

   0.440981	refresh_report_buffer: expected 3 bytes, but got 2 instead
   0.441006	Report[err]: (2 bytes) => 0f 00
   0.441024	Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0

   0.445020	Report[get]: (5 bytes) => 10 30 30 30 30
   0.445051	Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID: 0x10, Offset: 0, Size: 32, Value: 12336

You can try various encodings in drivers/powercom-hid.c:powercom_startup_fun().

> Or there was added a new report for example:
> "44 0x8436 Temperature R/O 2 Byte"
> This was missed in the old specification.

You might be able to use "explore" mode in usbhid-ups to dump all of the variables to see what is missing from the driver.

> All these things lead me to thought that powercom hid driver should handle 0x0004 case more careful.
> 
>> Here is an older Powercom device with productId 00a2 - how does your output of 'upsc' compare?
> 
> Here is my output for 0x0004:
> 
> :/etc/nut$ upsc powercom
> battery.charge: 100
> battery.charge.low: 15
> battery.charge.warning: 30
> battery.date: 2010/12/20
> battery.runtime: 800
> battery.type: PbAc
> device.mfr: POWERCOM Co.,LTD
> device.model: HID UPS Battery
> device.serial: 004-0D9F-000
> device.type: ups
> driver.flag.ignorelb: enabled
> driver.name: usbhid-ups
> driver.parameter.offdelay: 10
> driver.parameter.ondelay: 100
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.version: 2.6.4
> driver.version.data: PowerCOM HID 0.3
> driver.version.internal: 0.37
> input.frequency: 50.0
> input.voltage: 214.0
> input.voltage.nominal: 220
> output.frequency: 50.0
> output.voltage: 214.0
> output.voltage.nominal: 220
> ups.beeper.status: enabled
> ups.date: 2010/12/20
> ups.delay.shutdown: 20
> ups.delay.start: 60
> ups.load: 0
> ups.mfr: POWERCOM Co.,LTD
> ups.model: HID UPS Battery
> ups.productid: 0004
> ups.serial: 004-0D9F-000
> ups.status: OL
> ups.test.result: Done and passed
> ups.timer.shutdown: 0
> ups.timer.start: 0
> ups.vendorid: 0d9f
> 
> On 11/12/2014 03:05 AM, Charles Lepple wrote:
>> On Nov 11, 2014, at 3:30 PM, Maksym Bodaniuk <max.bodaniuk at gmail.com> wrote:
>> 
>>> Dear Charles and Artem,
>>> 
>>> I've recently bought a new PowerCom Imperial IMD825-AP LCD which identifies itself as 0x0d9f:0x0004.
>>> At first glance it seems that usbhid-ups driver works fine. But when I tried to shutdown UPS via DelayBeforeShutdown it started double beeping every couple seconds for indefinite time (the same problem described by Vincenzo Colonnella here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-February/006403.html). 
>>> 
>>> I suppose that recent protocol change affects a protocol specifications for DelayBeforeShutdown and powercom_shutdown_info methods should be modified to support 0x0004 devices. But unfortunately the protocol specifications attached by Alexey Morozov didn't clarify much for me.
>>> My assumption here that PowerCom developers made a new devices with ID 0x0d9f:0x0004 more compatible with USB HID PDC and therefore we do not need any specific conversions for passed values anymore.
>> Sigh, I wish the vendors wouldn't change operation without changing identifiers.
>> 
>> Do you have any recommendations on how the driver should decide whether it is an old 0x0004 or new 0x0004 device?
>> 
>> Here is an older Powercom device with productId 00a2 - how does your output of 'upsc' compare?
>> 
> 
> Best Regards,
> Maskym Bodaniuk

-- 
Charles Lepple
clepple at gmail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20141112/94e76414/attachment-0001.html>