there’s apparently a bug in the upnp server startup. I guess it fails if certain conditions hold true like ipv6 interfaces, other services on the same port etc.
It would actually help the most if you could compile the addon yourself with more debug statements (or debug in Eclipse) and drop the jar into the addons directory.
Can’t really help rn 
Cheers
I’m seeing the same here with 2.5.0.M3.
Same UPNP announcement thread not running status. I don’t have any other services running on the pi and this was all working with M2.
The same here. M2 is OK, M3 not able to pair.
Can confirm too, M3 messed it up.
@David_Graeff Do you have any idea how I can help? Maybe do you have a version with more debug output. I tried to install eclipse according to the guide, but all building failed with some missing jars maven tries to download. Don’t know what’s wrong there.
Currious thing. If I let do a request from the harmony hub first and then from a pc using a webbrowser:
2019-09-28 16:44:11.922 [DEBUG] [ulation.internal.HueEmulationService] - REST request GET bbcebb8e-efe0-4abf-96e8-cd246fe4e0f1/lights
2019-09-28 16:44:11.926 [DEBUG] [ulation.internal.HueEmulationService] - REST response: null
2019-09-28 16:44:20.004 [WARN ] [ueemulation.internal.upnp.UpnpServer] - Could not send UPNP response: Cannot assign requested address (sendto failed)
2019-09-28 16:44:23.837 [DEBUG] [ulation.internal.HueEmulationService] - REST request GET bbcebb8e-efe0-4abf-96e8-cd246fe4e0f1/lights
2019-09-28 16:44:23.841 [DEBUG] [ulation.internal.HueEmulationService] - REST response: {"403":{"state":{"bri":0,"ct":500,"on":false,"reachable":true,"mode":"homeautomation","alert":"none"},"type":"Color temperature light","modelid":"LTW001","uniqueid":"bf5f83bb-e0a2-43b1-b18b-ba275cb0958a-403","manufacturername":"Philips","swversion":"66012040","friendsOfHue":true,"colorGamut":"2200K-6500K","hascolor":false,"name":"HueEmu WZ Spots","config":{"archetype":"classicbulb","function":"functional","direction":"omnidirectional"},"capabilities":{"certified":true,"streaming":{"renderer":false,"proxy":false},"control":{}}},"404":{"state":{"bri":0,"ct":500,"on":false,"reachable":true,"mode":"homeautomation","alert":"none"},"type":"Color temperature light","modelid":"LTW001","uniqueid":"bf5f83bb-e0a2-43b1-b18b-ba275cb0958a-404","manufacturername":"Philips","swversion":"66012040","friendsOfHue":true,"colorGamut":"2200K-6500K","hascolor":false,"name":"HueEmu WZ Decke","config":{"archetype":"classicbulb","function":"functional","direction":"omnidirectional"},"capabilities":{"certified":true,"streaming":{"renderer":false,"proxy":false},"control":{}}}}I have no immediate idea. Some devices will properly send the “Content-Type” header (which was required in some revisions of the hue emu code and is actually correct behaviour) and some devices like Amazon Echos do not send that header. Newer revisions should not enforce that header anymore.
There might be more of those cases, where devices just deviate from the specification and the new hue emu code is too strict.
@David_Graeff Looks like something that jetty messes up or is it just the missing Accept: application/json ?. Here is a http capture if I requery the bridge.
GET /api/d90f5e66-89a3-4fbd-bf1d-5d528093918e/lights HTTP/1.1
connection: close, TE
content-length: 0
user-agent: LuaSocket 2.0.2
te: trailers
content-type: application/json
host: 192.168.XXX.XXX
HTTP/1.1 415 Unsupported Media Type
Connection: close
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 390
Server: Jetty(9.4.18.v20190429)
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 415 Unsupported Media Type</title>
</head>
<body><h2>HTTP ERROR 415</h2>
<p>Problem accessing /api/d90f5e66-89a3-4fbd-bf1d-5d528093918e/lights. Reason:
<pre> Unsupported Media Type</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.18.v20190429</a><hr/>
</body>
</html>Same also here. I updated now to 2.5 - M4. But no changes. Still not able to Pair / Same UPNP announcement thread not running status. All other Informations / Settings etc. is the same like jeshab reported.
Erkan:
Since you updated your install to M4, perhaps report your findings in the new M4 testing thread
I was curious as to if hue emulation was working or not
Yes, it’s the missing “Accept”. I’m puzzled now on what to do. If I add it, non-conforming devices will not work. If I leave it away with the new jetty version all requests are denied with a 415.
When I try to connect via the command line with cURL, when device pairing is off, there is no difference:
However, whe device pairing is on, there is a difference:
However, I dont’t get the point: The Hue Emulation is the server side. So why can’t you just ignore, whether or not the client sends the accept header?
As a last resort, you could make it configurable in the settings?
I did some testing, and I didn’t see issues with the Accept header. For me it appears Jetty returns 415 if a client sends “content-type” header on any GET request.
I made a filter that removed this header, and then all started working again. There might be a better way to instruct Jetty to ignore superfluous Content-Type headers.
Nicolai,
could you please explain how you made this filter?
Pekka
Hi @Pekka! I made it into a quick PR so you can test if you have the same issue as I did: https://github.com/openhab/openhab2-addons/pull/6402
My problem sees to be similar to what was described by @TheLexus
Nicolai,
sorry - I’m not too much into GIT… Seems that this filter is more than a simple configuration but requires recompilation of the addon?
Pekka
Yeah, it’s a code change that must be compiled in. I’m not that familiar with the build environment, I build my own. Does anyone else know if the jar for my PR can be downloaded from the build server?
I can confirm that this PR fixed my issue. I can now pair and control my devices again with my Harmony Hub using the latest OH 2.5 snapshot. Awesome job! 
I have merged the last patch of @ngrodum. I think hue emulation is in good shape again for the OH 2.5 release. What bugs me is that the status report page does not seem to work as expected if I look at the posted screenshot from above.
The reachability tests failed and the page says “upnp announcement thread not running” while it is clearly working as seen in the table.
Using the latest snapshot, the reachability test looks good on my end where the URLs that are supposed to be responding are marked properly. However the upnp announcement thread is still showing as not running.
I think I have fixed that issue in https://github.com/openhab/openhab2-addons/commit/58181fa9f76046f4ee3f8fab5a26ab32d73c0774.
