Tasmota: 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 https://github.com/arendst/Sonoff-Tasmota/issues/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\ESP8266WebServersrc​​

[aer0xkh]

Thank you. works fine!

[OFreddy]

@aer0xkh I am glad that it works for you. So does it for me.
Keep in mind that for platformio the packages and libraries are loaded and updated automatically.
I am not sure when this will happen. So your changes might be overwritten.

[aer0xkh]

yep, thank you!

[JF62]

Works fine for me too - ist there a chance to see this workaround in the near future?

[reloxx13]

PullRequest is open, see link above.

Aren cant do anything to it cuz its a Workaround in a used Library for an Alexa Bug.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.

[DobbyNator94]

Hey,

I have a Sonoff 4CH with the newer design and I flashed tasmota on it (5.14.0) (06.27.2018).
But I have still the problem that Alexa say's that the device is not responding. The parsing.cpp changed a lot, so I can't copy and paste your solution @OFreddy . I also turned on the HUE-Emulation to control all 4 ports.

Here I pull out the line from my parsing.cpp (I cloned the tasmota-dir from GitHub and used ATOM for flashing):

endif

  if (contentLength > 0) {
    if (searchStr != "") searchStr += '&';
    if(plainBuf[0] == '{' || plainBuf[0] == '[' || strstr(plainBuf, "=") == NULL){
      //plain post json or other data
      searchStr += "plain=";
      searchStr += plainBuf;
    } else {
      searchStr += plainBuf;
    }
    free(plainBuf);
  }
}
**_parseArguments(searchStr);
if (isForm){
  if (!_parseForm(client, boundaryStr, contentLength)) {
    return false;**
  }
}

It changed totally. So, what I must do, to controll the 4CH with Alexa? Maybe I make a mistake..
Thank you for your help!

And why is this error not been fixed since January?
I know, it's OpenSource.. But IMHO it's a big error and make it more difficult for beginners.

Thank you!

best regards,
Robin

[reloxx13]

the workaround is for framework 2.4.x.

tasmota 5.14.0 platformio.ini uses 2.3.0 as default which is also recommended.

you dont need the workaround.

the error is not tasmotas fault and its not a bug, if you had read this ticket you would know their is an open ticket at the library github. and as mentioned, you dont need teh workaround for 2.3.0.

[DobbyNator94]

Hey @reloxx13

okay.. Now I flashed your version from tasmota and it worlks flawless.
Thank you and sorry.

best regards,
Robin