Thanks @bastian: I have observed the same responses.
And thanks for opening the issue.
Like described by @bastian?
(Alexa complaining even though it’s working properly)?
I also removed all devices and added them again, but this issue is thiss there.
@bastian great debug. Your translations were correct I get those responses from time to time.
From what I can tell this is an Amazon issue. I saw a video the other day about using node red for alexa local control. In that live stream she return the same response even though it worked. The video maker said that’s normal right now.
@Thedannymullen How can this be an Alexa issue? Alexa doesn’t show this behaviour with a Philipps Hue bridge v2.
@lopez1de True statement! I did not think of that. Then I am lost! I do however know this for sure. Mine is intermittent in when it does it. I from time to time on 2.5m6 get it. Now that I am done with holiday travel I will put the release version on. But on this version the error messages are only there 10-20% of time.
Hi Tom,
how could I make this work in a docker Environment?
Thanks, Budo
- A real Hue v2 bridge uses https. The hue emulation does not.
- A real Hue v2 bridge doesn’t care about correct encoding, and content-type headers. Hue emulation does.
There are more of those subtle differences. I guess it is 1. that makes all DIY solutions struggle at the moment.
@David_Graeff thank you for pointing this out - I wasn’t aware of that.
I understand these two differences as being binary: you either use HTTPS or you don’t. You either choke on malformed content or you don’t.
Do you have any suspicion how this could lead to the problem described in https://github.com/openhab/openhab-addons/issues/6690?
Because that problem is not happening all the time, only most of it.
It’s not that easy. From a specific hue api version onwards the real bridge only allows https. Alexa Echoes might try https first, fallback to http for the command but will return a “failed to communicate” spoken response.
Regarding the http headers: This issue happened mid 2019 already. Hue emulation strictly expected “json” formatted content as specified by the Hue specification. Alexa Echos were sending json but an http content header of “text” which resulted in non working communications.
This probably has happened again with another http header. Alexa is expecting something, that we do not send yet or send in an unexpected way and that leads to a “device not responding” spoken message. I do not have time to debug that though.
Cheers, David
@David_Graeff - thank you for the explanation.
I wish I had more experience with debugging & coding, so I knew better how to investigate this some more myself.
If I want to analyse the communication between the binding and Alexa, how would I set that up? If I had to do it right away, I would install wireshark on my desktop with the goal to grab communications between Alexa and my (productive) OH (which run on the same network but not on my desktop). I doubt that that would work though, as I think the communications on a switched network will not involve my desktop machine…
You don’t need to invest much time in answering this, as I might not find the time I need to get up to speed with this. But if you can give me some hints or just names of tools/procedures I can google, that would be much appreciated.
Cheers! -bastian
I’ve submitted a PR which resolves the issue of Alexa complaining about the device malfunctioning when setting to a percentage, e.g. set room to 50%
4 Likes
I have the same issue here. On Top Alexa can’t handle “üäö” anymore 
Can i install the hue emulation from 2.5M1 on my 2.5.1 Openhab ?
This one worked fine.
Could anyone provide me a link to the 2.5M1 hue-emulation addon - can’t find the jar anywhere 
Would try if it works and report back
Simply rename the devices with the broken äöü in the Alexa App. Umlauts are working there
I can’t control the devices anymore - even if I rename them.
I can see them in the Alexa app as:
Verbunden über: Hue Hub
Beschreibung: Royal Philips Electronics intelligentes Gerät
Typ: sonstiges (various)
No way to control it
@ChrisW If you updated openHAB you will have to delete devices one by one and rescan. Once alexa gets confused this is the only way to fix. Most of these problems appear to be with how amazon identifies and links things behind the scenes.
I did that already.
It will discover the Items but they will show up as
Beschreibung: Royal Philips Electronics intelligentes Gerät
Typ: sonstiges (various)
and I can’t control them (tried using voice commands and the app)
Also it isn’t just Alexa which isn’t working any more
Logitech Harmony Hub also can’t control my openhab items through the emulation anymore
Tried the https://openhab.jfrog.io/openhab/libs-milestone-local/org/openhab/addons/bundles/org.openhab.io.hueemulation/
2.5.0.M2 from here (which also needed org.jupnp bundle , but it did not change the results.
(Hue Emulation was uninstalled from PaperUI before)
I’m pretty much out of ideas and might to have go back to my 2.5M1 backup.
Hi there
1st off all, thanks Mike for submitting the issue. They seem to have it fixed, but how would I patch it on my local system? I’m on stable 2.5.0. Also I don’t understand if this is an error of OH or hue emulation.
I’ve setup my rollershutters (which are actually dimmer items) to be controlled by Alexa over hue emulation.
Dimmer JA1_R1_Level "Küchenfenster" ["Lighting"] {channel="homematic:HmIPW-DRBL4:XXX:YYY:2#LEVEL"}
So when I give commands like “Alexa Küchenfenster 25%” or “Alexa Küchenfenster 90” - it does work but Alexa very often replys: “‘Küchenfenster’ scheint nicht richtig zu funktionieren”
Thank you
Would it help if we used nginx as a HTTPS-to-plain converter?
It’s already setup for a number of people to redirect port 80 to openhab.
Guys take a look here, this seems to allow the hueemulation module to load properly
https://community.openhab.org/t/solved-no-opencloud-when-upgrading-from-2-4-to-2-5m4/85348/41