Alexa Emulation support #51
Comments
|
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. |
|
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 :)) |
|
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 |
|
It might be that the dimming option was not ported due to lack of space.. |
|
In file xplg_wemohue.ino, there is a function called HueLights which eventually parses a value called "bri". |
Hue Emulation for shutters works good, but multicolor lamps need some fixes
|
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%. |
|
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: Is the second IF really required? I think not because this is already checked before. 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.
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 Can you explain again the changes here to understand impact. And last not least: General problem or just your finding with the shutter. We can leave this in because it does not break anything. |
|
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 ***@***.***> 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
|
|
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. |
|
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. |
|
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. |
|
Hi Michael, to get rid of the rounding issues you should use the variable: Settings.shutter_position[i] |
|
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" |
|
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. |
|
Hallo Stefan,
On 14. 9 .2018, at 09:23, stefanbode ***@***.***> 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
|
|
Hi @stefanbode, this is the log you should get if all is working correctly when setting it to 10%: Michael |
|
I now re-added lamp support and inversion support to my branch. My next steps are:
Michael |
|
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? |
|
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. |
|
Hi @stefanbode
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. 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
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.
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.
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 only commented out another trace, but I checked in that change 5 minutes ago.
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).
Please see my git checkout command below in step 1. 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:
/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 |
|
which module type do you configure and which light_type + light_subtype is active? Michael |
|
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 |
|
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. |
|
the light_type + light_subtype are set in sonoff.ino:GpioInit() automatically depending on the selected module type and depending on SETOPTION15. |
|
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. |
|
SB> Also from time to time there is 1% difference between what you requested and what you get 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? |
|
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 |
|
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? |
|
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. |
|
Well, I solved by integrating Home Assistant in alexa using this https://github.com/mike-grant/haaska |
|
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. |
|
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. |
|
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. |
|
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. |
|
It do not work either for me. Says something like "the device does not support this". Just waiting for a version with alexa support :-) |
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?
The text was updated successfully, but these errors were encountered: