Zwave error every 30 minutes: "Too many retries. Discarding message"


I am getting timeout errors for both of my two GreenWave Power Plugs every 30 minutes.
This might be related to the polling period which is set to 1800 seconds for both devices. Still, in the log it appears that the polling basically works, but in the end I still get a timeout:

2016-09-24 22:45:45.342 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 12: Timeout while sending message. Requeueing - 1 attempts left!
2016-09-24 22:45:45.345 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 12: Got an error while sending data. Resending message. 
2016-09-24 22:45:55.365 [WARN ] [ocol.ZWaveController$ZWaveSendThread] - NODE 12: Too many retries. Discarding message: Message: class=SendData[0x13], type=Request[0x00], priority=Get, dest=12, callback=18, payload=0C 03 71 04 00

Please see here for the log on debug level.

Unfortunately I cannot read from the logs what’s wrong. Any ideas?

This is my network topology, 9 and 12 being the devices which show the errors. Node 12 is in less than 1m distance from the controller.

@chris, any hint what I could check to find out why the timeout occurs and to stop it?

It’s possible that 1m is too close (although I’m not sure I would put money on that solving the problem). Transmitters that are too close to a receiver can overload the receiver so it doesn’t receive, so I would try moving them to see if this helps. Alternatively, you could try reducing the output power of node 12, although since you can’t reduce node 1 (probably) this may not help.

If it’s not an overload issue, then I’m not sure - it would be useful to see the debug log to see if the binding is sending a message that the device won’t respond to.

Hi @chris ,
thanks for the suggestions! I tried to move the power plug further away from the controller (now ~4 meters) but the errors do still appear.
I had some DEBUG log attached in the first post (as a link). Should I enable TRACE level to see even more details?

Thanks - this is fine. Give me some time to think about this, but it will either be fixed with a change to the database, or possibly a change to the binding.

@dominicdesu can you provide me the XML for this node please.

Sure, here it is: node12.xml (8.1 KB)

@chris, did you see my last reply (forgot to mention your name)? Anything else I can provide?

Sorry - I missed this…

Can you provide a ‘full’ debug log showing the initialisation of the device. I want to see some of the reports during initialisation.

The root problem is the binding is requesting alarm updates for a specific alarm which the manual says the device doesn’t support - so this is correct. I want to see if the device is reporting the alarms it supports in the initialisation - it’s not in the XML which makes me think it isn’t reported…

@chris, sure, here it is:
Hope this is what you wanted.

Thanks… But… Sorry - I missed one important point… In order to get the full initialisation in the log, you need to delete the XML for this device. This forces the binding to download all the device information again… (apologies for missing that).

@chris, no problem, thank you for looking into this!
Here is the log during OH2 startup after I deleted the xml file for Node 12:

@chris: did you see my reply? :slight_smile:

Sorry - I’ll update the database to (hopefully) solve this. It will probably be tomorrow some time (database is updated, but I’ll merge into the binding tomorrow…)


has something else changed here very recently?
I get a lot of timeouts now for different mains (plugs)

No, nothing has changed but it would be useful if you posted the information about what is timing out. Quite likely the new channels that you added for the alarms will be the cause.

mhh I change to debug log and post as soon as I see it again

but it is for multiple plugs (also devolo / philio … so I guess not related to the alarm channel I added to the fibaro

Ok, let’s see, but nothing has changed unless the database changed. In any case, we need the log…

I sent one via mail.
I hope thats the relevant part.