I recently upgraded my Denon receiver to a new model, which now also supports an HTTP protocol that my 17 years old receiver didn’t. I have the new protocol working, but somewhere between my old and new receiver there were models supporting another variant of the protocol. Probably somewhere around 2015-2016 things changed a bit.
I would like to hear from anyone using the binding with older models (I should be covered for now with brand new models), and who would be willing to run a few tests.
Currently I’m assuming that receivers exposing the API through port 8080 have a slightly different API than those exposing the API on port 80 (same as the web UI). However, I don’t know this for sure, so I would like to verify it.
It will involve:
Telling me the model name.
Installing a JAR for testing the new version of the binding (currently 4.2, but can backport to 4.0/4.1 as well if needed).
Performing a few HTTP requests - it can be done simply from a browser.
I can help, too.
1.) AVR X4500H
2.) openhab 4.2.0.M2 (development) + openhab 4.1.2 (“production”, AVR actually connected via Telnet)
btw :
1.) port 80 is redirected on my AVR to port 10443; port 8080 shows err 403.
2.) I’m using a bash script to collect video+audio codec infos from https://IP:10443/ajax/general/get_config?type=12
Hope you’re new binding adds channels for this type of info.
First, let me briefly go back to the already merged PR improving discovery. Probably there was a reason for the logic that in my case lead to the auto-generated label “Denon AVC-X4800H (Marantz Denon AVC-X4800H)”, so I would like to check with you how your discovery results now look like.
I have a suspicion they might now in some cases be like “AVR-X4500H” without “Denon” in front of it. In that case I need to prepare a small fix. However, this test would require you to delete your Thing in order to perform a scan for new DenonMarantz Things. It’s totally fine if you’d like to skip this test.
Now the real test…
If you are currently using Telnet, please disable that and check which port works for you (80 or 8080):
Now, please perform the following requests (in Postman, curl or whatever suits you, replace ‘denon’ with your receiver IP or hostname and 8080 with 80 if needed):
Hi Jacob,
1.) I’m running OH 4.2.0.M2 on DietPi 9.4.2/Docker 26.1.3. Just moved your jar-file to addons directory and got errors :
Error while starting bundle: file:/openhab/addons/org.openhab.binding.denonmarantz-4.2.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.denonmarantz [296]
Unresolved requirement: Import-Package: org.openhab.core.config.discovery.upnp
So I moved your jar-file to :
bash> ls -l /openhab/userdata/tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.denonmarantz/4.2.0.M2/
total 156
-rw-r--r-- 1 openhab openhab 70987 Mai 18 10:07 org.openhab.binding.denonmarantz-4.2.0.M2.jar.M2
-rw-r--r-- 1 openhab openhab 40 Mai 18 10:07 org.openhab.binding.denonmarantz-4.2.0.M2.jar.sha1.M2
-rwxr-xr-x 1 openhab openhab 77255 Mai 18 10:00 org.openhab.binding.denonmarantz-4.2.0-SNAPSHOT.jar
-rw-r--r-- 1 openhab openhab 41 Mai 18 11:27 org.openhab.binding.denonmarantz-4.2.0-SNAPSHOT.jar.sha1
Is this the right place for deployment in a dockered environment?
Anyway, I got a THING labeled “ki-avr (Denon AVR-X4500H)” getting online after setting to HTTP-Port 8080 (ki-avr=HOSTNAME)
2.) see below for test results:
I guess you would need another binding installed with this dependency, since I provided a JAR, not a KAR. You could for example try to install the HEOS binding normally, and see if that resolves the issue.
I can also help giving some test on this.
I’ve got an mr612 and a sr8015.
I’m off home this week because of famille concerns, but will give a try next week.
Thanks, so it appears to be completely compatible with my 2022 model. Did the new binding version also work correctly for you when using the HTTP protocol?
Thanks. Marantz SR8015 is from 2020, so I would expect it to work. I was not able to find MR612, is that the exact model name?
At this point I’m mostly interested in receivers introduced before 2018, especially between 2008 and 2015. However, any testing of the provided JAR is also valuable as I could have overlooked something in my own tests.
@laursen I have a Denon AVR-4520ci receiver, circa 2013 and am still running OH 4.1.1 and have not tried your updated binding, but I ran your exported POSTMAN query using port 80. For what it is worth here is the output:
I assume the M3 tests are without the provided JAR?
That’s a bit strange, because M3 and provided JAR has the same discovery changes. I guess it could be random, depending on whether the receiver is discovered through UPnP or mDNS. I don’t know if Docker could affect result. Can you try to run the discovery process while having debug logging enabled? And perhaps also paste the properties of the created Thing, i.e. something like:
modelId Denon AVC-X4800H
vendor Denon
That’s expected, since M3 doesn’t have the HTTP protocol improvements from the provided JAR.
Can you elaborate? Which channels doesn’t work with the JAR? The URL http://192.168.23.71:8080/goform/formMainZone_MainZoneXml.xml should not be requested by the JAR so I assume that’s M3 without the JAR, thus is not expected to work.
I assume this test is for port 80, and you receiver is responding to API requests on port 8080 only, correct?
Thank you. That’s very interesting because model year on that receiver is 2012, and it seems to support both old and new requests on port 80. So far I’ve only seen AppCommand.xml POST requests work on port 8080 on 2016+ models, and formMainZone_MainZoneXml.xml GET requests work on pre-2016 models on port 80.
The changes being made in the binding should not affect you, since the port 80 protocol implementation will not be changed. But it does mean that the presence of the AppCommand.xml POST request support is not directly tied to the port number. So far it doesn’t cause any problems, it would be worse to find a receiver NOT supporting that on port 8080.
@laursen I have a AVR-X2300W from around 2016 / 2017. API is responding on port 80 (getting 404 Not found on port 8080). Here are the responses for the different requests:
Based on the latest feedback, I have made some adjustments and created a version that will initially try to auto-detect the protocol details when starting the HTTP polling. This new version should work with all receivers supporting HTTP:
Not sure that I can add much, except that there were several firmware updates over the years. The last was in 2018 I believe. Perhaps Denon moved to a more unified firmware across its AVR lineup over the years(purely speculation). From 2012-2014 the AVR 4520CI was their flagship AVR model and was supported at least through 2018 with firmware updates.
Having said that, after removing Denon 4.1.1 binding, I installed your latest 4.1.3 and all seems fine. So far no difference between 4.1.1 and 4.1.3 as far as functionality.
I have the new protocol working, but somewhere between my old and new receiver there were models supporting another variant of the protocol. Probably somewhere around 2015-2016 things changed a bit.
