Openhab-addons: Onkyo binding floods log with "no route to host"

Created on 28 Jan 2017  路  8Comments  路  Source: openhab/openhab-addons

My receiver and some other devices are disconnected from power to save the 30W standby consumption.
I can turn on power via the Homematic binding. Unfortunately when power is off, the Onkyo binding floods the openhab log with the following entries:

2017-01-28 18:21:04.538 [ERROR] [b.binding.onkyo.internal.eiscp.Eiscp] - Can't connect: No route to host
2017-01-28 18:21:04.541 [ERROR] [b.binding.onkyo.internal.eiscp.Eiscp] - Error occurred during message waiting
java.io.IOException: Not Connected to Receiver
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.waitStateMessages(Eiscp.java:477)[212:org.openhab.binding.onkyo:2.0.0]
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp.access$1(Eiscp.java:338)[212:org.openhab.binding.onkyo:2.0.0]
        at org.openhab.binding.onkyo.internal.eiscp.Eiscp$DataListener.run(Eiscp.java:503)[212:org.openhab.binding.onkyo:2.0.0]

I think the the error log level should be changed to DEBUG so that it does not appear in the log anymore.

Most helpful comment

I would log a warning on first connection problem and set thing status to OFFLINE with correct error message. Any further connection problems as long as thing status is OFFLINE can then be ignored as they are expected in OFFLINE state. That way you still get something in the log with default logging setup and do not flood the log anymore.
If you want, you can additionally log something with INFO level when connection has been (re)established so you can keep track of when the receiver had been connected.

All 8 comments

I think the the error log level should be changed to DEBUG so that it does not appear in the log anymore.

Binding is designed to keep connection always open, so that's why all connection related problems are errors. Most of the users want to have connection always open, so logging level change prevent users to see connection errors from log.

Anyhow, I will add feature, where user can configure binding to be aware situation when receiver is fully powered off. If mode is enabled, binding will not log connection errors on error level but debug level.

Most of the users want to have connection always open, so logging level change prevent users to see connection errors from log.

Instead of logging errors, the correct way to tell the user that there is a connection problem is to set the ThingStatus to OFFLINE.
So I fully agree with @mrumpf: The logging must be done in debug level.

Instead of logging errors, the correct way to tell the user that there is a connection problem is to set the ThingStatus to OFFLINE.

I agree that ThingStatus should set to OFFLINE and cause is communication error and this is how binding already works. But reason for communication error can't be see from the status. For me status is trigger to see details from the log. Additionally, status only indicates the current state.

So I fully agree with @mrumpf: The logging must be done in debug level.

I hope that you are joking? Could you describe what is the purpose of the different logging levels? What is difference between error and debug level? For me this pretty obvious, if error occurs, error should logged. Debug level logging is just information which is needed for development purposes or root cause analyses. Normal user should never need to increase log level to debug level (well, of course if developer ask).

Personally I want to know if there is or has been any communication errors on my local network and what is the reason. So definitely all communication errors should logged so that errors can be found from the logs without using debug level. Debug level is normally so verbose that it doesn't make sense to keep it always on and also all errors easily disappears to nonsense.

But reason for communication error can't be see from the status.

That's not correct. You can (and should!) set the reason as a third parameter when setting the status. This is logged as an event and it is also shown to the user in the Paper UI.

Could you describe what is the purpose of the different logging levels?

Done here now: http://docs.openhab.org/developers/development/guidelines.html#e-logging

I would log a warning on first connection problem and set thing status to OFFLINE with correct error message. Any further connection problems as long as thing status is OFFLINE can then be ignored as they are expected in OFFLINE state. That way you still get something in the log with default logging setup and do not flood the log anymore.
If you want, you can additionally log something with INFO level when connection has been (re)established so you can keep track of when the receiver had been connected.

@martinvw I don't think that this issue is related to the Homematic binding. A Homematic device is only used to turn on/off the Onkyo device.

@MHerbst agree on that, removed the label :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

UrsusS picture UrsusS  路  5Comments

Nikos78 picture Nikos78  路  5Comments

bennybubble picture bennybubble  路  4Comments

mjcumming picture mjcumming  路  5Comments

smyrman picture smyrman  路  4Comments