Alexa Emulation support

[kouske]

Hi, Will this work with the Philips hue emulation?

For example: I want to send a command to set the curtain to 50% through my Amazon echo.

Is this possible?

[stefanbode]

Currently not, but the idea is great. I have an Echo, too. Therefore testing is no problem. I would assume to use the dimmer value für the shutter. This might work. Let me do some investigations what is already implemented.

[kouske]

If you could map the dimmer value then it would be awesome! I will try to look into it as well (hope I can ramp quickly :))

[stefanbode]

For me it looks like currently the hue does not support dimming. Just of off as far as I can see in the code of the wemos/hue

[kouske]

It might be that the dimming option was not ported due to lack of space..

[kouske]

In file xplg_wemohue.ino, there is a function called HueLights which eventually parses a value called "bri". This "bri" is later on sent to a function called LightSetHsb and I'm guessing it continues until we configure the hardware. Can we use this somehow? I just had a quick peek - not sure if this is even relevant but maybe, just maybe :)

[nospam2000]

Please test if my changes (see checkin above) fix your issue. At the moment it will only work correctly with shutters enabled, not with real lamps. It is not ready for a pull request, yet.

The shutters are shown as dimmable lamps in the Alexa App and show the current percentage. You can either set a percentage or switch it on/off which means 100% / 0%.

[stefanbode]

Great, I can promise my wife will love this. I checked already some code and have some question. Anyhow I will integrate this very soon. Here the list of questions:

  //STB mod
  //save old value in temp var
  bool on = power & (1 << (device-1));

  if(Settings.flag3.shutter_mode && (device > 0) && (device <= shutters_present)){
   // Need to check if this can really happen because alredy checked above
    //if((device < 0) || (device > shutters_present)) device = 1;
    // we go directly to the shutter_position. this holds the correct value and respect if the shutters are inverted
    bri = (float)(Settings.shutter_invert[device - 1] ? 100 - Settings.shutter_position[device - 1]: Settings.shutter_position[device - 1])/100.0f;
    on = bri  > 0; 
  }

Is the second IF really required? I think not because this is already checked before. I changed to the shutterposition variable because this is already between 0..100 and reflect the current position and not the "to be" position. Also added the invert feature. Should be fine.

  //STB mod
  // please explain why you changed this
  response->replace("{s}", String((uint8_t)(253.0f * sat + 1.5f)));
  response->replace("{b}", String((uint8_t)(253.0f * bri + 1.5f)));
}

You changed the calculation and this might cause incompabilities with the original code. Therefore I want to understand the issue. With the new shutter_position bri can get a clear 1.0. As far I can see your calculation is 254.5 maximum instead of 254.0. Please explain what you have seen here as an issue.

if(Settings.flag3.shutter_mode) maxhue = shutters_present;

I will change this because with ONE shutter on relay 3 and 4 there could be additional functionality. I see no requirement to limit this, but for sure check not to work on "shutter_presents *2" relays, because these belong to the shutter

    //bri = (float)tmp / 254.0f;    
        bri = (float)tmp / 253.0f;
        if (resp) {
          response += ",";
        }
        response += FPSTR(HUE_LIGHT_RESPONSE_JSON);
        response.replace("{id", String(device));
        response.replace("{cm", "bri");
    //response.replace("{re", String(tmp));
        response.replace("{re", String((uint8_t)tmp));

Can you explain again the changes here to understand impact.

And last not least:

  //stb mode
  // intresting. is this a general problem or just with the shutter configuration?
  while(path->endsWith("/")) {                        // remove trailing "/"
    path->remove(path->length() - 1, 1);
  }

General problem or just your finding with the shutter. We can leave this in because it does not break anything.

[nospam2000]

Hi,

I’m working at two issues at a time, because both are needed for the shutter emulation:

1. Tasmota issue arendst#3159 You should read my general comments about the emulation problems there

2. The emulation support for the shutters.

On 6. 9 .2018, at 08:59, stefanbode wrote: SB> Also added the invert feature. Should be fine.

There is the following conversion chain:

1. int percentage 2 to 100% (by voice or slider input) in the Alexa App
2. int value 6 (2%) to 254 (100%) internally passed value from Alexa to the hue emulation
3. float value 0..1.00 used internally by the emulation
4. int percent value used by the command D_CMND_POSITION in XdrvMailbox.payload
5. calculated target position in Shutter_Target_Position[]
6. float value 0..1.00 used internally by the emulation
7. int value 6 (2%) to 254 (100%) returned to Alexa from the emulation

Only if every value from step 7. matches exactly the value from step 2. the emulation works together with Alexa. Believe me the difference between “should be fine” and “it works” was the hard part of these changes! There are rounding issues in the floating point calculations and I had to check many percentage values to get the correct numbers.

Please don’t change any of the formulas unless you proved that Alexa is not working with my original formulas. In the original Tasmota code some values have been working, but not all. Just doing theoretical math is not enough here.

On 6. 9 .2018, at 08:59, stefanbode notifications@github.com wrote:

Is the second IF really required? I think not because this is already checked before.

No. I already made some additional changes, but I could’t check in the before my vacation. Now I pushed them.

I changed to the shutterposition variable because this is already between 0..100 and reflect the current position and not the "to be" position

Also added the invert feature. Should be fine.

As long as the rule from above is ok, this is fine.

//STB mod

// please explain why you changed this response->replace("{s}", String((uint8_t)(253.0f sat + 1.5f))); response->replace("{b}", String((uint8_t)(253.0f bri + 1.5f))); } You changed the calculation and this might cause incompabilities with the original code.

It fixes parts of issue #3159, see above.

Therefore I want to understand the issue. With the new shutter_position bri can get a clear 1.0.

As far I can see your calculation is 254.5 maximum instead of 254.0. Please explain what you have seen here as an issue.

The important value is the integer value which comes out of this calculation and you will see, that this one has a maximum of 254 (although it should be checked and clamped to 254 which is fixed in my latest commit).

if(Settings.flag3.shutter_mode) maxhue = shutters_present;

I will change this because with ONE shutter on relay 3 and 4 there could be additional functionality. I see no requirement to limit this, but for sure check not to work on "shutter_presents *2" relays, because these belong to the shutter

Sure, this can be adapted, but it requires further changes. One step after the other…

    response.replace("{re", String((uint8_t)tmp));

Can you explain again the changes here to understand impact.

It just returns the original value as result of the request and avoids any conversion in betweeen. When all conversions are working exactly this change is not needed.

For the formula changes, please see above for issue #3159.

And last not least:

//stb mode // intresting. is this a general problem or just with the shutter configuration? while(path->endsWith("/")) { // remove trailing "/" path->remove(path->length() - 1, 1); }

General problem or just your finding with the shutter. We can leave this in because it does not break anything.

An URL can end with a ‘/‘ and the original Hue Hub can deal with it (e.g. "http://192.168.1.70/api/ca9f32/lights/"). This is to make it possible to end a request with ‘/‘. I’m pretty sure you can find it in the http RFC. A simple ‘if’ would do it, the ‘while’ would just remove multiple ‘/‘ at the end. I discovered that problem when I tested with Postman.

I would prefer to have a generic interface and “light type=dimmable light”, but there are so many places which make assumptions about the light type, so I had to check the shutter_mode instead of using an own light type.

Michael

[stefanbode]

Hi Michael, I'm now integrating your enhancement into my version. But I cannot get it worked even with your original file. I do see the item in Alexa home, but with status "Gerät reagiert nicht". Inside the log I do see the following errors. Any hint? Looks like the address already has an error.

13:22:03 HTP: Hue API (/rayuWQujJTNe3q4xGCrdhRAEJE4AuqkVoqPXzs2Q/lights/1)
13:22:03 HTP: Hue API ({"state":{"on":false,"bri":1,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Marquise","modelid":"LCT007","uniqueid":"5c:cf:7f:24:60:a8:00:11-1","swversion":"5.50.1.19085"})
13:22:06 HTP: Hue API (/rayuWQujJTNe3q4xGCrdhRAEJE4AuqkVoqPXzs2Q/lights/1)
13:22:06 HTP: Hue API ({"state":{"on":false,"bri":1,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Marquise","modelid":"LCT007","uniqueid":"5c:cf:7f:24:60:a8:00:11-1","swversion":"5.50.1.19085"})
13:22:08 HTP: Hue API (/rayuWQujJTNe3q4xGCrdhRAEJE4AuqkVoqPXzs2Q/lights/1/state)
13:22:08 HTP: Hue API ([{"error":{"type":901,"address":"/","description":"Internal Error"}}])
13:22:12 HTP: Hue API (/rayuWQujJTNe3q4xGCrdhRAEJE4AuqkVoqPXzs2Q/lights/1)

[stefanbode]

I checked out your latest change of the file from your repository with the same behavior. No changes here. Seems to be something general not working.

[stefanbode]

OK, found one bug. If you define more relays than friendly names the complete emulation does not work anymore. E.g. 5 relays defined. The you will get the error above. Now commands where send to sonoff and executed. But I did not get the correct value back to Alexa. The execution on the device works. Error at Aleca is "xxxx antwortet nicht" In the log it looks ok.

14:26:17 HTP: Hue API ([{"success":{"/lights/1/state/bri":255}}{"success":{"/lights/1/state/on":true}}])
14:26:17 Shutter 0: Real Pos: 800, Target 20000, source: Shutter, pos %: 0, direction: 1, rtcshutter: 9

14:26:18 CFG: Saved to flash at 3F8, Count 644, Bytes 3820

[stefanbode]

Hi Michael, to get rid of the rounding issues you should use the variable: Settings.shutter_position[i] The benefit compared to your approach is that this variable only have INT from 0..100. Therefore no rounding problems here if you solve it once. In your approach: (float)Shutter_Target_Position[device-1] / (float)Shutter_Open_Max[device-1] is a real variable that can get whatever value with whatever rounding effects.

[stefanbode]

OK, still did not get it working BACK to Alexa. On the Tasmota side, everything looks ok. Also, the response for 40% on shutter1 make sense. 40% is bri:102. This is comming from arg(0) and also in the response. I have no idea, why Alexa claims "device xxx does not respond"

14:55:27 UPP: Hue 3 response packets sent to 192.168.178.96:58433
14:55:35 HTP: Hue API (/rayuWQujJTNe3q4xGCrdhRAEJE4AuqkVoqPXzs2Q/lights/1/state)
14:55:35 HTP: Hue POST args ({"on": true,"bri":102})
14:55:35 HueLights Before Path: /rayuWQujJTNe3q4xGCrdhRAEJE4AuqkVoqPXzs2Q/lights/1/state
14:55:35 HueLights Path: /lights/1/state
14:55:35 WebServer->args(): 1
14:55:35 WebServer->arg(0): {"on": true,"bri":102}
14:55:35 Alexa input 102
14:55:35 response: [{"success":{"/lights/1/state/bri":102}}{"success":{"/lights/1/state/on":true}}]
14:55:35 HTP: Hue API ([{"success":{"/lights/1/state/bri":102}}{"success":{"/lights/1/state/on":true}}])

[stefanbode]

Hi Michael, because I did you solution not working, I started from scratch with the original file and did my own research. I did not have these issues of calculation back and forward. With the values from 0..100 it works absolutely smooth. Additionally, I made all the changes that are required to work with inverted shutters and that there might be more than one shutter (you need to check the start relay for each shutter). Tested and checkedin. You can now also use Shutter1 and Schutter2 and Relay3 and Relay4. A mixed environment with shutter and lights works. The only thing you need to be aware of that Schutter2 must be at Relay5 and 6. Otherwise, you get into conflict with the maxhue_names.

[nospam2000]

Hallo Stefan,

On 14. 9 .2018, at 09:23, stefanbode notifications@github.com wrote:

Hi Michael, because I did you solution not working,

Can you please be more precise what is not working? My unmodified source code is exactly doing what is supposed to do. You can position to any percentage between 2% and 100% and also say on/off.

It is not finished and there are features missing (no inversion, no lamp support), but is is working fine with only shutters. That’s what I wrote in the forum. I was awaiting feedback, but your answer is: “I throw away your code and rewrote it from scratch”

Then I test your enhanced version of my code and all the things I fixed are removed and the only thing which is working is the on/off command.

This kind of communication is not really stimulating for me.

I did not have these issues of calculation back and forward. With the values from 0..100 it works absolutely smooth.

What happens with your code is the following:

1. Alexa voice command “Alexa Rollo 1 10%"

2. Alexa sends request for 10%=26: 23:18:27 HTP: Hue API (/ca9f99/lights/1/state) 23:18:27 HTP: Hue POST args ({"bri":26})

3. Tasmota sends response 23:18:27 RSL: RESULT = {"POWER2":"ON"} 23:18:27 RSL: POWER2 = ON 23:18:27 HTP: Hue API ([{"success":{"/lights/1/state/bri":26}}])

4. Alexa reads the value and gets back the position of the current postion, not the current setpoint 23:18:27 HTP: Hue API (/ca9f99/lights/1) 23:18:27 HTP: Hue API ({"state":{"on":true,"bri":254,"hue":0,"sat":0,"xy":[0.5, 0.5],"ct":500,"alert":"none","effect":"none","colormode":"hs","reachable":true},"type":"Extended color light","name":"Rollo 1","modelid":"LCT007","uniqueid":"dc:4f:22:ca:9f:99:00:11-1","swversion":"5.50.1.19085"})

5. Then Tasmota starts the positioning 23:18:28 Shutter 0: Real Pos: 18500, Target 2000, source: Shutter, pos %: 100, direction: -1, rtcshutter: 15 23:18:28 CFG: Saved to flash at F6, Count 134, Bytes 3820

With your version I always get “Das Gerät scheint nicht richtig zu funktionieren.” because the bri values you return in the query in step 4 don’t match the bri value in the alexa request in steps 2 and 3.

Please add the following trace for testing to see the responses for debugging the requests:

diff --git a/sonoff/xplg_wemohue.ino b/sonoff/xplg_wemohue.ino index adbba59..2464327 100644 --- a/sonoff/xplg_wemohue.ino +++ b/sonoff/xplg_wemohue.ino @@ -814,6 +814,8 @@ 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); }

  Michael

[nospam2000]

Hi @stefanbode,

this is the log you should get if all is working correctly when setting it to 10%:

07:23:20 HTP: Hue API (/ca9f99/lights/1/state)
07:23:20 HTP: Hue POST args ({"bri":26})
07:23:20 lastsource 21: webgui:7
07:23:20 HTP: Hue API ([{"success":{"/lights/1/state/bri":26}}])
07:23:20 HTP: Hue API (/ca9f99/lights/1)
07:23:20 HTP: Hue API ({"state":{"on":true,"bri":26,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Rollo 1","modelid":"LCT007","uniqueid":"dc:4f:22:ca:9f:99:00:11-1","swversion":"5.50.1.19085"})
07:23:20 CFG: Saved to flash at F6, Count 150, Bytes 3820
07:23:20 Shutter 0: Stopp Pos. 2000, relay: 0, pulsetimer: 0, rtcshutter: 20
07:23:20 RSL: SHUTTER1 = 10

Michael

[nospam2000]

I now re-added lamp support and inversion support to my branch.

My next steps are:

• fix the emulation in the arendst:master branch

• Support a mix of shutters and lamps

  Michael

[stefanbode]

Hi @nospam2000, I don't want to blame you or ignore your efforts for the community. I had the same problem like you, that my Alexa was not excepting the requests correctly as written some posts before. Also everything was right in the code. Because I was not able to fix this I revert back to the original code and try to understand how the translation is working. I found out that for this use case I do not need a forward/backward calculation. I just send back the request value I got. Thats the reason my code is much smaller currently. Additionally, I want to support multiple shutters and the relays because my shutter has 2 lamps and two shutters connected. This needs to work. I assume that with my configuration the shuttervalue in the alexa app does not match the real position if I move my shutter without alexa. I tried two unmodified version of your code. The one you send and the latest that was in your repository. But I only substitute ONE file. Both files did not work with my Alexa. Even if it is also german. Do you make somewhere else changes? Also I found out, that in my current live version I have absolutely no problems with the 255 range and converting 0..100 into this range. Alexa excepts and executes on all values. Where is your recent code that should work?

[stefanbode]

One thing that makes is a bit easier to work on the 0..100 range is, that you convert from a smaller range into the wider range and back. This ensures you have less problems with rounding. The other way round it is way more complicated.

[nospam2000]

Hi @stefanbode

Because I was not able to fix this I revert back to the original code and try to understand how the translation is working

In the meanwhile I created a new branch for fixing the emulation support in the original arendst/master branch. There I added two unit test files for the conversions between the units. Please see also my latest comment in https://github.com/arendst/Sonoff-Tasmota/issues/3159.

My repository has changed. The problem was that I was unable to create a repository as a fork of arendst/Sonoff-Tasmota because I already have a fork of your repository.

I renamed my fork from your repo to Sonoff-Tasmota-Shutter and created a new one called just Sonoff-Tasmota which unfortunately is not marked as fork of arendst/Sonoff-Tasmota. The link to my shutter repo branch is now https://github.com/nospam2000/Sonoff-Tasmota-Shutters/tree/emulationSupport

I found out that for this use case I do not need a forward/backward calculation. I just send back the request value I got.

For the response this is easy, but Alexa polls the whole state just after the response to get the whole state. There you normally don't have the originally set value.

Additionally, I want to support multiple shutters and the relays because my shutter has 2 lamps and two shutters connected. This needs to work.

I understand and agree, but first the base must be working, then it can be enhanced. I'm still in the phase of understanding the Tasmota functionality and the code.

I assume that with my configuration the shuttervalue in the alexa app does not match the real position if I move my shutter without alexa.

When moving it outside Alexa you should never have a problem. Alexa just polls and accepts the new value.

When you start from scratch should at least comment out the parts of the response you don't need. Especially the cm and x/y in the original code should be removed.

I tried two unmodified version of your code. The one you send and the latest that was in your repository. But I only substitute ONE file. Both files did not work with my Alexa. Even if it is also german. Do you make somewhere else changes?

I only commented out another trace, but I checked in that change 5 minutes ago.

Also I found out, that in my current live version I have absolutely no problems with the 255 range and converting 0..100 into this range. Alexa excepts and executes on all values.

This sounds like your Alexa is different from mine. It sounds strange, but it is not impossible. Can you please remove and re-add your devices in your next test (see steps 9 and 10 below).

Where is your recent code that should work?

Please see my git checkout command below in step 1. The most recent version is always my best version :-)

Let me describe what I do to reproduce my environment. I did this now, so I don't have any artifacts. I also changed my CFG_HOLDER version to start up with a fresh configuration:

1. git clone -b emulationSupport https://github.com/nospam2000/Sonoff-Tasmota-Shutters.git Sonoff-Tasmota-shutter-nospam2000

2. copy my user_config_overwrite.h which contains the following settings (+WLAN):

   #undef  CFG_HOLDER
   #define CFG_HOLDER        4620
   #undef EMULATION
   #define EMULATION              EMUL_HUE
   #undef MQTT_USE
   #define MQTT_USE               0

3. run build task PlatformIO:build (sonoff)

4. upload firmware esptool.py --chip esp8266 --before no_reset --port /dev/cu.usbserial-A9IHT7ZR write_flash 0 ~/Downloads/Arduino/Sonoff-Tasmota-shutter-nospam2000/.pioenvs/sonoff/firmware.bin

5. Go to web page: "Configure Module" = 07 Sonoff 4CH (which is my hardware)

6. Go to web page "Configure other", MQTT=off, Hue Bridge=on, set names 1..4

7. Logging serial=none, web=4 more debug

8. console commands:

   SETOPTION80 1
   SETOPTION14 1
   SETOPTION81 1
   SHUTTERRELAY2 3

9. go to https://alexa.amazon.de/spa/index.html#appliances and remove all existing Sonoff lamps for the device

10. Say "Alexa suche neue Geräte"

11. Say "Alexa Rollo 1 10%" which gives the following traces:

    21:17:40 HTP: Hue API (/ca9f99/lights/1/state)
    21:17:40 HTP: Hue POST args ({"bri":26})
    21:17:40 lastsource 19: webgui:7
    21:17:40 SRC: 
    21:17:40 RSL: RESULT = {"POWER2":"ON"}
    21:17:40 RSL: POWER2 = ON
    21:17:40 HTP: Hue API ([{"success":{"/lights/1/state/bri":26}}])
    21:17:40 CFG: Saved to flash at F9, Count 27, Bytes 3820
    21:17:40 HTP: Hue API (/ca9f99/lights/1)
    21:17:40 HTP: Hue API ({"state":{"on":true,"alert":"none","effect":"none","reachable":true,"bri":26},"type":"Extended color light","name":"Rollo 1","modelid":"LCT007","uniqueid":"dc:4f:22:ca:9f:99:00:11-1","swversion":"5.50.1.19085"})
    21:17:41 Shutter 0: Real Pos: 2500, Target 2000, source: , pos %: 20, direction: -1, rtcshutter: 16
    21:17:41 Shutter 0: Stopp Pos. 2000, relay: 1, pulsetimer: 0, rtcshutter: 20
    21:17:41 RSL: SHUTTER1 = 10
    21:17:41 SRC: 
    21:17:41 RSL: RESULT = {"POWER2":"OFF"}
    21:17:41 RSL: POWER2 = OFF
    21:17:41 CFG: Saved to flash at F8, Count 28, Bytes 3820

12. from the "Info" page:

    
    Program Version | 6.1.1.13
    Core/SDK Version | 2_3_0/1.5.3(aec24ac9)

/EDIT: first I forgot "SETOPTION80 1" in step 8, now it works

Can you please do the same so we have the same configuration, that means not only copy one file, but clone my whole repository so we have the same base?

  Michael

[nospam2000]

@stefanbode,

which module type do you configure and which light_type + light_subtype is active? Have you set "SETOPTION15 1?". The code behaves very differently depending on these 3 variables.

Michael

[stefanbode]

I use a generic ESP8266. In special a WEMOS D1 mini. It worked with Setoption15 ON and OFF. No issues here. what about the different light types. Where can I configure this one because I have not configured anything

[stefanbode]

I double checked my code. And it looks there is a two-way communication. Whenever I change the shutter on the Web frontend. I can see the correct value immediately in the Alexa App. So it seems to be something with the light types.

[nospam2000]

the light_type + light_subtype are set in sonoff.ino:GpioInit() automatically depending on the selected module type and depending on SETOPTION15. For example :

  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
    }
}
[...]
  else if (SONOFF_BN == Settings.module) {   // PWM Single color led (White)
    light_type = LT_PWM1;
  }
  else if (SONOFF_LED == Settings.module) {  // PWM Dual color led (White warm and cold)
    light_type = LT_PWM2;
  }
  else if (AILIGHT == Settings.module) {     // RGBW led
    light_type = LT_RGBW;
  }
  else if (SONOFF_B1 == Settings.module) {   // RGBWC led
    light_type = LT_RGBWC;
}

[stefanbode]

I have two shutter modules. One production and one for testing. Both are Wemos D1 mini. Also selected in the Configuration tab. The production one has two shutters, 2 Relays and PWM1,PWM2,PWM3 for an LED stripe with setoption15=0. My test module only has 2 shutters and two relays. Both modules work fine with the minimal changes in the WEMOSHUE file and without a complicated forward backward calculation. I do see not issues currently and as mentioned before also the reporting back of the actual position works. This will send back AFTER the shutter stops. During operation, you still see the old value. Also from time to time there is 1% difference between what you requested and what you get. But this is also fine because it is not possible to stop the motor in any condition exactly at the requested position.

[nospam2000]

SB> Also from time to time there is 1% difference between what you requested and what you get This is exactly the rounding issue which leads to the very annoying Alexa message "Das Gerät funktioniert nicht richtig" when you use the voice command. When you use the Alexa app, you will only see a small note for 2 seconds that there is a problem with the device. It has nothing to do with the time, but is reproducable for specifc values (use my unit tests with your formula and you will see which values).

SB> During operation, you still see the old value

Which will also lead to the Alexa error message from above. For sure you can ignore that error message, but the WAF for the voice commands will be very bad when you always get such error messages.

My question was: when you use my version, what problem do you see? How does you log look like (with command and response, like the one I posted)?

[stefanbode]

I currently cannot use your code because already on the 6.2 release. Will do ASAP. My Alexa complains nothing so far. Always get the OK. And Themis operates

[B1G1]

Hi, i bought an echo dot and i would like to use Alexa to open the shutters but i don’t understand how configure the Hue emulation. Con you help me?

[stefanbode]

Hi Bigi,

I do not know, if the Alexa integration currently works. It worked but then there were some changes.... It normally works like a dimmer. You set a name like "shutter kitchen" and then say "shutter kitchen to 50 percent". This was the idea and how it should work.

[B1G1]

Well, I solved by integrating Home Assistant in alexa using this https://github.com/mike-grant/haaska Now I can manage with the voice all the devices I have, including the shutters

[micdg96]

Is there any possibility to change the shutter percentage through Google Assistant?

[lollul]

Is there any possibility to change the shutter percentage through Google Assistant?

Yes, I've been using GA/Google Home for a couple of months now via gbridge.io. While there appears to be unofficial support in Google Home for shutters/blinds they are not supported yet on Google Home app (only voice commands work). So, I've set up my shutters as 'lights' in gbridge with Brightness and OnOff traits. Then I'm using a little mosquitto_sub/mosquitto_pub script to 'translate' gbridge topics to Stefan's Tasmota shutters topics. E.g. I translate 'onoff' from gbridge with payload 0 to SHUTTERCLOSE and 'onoff' with payload 1 to SHUTTEROPEN. I guess this translation could probably be avoided...may need a new command in Stefan's Tasmota though. There could be better way to do this of course. I simply decided to wait for official shutter/blinds support in GA and I'm fine with my hackish translation for now.

[stefanbode]

Best case you check how people are doing it with homeassistant. There are some nice examples. To work on a common topic for the shutter I would suggest to use the BACKLOG topic and then the commands (SHUTTEROPEN/SHUTTERCLOSE/SHUTTERPOSITION=30.... as a payload.As mentioned see the wiki with the homeassistant implementation. Should be very similar.

[DasLemo]

Hi, I hope it's okay i use this thread. Is the Alexa support currently broken? I know it was broken a while ago because Amazon changed something about the Hue-Support. Since then it worked again for me to pull the shutters completely up and down again but I am not able to close or open it toa certain percentage. I'm using the newest release (Sonoff-Tasmota 6.6.0.1 stb-1.5 by Theo Arends) but can't get it to work. Best regards!

[stefanbode]

Thanks for the feedback. The current update has several changes to the hue emulation. This might cause a breakdown. I was not able to test this yesterday. But will do soon, if you say the percentage does not work anymore.

[timmaeh]

It do not work either for me. Says something like "the device does not support this".

Just waiting for a version with alexa support :-)