Denon Binding spams NoRouteToHostException

So I’m having a problem, I turn off the power to my Denon AVR, when I do that, the Denon binding starts to spam the log with since the HTTP Refresh Service tries to connect to the AVR again, but since it’s offline it can’t.

Is there any way I can make a rule that checks if the item Socket_GA_Living_AVR is ON or OFF and then stop and start the refresh service depending on the state?


Same here, this should be fixed. I currently removed the binding.
Have you created an issue at github?

Also here. Although I use a Marantz. In addition I see that no status updates are carried out anymore if I e.g. change the rule or sitemap files of openHAB.

Are you using the latest version of the binding? Log levels for these messages have changed about 2 months ago.

I believe so: version 1.8.0.
Maybe its because I connect to a Marantz.
In principle its a splendid binding!!! and works great.

Ok that should be recent enough. What’s in the log files when this happens, could you post the complete stack trace?

I set the warning level OFF for HTTPUtil in the logback.xml as a workaround, so I have no recent log with the stack trace, but this issue is easily reproducable, connect your Denon/Marantz receiver to your local network, start the binding, and then cut off the power of the AVR after the binding got the connection.

The refresh service will then try to connect to the Denon which won’t work and therefore it will throw exceptions. I looked at the code
You can see there is no exception handling, since the creator probably didn’t consider this particular situation. I can create a pull request and fix the exception handling. There definitely should be a logging entry if the refresh service doesn’t get a connection, but I’m not sure which log level it should have, DEBUG or INFO?

IMHO it should be DEBUG, since it would still spam the log if the level was INFO, but when there is a real issue with the refresh service, e.g. if a user configured a wrong IP for his denon instance, you wouldn’t see it if you don’t set the log level to DEBUG. So I’ll let you decide.

Edit: I was wrong, there is no real exception, therefore there is no stack trace, since HTTPUtil is designed to log out errors like this.

Ah, I made a few changes a while back that handled powered off receivers, but that only considered using the telnet method. In these methods I’m also using the DEBUG log level, so using this for the http methods sounds fine.

Looks like we have to stop using HttpUtil and use another implementation. Do you have time to change this any time soon? Otherwise I’d be happy to help.

I’m already trying to fix this, but I could really need your help, since you are more fond of the whole library that OpenHAB provides.
My first attempt was using the checkValidity method with port 80 as parameter from, which prevents most of the log spam, but as soon as the AVR boots and has an available webserver on port 80, it will throw Fatal transport error: Read timed out since the webserver is available but it takes a while until it serves the XML files, so until the webserver fully started, it will throw SocketTimeoutExceptions…

It makes me pretty angry that these damn HTTPUtils catch their own exceptions, who in the world does this? A normal library would just provide it’s methods which throw exceptions which should be handled by the application that uses the library… IMHO this is total BS…

I’d just smash out those try catch clauses from the HTTPUtils, but I’m sure that when I do this, a million bindings would explode so I’d have to fix every single binding… But on the other hand I’d have to use workarounds just to get the denon binding to work properly, this is just stupid… I’m mad.

Probably have to reimplement the execute method from the HTTPUtils within the denon binding or just create my own HTTPUtils2 which would be the best alternative.

This is rather annoying indeed. Instead of changing HttpUtil I went with creating my own http request method. Code is here: What do you think?

Yeah I also considered it doing it this way, but I was a little busy lately so I haven’t done anything yet.
But as it seems I don’t have to, your code looks fine to me, ready for the pull request. :slightly_smiling: