[SOLVED] [hueemulation] No Longer Able to Pair with Harmony Hub

jeshab · August 24, 2019, 12:06am

I am having an issue with my Logitech Harmony Hub not able to pair with the Hue Emulation service. It used to work up until the end of June when I moved my Docker container on to a different host. Since then it is not longer working. I am currently running the latest OH 2.5 snapshot build 1665 docker image.

Looking at the self status page, none of the URLs are marked as responsive while I can access through my browser along with any of the URLs from the server where OH is running. I am using nginx to proxy into my OH server. Also, the binding seems to be able to pick devices broadcasting on my network including my Harmony Hub.

After increasing the debugging logs, I don’t see any self test failure or any other errors that would explain the reason for my issue. So I assume the self tests aren’t failing but they somehow end up being considered as unresponsive. The fact that the self test page is showing the upnp announcement thread not running is probably the resulting issue here. Just to be sure, I tried to remove the hue configuration from my Harmony Hub setup but wasn’t able to pair against after that.

Any idea how I can resolve this one?

Self test api status

Logs

[previous host]

2019-06-26 13:31:23.077 [INFO ] [io.hueemulation.internal.ConfigStore] - Hue Emulation pairing disabled
2019-06-26 13:31:25.503 [WARN ] [ulation.internal.HueEmulationService] - The UPnP Server service has not been started!
2019-06-26 13:31:25.510 [INFO ] [ulation.internal.HueEmulationService] - Hue Emulation service available under /api
2019-06-26 13:31:27.466 [INFO ] [ueemulation.internal.upnp.UpnpServer] - Hue Emulation UPNP server started on 127.0.0.1:8080
2019-06-26 13:31:29.223 [INFO ] [ulation.internal.HueEmulationService] - Hue Emulation service available under /api
2019-06-26 13:31:30.012 [INFO ] [ueemulation.internal.upnp.UpnpServer] - Hue Emulation UPNP server started on <externalIp>:80

[current host]

2019-08-23 16:02:12.027 [INFO ] [io.hueemulation.internal.ConfigStore] - Hue Emulation pairing disabled
2019-08-23 16:02:13.238 [WARN ] [ulation.internal.HueEmulationService] - The UPnP Server service has not been started!
2019-08-23 16:02:13.240 [INFO ] [ulation.internal.HueEmulationService] - Hue Emulation service available under /api
2019-08-23 16:02:13.466 [INFO ] [ueemulation.internal.upnp.UpnpServer] - Hue Emulation UPNP server started on 127.0.0.1:8080
2019-08-23 16:02:13.871 [INFO ] [ulation.internal.HueEmulationService] - Hue Emulation service available under /api

jeshab · August 31, 2019, 12:45am

@David_Graeff Sorry to bother you. Any idea how can I resolve my issue? I tried to isolate any port conflicts with other applications running on the same server but it didn’t seem to help. Maybe some additional debug logging needs to be added around the UPnP server initialization?

David_Graeff · September 6, 2019, 9:02pm

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

Mike_Bagdanoff · September 11, 2019, 5:43am

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.

Peter_Cheben · September 21, 2019, 11:15pm

The same here. M2 is OK, M3 not able to pair.

TheLexus · September 28, 2019, 2:42pm

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":{}}}}

David_Graeff · October 3, 2019, 10:52pm

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.

TheLexus · October 7, 2019, 12:54pm

@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>

GeminiServer · October 20, 2019, 2:23pm

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.

Andrew_Rowe · October 20, 2019, 2:48pm

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

David_Graeff · October 20, 2019, 4:44pm

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.

Pekka · October 21, 2019, 5:27pm

When I try to connect via the command line with cURL, when device pairing is off, there is no difference:

vs.

However, whe device pairing is on, there is a difference:

vs.

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?

ngrodum · November 16, 2019, 12:25pm

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.

Pekka · November 16, 2019, 12:52pm

Nicolai,

could you please explain how you made this filter?

Pekka

ngrodum · November 16, 2019, 1:53pm

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

Pekka · November 16, 2019, 2:11pm

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

ngrodum · November 16, 2019, 3:22pm

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?

GeminiServer · November 18, 2019, 3:22pm

I have build it and i can confirm that the workaround of @ngrodum is working.

jeshab · December 4, 2019, 5:10pm

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!

David_Graeff · December 5, 2019, 8:42pm

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.