home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
70.45k stars 29.38k forks source link

Denon AVR is not being detected by the config flow #37484

Closed ghost closed 4 years ago

ghost commented 4 years ago

The problem

My Denon AVR is not being detected by the config flow (also not with manual IP) I can't use my Denon anymore. Has worked for years before :-(

Environment

Problem-relevant configuration.yaml

THE PREVIOUS configuration.yaml SETTING I USED BEFORE. IT'S NOW REMOVED. media_player:

Traceback/Error logs

If I don't enter a IP in the config flow it says: Failed to discover a Denon AVR Network Receiver

And if I do enter a manual IP adres it says: Failed to connect, please try again
and registers in the log these two:

2020-07-05 11:18:35 WARNING (ThreadPoolExecutor-11_1) [DenonAVR] Receiver name could not be determined. Using standard name: Denon AVR.

2020-07-05 11:18:35 ERROR (MainThread) [homeassistant.components.denonavr.receiver] Missing receiver information: manufacturer 'None', name 'Denon AVR', model 'None', type 'avr'

Additional information

But if I press the big plus sign. Lookup Denon, enter your IP/hostname.

192.168.66.9

I get: Failed to connect, please try again. And it has been working for years before updating to 112.2

elupus commented 4 years ago

It can still by added manually by config flow even if it's not detected auto.

probot-home-assistant[bot] commented 4 years ago

denonavr documentation denonavr source (message by IssueLinks)

probot-home-assistant[bot] commented 4 years ago

Hey there @scarface-4711, @starkillerog, mind taking a look at this issue as its been labeled with an integration (denonavr) you are listed as a codeowner for? Thanks! (message by CodeOwnersMention)

elupus commented 4 years ago

No what doesn't? The config flow support manual entry of hostname.

Docs are indeed wrong. But you don't need it to be automatically detected for config flow to work.

elupus commented 4 years ago

PS. You should still remove it from your yaml config.

elupus commented 4 years ago

To be even more explicit. Go into the integration page in home assistant. press the big plus sign (bottom right i think). Lookup Denon, enter your IP/hostname.

elupus commented 4 years ago

It was turned on when your tried this right? Check the logs if they give a clue.

starkillerOG commented 4 years ago

@MrUserY try disconecting mains power, wait 10 sec plug it back in and try the setup again.

Any messages in the log when you get the connection error during config flow?

elupus commented 4 years ago

I'm somewhat thinking he may have been hit by the really bad idea of using get_mac to get unique id. Given your IP range, @MrUserY , are your home assistant on a separate vlan/subnet?

ghost commented 4 years ago

I've rebooted, and did the things with the powerplug. Still no connection. Her's my complete log after this reboot:

` 2020-07-05 11:06:35 WARNING (MainThread) [slixmpp.stringprep] Using slower stringprep, consider compiling the faster cython/libidn one.

2020-07-05 11:06:40 ERROR (MainThread) [homeassistant.core] Error doing job: Task was destroyed but it is pending!

2020-07-05 11:07:32 ERROR (SyncWorker_9) [DenonAVR] No connection to /goform/AppCommand.xml end point on host 192.168.66.9

2020-07-05 11:07:32 ERROR (SyncWorker_9) [DenonAVR] Getting renamed and deleted sources failed.

2020-07-05 11:07:41 WARNING (ThreadPoolExecutor-0_1) [DenonAVR] Receiver name could not be determined. Using standard name: Denon AVR.

2020-07-05 11:07:47 ERROR (MainThread) [homeassistant.components.denonavr.receiver] Missing receiver information: manufacturer 'None', name 'Denon AVR', model 'None', type 'avr' `

ghost commented 4 years ago

I'm somewhat thinking he may have been hit by the really bad idea of using get_mac to get unique id. Given your IP range, @MrUserY , are your home assistant on a separate vlan/subnet?

Everything is on the same network. Not in a seperate VLAN.

elupus commented 4 years ago

Odd, I'll have to defer to @starkillerOG . No idea of the internals here.

ghost commented 4 years ago

This is how it's discovered in Bonjour network: (does that help?)

Service name: _http._tcp. DENON DN-500AV DENON-DN-500AV.local. 192.168.66.9:80

Service name: _raop._tcp. 0005CDC0D47B@DENON DN-500AV DENON-DN-500AV.local. 192.168.66.9:1027

The device uses the regular DenonAVR protocol.

MartinHjelmare commented 4 years ago

I'm somewhat thinking he may have been hit by the really bad idea of using get_mac to get unique id.

get_mac is not used anymore to get a unique_id. It's optional now and only used to get a mac address to use in the device info connections set.

ghost commented 4 years ago

Hi, I'm having the same issue since the newest home assistant update. Edit: I just tried the Denon avr UI Integration, and it has less features than the old one I configured via my configuration.yaml. Is there a way I can get the old one back?

starkillerOG commented 4 years ago

@MrUserY clearly there is something wrong with device communication here. Probably the description xml is not located at the right place or is malformed or something....

could you post the XML from this address: http://192.168.1.IP:8080/description.xml

Or maybe for your receiver it schould be: http://192.168.1.IP:80/description.xml just a guess based on the bonjour info.

@MartinHjelmare is there an easy way for @MrUserY to see what ssdp discovers (netdisco) (I mean also the devices that are not properly recognized in the manifest.json)?

starkillerOG commented 4 years ago

No what doesn't? The config flow support manual entry of hostname.

Docs are indeed wrong. But you don't need it to be automatically detected for config flow to work.

What is wrong with the docs? The timeout is not available anymore so I did make a PR to remove that from the docs, but the rest of the docs are correct I think...

starkillerOG commented 4 years ago

Hi, I'm having the same issue since the newest home assistant update. Edit: I just tried the Denon avr UI Integration, and it has less features than the old one I configured via my configuration.yaml. Is there a way I can get the old one back?

All features are still there, you first need to setup the integration and afterwords those options are configurable using options flow.

starkillerOG commented 4 years ago

And YAML configuration is depricated, that old method is not available anymore

starkillerOG commented 4 years ago

@Sjorsa2 are you able to setup the integration through config flow or not?

ghost commented 4 years ago

@starkillerOG Yes, I missed that there was an "options" button on the integration, thanks! I was missing multiple zones, but they are back now!

elupus commented 4 years ago

No what doesn't? The config flow support manual entry of hostname. Docs are indeed wrong. But you don't need it to be automatically detected for config flow to work.

What is wrong with the docs? The timeout is not available anymore so I did make a PR to remove that from the docs, but the rest of the docs are correct I think...

"CONFIGURATION VARIABLES" uses the nomenclature of old style yaml config. All those entries are going to be translated to other names when displayed in Option Flow. I may have been somewhat too quick, to say they are wrong. But it should be more clear that it's configuration flow fields.

ghost commented 4 years ago

clearly there is something wrong with device communication here. Probably the description xml is not located at the right place or is malformed or something....

could you post the XML from this address: http://192.168.1.IP:8080/description.xml

Or maybe for your receiver it schould be: http://192.168.1.IP:80/description.xml just a guess based on the bonjour info.

@MartinHjelmare is there an easy way for @MrUserY to see what ssdp discovers (netdisco) (I mean also the devices that are not properly recognized in the manifest.json)?

@starkillerOG Oh wow, nice information page you get when I do that! Here's the XML! description.txt

ghost commented 4 years ago

I was wrong about the documentation. I didn't notice that sneeky basterd change or it kept the old text in my browser cache I don't know. But I'm sorry for not noticeing that documentation part. I've updated this post because of this.

But the configflow non-detection issue of the Denon remains! I supplied you with the XML above. :-)

starkillerOG commented 4 years ago

@MrUserY Alright got it, the problem is that the manufacturer is listed as "DENON PROFESSIONAL", currently only "DENON", "Denon" and "Marantz" are accepted...

Will make a PR to fix this.

Just to be sure, did you use http://192.168.1.IP:8080/description.xml or http://192.168.1.IP:80/description.xml? (Which port did you use?)

ghost commented 4 years ago

Hi,

I used http://192.168.1.IP:8080/description.xml

Yeah Denon Professional is just Denon, but with a professional touch. Like Maranz Professional. Same company, same Denon AVR protocol.

Would be great if you can add it. Thanks!

skynet01 commented 4 years ago

For me, the popular Denon HEOS7 speaker is also not properly identified so the log has these errors:

Host 172.16.3.166 returned HTTP status code 403 to GET request at end point /goform/formMainZone_MainZoneXml.xml Unable to get device information of host 172.16.3.166, can not use the serial number as identification Host 172.16.3.166 returned HTTP status code 403 to GET request at end point /goform/formMainZone_MainZoneXmlStatus.xml Receiver name could not be determined. Using standard name: Denon AVR.

Which then further results in thousands of these errors, which makes sense since it doesn't have any sources :)

` Logger: DenonAVR Source: components/denonavr/media_player.py:144 First occurred: July 5, 2020, 3:29:13 PM (19821 occurrences) Last logged: 10:37:27 AM

Host 172.16.3.166 returned HTTP status code 403 to POST command at end point /goform/AppCommand.xml Getting renamed and deleted sources failed. Host 172.16.3.166 returned HTTP status code 403 to GET request at end point /goform/formMainZone_MainZoneXml.xml Missing status information from XML of Main for: Power, InputFuncSelect, Mute, MasterVolume No connection to /goform/AppCommand.xml end point on host 172.16.3.166 `

ghost commented 4 years ago

Should’t the Denon Heos platform be used instead of the Denon AVR?

starkillerOG commented 4 years ago

@skynet01 did the HEOS7 used to work in the previous homeassistant version?

I do not think HEOS speakers can be controlled using the DenonAVR integration. I know there is a dedicated heos integration specifically for Heos speakers.

Denon/Marantz AVR receivers that also support Heos are supported by the DenonAvr integration but pure heos speakers like the heos5 and heos7 will probably not work, but I am not completely sure....

skynet01 commented 4 years ago

Yep, that's what I use :) But unfortunately, integration still finds it and tries to add it (but I also have Marantz receiver that works properly with this integration so I do need this integration for my primary receiver). Manual integration sorta worked with HEOS7 (i could power it off and that's about it), but HEOS integration provided way more control so I switched to that just for the speaker.

Maybe there is a way to exclude Denon Heos speakers somehow? Since you can't remove them from integration.

starkillerOG commented 4 years ago

@skynet01 could you post the xml from this address for the HEOS7: http://192.168.1.IP:60006/upnp/desc/aios_device/aios_device.xml

Then I can look if there is something to exclude the HEOS speakers...

If you also have a Marantz receiver that is capable of HEOS, please also post the xml of that device using the same address but diffrent IP.

starkillerOG commented 4 years ago

In the meantime you schould be able to ignore the discovered HEOS7 speaker. If you hit the ignore button it schould not show up again...

skynet01 commented 4 years ago

Is there a way to remove a single device without removing the whole integration? Since i don't want to remove my Marantz. Attached is the file you need (rename it to .XML) aios_device.txt

ol-iver commented 4 years ago

I'm somewhat thinking he may have been hit by the really bad idea of using get_mac to get unique id.

get_mac is not used anymore to get a unique_id. It's optional now and only used to get a mac address to use in the device info connections set.

There are two issues with auto discovery I identified in my own setup using the docker version of home assistant with a bridged network.

  1. SSDP broadcast does not return a proper result, because it is send using the IP of the bridged network adapter home assistant uses. The receiver is in a different network
  2. getmac does not return the mac address because it tries to get it from /proc/net/arp. This is empty in the container and only populated in the host machine.

This is rather a general issue than a denonavr specific one. How do other platforms solve this? For issue 1. it might help in some setups to send the SSDP broadcast to the network of the "Internal URL" in homeassistant Regarding issue 2. /proc/net/arp of the host machine could be mounted into the home assistant container.

elupus commented 4 years ago

Ssdp can do IP address directed discovery for manually setup.

ol-iver commented 4 years ago

It works when I enter the IP manually. I'm just thinking that it would be nice to fix auto discovery for docker setups.

starkillerOG commented 4 years ago

@skynet01 I made a PR to ignore the HEOS speakers, that schould fix your issue.

starkillerOG commented 4 years ago

@scarface-4711 you are right that the SSDP is not an issue of the denonavr integration but more general for all integrations that use SSDP with the setup you mentioned.

I do not know the details of getmac, but sounds like that is an issue that needs to be opened in the getmac lib, anyway the mac is not really nessesary for the denonavr integration anyway, so it will not impact any performance. Does the getmac log an error? if so we could lower that to debug level since it is not important.

ghost commented 4 years ago

Case closed, but hey YEAH IT WORKS! 122.4

ghost commented 4 years ago

Oh wait. Every reboot the log says:

Receiver name could not be determined. Using standard name: Denon AVR. 3:52:28 PM – util/thread.py (WARNING)

Error is fine, but doesn't need to tell that every reboot right? Small "beauty error" that maybe can taken in a feature fix?

ghost commented 4 years ago

@starkillerOG Did you note this commend after the issue was closed? Can this "Receiver name could not be determined" for the DN500AV be fixed? I Don't want to open a new issue for something so small. Would be a small beauty fix to keep de logs clean ;-)

starkillerOG commented 4 years ago

@MrUserY did you set a friendly name in the receiver itself (settings of the receiver)? I will make a PR to reduce the log level of that warning to info. In principle it is a valid warning because apperently your device info xml is missing the friendly name, not that important (hence the proposed reduction of log level) but still a valid issue.

Will probably not be fixed untill some other problem which is more serious requires an update of the lib, a new version release just for this is a bit overkill I think. But will be fixed somewhere in the future.

ghost commented 4 years ago

Thanks keep the issue on the list for future change!

I’ve never changed the friendly name in the settings, think I’ll still the standard setting. The current setting should be in the XML I attached in the original issue then. It could be that this one is also slightly different the from other Denon devices and that way wont’t be recognized. Anyway I’ll look in to it.

Thanks.

ghost commented 4 years ago

@starkillerOG Changed Friendly name in settings. But error still persists. Just for info, so you know!

Receiver name could not be determined. Using standard name: Denon AVR. 2:42:19 PM – /usr/local/lib/python3.8/site-packages/denonavr/denonavr.py (WARNING)