-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upnp - Device not discovered #110216
Comments
Hey there @StevenLooman, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) upnp documentation |
Hello, I did some investigations and managed to make my device work by making some changes in the source code. Basically the modifications searches the device in the ssdp cache before trying the formerly designed solution. |
Thank you for the issue @bigfoot38, investigating and providing a potential fix! I'll take a look at it shortly. |
Again @bigfoot38, thank you for investing time into investigating this. Let's look at the changes. The next code listing contains the part you've changed. Feel free to create a PR in the future! This makes reviewing and commenting also a bit easier. async def async_setup_entry(hass: HomeAssistant, entry: ConfigEntry) -> bool:
...
async with asyncio.timeout(10):
LOGGER.debug("Searching in cache: %s, at: %s", udn, st)
discovery_info = await ssdp.async_get_discovery_info_by_udn_st(hass, udn, st)
if discovery_info is None:
for di in await ssdp.async_get_discovery_info_by_st(hass, st):
LOGGER.debug("udn for st: %s : %s", st, di.ssdp_udn)
LOGGER.debug("di : %s", di)
if di.upnp['UDN'] == udn:
usn = f"{di.ssdp_udn}::{st}"
discovery_info = di
break
if discovery_info is not None:
LOGGER.debug("Device from cache: %s, at: %s", udn, discovery_info)
else:
LOGGER.debug("Device not in cache.")
async def device_discovered(
headers: ssdp.SsdpServiceInfo, change: ssdp.SsdpChange
) -> None:
if change == ssdp.SsdpChange.BYEBYE:
return
nonlocal discovery_info
LOGGER.debug("Device discovered: %s, at: %s", usn, headers.ssdp_all_locations)
discovery_info = headers
device_discovered_event.set()
cancel_discovered_callback = await ssdp.async_register_callback(
hass,
device_discovered,
{
"usn": usn,
},
)
try:
async with asyncio.timeout(10):
await device_discovered_event.wait()
except asyncio.TimeoutError as err:
raise ConfigEntryNotReady(f"Device not discovered: {usn}") from err
finally:
cancel_discovered_callback()
...
By this part you most likely mean the block in the first with-statement (i.e., A bit of explanation about the ssdp-component. The cache you mention is not really a cache. Rather, it is the actual list of devices the ssdp-component has seen. Whenever a new device is seen, this device is added to this list. Also, whenever a device is no longer seen (or notifies that it will be going offline), the device is purged from this list. Any interaction from components such as this upnp component, is on this list. This is a bit of a simplification though, but it The function does core/homeassistant/components/ssdp/__init__.py Lines 306 to 317 in 3e67b98
In essence, the new changes does duplicate work by first trying to match manually, and later on the matching is done "in" the register-callback mechanism. However, why does your change match the Sagem router, why the original does code not? The UPnP Device Architecture 2.0 document describes the UPnP architecture and the messages sent between devices. Chapter 1 describes the discovery process, what we are using here. The document states that a USN (Unique Service Name) identifies a unique instance of a device or a service. It is a combination of the UDN (Unique Device Name) and optionally the ST (Search Target). I think you are familiar with both, given the changes you've done. An example of a USN the upnp component uses is In your logs (thank you for providing those!), the USN is logged as The UDN is found (via the USN) in the search mechanism, and also in the device description part. An XML file describes the device and the capabilities of this device. You can see this when you point your browser to I do think the UDN found in the device description differs from the UDN found in the search responses and that this is the reason why the device is never matched. When the config entry is created the UDN from the device description is used. Then, when initializing the component from the config entry, the UDN is different and thus not matched. Your change uses the UDN from the device description which is why it works for you. Sorry for the lengthy reply. This goes very deep very fast and I hope this is comprehensible for you. To investigate a bit further, please provide the logging including your change. This reports the UDN and ST and the In the end though, I do think your router does not conform to the UPnP specification and is the reason why the Sagem router isn't detected. |
Thanks for the explanations, They makes things much clearer. My intention was mainly to try to make my device working with the idea that it may help for debugging. My knowledge in that field are almost zero, I was like, well, trying to open a can with a screwdriver. Please find enclosed the log you requested. Regards |
Thank you for the logging @bigfoot38. As expected, it seems the UDN the router reports via SSDP/search is different than it reports via the device description/XML. A part of the logging:
Above lists the discovery info/ These values differ and as a result, the discovery info is not used (regularly, your patch changes this and thus is working for you). However, the question is perhaps why is the stored I'll see if the used |
@bigfoot38 is it possible for you to test the mentioned PR? |
Tried it out, it works well. |
Thank you for testing and providing the logs. I don't see anything off in the logs, except for the Device Description-UDN used here and there. I'd like to make one change to make sure existing entries don't break. This searches for both the Device Description-UDN (such as it is now) and the SSDP-UDN for the If you want to, you could file a bug with Sagem, stating the UDNs are different and point to this issue. Hopefully they can fix the mismatch and prevent future errors (in systems other than Home Assistant). Though I do understand you do not want to do this and/or Sagem won't even corporate. |
Your welcome, thank you for making my device working with home assistant. I tested your latest changes and it still work:
I will try to fill up a bug with Sagem. However, this device is the property of my internet provider who may has modified the firmware since its logo is on the router's web interface. |
The problem
A Upnp device (Sagem F@ST3286) is shown as available in HomeAssistant "Integrations". I tried to add the corresponding integration to use it but HomeAssistant fails to configure the device with this message: "Configuration failed, trying again" (translated from french, the english wording may differ). When moving the mouse on the message, a tooltip states: "Device not discovered: uuid: 277F2473-1148-4B42-B509-435C99884FD2...".
I activated the log, but this message does not appears. The only message reported from the "upnp" component is:
[homeassistant.components.upnp] Setting up config entry: 9389736d1da1f230e5c1c5360f942529
There is no message after this one during 30 seconds. From the source code, I understand that something should happen within 10s. Tried to dig further, but without success.
What version of Home Assistant Core has the issue?
core-2023.12.3
What was the last working version of Home Assistant Core?
First time using HomeAssistant
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Upnp
Link to integration documentation on our website
https://www.home-assistant.io/integrations/upnp
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response
The text was updated successfully, but these errors were encountered: