Core: Single Synology DSM discovered again and again after already configured in UI

[tinuva]

The problem

In continuation of #35285
I have a single Synology DSM on a single ethernet port which is already configured within HA.
The problem I have is, it gets discovered again and again. There is also no way to disable Discovery for Synology DSM devices.

I am running HA in a Docker container on a separate device from the DSM.

I have removed and added the DSM in the UI multiple times to try and get around this. Using the DNS name on my network, currently using the IP address directly. None of the configurable options when setting it up makes a difference in this devices being discovered again.

Environment

• Home Assistant Core release with the issue: Multiple releases all the way from 0.109.4 up to 0.116.4 - I have upgraded to 0.117.0 but I am sure this issue will still be there
• Last working Home Assistant Core release (if known): I have had this issue for as long as I can remember, but only started using HA as of 2020 March
• Operating environment (OS/Container/Supervised/Core): Ubuntu 18.04 running it as the previous supervised setup
• Integration causing this issue: Synology DSM
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/synology_dsm/

Problem-relevant configuration.yaml

N/A - this is configured in the UI

Traceback/Error logs

Additional information

[tinuva]

Still happens in 0.117.0

[probot-home-assistant[bot]]

synology_dsm documentation
synology_dsm source
_{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @hacf-fr, @quentame, mind taking a look at this issue as its been labeled with an integration (synology_dsm) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[Quentame]

@raman325 created the same issue last night and close the issue him self :sweat_smile: #42531

See his investigations: https://github.com/home-assistant/core/issues/42531#issuecomment-718273450

When debugging zeroconf (used to discover integrations), he got this log:

2020-10-28 19:47:24 DEBUG (zeroconf-ServiceBrowser__xbmc-jsonrpc-h._tcp.local.-_esphomelib._tcp.local.-_ipp._tcp.local.-_viziocast._tcp.local.-_homekit._tcp.local.-_daap._tcp.local.-_http._tcp.local.-_nut._tcp.local.-_plugwise._tcp.local.-_wled._tcp.local.-_spotify-connect._tcp.local.-_googlecast._tcp.local.-_printer._tcp.local.-_ipps._tcp.local.-_ssh._tcp.local.-_api._udp.local.-_dkapi._tcp.local.-_elg._tcp.local.-_axis-video._tcp.local.-_bond._tcp.local.-_Volumio._tcp.local.-_hap._tcp.local.-_miio._udp.local._349) [homeassistant.components.zeroconf] Discovered new device diskstation._http._tcp.local. {'host': '169.254.145.222', 'port': 5000, 'hostname': 'diskstation.local.', 'type': '_http._tcp.local.', 'name': 'diskstation._http._tcp.local.', 'properties': {'_raw': {'vendor': b'Synology', 'model': b'DS1817+', 'serial': b'XXXXXXXXXX000', 'version_major': b'6', 'version_minor': b'2', 'version_build': b'25426', 'admin_port': b'5000', 'secure_admin_port': b'5001', 'mac_address': b'HIDDEN'}, 'vendor': 'Synology', 'model': 'DS1817+', 'serial': 'XXXXXXXXXX000', 'version_major': '6', 'version_minor': '2', 'version_build': '25426', 'admin_port': '5000', 'secure_admin_port': '5001', 'mac_address': 'HIDDEN'}}

I'll take a look, but following this code https://github.com/home-assistant/core/blob/2a795c039742c31a72323e382a98e89e0d1fbfa9/homeassistant/components/synology_dsm/config_flow.py#L177-L191 the integration already check if the discovered device does not exists in the MAC address of configured NAS... maybe we should check URLs too.

@tinuva & @raman325: can you check if the MAC address discovered with zeroconf is different from the one configured (check in [HA_config_bir]/.storage/core.config_entries) ?

Thanks

[tinuva]

I have the following entries:
Entry1:

                "entry_id": "18b28b8ea21e4bfb9b82ebf6fed67093",
                "version": 1,
                "domain": "synology_dsm",
                "title": "Ignored",
                "data": {},
                "options": {},
                "system_options": {
                    "disable_new_entities": false
                },
                "source": "ignore",
                "connection_class": "cloud_poll",
                "unique_id": "001132AC34CB"
            }

Entry2:

{
                "entry_id": "c7eadb54f9a211ea81668bca225d9a17",
                "version": 1,
                "domain": "synology_dsm",
                "title": "192.168.241.10",
                "data": {
                    "host": "192.168.241.10",
                    "port": "5000",
                    "ssl": false,
                    "username": "tinuva",
                    "password": "<removed>",
                    "mac": [
                        "00-11-32-AC-34-CB"
                    ]
                },
                "options": {},
                "system_options": {
                    "disable_new_entities": false
                },
                "source": "import",
                "connection_class": "cloud_poll",
                "unique_id": "1940PCxxxxx"
            }

[tinuva]

The actual mac address is:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:32:ac:34:cb brd ff:ff:ff:ff:ff:ff

I do have docker interfaces, but none of them shows anything that could explain the unique id 1940PCN588802

[tinuva]

Can I remove the ignored entry and move the unique id over?

[Quentame]

Can I remove the ignored entry and move the unique id over?

Emmmm, don't think this is a good idea

[Quentame]

The actual mac address is:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:32:ac:34:cb brd ff:ff:ff:ff:ff:ff

I do have docker interfaces, but none of them shows anything that could explain the unique id 1940PCN588802

Can you set the log level to debug to the zeroconf component described here : https://github.com/home-assistant/core/issues/42531#issuecomment-718245702 ?
And paste here the concerned log.

So we can check if the MAC and serial (config unique_id) are identical or not.

[tinuva]

2020-10-29 10:38:15 DEBUG (zeroconf-ServiceBrowser__ipp._tcp.local.-_miio._udp.local.-_nut._tcp.local.-_ipps._tcp.local.-_homekit._tcp.local.-_elg._tcp.local.-_hap._tcp.local.-_plugwise._tcp.local.-_printer._tcp.local.-_viziocast._tcp.local.-_axis-video._tcp.local.-_bond._tcp.local.-_http._tcp.local.-_Volumio._tcp.local.-_xbmc-jsonrpc-h._tcp.local.-_ssh._tcp.local.-_wled._tcp.local.-_dkapi._tcp.local.-_esphomelib._tcp.local.-_spotify-connect._tcp.local.-_api._udp.local.-_googlecast._tcp.local.-_daap._tcp.local._314) [homeassistant.components.zeroconf] Discovered new device diskstation._http._tcp.local. {'host': '192.168.241.10', 'port': 5000, 'hostname': 'diskstation.local.', 'type': '_http._tcp.local.', 'name': 'diskstation._http._tcp.local.', 'properties': {'_raw': {'vendor': b'Synology', 'model': b'DS218+', 'serial': b'1940PCxxxxx', 'version_major': b'6', 'version_minor': b'2', 'version_build': b'25426', 'admin_port': b'5000', 'secure_admin_port': b'5001', 'mac_address': b'00:11:32:ac:34:cb'}, 'vendor': 'Synology', 'model': 'DS218+', 'serial': '1940PCxxxxx', 'version_major': '6', 'version_minor': '2', 'version_build': '25426', 'admin_port': '5000', 'secure_admin_port': '5001', 'mac_address': '00:11:32:ac:34:cb'}}

Looking better json:

{
    'host': '192.168.241.10',
    'port': 5000,
    'hostname': 'diskstation.local.',
    'type': '_http._tcp.local.',
    'name': 'diskstation._http._tcp.local.',
    'properties': {
        '_raw': {
            'vendor': b 'Synology',
            'model': b 'DS218+',
            'serial': b '1940PCxxxxx',
            'version_major': b '6',
            'version_minor': b '2',
            'version_build': b '25426',
            'admin_port': b '5000',
            'secure_admin_port': b '5001',
            'mac_address': b '00:11:32:ac:34:cb'
        },
        'vendor': 'Synology',
        'model': 'DS218+',
        'serial': '1940PCxxxxx',
        'version_major': '6',
        'version_minor': '2',
        'version_build': '25426',
        'admin_port': '5000',
        'secure_admin_port': '5001',
        'mac_address': '00:11:32:ac:34:cb'
    }
}

[tinuva]

Serial matches my unique id.

[mib1185]

Hi,

the serial is set as unique_id:

https://github.com/home-assistant/core/blob/2a795c039742c31a72323e382a98e89e0d1fbfa9/homeassistant/components/synology_dsm/config_flow.py#L184

https://github.com/home-assistant/core/blob/2a795c039742c31a72323e382a98e89e0d1fbfa9/homeassistant/components/synology_dsm/config_flow.py#L190-L191

but the check for "already_configured" compares the unique_id with the mac addresses, not the serial numbers

https://github.com/home-assistant/core/blob/2a795c039742c31a72323e382a98e89e0d1fbfa9/homeassistant/components/synology_dsm/config_flow.py#L187-L188

https://github.com/home-assistant/core/blob/2a795c039742c31a72323e382a98e89e0d1fbfa9/homeassistant/components/synology_dsm/config_flow.py#L226-L233

@Quentame If you are to busy, I can fix this and create a PR.

regards,
michael

[Quentame]

@tinuva Serial matches my unique id.

Indeed, serial and mac_address matches your current configuration.

---

@Quentame If you are to busy, I can fix this and create a PR.

I would appreciate it :blush:
And if you want to get more involved into the component, you can add you as code owner, so you will be notified when issues are coming :relieved:

[raman325]

sorry for the flood of tickets @Quentame the reason I closed my ticket is because I assumed it was related to some other things I was doing. As an example, I have a macvlan network which I am using to allow my Synology NAS to use the pihole container it is hosting.

Anyway I looked again and now the IP discovered is different, showing an internal Docker now. Will have to test this a couple of times to figure out what's going on. Regardless, mac and serial matches my config entry, so I think @tinuva 's fix may resolve my issue as well

[mib1185]

https://github.com/home-assistant/core/blob/2a795c039742c31a72323e382a98e89e0d1fbfa9/homeassistant/components/synology_dsm/config_flow.py#L177
content of discovery_info:

{
  "ssdp_location": "http://192.168.100.200:5000/ssdp/desc-DSM-eth0.xml",
  "ssdp_st": "upnp:rootdevice",
  "deviceType": "urn:schemas-upnp-org:device:Basic:1",
  "friendlyName": "diskstation (DS218play)",
  "manufacturer": "Synology",
  "manufacturerURL": "http://www.synology.com",
  "modelDescription": "Synology NAS",
  "modelName": "DS218play",
  "modelNumber": "DS218play 6.2-25426",
  "modelURL": "http://www.synology.com",
  "modelType": "NAS",
  "serialNumber": "001132867ee2",
  "UDN": "uuid:73796E6F-6473-6D00-0000-001132867ee2",
  "serviceList": {
    "service": {
      "URLBase": "http://192.168.100.200:5000",
      "serviceType": "urn:schemas-dummy-com:service:Dummy:1",
      "serviceId": "urn:dummy-com:serviceId:dummy1",
      "controlURL": "/dummy",
      "eventSubURL": "/dummy",
      "SCPDURL": "/ssdp/dummy.xml"
    }
  },
  "presentationURL": "http://192.168.100.200:5000/",
  "ssdp_usn": "uuid:73796E6F-6473-6D00-0000-001132867ee2::upnp:rootdevice",
  "ssdp_ext": "",
  "ssdp_server": "Synology/DSM/192.168.100.200"
}

as you can see, the MAC address is given as serialNumber by DSM via SSDP, but not the real serial.

If this discovered DSM is "ignored" on UI it will be stored in .storage/core.config_entries with unique_id having the MAC address

            {
                "entry_id": "0120661028e281e9dd840f9a2dd6304d",
                "version": 1,
                "domain": "synology_dsm",
                "title": "Ignored",
                "data": {},
                "options": {},
                "system_options": {
                    "disable_new_entities": false
                },
                "source": "ignore",
                "connection_class": "cloud_poll",
                "unique_id": "001132867EE2"
            }

But if you setup the discovered (_same when configured manually via UI, without SSDP discovery_) DSM, it will be stored in .storage/core.config_entries with unique_id having the real serial

            {
                "entry_id": "fa0d90707624eaa81cf115768c392e12",
                "version": 1,
                "domain": "synology_dsm",
                "title": "192.168.100.200",
                "data": {
                    "host": "192.168.100.200",
                    "port": 5001,
                    "ssl": true,
                    "verify_ssl": false,
                    "username": "xxxxxxxx",
                    "password": "*****************",
                    "mac": [
                        "00-11-32-86-7E-E2"
                    ]
                },
                "options": {},
                "system_options": {
                    "disable_new_entities": false
                },
                "source": "user",
                "connection_class": "cloud_poll",
                "unique_id": "17C0Q********"
            }

summerized:
under usual conditions, it should not happen (_for me it was not possible to reproduce the issue on my "lab"_), that a configured DSM is still discovered, because discovered field 'serialNumber' already exists as mac address in .storage/core.config_entries and therefore ignored.
But if the same DSM is discovered with another mac address, it will be shown as new discovered DSM system.
Last but not least, I have to revert my last comment https://github.com/home-assistant/core/issues/42555#issuecomment-718678581 because the current code works as designed, it was a confusion on my side, because I expected that discovered field 'serialNumber' is the real serial number.

IMHO no code change is needed

regards,
Michael

---

And if you want to get more involved into the component, you can add you as code owner, so you will be notified when issues are coming 😌

I will think about it, I am not unwilling ;)

[tinuva]

Thank you for the investigation @mib1185

So if the code is working fine as is, how do I resolve my issue?

[mib1185]

Hi @tinuva ,

i have prepared a debug version (_based on 0.117.1_) on my own fork -> synology_dsm-debug and would kindly ask you to update to this debug version.
After you have updated, enable debug logging for the synology-dsm integration by adding the following lines to your configuration.yaml

logger:
  default: info
  logs:
    homeassistant.components.synology_dsm: debug

Please provide all loglines related to synology_dsm while homeassistant ist booting and the re discover of already configured DSM does appear.

If you need support for updating, than please do not hesitate to ask 😉

regards,
Michael

---

P.S.: note to me - implement in generell debug logging into synology_dsm 😃

[Quentame]

P.S.: note to me - implement in generell debug logging into synology_dsm

:eyes: :heart_eyes:

[tinuva]

Hi @tinuva ,

i have prepared a debug version (_based on 0.117.1_) on my own fork -> synology_dsm-debug and would kindly ask you to update to this debug version.
After you have updated, enable debug logging for the synology-dsm integration by adding the following lines to your configuration.yaml

logger:
  default: info
  logs:
    homeassistant.components.synology_dsm: debug

Please provide all loglines related to synology_dsm while homeassistant ist booting and the re discover of already configured DSM does appear.

If you need support for updating, than please do not hesitate to ask 😉

regards,
Michael

P.S.: note to me - implement in generell debug logging into synology_dsm 😃

ok so took me a while to figure out how to get this installed into my "unsupported" supervised install but got it I think.

2020-11-02 17:34:44 ERROR (MainThread) [homeassistant.components.synology_dsm.config_flow] {'api': None, 'code': -1, 'reason': 'Unknown', 'details': 'ConnectionError = <urllib3.connection.HTTPSConnection object at 0x7fb5c5f88c10>: Failed to establish a new connection: [Errno 113] Host is unreachable'}
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - discovery_info: {'ssdp_location': 'http://192.168.241.10:5000/ssdp/desc-DSM-eth0.xml', 'ssdp_st': 'upnp:rootdevice', 'deviceType': 'urn:schemas-upnp-org:device:Basic:1', 'friendlyName': 'diskstation (DS218+)', 'manufacturer': 'Synology', 'manufacturerURL': 'http://www.synology.com', 'modelDescription': 'Synology NAS', 'modelName': 'DS218+', 'modelNumber': 'DS218+ 6.2-25426', 'modelURL': 'http://www.synology.com', 'modelType': 'NAS', 'serialNumber': '001132ac34cb', 'UDN': 'uuid:73796E6F-6473-6D00-0000-001132ac34cb', 'serviceList': {'service': {'URLBase': 'http://192.168.241.10:5000', 'serviceType': 'urn:schemas-dummy-com:service:Dummy:1', 'serviceId': 'urn:dummy-com:serviceId:dummy1', 'controlURL': '/dummy', 'eventSubURL': '/dummy', 'SCPDURL': '/ssdp/dummy.xml'}}, 'presentationURL': 'http://192.168.241.10:5000/', 'ssdp_usn': 'uuid:73796E6F-6473-6D00-0000-001132ac34cb::upnp:rootdevice', 'ssdp_ext': '', 'ssdp_server': 'Synology/DSM/192.168.241.10'}
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - mac: 001132AC34CB
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - existing_macs: ['001132AC34CB']
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - async_abort(reason=already_configured)

[tinuva]

Is it possible its still there from a previous discovery stuck in my integrations page?

Edit:
Deleted my already configured device and configured the currently discovered device. Will wait for it to show up again as discovered then check the logs.

[mib1185]

ok so took me a while to figure out how to get this installed into my "unsupported" supervised install but got it I think.

2020-11-02 17:34:44 ERROR (MainThread) [homeassistant.components.synology_dsm.config_flow] {'api': None, 'code': -1, 'reason': 'Unknown', 'details': 'ConnectionError = <urllib3.connection.HTTPSConnection object at 0x7fb5c5f88c10>: Failed to establish a new connection: [Errno 113] Host is unreachable'}
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - discovery_info: {'ssdp_location': 'http://192.168.241.10:5000/ssdp/desc-DSM-eth0.xml', 'ssdp_st': 'upnp:rootdevice', 'deviceType': 'urn:schemas-upnp-org:device:Basic:1', 'friendlyName': 'diskstation (DS218+)', 'manufacturer': 'Synology', 'manufacturerURL': 'http://www.synology.com', 'modelDescription': 'Synology NAS', 'modelName': 'DS218+', 'modelNumber': 'DS218+ 6.2-25426', 'modelURL': 'http://www.synology.com', 'modelType': 'NAS', 'serialNumber': '001132ac34cb', 'UDN': 'uuid:73796E6F-6473-6D00-0000-001132ac34cb', 'serviceList': {'service': {'URLBase': 'http://192.168.241.10:5000', 'serviceType': 'urn:schemas-dummy-com:service:Dummy:1', 'serviceId': 'urn:dummy-com:serviceId:dummy1', 'controlURL': '/dummy', 'eventSubURL': '/dummy', 'SCPDURL': '/ssdp/dummy.xml'}}, 'presentationURL': 'http://192.168.241.10:5000/', 'ssdp_usn': 'uuid:73796E6F-6473-6D00-0000-001132ac34cb::upnp:rootdevice', 'ssdp_ext': '', 'ssdp_server': 'Synology/DSM/192.168.241.10'}
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - mac: 001132AC34CB
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - existing_macs: ['001132AC34CB']
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - async_abort(reason=already_configured)

theese debug lines looks good and shows that code works as expected.
Therefore I´m looking forward if (hopefully not) your DSM is still re-discovered.

regards,
Michael

[Quentame]

2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - discovery_info: {'...': '...', 'serialNumber': '001132ac34cb', '...': '...'}
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - mac: 001132AC34CB
2020-11-02 17:35:13 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - existing_macs: ['001132AC34CB']

serialNumber == MAC ? 🤔

[mib1185]

jepp ... this is what is provided in discovery_info when async_step_ssdp() is called.
I´m not sure, but guess that discovery_infois provided from zeroconf integration?!

[Quentame]

Yes, Oh yeah a serial for zeroconf might be its MAC ...

[tinuva]

ok I don't know what to say. Something doesn't make sense.

I just restarted home assistant now to reload updated configs, and I get a notification there is a new device discovered. Double check, its the Synology DSM.

However the logs show it should have been aborted:

root@trex:/data# cat /data/docker/hassio/homeassistant/home-assistant.log | grep -i synology
2020-11-07 14:42:59 ERROR (MainThread) [homeassistant.components.synology_dsm.config_flow] {'api': None, 'code': -1, 'reason': 'Unknown', 'details': 'ConnectionError = <urllib3.connection.HTTPSConnection object at 0x7f4d94d56e50>: Failed to establish a new connection: [Errno 113] Host is unreachable'}
2020-11-07 14:43:20 DEBUG (zeroconf-ServiceBrowser__ipp._tcp.local.-_homekit._tcp.local.-_nut._tcp.local.-_elg._tcp.local.-_api._udp.local.-_googlecast._tcp.local.-_ipps._tcp.local.-_viziocast._tcp.local.-_ssh._tcp.local.-_http._tcp.local.-_daap._tcp.local.-_hap._tcp.local.-_spotify-connect._tcp.local.-_plugwise._tcp.local.-_axis-video._tcp.local.-_Volumio._tcp.local.-_wled._tcp.local.-_bond._tcp.local.-_esphomelib._tcp.local.-_miio._udp.local.-_dkapi._tcp.local.-_xbmc-jsonrpc-h._tcp.local.-_printer._tcp.local._328) [homeassistant.components.zeroconf] Discovered new device diskstation._http._tcp.local. {'host': '192.168.241.10', 'port': 5000, 'hostname': 'diskstation.local.', 'type': '_http._tcp.local.', 'name': 'diskstation._http._tcp.local.', 'properties': {'_raw': {'vendor': b'Synology', 'model': b'DS218+', 'serial': b'1940PCN588802', 'version_major': b'6', 'version_minor': b'2', 'version_build': b'25426', 'admin_port': b'5000', 'secure_admin_port': b'5001', 'mac_address': b'00:11:32:ac:34:cb'}, 'vendor': 'Synology', 'model': 'DS218+', 'serial': '1940PCN588802', 'version_major': '6', 'version_minor': '2', 'version_build': '25426', 'admin_port': '5000', 'secure_admin_port': '5001', 'mac_address': '00:11:32:ac:34:cb'}}
2020-11-07 14:43:28 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - discovery_info: {'ssdp_location': 'http://192.168.241.10:5000/ssdp/desc-DSM-eth0.xml', 'ssdp_st': 'upnp:rootdevice', 'deviceType': 'urn:schemas-upnp-org:device:Basic:1', 'friendlyName': 'diskstation (DS218+)', 'manufacturer': 'Synology', 'manufacturerURL': 'http://www.synology.com', 'modelDescription': 'Synology NAS', 'modelName': 'DS218+', 'modelNumber': 'DS218+ 6.2-25426', 'modelURL': 'http://www.synology.com', 'modelType': 'NAS', 'serialNumber': '001132ac34cb', 'UDN': 'uuid:73796E6F-6473-6D00-0000-001132ac34cb', 'serviceList': {'service': {'URLBase': 'http://192.168.241.10:5000', 'serviceType': 'urn:schemas-dummy-com:service:Dummy:1', 'serviceId': 'urn:dummy-com:serviceId:dummy1', 'controlURL': '/dummy', 'eventSubURL': '/dummy', 'SCPDURL': '/ssdp/dummy.xml'}}, 'presentationURL': 'http://192.168.241.10:5000/', 'ssdp_usn': 'uuid:73796E6F-6473-6D00-0000-001132ac34cb::upnp:rootdevice', 'ssdp_ext': '', 'ssdp_server': 'Synology/DSM/192.168.241.10'}
2020-11-07 14:43:28 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - mac: 001132AC34CB
2020-11-07 14:43:28 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] _mac_already_configured - existing_macs: ['001132AC34CB']
2020-11-07 14:43:28 DEBUG (MainThread) [homeassistant.components.synology_dsm.config_flow] async_step_ssdp - async_abort(reason=already_configured)

[tinuva]

I removed the "ignored" entry from my entries file in storage.

So now this is interesting. I do not have any DSMs configured, only a single DSM on the network, and now I see this:

So the hostname on my DSM is "diskstation" and that is the one it looks like I will be able to ignore. So now where is this first DSM without a hostname, coming from and also why am I not able to ignore it?
Is there another discovery path somehow that I am unaware off?

[mib1185]

Hi @tinuva ,

sorry for late response.
The synology_dsm integration only applies to ssdp discovery, but not sure if there might be overlapping with zeroconf possible 🤔
Please could you click on 'configure' of both items and provide a screenshot of each of the next user input dialog (_without changing any data fields_)?
Also not sure, if there might be any relics of an previous configured DSM somewhere and somehow in your configuration files or the /config/.storage 🤔
regards,
Michael

[tinuva]

Sure.

Without changing any values, this is what I see.

First, the problematic one, which doesn't have an ignore button and seems to always re-appear, even if I configure it:


As you can see, hostname field is empty on it.

Then the second one, if I configure this one, it will not come back and work as expected and from the above log entries:

[tinuva]

Also tried to grep for synology in .storage but nothing found while nothing is configured:

root@trex:/data/docker/hassio/homeassistant/.storage# pwd
/data/docker/hassio/homeassistant/.storage
root@trex:/data/docker/hassio/homeassistant/.storage# grep -lir "synology" *
root@trex:/data/docker/hassio/homeassistant/.storage#

[tinuva]

ok I am embarrassed to admit this but I think I found the issue.

In my main home assistant config folder I found this:

root@trex:/data/docker/hassio/homeassistant# grep -lir "synology" *
home-assistant.log
home-assistant_v2.db
includes/logger.yaml
packages/synology_dsm.yaml
secrets.yaml

After commenting out the setup in packages/synology_dsm.yaml

#synology_dsm:
#  - host: !secret synology_dsm_host
#    username: !secret synology_dsm_username
#    password: !secret synology_dsm_password

It looks like the Synology DSM without the ignore button is now history.
Would've preferred a warning or error in the logs that say I should remove the synology_dsm: config instead of this really strange behavior. I believe I must have missed the part in the changelogs which states I should remove it if I have.

Apologies for sending you guys down a rabbit hole on this issue!

[mib1185]

Hi @tinuva ,

first, nice to hear, that you could identify the cause.
According the behaviour, when still yaml configured exists for synology_dsm integration, it is works as designed, because the integration will still read the yaml configureation by async_setup() but is forwarded to config-flow based setup by async_step_import() ... in other words - the integration does not and can not know if the existing yaml configuration is still wanted or not 😉
But there is an open PR #42777 to remove the old yaml configuration approach from synology_dsm.

regards,
Michael

[raman325]

I also had an errant entry left in my configuration.yaml and removing it resolved the issue 🤦🏾

[mib1185]

Hi @tinuva ,

because the cause is found and not related to an bug in code, may I kindly ask you you to close this issue?
The open point of removing old yaml configuration approach is still addressed within #42777 , but not really related to the issue itself.

regards,
Michael

[tinuva]

Hey @mib1185

Happy to close as my issue is resolved and by the looks of it, the exact same resolution worked for @raman325 (was keeping it open initially to see if he still has the issue).

Thank you for your support!