Tasmota: Hue emulation Alexa works but says "this value is outside the range of the device"

[yonaesp]

I'm using dual sonoff, with wemo it only detects one relay, with hue detecting both and it works perfectly when I say "Alexa, turn on button 1", normally alexa must answer "ok" but in this case he answers "this value is outside the range of the device" however, it turns on and off without problem, and when I use "Alexa, turn off the button 1" it responds correctly "ok".

My device is in Spanish since I am participating in the closed beta, it is likely that in English it will respond with a different word as indicated here: 1639

I have also tried modifying the line indicated in this comment, 360218536 recompiling the firmware and installing it, but the problem persists.

Another problem that I have, from the alexa app I can turn on the relays but I can not turn them off, however using the voice command if I can do it.

this only happens to me with hue emulation.

[Jason2866]

Maybe the name button 1 is for Alexa iritating. Change it to something common.
Maybe you try light as name. In general that is not a Tasmota problem!
I use Alexa too, and it works perfect hrre in Germany.

[yonaesp]

The real name is "Arriba/Up", button 1 is only an example.

[Jason2866]

"/" is not allowed just a simple usual word

[yonaesp]

it's only "Arriba" ( /up is the translation that I have used here as an informative).

[Jason2866]

Maybe Alexa isnt working like it should since it is in beta state in your region.
This help you not at all, but Tasmota is working correct with HueEmulation with Alexa in
countrys where is official supported

[yonaesp]

Is possible, Here (Green = Translation to English) I attach some images of what appears in the app Alexa to see if that can indicate something.

I do not have any Skills activated, should I activate any?

It also does not allow me to edit the button settings

[Jason2866]

No skill is needed to activate. Changing names edit button works here (Germany).
My setup looks like this.

[yonaesp]

from what I see you does not show any error, therefore it seems clear that this is a problem with the beta version.

thanks for your help, the solution will be to wait then :D

[Jason2866]

Your welcome, please close this issue.

[yonaesp]

In the uk version has the same problem, so it is not something related to the beta of Spain.

@Jason2866 If you do not get that error when you turn it on, I would like you to tell me how you have configured your sonoff, hue bridge? mqtt enabled?
I do not understand why you do not have this error and others do, maybe some parameter configured differently

[Jason2866]

@yonaesp
Config: Hue Bridge, mqtt, web, disabled mDNS, disabled Domoticz, disabled HomeAssistant
Simple Friendly Name (only letters) -> "speakable"
Tasmota v.6.1.1b with arduino core 2.3.0 (this is urgent!)

[yonaesp]

@Jason2866
How can I get the version you mention? (6.1.1b 2.3.0)
I do not see that version here https://github.com/arendst/Sonoff-Tasmota/releases

should I join files and compile my own firmware? thanks!

[yonaesp]

@Jason2866 I download, configure and compile with 2.3.0 the firmware: 6.1.1b-mod-1.35.2 using arduino IDE.
but the problem persists, I still do not understand why you alexa does not answer this message when you turn on the devices.
I think I have nothing left to check.

Do you have any installed skill related to hue or ifttt? thanks.

[Jason2866]

No skill installed. No ifttt
Alexa always answers with ok for on and off

[ascillato2]

Hi,

Have you managed to solve your issue?

[yonaesp]

@ascillato2 No, I still do not understand why jason2866 does not have this problem.
It happens in the Spanish and English versions, I have tried different tasmota versions and it remains, I still do not know what the error is associated with.

@Jason2866 can you share your firmware.bin here please?

[Jason2866]

@yonaesp
I cant share because i use hard coded wifi credentials. Deleted the wifi config part to save space.
In earlier versions i did this myself (not as elegant as @arendst) . Since 6.1.1 this is a option :-)
If you mail me your wifi settings i could compile your version of my used setup.
Maybe this version is not a good choice for you. I disabled options i will never use (wificonfig, Domoticz, all things belong to Hass, mDNS)

[yonaesp]

@Jason2866 OK, tell me where I can contact you to send you the credentials.

When I try to install the firmware using 2.3.0, after restarting the sonoff never started again since in arduino ide it did not allow selecting more than 500kb of memory with that version.

[Jason2866]

Your version
firmware.zip
Good Luck!

[yonaesp]

@Jason2866 the problem persists, perhaps in the German version is implemented correctly alexa and in uk and spain not yet.

I guess we just have to wait and report the error to Amazon directly.
Thank you very much for your time and help, greetings!

[Boris16]

Hi, I have the same problem (sporadic).

First I flash a Wemos D1 Mini and it works fine. Second I flashed a Sonoff Basic R2 V1.0 (2017-10-11) with Tasmota 6.1.1 german. To use the GPO14, I use the hue bridge emulation.

Sometimes Alexa found a lamp with color adjustment and sometimes a normal lamp. When the lamp with color setting is found, Alexa will give the info "this value is outside the range of the device" at the power-on command.
As mentioned above "sporadically". After deleting the device and search it again, sometimes the lamp without color setting is found. And then it works without "this value is outside the range of the device".

So far I have not had any problems with the Wemos D1 Mini.

Is it possible to parameterize Tasmota in such a way that hue bridge emulation always detects a lamp without color management?

[nospam2000]

I have the same problem with a Sonoff 4CH-R2: the lamps can be switched on, but not off. They are detected as dimmable color lamps. Alexa cannot read the state of the lamp.

Also from my side the question: How is it possible to select a simple on/off lamp instead of a dimmable multicolor lamp?

I'm in Germany, but I use the standard english localization. I don't have an MQTT server.

[nospam2000]

They are detected as dimmable color lamps.

When I remove the "lamps" in the Alexa app and let Alexa rediscover the lamps, the type may change to simple on/off lamp. This worked for 3 out of 4 lamps, for the 4th lamp I had to remove and add it again. Even then it didn't work.

[thylonius]

Hi all,
I discovered that the issue is related to the response of tasmota. Tasmota for now reports new devices always as „extended color lights“, and therefore Alexa sends not only state change commands, but as well brightness setting etc. when tasmota is configured as simple switch without any special light features (light_type ==0) a response from tasmota is replying with the correct state change but brightness etc. will be reported back to Alexa as „0“.
To fix this simply (I know it is ugly, but plan to create a pull request): go to xplg_wemohue.ino
And change within function HueLightStatus1 the first if condition to update the hue, sat, bri unconditionaly:

//if (light_type) {
LightGetHsb(&hue, &sat, &bri);
//}

I said it‘s ugly. But it would require a proper design and separate configurability of light_type.
You will notice that you won‘t be able to set brightness etc as a device Independent value in the Alexa app. As far as I understand from your usecases that won’t matter much.

Regards

[thylonius]

Further notice: more elegant way would also be to change tasmota to report devices as „on/off light“. You could do this by changing the JSON responses. For now I was able to change tasmota to report only „on/off light“, but still struggling with the state responses ...will report here if it turns out well.

Regards

[nobodyAtall]

@thylonius

Tried your workaround in xplg_wemohue.ino but didn't make much difference.
Device is detected in Alexa but it either says:

• Device doesn't support requested value
  or
• Device is unresponsive

Toggling the sonoff on, works. But it won't turn again off via the Alexa app.

Also seeing this in the HA journal:

journalctl -f -u home-assistant@homeassistant

Aug 23 00:34:19 osmc hass[20222]: Traceback (most recent call last):
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_protocol.py", line 378, in start
Aug 23 00:34:19 osmc hass[20222]: resp = await self._request_handler(request)
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_app.py", line 341, in _handle
Aug 23 00:34:19 osmc hass[20222]: resp = await handler(request)
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/http/view.py", line 113, in handle
Aug 23 00:34:19 osmc hass[20222]: result = await result
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 177, in put
Aug 23 00:34:19 osmc hass[20222]: parsed = parse_hue_api_put_light_body(request_json, entity)
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 324, in parse_hue_api_put_light_body
Aug 23 00:34:19 osmc hass[20222]: return (result, brightness) if report_brightness else (result, None)
Aug 23 00:34:19 osmc hass[20222]: UnboundLocalError: local variable 'report_brightness' referenced before assignment

[thylonius]

Hi,
Could you send me your modified ino file?
I would like to compare with mine...earliest tomorrow, quite late already.
Have you removed all depencies on light_type in the file? Could also be possible that I messed up.

RegardS

Am 22.08.2018 um 23:35 schrieb Vassilis Tsogkas [e-mail]:

@thylonius

Tried your workaround in xplg_wemohue.ino but didn't make much difference.
Device is detected in Alexa but it either says:

Device doesn't support requested value
or
Device is unresponsive
Toggling the sonoff on, works. But it won't turn again off via the Alexa app.

Also seeing this in the HA journal:

journalctl -f -u home-assistant@homeassistant

Aug 23 00:34:19 osmc hass[20222]: Traceback (most recent call last):
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_protocol.py", line 378, in start
Aug 23 00:34:19 osmc hass[20222]: resp = await self._request_handler(request)
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_app.py", line 341, in _handle
Aug 23 00:34:19 osmc hass[20222]: resp = await handler(request)
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/http/view.py", line 113, in handle
Aug 23 00:34:19 osmc hass[20222]: result = await result
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 177, in put
Aug 23 00:34:19 osmc hass[20222]: parsed = parse_hue_api_put_light_body(request_json, entity)
Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 324, in parse_hue_api_put_light_body
Aug 23 00:34:19 osmc hass[20222]: return (result, brightness) if report_brightness else (result, None)
Aug 23 00:34:19 osmc hass[20222]: UnboundLocalError: local variable 'report_brightness' referenced before assignment

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[nospam2000]

I tried to patch the detected type and emulate an Osram socket by replacing these two defintions in sonoff/xplg_wemohue.ino:

const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
  "{\"on\":{state},"
  "\"alert\":\"none\","
  "\"mode\":\"homeautomation\","
  "\"reachable\": true}";

const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM =
",\"type\":\"On/Off plug-in unit\","
"\"name\":\"{j1\","
"\"modelid\":\"Plug 01\","
"\"manufacturername\":\"OSRAM\","
"\"productname\":\"On/Off plug\","
"\"capabilities\":{"
  "\"certified\":false,"
  "\"control\":{},"
  "\"streaming\":{"
    "\"renderer\":false,"
    "\"proxy\":false"
  "}"
"},"
"\"config\":{"
  "\"archetype\":\"classicbulb\","
  "\"function\":\"functional\","
  "\"direction\":\"omnidirectional\""
"},"
"\"uniqueid\":\"{j2\","
"\"swversion\":\"V1.04.12\"}";

unfortunately I was not able to download the modified firmware, because my USB serial converter gave up. Maybe someone of you can check this out.

[nobodyAtall]

@nospam2000 Same behavior with your suggested change:

Aug 24 01:13:25 osmc hass[5143]: Traceback (most recent call last):
Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_protocol.py", line 378, in start
Aug 24 01:13:25 osmc hass[5143]: resp = await self._request_handler(request)
Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_app.py", line 341, in _handle
Aug 24 01:13:25 osmc hass[5143]: resp = await handler(request)
Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/http/view.py", line 113, in handle
Aug 24 01:13:25 osmc hass[5143]: result = await result
Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 177, in put
Aug 24 01:13:25 osmc hass[5143]: parsed = parse_hue_api_put_light_body(request_json, entity)
Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 324, in parse_hue_api_put_light_body
Aug 24 01:13:25 osmc hass[5143]: return (result, brightness) if report_brightness else (result, None)
Aug 24 01:13:25 osmc hass[5143]: UnboundLocalError: local variable 'report_brightness' referenced before assignment

@thylonius this is the file I used (attached)
xplg_wemohue.ino.txt

[nobodyAtall]

My related HA config:

...

mqtt:
broker: 192.168.1.51
discovery: true

discovery_prefix: homeassistant

username: DEVuser
password: DEVpw

switch:

• platform: mqtt
  name: "Sonoff Switch 01"
  command_topic: "cmnd/sonoffDEV1/power"
  state_topic: "stat/sonoffDEV1/POWER"
  qos: 1
  payload_on: "ON"
  payload_off: "OFF"
  retain: true
• platform: mqtt
  name: "Sonoff Switch 02"
  command_topic: "cmnd/sonoffDEV2/power"
  state_topic: "stat/sonoffDEV2/POWER"
  qos: 1
  payload_on: "ON"
  payload_off: "OFF"
  retain: true
• platform: mqtt
  name: "Sonoff Plug 01"
  command_topic: "cmnd/sonoffPLUG1/power"
  state_topic: "stat/sonoffPLUG1/POWER"
  qos: 1
  payload_on: "ON"
  payload_off: "OFF"
  retain: true
  ...

[thylonius]

@nobodyAtall

Used your file in my config to be sure. For me it does work. How could we find differences?
Could you explain where you log that traces of yours and what the link with homeassistant?
I do not use any other infratructure than alexa (as voice command interface mainly).
I emulate 4 devices on ESP-12E Board with tasmota v6.1.1. (Controlling a hydroponic system in my garden)

Program Version 6.1.1
Build Date & Time 2018-08-24T10:41:18 (< with your file)
Core/SDK Version 2_3_0/1.5.3(aec24ac9)
Uptime 0T00:11:46
Flash write Count 5189 at F8000
Boot Count 2008
Restart Reason Software/System restart
Friendly Name 1 Wasser1
Friendly Name 2 Wasser2
Friendly Name 3 Wasser3
Friendly Name 4 Wasser4
Jörg

[nospam2000]

I have changed 2 things in my definition, now it is working for me:

1. removed the blank in the "reachable" line
2. added the "swupdate" section
   now two of four channels of my Sonoff 4CH are working. There is lots of random going on ...

const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
  "{\"on\":{state},"
  "\"alert\":\"none\","
  "\"mode\":\"homeautomation\","
  "\"reachable\":true}";

const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM =
",\"swupdate\": {"
    "\"state\": \"notupdatable\","
    "\"lastinstall\": null"
"},"
"\"type\":\"On/Off plug-in unit\","
"\"name\":\"{j1\","
"\"modelid\":\"Plug 01\","
"\"manufacturername\":\"OSRAM\","
"\"productname\":\"On/Off plug\","
"\"capabilities\":{"
  "\"certified\":false,"
  "\"control\":{},"
  "\"streaming\":{"
    "\"renderer\":false,"
    "\"proxy\":false"
  "}"
"},"
"\"config\":{"
  "\"archetype\":\"classicbulb\","
  "\"function\":\"functional\","
  "\"direction\":\"omnidirectional\""
"},"
"\"uniqueid\":\"{j2\","
"\"swversion\":\"V1.04.12\"}";

[nospam2000]

after adding these line:

  while(path->endsWith("/")) {                        // remove trailing "/"
    path->remove(path->length() - 1, 1);
  }

after
path->remove(0, 4); // remove /api

in sonoff/xplg_wemohue.ino, all of my 4 channels were working. As I said above this might be totally random, but at least the responses now also work when the requests end with "/"

[nobodyAtall]

@nospam2000
Thanks, can you post your xplg_wemohue.ino file?

[nospam2000]

@nobodyAtall: I have lot's of stuff in xplg_wemohue.ino which would cause more confusion (e.g. additional logging and commented sections). Let me tidy it up first. I will probably create a new git branch.

I'm still in the evaluation phase and try to figure out why sometimes 3 and sometimes only 1 device is detected correctly.
In my previous try it seemed to make difference if a lamp is switched on or off, but in the next try I could not confirm that theory.

[nospam2000]

@nobodyAtall I switched now to the git HEAD version and reverted all unneeded changes. For a simple on/off contact this works fine, for a multicolor the original response string needs to be adapted, for example there is a space in "xy" after the comma:
"xy":[0.5, 0.5]

Here the diff, including the dump of the response:

diff --git a/sonoff/xplg_wemohue.ino b/sonoff/xplg_wemohue.ino
index 9a7cdee..ef68e4a 100644
--- a/sonoff/xplg_wemohue.ino
+++ b/sonoff/xplg_wemohue.ino
@@ -453,14 +453,14 @@ const char HUE_DESCRIPTION_XML[] PROGMEM =
   "\r\n";
 const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
   "{\"on\":{state},"
-  "\"bri\":{b},"
-  "\"hue\":{h},"
-  "\"sat\":{s},"
-  "\"xy\":[0.5, 0.5],"
-  "\"ct\":500,"
+//  "\"bri\":{b},"
+//  "\"hue\":{h},"
+//  "\"sat\":{s},"
+//  "\"xy\":[0.5,0.5],"
+//  "\"ct\":500,"
   "\"alert\":\"none\","
   "\"effect\":\"none\","
-  "\"colormode\":\"hs\","
+//  "\"colormode\":\"hs\","
   "\"reachable\":true}";
 const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM =
   ",\"type\":\"Extended color light\","
@@ -756,6 +756,9 @@ void HueLights(String *path)
   else {
     WebServer->send(406, FPSTR(HDR_CTYPE_JSON), "{}");
   }
+
+  snprintf_P(log_data, sizeof(log_data), PSTR(D_LOG_HTTP D_HUE_API " (%s)"), response.c_str());
+  AddLog(LOG_LEVEL_DEBUG_MORE);
 }

 void HueGroups(String *path)
@@ -792,6 +795,10 @@ void HandleHueApi(String *path)
   uint8_t args = 0;

   path->remove(0, 4);                                // remove /api
+  while(path->endsWith("/")) {                        // remove trailing "/"
+    path->remove(path->length() - 1, 1);
+  }
+
   uint16_t apilen = path->length();
   snprintf_P(log_data, sizeof(log_data), PSTR(D_LOG_HTTP D_HUE_API " (%s)"), path->c_str());
   AddLog(LOG_LEVEL_DEBUG_MORE);                      // HTP: Hue API (//lights/1/state)

[ascillato2]

Hi,

Have you managed to solve your issue?

[nospam2000]

My issues are now solved. I use tasmota for shutters and therefore I need to emulate a dimmable lamp without any colors. See my branch and the checkin for shutters which emulate a dimmable lamp.

There are several problems:

1. Alexa is very picky about the consistency across the values. That means for a dimmable lamp the "on" value and the "bri" value must fit together:
   on==true: 6 <= bri <= 254
   on==false: bri = 0
   For a color lamp there are probably more dependencies especially between the different color rooms (hsv, rgb, x/y). Setting x/y to a fixed value is not a good idea, better leave it out when it is not supported.

1. When Alexa sets bri to a value, the value of bri is checked after setting it (I don't mean the response, there is an extra read call). When the value doesn't exactly match, you will get a "the device doesn't work correctly" error message.
   When converting between the alexa bri values and internal float percentage values, the formulas must be corrected:

Alexa_bri = (uint8_t)(253.0f * Tasmota_bri + 1.5f))
Tasmota_bri = (float)Alexa_bri / 253.0f

The factor 254 was incorrect. I checked it for around 30 different bri values and the formula above (especially the first one) gives an exact result for all that percentage values.

1. The discovery should only return the values for the configured lamp type, the means the color values should not be reported for a dimmable lamp and a on/off lamp should not report bri. This is missing in my checkin, it only supports a dimmable shutter.

[ascillato]

Very interesting. Thanks.

Please, can you make a Pull Request ?

[nospam2000]

The concept of the lamp types and subtypes is still unclear to me, especially how to store separate bri value when you have multiple lamps.
I have seen there is not only a bri value (mapped to 'light_brightness'), but additionally a dimming setting and I didn't understand the relationship between those two.

To make a working pull request there need to be some clarifications before. With the main branch, only one dimmable/color lamp can work. For the shutters I'm using (from stefanbode's fork) each shutter has a separate position which is mapped to a separate bri value.

[nospam2000]

@ascillato2: I now made a first version, see my emufix branch. I haven't tested it with any color lamps yet, just simple on/off lamps and in the context of shutters I tested the brightness.
Can anybody please test this version with a color lamp?

[ascillato]

Hi, your modifications seems ok but I don't have Alexa to test that.

@reloxx13 Please, could you test that?

[nospam2000]

In the meanwhile I have done some tests on my own:

1. Moduletype = 22 Sonoff BN SETOPTION15 1 => the lamp shows up as dimmable lamp
2. ModuleType = 17 AiLight => the lamp is detected as multicolor dimmable lamp

[nospam2000]

After some more tests with the brightness value of the multicolor lamp it turned out, that there are so many conversions in xdrv_04_light.ino which all intruduce rounding errors. That means it is almost impossible to get the same brightness value back that you have written, at least when the RGB mapping is used ((light_subtype > LST_COLDWARM && !gotct)==true) and LightRgbToHsb() is called. I tried to fix some of the conversions and tested all percent values from 2 to 100. 64 values are working, here the test results with the list of values which give the error "Lampe1 scheint nicht richtig zu funktionieren" (in english: "Lamp1 doesn't work properly"):

setpoint%  intern%   setpointA readoutA
                     Alexa     Alexa
3                      9         8
5                     14        13
7                     19        18
9                     24        23
33         32         84        82
40                   102       103
42         41        107       105
44         43        112       110
46         45        117       115
48         47        122       120
51                   130       129
52                   133       132
53                   135       134
54                   138       137
56                   143       142
58                   148       147
60                   153       152
61         60        155       154
62                   158       157 
64                   163       162
66                   168       167
67                   171       170
68                   173       172
69                   176       175
70         69        178       177
71                   181       180
77                   196       195
79                   201       200
80                   203       204
81 ????????? => Alexa: "I don't know how to perform this setting"
82         81        208       205
91         90        231       229
93         92        236       233
95         94        241       239
97         96        246       244
99         97        251       248

The list contains only values in column 2 and 4 when the value is wrong. Column 2 should match column 1, column 4 should match column 3.
A possible solution would be to store the written values in xplg_wemohue.ino and cache them for 2 seconds, so those values can be returned exactly without conversion and the read request following the write request would be satisfied.

Michael

[nospam2000]

Hi,

I now made some unit tests and added them to my git branch:

1. tools/TestAlexaValueMappings.cpp: tests the behaviour and quality of my own Alexa to factor functions
2. tools/TestColorPluginValueMappings.cpp: tests the behaviour and quality of the LightSetHsb() and LightGetHsb() functions, depending on light_type, light_subtype and Settings.module. At the moment I only test the bri value.

The results are good, except for the following settings:

    light_type = LT_RGBWC;
    light_subtype = LST_RGBWC;
    Settings.module = AILIGHT;
    bool gotct = false;

I can tune the conversion to a match rate of 70%, but not more.

This means the module type SONOFF_BN with SETOPTION15 1 works good, but not the color lamps. I made no tests for gotct=true.
Either the LightSetHsb() and LightGetHsb roundtrip precision is enhanced, or the values need to be stored as duplicate in the emulation plugin.

To make it clear: all values are set correctly (+-2%), but you will get the annoying Alexa message, that the device is not working properly.

Michael

[andrethomas]

Hi, any feedback on this issue?

[ascillato2]

@nospam2000

Hi,

Any news on this?

[ascillato]

Hi,

Any news on this?

[nospam2000]

No news. I uploaded my current state to my emufix branch and nobody had the time to test it.

@yonaesp and @Boris16: can you please test my version and give feedback?

[Jason2866]

@nospam2000
Will try too the next few days. But i think i cant help much because i never had this problem!
So my test will be just, is there something broken with this changes

[yonaesp]

No news. I uploaded my current state to my emufix branch and nobody had the time to test it.

@yonaesp and @Boris16: can you please test my version and give feedback?

Okay, it does not work. I installed the firmware and two bulbs appear without the option to choose color, but when I try to turn on or off alexa says "< bulb name > is not compatible with this"

[nospam2000]

@yonaesp: what kind of hardware did you select and which settings did you use?
Relais have no color, just on/off, so the color and brightness controls are not shown.
Dimmable lights also don't have color, just brightness and on/off.
AILIGHT has color, but only one and not multiple.

[Boris16]

Hello,
With the version V6.2.1.3 download Sonoff-Tasmota-emufix I also have a problem. All tests with Alexa Echo Dot and Sonoff Basic R2.

But one after anonther:
1.) I test a Sonoff Basic R2 with Tasmota V6.3.0. Sporadically, it works well. But sometimes a lamp with color adjustment is detected and then the error "this value is outside the range of the device" occurs. As mentioned sporadically!!! If the error occurs and I delete the device and try again, it sometimes works fine.
2.) I compile Sonoff-Tasmota-emufix (in german) with Atom and update the Sonoff via OTA.
3.) If I say to Alexa "switch on / off" I get the answer: "... antwortet nicht". But the Sonoff turns on or off correctly as expected!!!
4.) I tried to use the device via the Alexa app but I can only turn on the Sonoff. When I try to turn the Sonoff off via the App an error occurs "Gerät reagiert nicht".

[Boris16]

There are two things that I do not understand:
1.) Why does the problem occur sporadically?
2.) Tasmota knows the used device (e.g., a Sonoff Basic with a relay). Why can not the emulation take this into account?

[yonaesp]

@yonaesp : ¿Qué tipo de hardware seleccionó y qué configuraciones usó?
Los Relais no tienen color, solo está activado / desactivado, por lo que no se muestran los controles de color y brillo.
Las luces regulables tampoco tienen color, solo brillo y encendido / apagado.
AILIGHT tiene color, pero solo uno y no múltiple.

I know, it was to say that you have managed to show as a normal bulb (no dimmable bulb). the configuration is by default in the sonoff, I just enabled emulation hue and mqtt, I also tried with mqtt disabled.
From Alexa I look for devices and two new bulbs appear, but when I try to turn on with Alexa it shows the error mentioned above

[Boris16]

@yonaesp : Los Relais no tienen color, solo está activado / desactivado, por lo que no se muestran los controles de color y brillo.

That's exactly the problem. Sporadically, the setting for the color is also displayed when using a relay. And then the error occurs.

[yonaesp]

@yonaesp : Los Relais no tienen color, solo está activado / desactivado, por lo que no se muestran los controles de color y brillo.

That's exactly the problem. Sporadically, the setting for the color is also displayed when using a relay. And then the error occurs.

I know, I'm talking about the modified firmware, the firmware modified by @nospam2000 fixes this (the color / brightness option never appears) but it gives the error that I said earlier when trying to turn on, I am using the translator and maybe it does not allow me to explain myself well

[nospam2000]

@Boris16

2.) Tasmota knows the used device (e.g., a Sonoff Basic with a relay). Why can not the emulation take this into account?

My fix takes this into account. It checks the light_type and the light_subtype. According to the code it seems really unlikely that this fails. I even checked if those two variables are changed anywhere else in the code, but they are only set in LightInit() of the xdrv_04_light driver. As long as this initialization is called exactly once on startup, that code acts always the same.

light_type and light_subtype depend on the configured device type, the PWM option 15 setting and if #define USE_WS2812 is set. This is why I need to know your settings of that options.

Do you only have the Hue Emulation enabled or also the Wemo Emulation?
I always disable the Wemo emulation in the settings.

1.) Why does the problem occur sporadically?

Good question. It would be helpful, if you can switch the debug level to extra verbose and post the traces to see whats really happening.

Michael

[yonaesp]

@nospam2000
I can not have hue and wemo emulation at the same time, I only use hue.

apparently as they say with your firmware sometimes appears with the option of adjustable bulb and other not.
this time I have managed relay 1 to work, but it keeps the same error message as with the stock firmware.
relay 2 alexa says that this device does not respond

also I see this in the console a lot of times:

04:37:55 UPP: Multicast (re)joined
04:38:01 RSL: stat/sonoff/RESULT = {"POWER1":"ON"}
04:38:01 RSL: stat/sonoff/POWER1 = ON
04:38:06 MQT: Attempting connection...
04:38:13 MQT: Connect failed to 192.168.2.114:1883, rc -2. Retry in 10 sec
04:38:13 RSL: stat/sonoff/RESULT = {"POWER1":"OFF"}
04:38:13 RSL: stat/sonoff/POWER1 = OFF
04:38:13 UPP: Multicast (re)joined
04:38:24 MQT: Attempting connection...
04:38:31 MQT: Connect failed to 192.168.2.114:1883, rc -2. Retry in 10 sec
04:38:31 UPP: Multicast (re)joined

[Jason2866]

@yonaesp
That looks like a wifi connection problem. Try to use latest development version.
Compile it with core 2.3.0.

[yonaesp]

I finally managed to install the firmware correctly and managed to configure the sonoff correctly

I have to say that the solution is effective, I had some problems but it turned out that I did not choose the sonoff model correctly.

In the configuration I only activated emulation hue, I had to modify the names until Alexa seems to detect well and then I restarted the sonoff

I hope that this configuration is applied soon to the official firmware.

thank you all for your great work!
@Jason2866 @nospam2000 @Boris16 @ascillato2 @thylonius

[gourry]

Thanks for this. I also applied the solution from the emufix branch by nospam2000 and everything is working.
I'm using Amazon echo in Italy that was launched a few weeks ago and I struggled for many days trying to emulate philips hue. I tried both fauxmoESP and tasmota, the first was not even detected by Alexa, while the second was failing as described in this issue.
I hope this this fix will get in the main repository soon. Thanks all!

[Jason2866]

Tried emufix branch. Doesnt work good. It switches the device on / off
but Alexa says "xxxx antwortet nicht"
The solution that is now standard works without any issue
PR isnt recommended.

[yonaesp]

Tried emufix branch. Doesnt work good. It switches the device on / off
but Alex say "xxxx antwortet nicht"
The solution that is now standard works without any issue
PR isnt recommended.

This happened to me when I did not choose the correct sonoff model in the configuration, apparently my sonoff was 4ch pro, and I set the sonoff 4ch in the configuration.

[Jason2866]

Mine is a sonoff basic and it is correct choosen. So the solution needs rework

[yonaesp]

Mine is a sonoff basic and it is correct choosen. So the solution needs rework

Can you try with other sonoff models in the config?

[gourry]

I'm using Generic module configuration with 2 relays and 1 button and the emufix branch is working for me. Official tasmota is not working not in hueemulation not in wemo. Hue emulation is either detected as dimmable or not dimmable (randomly). When detected as "not dimmable" Alexa reports that the device does not work and refuses every command. When detected as dimmable, commands works but an annoying message about the device not supporting the selected value is returned. Emufix branch makes my module detected ad on/off switch and Alexa is able to operate on it replying OK. I have an echo Dot 3rd generation and an Echo 2nd generation.

[Jason2866]

Tried with orig. Tasmota code (6.3.0.8) on a Wemos Mini (Module Generic) with HueEmulation
with 3 relais and 1 PWM channel.
All 3 relais switches with Alexa and dimming works if i say "Alexa xx Prozent"
No issue. Used Echo Dot 2nd generation

[nospam2000]

with 3 relais and 1 PWM channel.

Can you please give me a hint how to configure this?
What do you see in the Alexa app, 3x on/off light + 1xdimmable light?

[Jason2866]

Just define in module generic
relais1 relais2 relais3 to a free GPIO and to another free GPIO PWM1
Then give under friendly name every device a speakable name.
I see every device as dimmable lamp, but just the pwm can be dimmed
Thats it

[Escanor87]

I solved creating a task with alexa with the same name that turn the light at 100% if i say a word. So, i don't say "alexa, turn on salotto" but "alexa, salotto" that is the task. Of course is not a very solution but it works..

[pcb1962]

I have the issue that Alexa sees every one of my sonoff switches as a dimmable light, is there a code hack I can put in to make Alexa see them as just on/off switches? When I say "Alexa turn on the kitchen lights" she does it correctly but responds every time with "That value is out of range for device kitchen lights". Would be great to get rid of this annoying response.

[ewari]

I programmed tasmota with Hue-Emulation to 5 sonoff T1(2Chan)-switches and all switches work fine when I use them with Alexa and EchoDot2 at home in Germany with fixed IP-Addresses 192.168.1.X. But when I reprogram these 5 switches for an austrian Network where IP-Addresses 10.0.0.X and an EchoDot3 are used then following occures in Austria:
Alexa finds all 5 switches with their 2 Relays and so 10 new "lamps" appear in the Alexa App. When I want to switch one of these lamps via the Alexa App an additional color-field is shown and it seems that the App tries to connect with the real Hue server in the Netherlands! After few seconds the App shows that no connection to this server is possible. There is no Hue-Skill installed!
When Alexa is commanded to switch one of the lamps ON or OFF then the answer is "That value is out of range". Only very, very seldom one of the switches really reacts.
Another strange thing is, that the 10 lamps are listed under "lamps" but if I try to create a "group" then from the group-menu these lamps cannot be found.
I reenstalled the Alexa-App and let Alexa find the sonoffs again and again. The only differences between my home in Germany and the Destination in Austria are EchoDot2 vs. EchoDot3 and a Router with IP-range 192.168.1.X vs. Router with IP-range 10.0.0.X.
Can please anybody help?

[gourry]

I don't know if this is a coincidence but even in my home ( Italy ) where official tasmota is not working with hue emulation ( same behavior explained above ), router is set with IP-range 10.0.0.x

[arendst]

I love to help but I have no alexa. I remember someone noticed problems too with the latest alexa hardware/software so I don't think it's an IP address range issue.

It wouls be great if someone stood up and takes ownership op these continuing alexa issues.

[nospam2000]

@arendst there are different expectations: the light driver is made for real Sonoff hardware and only one single light and not meant to work with custom hardware and multiple channels (3xdigital, 1xPWM) like Jason2866 wants to use it.
My fix-branch was in the direction of not supporting such custom cases, but mimic the behaviour of the light driver (one light or n relays). This will fix the problem of pcb1962 but break the use-case of Jason2866.

Which direction shall we go?

[Jason2866]

Hue Emulation is made for more channels (= relais) on one device.
For just one channel is wemo emulation
The Hue Emulation works perfect for me (NEVER had any problem!). So it isnt a general problem...
As Theo stated it has to be a comnination from other "things"
What i can say your fork brakes anything in my setup...
I am sorry but i cant help to fix this issue because i have no problem

[nospam2000]

Hue Emulation is made for more channels (= relais) on one device.

Yes, but the "light driver" only knows about a single light.

[Jason2866]

I think to get an overview we need an list of used devices:
Router, Echo ? Generation? Tasmota version? Country of Amazon Account? Used in country?
My setup:
Digitalisierungsbox premium (= Bintec Router), Echo Dot 2nd Gen., Tasmota 6.3.0.14, Germany, Germany

[Jason2866]

Why, does light driver work for me? Maybe it can be nailed from that direction?
In Alexa it appears as standalone single device, and reacts like that

[nospam2000]

The light driver handles brightness and color values, the on/off values for the relays are handled separately. It works in your case because in the original code there is no interaction between the on/off settings of the relays and the brightness.

When I say "Alexa Lamp1 50%" (or "0%") I would expect, that the lamp is also turned on (off) and this requires a coupling between a relay and the "light driver". From a perspective of a light emulation this fits perfectly, but is this what you want?

[Jason2866]

Why not? If this is the only solution to get more channels on one device done...
I can set brightness and after that switch it on.
With the latest Alexa change you can combine this commands
But this is not the problem. It works for me that way for others not. What is the reason for that?

[gourry]

I'm exactly in the opposite situation of Jason2866... In my scenario tasmota 6.3.0.x is broken, while nospam2000 branch works. I don't even need brightness and colors, even the basic relay on/off are broken. If that could help, I could try again with more recent tasmota Dev branch, but I didn't see any recent change in the hue emulation area on github commits.

[Jason2866]

@nospam2000
Just tried now. If i say "Alexa Test 70%" and it was off before it switches on at 70%
"Alexa Test 0%" switches off
I do not need 2 commands!

[jojo-muc]

Hi,

I deleted the brightness and colors JSON status in plug_wemohue.ino. For the Sonoff S20, Basic and ESP8266-D1 works for me.

line 462: ("KAFFEE" was for the test ;) )

const char HUE_LIGHTS_STATUS_JSON[] PROGMEM = "{\"on\":{state}," "\"reachable\":true}"; const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM = ",\"type\":\"On/off light\"," "\"name\":\"{j1\"," "\"modelid\":\"KAFFEE\"," "\"uniqueid\":\"{j2\"," "\"swversion\":\"5.50.1.19085\"}"; const char HUE_GROUP0_STATUS_JSON[] PROGMEM = "{\"name\":\"Group 0\"," "\"lights\":[{l1]," "\"type\":\"LightGroup\"," "\"action\":";

[trojanobelix]

I have also the Hue emulation problem: Alexa works but says "this value is outside the range of the device"
Can someone clarify the settings for Sonoff S2x module?
I have read several hints and I think

MQTT disabled
Belkin WeMo single device emulation

should work.

I use an Alexa echo and tasmota 6.3.0

btw Can someone send me a link for an update server to update the module to the actual development branch via OTA. Or must this be done via USB/UART adapter?

[Jason2866]

OTA: http://thehackbox.org/tasmota/sonoff.bin

[trojanobelix]

Thanks for the Link. But with 6.0.17 and MQTT disabled on Belkin WeMo single device emulation I also become

"Light does not answer"

and with Emulation | Hue Bridge still

"this value is outside the range of the device"

Think Alexa on the S2x needs some polish

[Jason2866]

@trojanobelix
Yes, we know... But i cant take a look in this issue. I dont have any error.

[trojanobelix]

I'm on the German version, too: so it should work:

Config: Hue Bridge, mqtt, web, disabled mDNS, disabled Domoticz, disabled HomeAssistant
...
Tasmota v.6.1.1b with arduino core 2.3.0 (this is urgent!)

These settings mostly set in code, arn't they?

[Jason2866]

Yes, but i dont know if this really matters. I just disabled it because i dont need it. Saves flash and Ram...

[trojanobelix]

Okay, just to be sure: Your Link to 6.0.17 is with arduino core 2.3.0.
And this version does/would work on your German Alexa with Sanonoff S2x Module?

Then I have no idea why it does not work without the "value outside" message

May thanks for your help and best regards!

[trojanobelix]

My setup shows the color (German: "Farbe") !?

Router, Echo ? Generation? Tasmota version? Country of Amazon Account? Used in country?
My setup:
Fritzbox 7490 (Mesh with 1750E) , Echo Plus 1nd Gen., Tasmota 6.3.0.17, Germany, Germany

So it can not be the German implementation that make it works.

[Jason2866]

German, with german Amazon account. Echo Dot 2nd gen.
Worked with all versions since 5.x until latest dev version.
Core 2.3.0. Patched 2.4.2 (core patch in precompiled included!) and Stage core 2.5.0
Router Digitalisierungsbox premium (bintec router be ip+) with bintec and LANCOM wired Accesspoints
Fritzbox and Mesh can make problems!

[jojo-muc]

Hi,

I checked the JSON message get back from the hue API. The value "0" for the "bri" parameter is not valid.
You can check this with this api call:
http://yoursonoffip/api/username/lights

Description in the Philips Hue API:

bri | uint8 | The brightness value to set the light to.Brightness is a scale from 1 (the minimum the light is capable of) to 254 (the maximum).Note: a brightness of 1 is not off.e.g. “brightness”: 60 will set the light to a specific brightness
-- | -- | --

Workaround in xplg_wemohue.ino. I have set the float bri = 1.

void HueLightStatus1(byte device, String *response)
{
float hue = 0;
float sat = 0;
float bri = 1;
uint16_t ct = 500;

Why is this part not working?

if (hue_json.containsKey("bri")) { // Brightness is a scale from 1 (the minimum the light is capable of) to 254 (the maximum). Note: a brightness of 1 is not off.
tmp = hue_json["bri"];
tmp = tmax(tmp, 1);
tmp = tmin(tmp, 254);
bri = (float)tmp / 254.0f;
if (resp) {
response += ",";
}
response += FPSTR(HUE_LIGHT_RESPONSE_JSON);
response.replace("{id", String(device));
response.replace("{cm", "bri");
response.replace("{re", String(tmp));
resp = true;
change = true;
}

However, the S20, Sonoff Basic etc don't need hue, sat, bri...
I commented the parameters in the JSON Output. (xplg_wemohue.ino)

Now, I don't have any controller for brightness, color in the Alexa App with the hue emu ;)

Summary:

For the switch devices (S20, Basic, 4ch, Wemo D1, etc.) I commented the hue/sat/bri lines in the JSON Output.

[Jason2866]

Will try if is still working with this changes.
I get this for off:
{"1":{"state":{"on":false,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Fluter","modelid":"LCT007","uniqueid":"ec:fa:bc:13:d9:2f:00:11-1","swversion":"5.50.1.19085"}}
and for on:
{"1":{"state":{"on":true,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Fluter","modelid":"LCT007","uniqueid":"ec:fa:bc:13:d9:2f:00:11-1","swversion":"5.50.1.19085"}}

Switches without error response

[trojanobelix]

For me it seems that the commit
v5.12.0h - Change to default PWM Color/Dimmer Theo Arends [e-mail] 21.03.2018 09:27:05 687f96f843b16a31212f4b84fa54a0607321aec6

has break the basic S2x module

Settings.flag.pwm_control is set to default 1 in settings.ino in that commit

In sonoff.ino

light_type = LT_BASIC; // LT_BASIC is enumed as  0
  light_type = LT_BASIC;                     // Use basic PWM control if SetOption15 = 0
  if (Settings.flag.pwm_control) {
    for (byte i = 0; i < MAX_PWMS; i++) {
      if (pin[GPIO_PWM1 +i] < 99) light_type++;  // Use Dimmer/Color control for all PWM as SetOption15 = 1
    }
  }

light_type is incremented an therefor in xplg_wemohue.ino
all the if (light_type) are true and the LightSetHsb tries to set the brightness

Maybe an addional test on the code line
if (Settings.flag.pwm_control )
to make sure that (Settings.my_gp.io[i]) is an PWM Output
can do the trick?

Can anyone confirm this? Maybe the maintainer and commiter?

[arendst]

Well the check is exactly what this line does:

if (pin[GPIO_PWM1 +i] < 99) light_type++;

If no PWM is defined (so pin[GPIO_PWM1 +i] equals 99) and therefore no light the light_type stays at 0;

[jojo-muc]

Hallo Jason,

Ich vermute mal das wir in deutsch schreiben können ;)

Das Problem ist der „bri“:0 Parameter. Hier darf laut API von Philips nur ein Wert von 1 - 254 an Alexa zurück gegeben werden. Es ist im Code eine Routine vorgesehen die den Parameter nur zwischen 1 - 254 zulässt. Allerdings wird diese nicht ausgeführt.

Welche Version hast Du aktuell aufgespielt? So wie ich das sehe wird bei den älteren Version ein anderer „colormode“ übergeben.
Bei Deiner Version:

"colormode":"hs"

Bei mir „colormode“:“ct"

Ich vermute mal das bei „ct" der Wert 0 bei Bri nicht berücksichtigt wird.

Kannst Du bei der neuen Version die unnötigen Parameter in xplg_wemohue.ino auskommentieren und flashen.
Ab Zeile 462:

const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
"{"on":{state},"
//""bri":{b},"
//""hue":{h},"
//""sat":{s},"
//""xy":[0.5, 0.5],"
//""ct":{t},"
//""alert":"none","
//""effect":"none","
//""colormode":"{m}","
""reachable":true}";

Mit der Änderung werden keine Werte für Helligkeit, Farbe etc. an Alexa übertragen. Somit sind auch die unnötigen Regler in der Alexa App verschwunden.

Bei mir sieht die Abfrage jetzt so aus.
{"state":{"on":false,"reachable":true},"type":"Extended color light","name":"TEST","modelid":"LCT007","uniqueid":"b4:e6:2d:42:c2:64:00:11-1","swversion":"5.50.1.19085"}

Wäre super wenn Du mir ein Rückmeldung geben könntest.
Solltest Du Unterstützung brauchen, melde Dich.

VG
Jojo

colormode string 2, 2 Indicates the color mode in which the light is working, this is the last command type it received. Values are “hs” for Hue and Saturation, “xy” for XY and “ct” for Color Temperature. This parameter is only present when the light supports at least one of the values.

Am einfachsten ist es

Am 16.12.2018 um 12:17 schrieb Jason2866 [e-mail]:

Will try if is still working with this changes.
I get this for off:
{"1":{"state":{"on":false,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none“,c,"reachable":true},"type":"Extended color light","name":"Fluter","modelid":"LCT007","uniqueid":"ec:fa:bc:13:d9:2f:00:11-1","swversion":"5.50.1.19085"}}
and for on:
{"1":{"state":{"on":true,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Fluter","modelid":"LCT007","uniqueid":"ec:fa:bc:13:d9:2f:00:11-1","swversion":"5.50.1.19085"}}

Switches without error response

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3159#issuecomment-447635083, or mute the thread https://github.com/notifications/unsubscribe-auth/Arls86dwIfTr-kVO8O3f0P6O4Hwsfg6sks5u5ivTgaJpZM4VGodA.

[Jason2866]

Yes, i am German. But lets talk in english. GitHub is english. Others should have the chance to follow.
Flashed another device with latest 6.3.0.17 and Core Stage 2.5.0.
Off:
{"1":{"state":{"on":false,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Test","modelid":"LCT007","uniqueid":"b4:e6:2d:15:85:b3:00:11-1","swversion":"5.50.1.19085"}}
ON:
{"1":{"state":{"on":true,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Test","modelid":"LCT007","uniqueid":"b4:e6:2d:15:85:b3:00:11-1","swversion":"5.50.1.19085"}}
I always do have "colormode":"hs" Now i gonna try your changes!!

[Jason2866]

Your changes has the result for me "Test antwortet nicht"
But it does switch on and off!
Off:
{"1":{"state":{"on":false,"reachable":true},"type":"Extended color light","name":"Test","modelid":"LCT007","uniqueid":"b4:e6:2d:15:85:b3:00:11-1","swversion":"5.50.1.19085"}}
ON:
{"1":{"state":{"on":true,"reachable":true},"type":"Extended color light","name":"Test","modelid":"LCT007","uniqueid":"b4:e6:2d:15:85:b3:00:11-1","swversion":"5.50.1.19085"}}

[Jason2866]

Reverted back to original code and now it works as it should again!
Off:
{"1":{"state":{"on":false,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Test","modelid":"LCT007","uniqueid":"b4:e6:2d:15:85:b3:00:11-1","swversion":"5.50.1.19085"}}
ON:
{"1":{"state":{"on":true,"bri":0,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Test","modelid":"LCT007","uniqueid":"b4:e6:2d:15:85:b3:00:11-1","swversion":"5.50.1.19085"}}
So as i stated before for me the code works without any issue!

[jojo-muc]

Did you delete the device in the App?

Am 16.12.2018 um 13:55 schrieb Jason2866 [e-mail]:

Reverted back to original code and now it works as it should again!

[Jason2866]

YES

[jojo-muc]

Different "colormode". Which device? Sonoff S20?

[Jason2866]

Tested on S20, WemosMini, pow, Shp2, ch4 and basic all working

[trojanobelix]

Well the check is exactly what this line does:

if (pin[GPIO_PWM1 +i] < 99) light_type++;

If no PWM is defined (so pin[GPIO_PWM1 +i] equals 99) and therefore no light the light_type stays at 0;

@arendst
Hmmm, ok. Your are right. But if light_type stays at 0, then the S2x code should never reach LightSetHsb().
Then the default value of bri, which is 0, ist send via HueLights. And bri = 0 is not a valid value for brightness.

[Jason2866]

@jojo-muc Could you test with bri <> 0 ?

[jojo-muc]

I tested with bri = 254. No error, but brightness and color controller.

[Boris16]

I've just flashed a brand new Sonoff S20 with Tasmota 6.3.0. Everything works very well.
MQTT disabled, Emulation: Belkin WeMo Einzelnes Gerät

Alexa found two devices:
- Schreibtischlampe WeMo Steckdose
- Schreibtischlampe WeMo Switch

[jojo-muc]

Hi,

Belkin Wemo works as expected.
Could you change to hue emulation and control the S20 with the Alexa App?

Am 17.12.2018 um 15:04 schrieb Boris16 [e-mail]:

I've just flashed a brand new Sonoff S20 with Tasmota 6.3.0. Everything works very well.
MQTT disabled, Emulation: Belkin WeMo Einzelnes Gerät

Alexa found two devices:

• Schreibtischlampe WeMo Steckdose
• Schreibtischlampe WeMo Switch

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3159#issuecomment-447857018, or mute the thread https://github.com/notifications/unsubscribe-auth/Arls8wmkA4Aeuhi2jnQpMTUAEukrrsRGks5u56SDgaJpZM4VGodA.

[Boris16]

Hi,
The hue emulation is only needed if you are using a Sonoff device with multiple channels. For an S20 it makes no sense, because the S20 is a single-channel device for a specific usecace (use as a socket switch).
I have already flashed many devices (Basic, Dual, 4CH Pro, Wemos D1 Mini) and also operated and tested with the hue emulation. My experience has shown that the hue emulation sometimes works as desired (without color adjustment) and sometimes not.
For me, the following steps has conduct to the correct function:

1: Search device with Alexa.
2: Check in the Alexa Handy App that the color adjustment does not exist.
3: If the color adjustment exists: delete the two devices (VERY IMPORTANT !!!) on the Alexa website "https://alexa.amazon.de/spa/index.html#appliances" NOT with the Alexa App.
You should find two (or more devices for multi-channel devices). "Hue Light" and "Royal Philips Electronics intelligentes Gerät".
4: Try step 1 again. I tried it several (0..10) times. Good luck.

Why it works sporadically and sporadically not, I don't know.

[gourry]

Hello, I checked the workaround provided by jojo-muc and it seems good. It's effectively making Alexa usable without the bad error message. I'm proposing a PR for it.

[Jason2866]

@gourry PR wouldnt be merged because for others it renders Alexa functionality!
This isnt the solution for the issue

[gourry]

@Jason2866 what do you mean with "renders"? I don't understand it. Is it breaking Alexa in your configuration?

[Jason2866]

For me the current solution works flawessly.
With this change it get the error message "Das Gerät reagiert nicht"

[gourry]

Did you try to remove the device and readd it? It seems strange because the only change done is fixing the default value that is outside the range...
I don't understand how the value out of range is working in your setup and the value inside range is not

[Jason2866]

EDIT!!: After powercycle device and Alexa after deleting device in Alexa and new discovery it works!
@arendst PR should be merged to see if it solves it for all

[gourry]

Great, good to hear it!

[ascillato2]

Closing issue as it has been solved.

Please, if anyone is having this problem with latest Tasmota from the development branch, ask to reopen this issue. Thanks

[trojanobelix]

Worked! Nice!