Official Alexa Smart Home Skill for openHAB 2

[m4rk (Mark)]

Thanks. If the bug is fixed would that fix my issue?

[jeshab (Jeremy)]

@m4rk

If the bug is fixed would that fix my issue?

Correct. There is mismatch between your OH server locale English (AT) and your Alexa device locale English (UK). The fix would be only to use the language and not the country.

If you really want to play with this functionality right now, you can append @en-GB to your text-based names but keep in mind that this syntax may no longer be supported after the fix is implemented.

String TestString "Test" {alexa="ModeController.mode" [supportedModes="Normal=Normal@en-GB:Cottons@en-GB,Delicate=@Value.Delicate:Knits@en-GB"]}

[Marc_W (Marc)]

@jeshab

You shouldn’t translate them on your end.

Ah, quite important.

Rollershutter Atrium_Jalousie_West "Avocado" <rollershutter> { channel="zwave:device:babe135b:node3:blinds_control", alexa="RangeController.rangeValue" [supportedRange="0:100:1", presets="0=@Value.Close,100=@Value.Open,20=blau", unitOfMeasure="Percent", actionMappings="close=0,open=100,lower=(-10),raise=(+10)", stateMappings="Closed=0,Open=1:100"]}

The action names are working now for me in German, when using the commands

• “Alexa, fahre Avocado ganz nach oben!” → Rollershutter opens entirely
• “Alexa, fahre Avocado ganz nach unten!” → Rollershutter closes entirely
• “Alexa, fahre Avocado hoch!” → Rollershutter opens entirely
• “Alexa, fahre Avocado runter!” → Rollershutter closes entirely

What is not working (correctly):

• “Alexa, fahre Avocado etwas nach oben!” → Rollershutter opens entirely, which is wrong
• “Alexa, schließe/öffne Avocado!” → Avocado doesn’t support this (What esle should be the translation to “open”/“close”?)

And finally, I understand that I can use any non-reserved name in presets, and define the name in my local language, right? So, as in this case, I should be able to name a preset “blau”, and don’t need to name it “blue”, right? Still, none of these commands can activate the preset:

• “Alexa, aktiviere Einstellung blau für Avocado!” → I don’t know about that.
• “Alexa, verwende Einstellung blau für Avocado!” → Ba-dum
• “Alexa, setze Avocado auf Einstellung blau” → I don’t know how to perform this setting for Avocado
• “Alexa, setze Avocado auf blau” → I don’t know how to perform this setting for Avocado

I will gladly provide examples in German, once I get this working.

[m4rk (Mark)]

Oh great. It was on my to do list for Xmas. So now I can continue in between eating and drinking

edit… Confirmed. The suggested temporary work around fixes my issue

Happy Holidays to all

[jeshab (Jeremy)]

@Marc_W

Ah, quite important.

Rollershutter Atrium_Jalousie_West "Avocado" <rollershutter> { channel="zwave:device:babe135b:node3:blinds_control", alexa="RangeController.rangeValue" [supportedRange="0:100:1", presets="0=@Value.Close,100=@Value.Open,20=blau", unitOfMeasure="Percent", actionMappings="close=0,open=100,lower=(-10),raise=(+10)", stateMappings="Closed=0,Open=1:100"]}

It’s also case sensitive since these are considered as ids: actionMappings="Close=0,Open=100,Lower=(-10),Raise=(+10)"

@Marc_W

And finally, I understand that I can use any non-reserved name in presets, and define the name in my local language, right? So, as in this case, I should be able to name a preset “blau”, and don’t need to name it “blue”, right?

Correct. “setze Avocado auf blau” should have worked. Check your regional settings following this thread.

[Marc_W (Marc)]

@jeshab

It’s also case sensitive since these are considered as ids: actionMappings="Close=0,Open=100,Lower=(-10),Raise=(+10)"

Great. Now “Alexa, schließe/öffne Avocado!” works as intended.

However, I had previously configured locale in the Paper UI, now I also uncommented and edited these lines into services/runtime.cfg:

org.eclipse.smarthome.i18n:language=de
org.eclipse.smarthome.i18n:region=DE

As I’m not sure, whether these should be as Strings or like Enumerations, I also tried

org.eclipse.smarthome.i18n:language="de"
org.eclipse.smarthome.i18n:region="DE"

Then I restarted the openhab2.service (just in case). However, using the custom preset is still notpossible and “setze Avocado auf blau” does not work.

Do you have more of your valuable advice?

[jeshab (Jeremy)]

@Marc_W

Do you have more of your valuable advice?

You need to trigger an Alexa discovery after making that change on the openHAB side.

[Marc_W (Marc)]

@jeshab

You need to trigger an Alexa discovery after making that change on the openHAB side.

Of course I did that, too. After every edit in the OH item config, too.

[jeshab (Jeremy)]

@Marc_W

Of course I did that, too. After every edit in the OH item config, too.

So I think I found the culprit here. What version of OH are you running? The regional settings service pid was renamed in 2.5. The skill is expecting the previous pid.

In the meantime, as I mentioned to @m4rk, you can append @de-DE to your preset text-based name as a workaround until this change is implemented.

Thanks for helping identify this one!

Add new regional settings service pid support

[Marc_W (Marc)]

@jeshab

Thanks for helping identify this one!

I’m glad I could contribute, when actually you were helping me.

[jeshab (Jeremy)]

@m4rk @Marc_W The two bugs that I listed above are now fixed and released to the live skill.

Can you please remove the workaround I mentioned previously and trigger an Alexa discovery? As long as your regional language setting is setup in line with Alexa, you shouldn’t have to specify it at the item level.

The previous “locale” format is no longer supported (The usage documentation may take up to 24 hours to reflect the latest changes). If you need to override the server language property at the item level, you can add it to the language metadata parameter. This setting covers all text-based names defined in the item configuration.

String TestString "Test" {alexa="ModeController.mode" [supportedModes="Normal=Normal:Cottons,Delicate=@Value.Delicate:Knits", language="en"]}

[m4rk (Mark)]

Hi Jeremy,

Thank you. All working now without any extra bits of language code

Alexa had trouble with ‘Knits’ in your example. She thinks I say two minutes and sets a timer. Doh! So, I changed it to Woolens

For my blinds, open, close, raise and lower all work.

The work around for the lack of an Alexa Stop command for blinds is working and totally handled by openHAB without an Alexa routine. I used both mode and range controllers to do it.

Or I should say it could be fully handled by openHAB. However, to stop a blind I have to say ‘Set blind to stop’ …hmmmm … its a bit clunky

To make it more natural I did create an Alexa routine for ‘Stop blind’ voice command

So, it all works with less code now.

Here is the code for others. It may need a bit more more tidying!

items

Group OfficeTest "Office test blind" {alexa="Endpoint.Other"}
String OfficeBlindStop "Stop office blind" (OfficeTest) {alexa="ModeController.mode" [supportedModes="STOP=STOP,UP=UP, DOWN=DOWN"]} //, could use this instead of command in rule >>>  expire="5s,command=STOPPED"
Rollershutter OfficeBlinds "Office blinds" (OfficeTest) {alexa="RangeController.rangeValue" [category="EXTERIOR_BLIND",supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)"], channel="openwebnet:bus_automation:Screen10:55:shutter" }

rule "STOP BLIND"
when 
    Item OfficeBlindStop changed to 'STOP'
then
    OfficeBlinds.sendCommand(STOP)
    Thread::sleep(1000)
    OfficeBlindStop.postUpdate('STOPPED')
end

I elaborated more for the particular blinds binding I am using here:

[BTicino/OpenWebNet] New openHAB2 binding ready for testing

Hi, I have voice commands now working with Alexa without need for an Alexa routine. ‘Alexa, Open, Close, Raise, Lower blind’ all work without Alexa routines or openHAB rules and proxy items. I now use the more capable v3 Alexa tagging. There was an issue with mixed language and locations like me. English language but in located Austria with .de Amazon server. However, Jeremy, the Alexa skill developer quickly fixed that bug. The one missing command is STOP and for that I still need an openHAB …

Now I will test room awareness.

[dlaplexurenet (David Laroche)]

Hi,

Is there a way to auto-create Alexa groups (not categories like plugs, lights, …) according to the OpenHAB groups?
I want to achieve that it will sync the rooms from OH to Alexa and as such having a living group matching the group in OH allowing to switch on/off lights and/or plugs all simultaneously. As far as I understand the current doc there seems to be no possibility for this or am I wrong?

See screenshots:

Thanks,
David

[Marc_W (Marc)]

Hi Jeremy.

@jeshab

Can you please remove the workaround I mentioned previously and trigger an Alexa discovery? As long as your regional language setting is setup in line with Alexa, you shouldn’t have to specify it at the item level.

Of course. My setup is working now as follows:

Rollershutter RS1 "Avocado" <rollershutter> { channel="...", alexa="RangeController.rangeValue" [supportedRange="0:100:1", presets="0=@Value.Close,100=@Value.Open,20=blau", unitOfMeasure="Percent", actionMappings="Close=0,Open=100,Lower=(-10),Raise=(+10)", stateMappings="Closed=0,Open=1:100"]}  

(I hope I understood correctly to have Lower/Raise in upper-case first letters, to refer to the builtin action and have Alexa translate my voic commands and compare the translation with the builtin actions!?)

and responds correctly to the following commands in German:

• “Alexa, setze Avocado auf blau!”
• “Alexa, setze Avocado auf 30 Prozent!”
• “Alexa, schließe/öffne Avocado!”
• “Alexa, fahre Avocado ganz runter”
• “Alexa, fahre Avocado ganz rauf!”

I noticed some strange behaviour here:

• “Alexa, fahre Avocado runter!” (In my opinion, this should be equivalent so “Alexa, lower Avocado!”) → Result: Alexa executes something, but on each even command, the Rollershutter goes down (by some seemingly random amount and not 10%), on each odd command the Rollershutter goes up (by some different, seemingly random amount).
• “Alexa, fahre Avocado hoch!” → Same behaviour as previous point (moving up, down on alternate commands, seemingly random travel distance)

In summary: yes, presets work in local language, but there is unexpected behaviour in the Raise/Lower commands

[jeshab (Jeremy)]

@m4rk

The work around for the lack of an Alexa Stop command for blinds is working and totally handled by openHAB without an Alexa routine. I used both mode and range controllers to do it.

Or I should say it could be fully handled by openHAB. However, to stop a blind I have to say ‘Set blind to stop’ …hmmmm … its a bit clunky

To make it more natural I did create an Alexa routine for ‘Stop blind’ voice command

So this is exactly what I would have recommended. The only difference is that I would set your proxy item to autoupdate=false so you don’t have to mess around with its state and the skill would also use the command received as the current state. I updated below, your item definition (added missing stateMappings parameter) and rule.

Group OfficeTest "Office test blind" {alexa="Endpoint.ExteriorBlind"}
String OfficeBlindsCommand "Office blinds command" (OfficeTest) {alexa="ModeController.mode" [friendlyNames="@Setting.Direction", supportedModes="STOP=STOP,UP=UP, DOWN=DOWN"], autoupdate="false"}
Rollershutter OfficeBlinds "Office blinds" (OfficeTest) {alexa="RangeController.rangeValue" [friendlyNames="@Setting.Opening", supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)", stateMappings="Closed=100,Open=1:100"], channel="openwebnet:bus_automation:Screen10:55:shutter"}

rule "Office Blinds Command"
when 
    Item OfficeBlindsCommand received command STOP or
    Item OfficeBlindsCommand received command UP or
    Item OfficeBlindsCommand received command DOWN
then
    OfficeBlinds.sendCommand(receivedCommand)
end

On a side note, after putting some more thoughts into potentially allowing Rollershutter items to be ModeController, I realized that this will be a problem for the state reporting and would basically require to add each number value from 0 to 100 as supported modes. So this will unfortunately not happen and the solution above should be the recommended solution for the time being.

[jeshab (Jeremy)]

@dlaplexurenet

Is there a way to auto-create Alexa groups (not categories like plugs, lights, …) according to the OpenHAB groups?

You can’t auto-create Alexa groups but you can have openHAB groups modeled as a device. You just need to make sure to define a group type on that item.

In the example below, all 4 items will be modeled as a device on the Alexa side. If you request “Alexa, turn off all lights”, all the lights associated to the group will be turned off. Likewise, you can control each light individually; “Alexa, set color light to blue”

Group:Switch:OR(ON,OFF) Lights "All Lights" {alexa="Lightning"}
Switch SwitchLight "Switch Light" (Lights) {alexa="Lightning"}
Dimmer DimmerLight "Dimmer Light" (Lights) {alexa="Lightning"}
Color ColorLight "Color Light" (Lights) {alexa="Lightning"}

It important to note that if you are looking to take advantage of the Alexa-enabled group feature (aka room awareness), you will have to use Alexa groups. There is no way around it.

[jeshab (Jeremy)]

@Marc_W

I noticed some strange behaviour here:

• “Alexa, fahre Avocado runter!” (In my opinion, this should be equivalent so “Alexa, lower Avocado!”) → Result: Alexa executes something, but on each even command, the Rollershutter goes down (by some seemingly random amount and not 10%), on each odd command the Rollershutter goes up (by some different, seemingly random amount).
• “Alexa, fahre Avocado hoch!” → Same behaviour as previous point (moving up, down on alternate commands, seemingly random travel distance)

So your item definition looks good. And according to Amazon utterance examples, the lower/raise requests you are using should work as intended. Have you checked your event logs to see the command received? Also, check your Alexa voice transcript history to see how your request was understood.

[m4rk (Mark)]

I tested the rule and it goes into a loop

[jeshab (Jeremy)]

How so? Can you post some of your event logs?

[m4rk (Mark)]

openHAB got into a loop of some sort. The log was filling up with get requests. I fixed that clearing the cache and a few reboots.

Now I get this in the log :
Command ‘STOP’ has been ignored for group ‘OfficeBlind’ as it is not accepted

Group OfficeBlind "Office test" {alexa="Endpoint.EXTERIOR_BLIND"}
    String OfficeBlindCommand "Office blind command" (OfficeBlind) {alexa="ModeController.mode" [supportedModes="STOP=STOP,UP=UP, DOWN=DOWN", autoupdate="false"]} 
    Rollershutter Office_RollerShutter "Office blind [%d %%]" <blinds> (OfficeBlind,gAllBlinds) {alexa="RangeController.rangeValue" [supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)"], channel="openwebnet:bus_automation:Screen10:55:shutter" }

This causes the error and the blind does not stop :

rule "Office blind command"
when 
    Item OfficeBlindCommand received command STOP or
    Item OfficeBlindCommand received command UP or
    Item OfficeBlindCommand received command DOWN
then
    OfficeBlind.sendCommand(receivedCommand)
    //Office_RollerShutter.sendCommand(STOP)
    //Thread::sleep(1000)
    //OfficeBlindCommand.postUpdate('STOPPED')
end

This works

rule "Office blind command"
when 
    Item OfficeBlindCommand received command STOP or
    Item OfficeBlindCommand received command UP or
    Item OfficeBlindCommand received command DOWN
then
    //OfficeBlind.sendCommand(receivedCommand)
    Office_RollerShutter.sendCommand(STOP)
    Thread::sleep(1000)
    OfficeBlindCommand.postUpdate('STOPPED')
end