Sonoff Touch 2 CH - EMUL_HUE - Alexa says device not responding - HUE APP and WEMO WORKS

[aer0xkh]

Hi,

I can't switch the toggle with Alexa. (device not responding)
The Hue App recognized both device and works with it.
If I change to wemo it work but only with one channel. Is there a workaround?

Tasmota 5.11.1c

Thank you

[OFreddy]

Hi.
I am experiencing the same problems with a Sonoff Dual device. I am using lots of Sonoff Basic devices with Wemo emulation which are operating very reliable. For a special application with limited space I wanted to use the Sonoff Dual device. It also operates with Wemo emulation as a 1 channel device. But to operate both channels I need to change to Hue emulation.

It seems that there might be an issue with Hue emulation and the current Alexa firmware. The switch is not operating and alexa says device is not responding.

I have spend lots of time for several days using lots of different version of the Tasmota software. Can anyone specify which settings/actions are required to make it work together with Hue emulation?
Is a MQTT broker really required to make it word together?

Thank you in advance.

[KennethLavrsen]

I think you see same issue as reported on #1434

People report the issue in two ways. All agree that Alexa detect the device. All say the response from Alexa is that the device is not responding. But for some the switch actually change. And for others like me nothing happens at all. There is a bug in Tasmota related to Hue. Like the other reporters the Wemo mode works which is fine for the single switch devices. I hope we manage to find a fix for this before my dual switch devices arrive from China.
Any way we can help to debug this?

I tried to set debug level to the highest and monitor the console and then ask Alex to turn the device on and off. And every time I can see this in the log

`11:59:32 HTP: Hue API (/IflxapTw81LhloSQ4g8PeNPtKM5GPmbeL4Mntvzw/lights/1/state)

11:59:36 UPP: Hue 3 response packets sent to 192.168.1.25:9313

11:59:38 WIF: Checking connection...

11:59:38 WIF: Connected

11:59:38 UPP: Hue 3 response packets sent to 192.168.1.25:9313`

Switch does not change and Alexa says "fan isn't responding" (device name is fan)

[aer0xkh]

Device restarted and after that I said "Alexa, Turn device on"

exactly in the moment when Alexa told me that the device is not responding I saw that line in log.
10:00:54 HTP: Hue API (/XG6SGHcixR9mTTjwUbS0vNVAgn60QcDe1tQVbQZA/lights/1/state)

[OFreddy]

In the meantime I registered for an account at developers.meethue.com to get access to the Hue protocol specifications.
With this information I have figured out the problem. Unfortunately I am currently not able to fix it as I am not familiar with the toolchain and the libraries. Perhaps somebody can give a hint.

These are the major differences:

• Tasmota expects the JSON command string as a content key/value pair seperated by an '='
• Alexa appends the only the JSON command string as a content stream to the HTTP PUT.

Explanation:

Alexa sends the PUT command just with plain JSON appended to the URI. Therefore tasmota responds with an internal error. I found it in the code of xplg_wemohue.ino in line 652 as the argument count in the HTTP PUT from Alexa is zero:
if (1 == WebServer->args()) {

Returned Error code constant:
const char HUE_ERROR_JSON[] PROGMEM = "[{\"error\":{\"type\":901,\"address\":\"/\",\"description\":\"Internal Error 1\"}}]";

Example of an accepted command send from a web browser:

Example of a rejected command send from Alexa:

[aer0xkh]

Any news? I tried several versions of tasmota without succes

[OFreddy]

In my opinion this can't be fixed with another Tasmota version.
Alexa is doing the mess?!?
Anyhow the changes have to be done in the ESP8266WebServer belonging to the ESP8266 Library.

Alexa sends a HTTP PUT with

    Content-type: application/x-www-form-urlencoded

This requires the content to be in key-value tuples separated by '&', with a '=' between the key and the value.

    1={"on": true}

But it sends the content only in plain JSON

    {"on": true}

In other words, the Alexa request content type must be changed to

    application/json

or the content itself must be changed to

    1={"on": true}

This is also reflected by the Wireshark interpretation of the Alexa request frame indicating the key to be {"on": true} and value empty:

I have tested this with Postman and the current Tasmota version - It works

[aer0xkh]

@arendst is there a chance? sorry if I miss understand it

[OFreddy]

With this workarround in parsing.cpp in the ESP8266WebServer of the esp8266 library (Arduino, V2.4.0, line 193) it works fine for me:

    if(!isEncoded||(0==_currentArgCount)){ // @20180124OF01: Workarround for Alexa Bug

[aer0xkh]

Do you know where I can find that library in atom? I see parsing.cpp in webserver.ino but I don't know where the file is located

[reloxx13]

C:\Users\YOURUSERNAME.platformio\packages\framework-arduinoespressif8266\libraries\ESP8266WebServer\src​​

[aer0xkh]

Thank you. works fine!