[Nut-upsdev] POWERCOM HID USB controller update

Wed Nov 12 14:30:06 UTC 2014

>
> 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
>

Here is my output:

   0.356896     Path: UPS.PowerSummary.*DelayBeforeShutdown*, Type:
Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0
   0.361823     refresh_report_buffer: expected 5 bytes, but got 3 instead
   0.361893     Report[err]: (3 bytes) => *10 00 00*
   0.361951     Path: UPS.PowerSummary.*DelayBeforeStartup*, Type: Feature,
ReportID: 0x10, Offset: 0, Size: 32, Value: 0
   0.366816     refresh_report_buffer: expected 3 bytes, but got 2 instead
   0.366873     Report[err]: (2 bytes) => *11 dc*

It looks like my UPS with has another output. Probably, you were right and
we really have different behaviour for the same ID?..

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.
>

I will do some exploration as soon as have direct access to the UPS.

Hope that PowerCOM team will make some clarification here.

2014-11-12 15:39 GMT+02:00 Charles Lepple <clepple at gmail.com>:

> 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> <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/adc4b9b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PowerCOM.log
Type: text/x-log
Size: 38407 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20141112/adc4b9b1/attachment-0001.bin>