Onkyo binding floods log with "no route to host"
See original GitHub issueMy 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.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Onkyo Binding works, but generates TONS of errors in log
Onkyo Binding works, but generates TONS of errors in log ... OnkyoConnection] - Can't connect: No route to host (Host unreachable) ...
Read more >WebConsole and Programming Guide - NX-Series Controllers
Servicing is required when the apparatus has been damaged in any way, such as power-supply cord or plug is damaged, liquid has been...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

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.
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.
Done here now: http://docs.openhab.org/developers/development/guidelines.html#e-logging