WARN message every second: RetrieveRemoteDescriptors - Device descriptor retrieval failed

  • Platform information:

    • Hardware: Raspberry Pi 3 Model B Rev 1.2
    • OS: openHABian (current release) / Raspbian GNU/Linux 8 (jessie)
    • Java Runtime Environment: openjdk version “1.8.0_152”
    • openHAB version: openHAB 2.4.0~S1442-1 (Build #1442)
  • Issue of the topic:
    Since the update to the latest version (note: I did not update for several months) my logfile is being filled with warnings (see below).
    To try to get to the bottom of it, I deinstalled the Network and the Samsung A/C Binding (since the IP address that is mentioned in the warning is the one of my air conditioner). But the messages appears furthermore every second (and always with the same IP address).
    Does anyone have an idea where it comes from?

  • If logs where generated please post these here using code fences:

2018-11-25 13:19:05.742 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response:
2018-11-25 13:19:06.743 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response:

is that URL working on a browser?

Uninstalling the binding will not remove the Items
Do you have any Items that are still in your system that were used by the Samsung Binding?
or maybe some other Items using the HTTP binding and polling this URL?

Hi @Dim!

Thank you for your quick response!

Yes, the URL is working in a browser. It is the IP address of my air conditioner (which rejects the attempt since no certificate is provided with the request).

But I have got no item defined for this device (I just checked it again with Paper UI, karaf and I scanned all my configuration files).

I have got no idea who or what is trying to access this device and also why …

check if there is a file related to the Samsung AC Binding stored within userdata:


if it exists, check it’s contents
stop oh2, and delete this file, start oh2

No difference. :disappointed_relieved:

2018-11-26 22:20:07.214 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response:
2018-11-26 22:20:08.215 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response:
2018-11-26 22:20:08.771 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response:

Try to clear cache & tmp to see if this helps. Clear the Cache

meanwhile, I am trying to understand where these settings could have been stored to clean them

The problem persists …

2018-11-26 23:15:12.035 [INFO ] [org.jupnp.UpnpServiceImpl           ] - Starting UPnP service...
2018-11-26 23:15:12.727 [INFO ] [org.jupnp.QueueingThreadPoolExecutor] - Thread pool 'upnp-async' exhausted, queueing tasks now.
2018-11-26 23:15:13.443 [WARN ] [p.protocol.RetrieveRemoteDescriptors] - Device descriptor retrieval failed, no response:

try the following command to see if we can identify where the config parameter is coming from:

grep -r "" /var/lib/openhab2/ /etc/openhab2/

No result:

[23:11:56] openhabian@openHABianPi:/etc/openhab2/services$ grep -r "" /var/lib/openhab2/ /etc/openhab2/
[23:22:33] openhabian@openHABianPi:/etc/openhab2/services$

The warning just says that the device descriptor refers to something that does not exist.
So it is no openHAB issue, it is a device issue. You might see those warnings even with other, non UPnP compliant devices.
Best way to get ridd of those warnings would be to change the loglevel for UPnP at Karaf console

log:set ERROR org.jupnp
1 Like

Hi @hmerk!
Thank you for your hint!
I like to understands things, so I’ve got one more question regarding that topic:
since (if I understand that right) openHAB initiates the connection attempt toward that device, I think that somewhere within the openHAB context (configuration files etc.) the device descriptor you mentioned must be defined. Where can I find this descriptor?
Or is the UPnP Service autonomously scanning the network, discovering this device and trying to request its capabilities?
Thank you in advance for your support!
Best regards, Nico

Hi Nico,
it is like you guessed the UPnP service scanning the network for new devices.
That‘s why I mentioned that you might see this with other devices not following the UPnP specs.