Zwave; Greenwave powernode 6 reports Buffer too short

@chris Do you have any idea where this buffer too short comes from ? I am using 2.4.0 snapshot build # 1371.
Gert

This means that the message that is received from the device is incomplete or corrupt and the binding is unable to process it. If you go a debug log we could confirm exactly what was wrong.

Hello,
I have the same problem, same device. with version 2.3 (stable) I had no problems.

Here the xml file for node2 node2.xml (9.0 KB)

2018-12-20 19:10:21.995 [ERROR] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Meter Report: Buffer too short: length=3, required=4
  • Platform information:
    • Hardware: raspberry pi 3 b
    • OS: Raspbian GNU/Linux 9 (stretch)
    • Java Runtime Environment: Java™ SE Runtime Environment (build 1.8.0_181-b13)
    • openHAB version: 2.4.0 (Build) stable

Try to reset the device - this is probably a problem with the data the device is sending, and not the binding. If you are sure it’s a binding issue, then please provide a debug logfile so I can confirm.

Hello Chris,

I have not done any reset yet, but I have the debug logfile here … hope this helps

openhab.log (1022.6 KB)

Thanks - this confirms the problem is with the device -:

2018-12-21 10:10:22.144 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 03 32 02 21 
2018-12-21 10:10:22.145 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 586: [WAIT_REQUEST] priority=Get, requiresResponse=true, callback: 97
2018-12-21 10:10:22.146 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:DONE)
2018-12-21 10:10:22.147 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: resetResendCount initComplete=true isDead=false
2018-12-21 10:10:22.149 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Incoming command class COMMAND_CLASS_METER, endpoint 0
2018-12-21 10:10:22.150 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY not supported
2018-12-21 10:10:22.151 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 2: Received COMMAND_CLASS_METER V2 METER_REPORT
2018-12-21 10:10:22.152 [ERROR] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Meter Report: Buffer too short: length=3, required=4

We see the command received above -:

2018-12-21 10:10:22.144 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 03 32 02 21 

The 32 is the command class, and the 02 is the command, the 21 is the meter type - there is no data included, and this is why the binding complains that the command is too short to process. The 03 before this says that the frame is 3 bytes long (as we see) and this is too short for the meter data for starters. This length comes from the device, so we can confirm that the data was sent incorrectly from the device.

O.k., what does that mean? is the device broken?
what should I do? How can I perform a reset?
I’m grateful for hints and can also do a few experiments if it is helpful …

It means the device is sending incorrect data and you should reset it.

Reset the device and see if it sorts itself out - it probably will.

For starters I would suggest to just power it off and back on - I think that that normally resolves these sort of issues, but I don’t have this device, so can’t really be too specific - sorry.

Thank you very much, I will try to reset the device and will give you feedback!

yesterday I unplugged the device and plugged it back, today the errors have occurred again …

It is the following device: https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/102

Here is the debug logfile: openhab.log (19.7 KB)

Sorry - there’s not a lot I can do. This is not a binding problem as I explained previously - the device is sending invalid data. I could reduce the logging down from ERROR to INFO though.

@chris I hope that you will do that for all Greenwave devices, as there versions with country dependent powerplugs with 1, 5 or 6 plugs. Error indicates for me something I have to solve. Thank you for you great work on the bindings and happy season.

Gert Könemann.

Sorry - I’m not sure what you are referring to? What are you expecting me to do with these devices?

@ chris wrote:
Maintainer

2d

Sorry - there’s not a lot I can do. This is not a binding problem as I explained previously - the device is sending invalid data. I could reduce the logging down from ERROR to INFO though.


I was referring to your proposal to change ERROR to INFO for the messages in this thread.

Gert

Ah - ok, I think I’ve already done that. I’d not device dependent as it’s in the binding code.

Thanks, I will update the binding and see what happens.

Gert

I just checked - I updated this a couple of days back. I changed it to WARN… I could reduce it further, but as always there’s a compromise - I could nearly convince myself to make this DEBUG if there’s a consensus?

1 Like

@chris I did not see a real world impact when this message appears. Therefore for me DEBUG is OK.

Gert

Hi all,

I have the exact same error on both my GWPN1 nodes.
The error does not always occur. But only sometimes. Any fix for the issue? Its not really critical as it is only a meter report.

Thanks,

Ramon

The problem is with the device, so unless there is new firmware, I guess there is no fix.