Thanks for the quick answer @jeshab and @sihui!
I’ll stick with the V2 for now than.
Any idea when the V3 is planned to be released?
Thanks, Adam
Hi, can you explain how you solved it?
After that I enable the openHAB skill on Alexa. When requested, (use the credentials of your openHAB Cloud account to connect your system to Alexa) I don’t get outh credentials from openhab and so my system is not detected.
I state that everything works with Google Assistant.
Ok, I solved it by myself. You had to deactivate your account and activate it again.
Hi all, is it possible to use the new form of tags with 2.5m2? I’d like to link my daikin clima to Alexa like a thermostat if is fixed now
Hello
Thanks for your skill.
I am trying to make it works with no clue.
i have a raspberry pi with openhab 2.14. i have installed the skill and the connector but when i scan for item i found nothing.
My item with
// RF Socket Items
Group:Switch:OR(OFF, ON) Gplugs <poweroutlet>
Switch Power_Plug_Socket_1 <poweroutlet> (Gplugs) [ "Switchable" ]
Switch Power_Plug_Socket_2 <poweroutlet> (Gplugs) [ "Switchable" ]
Switch Power_Plug_Socket_3 <poweroutlet> (Gplugs) [ "Switchable" ]
Switch Power_Plug_Socket_4 <poweroutlet> (Gplugs) [ "Switchable" ]
String PlaceHolder ""
Switch Remote_Send { channel="exec:command:remote-send:run" }
String Remote_Send_Args { channel="exec:command:remote-send:input" }
String Remote_Send_Out { channel="exec:command:remote-send:output" }
==> /var/log/openhab2/events.log <==
2019-10-16 22:18:11.666 [vent.ItemStateChangedEvent] - hue_0107_0017884165ce_3_presence changed from OFF to ON
2019-10-16 22:18:12.101 [vent.ItemStateChangedEvent] - hue_0107_0017884165ce_3_last_updated changed from 2019-10-16T22:13:30.000+0100 to 2019-10-16T22:18:11.000+0100
2019-10-16 22:18:12.171 [me.event.ThingUpdatedEvent] - Thing 'hue:0107:0017884165ce:3' has been updated.
2019-10-16 22:18:21.345 [vent.ItemStateChangedEvent] - hue_0107_0017884165ce_3_presence changed from ON to OFF
2019-10-16 22:18:21.748 [vent.ItemStateChangedEvent] - hue_0107_0017884165ce_3_last_updated changed from 2019-10-16T22:18:11.000+0100 to 2019-10-16T22:18:21.000+0100
2019-10-16 22:18:21.793 [me.event.ThingUpdatedEvent] - Thing 'hue:0107:0017884165ce:3' has been updated.
2019-10-16 22:20:12.737 [me.event.ThingUpdatedEvent] - Thing 'hue:0302:0017884165ce:2' has been updated.
2019-10-16 22:25:12.363 [vent.ItemStateChangedEvent] - hue_0302_0017884165ce_2_temperature changed from 20.22 °C to 20.36 °C
2019-10-16 22:25:12.491 [me.event.ThingUpdatedEvent] - Thing 'hue:0302:0017884165ce:2' has been updated.
2019-10-16 22:30:12.101 [me.event.ThingUpdatedEvent] - Thing 'hue:0302:0017884165ce:2' has been updated.
==> /var/log/openhab2/openhab.log <==
2019-10-15 22:10:00.871 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'powerplugs.items'
2019-10-15 22:21:13.157 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2019-10-15 22:21:13.598 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 1c70fa7e-72be-448d-814d-919491bb582d, base URL = http://localhost:8080)
2019-10-15 22:21:17.592 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 1c70fa7e-72be-448d-814d-919491bb582d, base URL = http://localhost:8080)
2019-10-15 22:23:30.073 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2019-10-15 22:23:30.328 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 1c70fa7e-72be-448d-814d-919491bb582d, base URL = http://localhost:8080)
2019-10-15 22:23:36.494 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 1c70fa7e-72be-448d-814d-919491bb582d, base URL = http://localhost:8080)
2019-10-16 00:00:32.639 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:home
2019-10-16 00:00:35.331 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:home
2019-10-16 20:34:04.626 [INFO ] [eemulation.internal.ConfigManagement] - Hue Emulation pairing disabled. Service available under /api
Somebody can help me please?
Your item definitions are missing labels. You can refer to these recommendations on how to name them.
1 Like
Many thanks i must have read a bad doc where you have only to write
[ “Switchable” ] in your item files 
Hi,
is it possible to define custom colors for the ColorController?
I have a color item and basically it wokes fine with Alexa:
Color DG_Buero_TV_Light_HSB "TV Licht HSB" (DG_Buero, DG_Buero_TV_Light) { alexa="ColorController.color", channel="shelly:shellyrgbw2-color:661f4f:color#hsb" }
Now I have predefined colors with my LED stripe like “Red, Orange”. So I can change the color with Alexa.
Unfortunately some of these colors don’t look very good. e.g. “orange” is more a yellow than an orange.
So I was wondering if it’s possible to do to something similar with the ColorController like with a Selection item where I’m mapping my own HSB-Colors:
Selection item=DG_Buero_TV_Light_HSB mappings=["8,100,89"="Orange", "60,100,100"="Gelb", "0,100,100"="Rot", "156,100,62"="Türkis", "20,100,73"="Amber", "277,87,94"="Lila", "232,100,89"="Hellblau", "240,100,100"="Blau", "0,0,100"="Weiß", "128,100,89"="Hellgrün", "320,100,100"="Rosa", "120,100,100"="Grün" ] label="Farbe" icon="colorpicker"
best regards,
Michael
Unfortunately, there is no way to customize colors in the Alexa Skill API as of yet. The only solution here would be to use a proxy color item and mapping rules to use your predefined color values while having the reported state in line with Alexa’s color values. Also, you should use the “Lighting” metadata label, since the color controller interacts with the color levels only. You wouldn’t be able to dim or turn on/off that light the way you have set it up, unless these capabilities are controlled with different channels.
items
Color DG_Buero_TV_Light_HSB_Alexa "TV Licht HSB" (DG_Buero, DG_Buero_TV_Light) {alexa="Lighting"}
Color DG_Buero_TV_Light_HSB "TV Licht HSB" (DG_Buero, DG_Buero_TV_Light) {channel="shelly:shellyrgbw2-color:661f4f:color#hsb"}
rules
rule "TV Licht HSB Alexa Commands"
when
Item DG_Buero_TV_Light_HSB_Alexa received command
then
switch receivedCommand.toString {
case "39,100,100": DG_Buero_TV_Light_HSB.sendCommand("8,100,89") // Orange
...
default: DG_Buero_TV_Light_HSB.sendCommand(receivedCommand)
}
end
rule "TV Licht HSB Changes"
when
Item DG_Buero_TV_Light_HSB changed
then
switch DG_Buero_TV_Light_HSB.state.toString {
case "8,100,89": DG_Buero_TV_Light_HSB_Alexa.postUpdate("39,100,100") // Orange
...
default: DG_Buero_TV_Light_HSB_Alexa.postUpdate(DG_Buero_TV_Light_HSB.state)
}
end
1 Like
Thanks for your help. Great idea.
I’ve implemented the items and rules like you suggested but the logs shows, that the rules are not working:
2019-11-03 17:36:57.961 [vent.ItemStateChangedEvent] - DG_Buero_TV_Light_Watt changed from 7.12 to 3.49
2019-11-03 17:37:02.692 [ome.event.ItemCommandEvent] - Item ‘DG_Buero_TV_Light_HSB_Alexa’ received command 39,100,100
2019-11-03 17:37:02.716 [vent.ItemStateChangedEvent] - DG_Buero_TV_Light_HSB_Alexa changed from 240,100,100 to 39,100,100
2019-11-03 17:37:02.720 [ome.event.ItemCommandEvent] - Item ‘DG_Buero_TV_Light_HSB’ received command 39,100,100
2019-11-03 17:37:02.751 [nt.ItemStatePredictedEvent] - DG_Buero_TV_Light_HSB predicted to become 39,100,100
I forgot to convert both switch case conditions to string type. I have updated my original post. It should work now.
Hello Jeremy,
thanks a lot, now it works.
Best regards, Michael
I am struggling with this as well:
Is is possible to define two {} within one item?
one with the {alexa=" stuff and one with e.g. z-wave like {channel="zwave?
Furthermore:
Is there a way to block and control trough amazon to OH, when I am not home?
(I switch off Alexa with a power plug, but theoretically my openhab would still be controllabe by amazon)
I see…
So, you always need an auxiliary item for each item you would like to switch?
You only need an auxiliary item if the command generated by the Alexa skill cannot be directly processed on the OH side. Most of the time, you would have both alexa and channel metadata values defined on a given item.
Dimmer BedromLight "Bedroom Light" {alexa="Lighting", channel="zwave:..."}
The only way I could think of would be to switch the openHAB Cloud service mode from remote to notification, back and forth, via the REST API using a rule that triggers a curl command. This will prevent the skill from issuing commands to your OH server, when in notification mode, but would also prevent any other remote access such as the openHAB mobile app. Just to be clear, the expose items referred below are the ones you setup for IFTTT integration. No need to add the items setup for the Alexa skill in that list.
curl -X PUT --header "Content-Type: application/json" --header "Accept: application/json" -d "{
\"mode\": \"remote\",
\"baseURL\": \"https://myopenhab.org/\",
\"expose\": [
\"<exposeItem1>\",
\"<exposeItem2>\",
...
]
}" http://localhost:8080/rest/services/org.openhab.openhabcloud/config
Oh, great! I didn’t know that this is even possible!
Thanks a mil!
hmm… that’s not really perfect, but might be ok (I go to my server through VPN anyway)
Hi,
I am struggling to get voice commands for opening and closing my blinds to work reliably with RangeController. It has worked but not consistently. Voice commands to a numbered position work every time.
Is anyone using the range controller meta data with success?
My item definition is like these examples:
Rollershutter Test "stone" {alexa="RangeController.rangeValue" [presets="0=@Value.Open,100=@Value.Close"], channel="openwebnet:bus_automation:Screen10:55:shutter" }
I also tried with
Rollershutter Test "stone" {alexa="RangeController.rangeValue" [presets="0=@Value.Open,100=@Value.Close", supportedRange="0:100:10], channel="openwebnet:bus_automation:Screen10:55:shutter" }
Rollershutter Test "stone" {alexa="RangeController.rangeValue" [presets="0=@Value.Open,100=@Value.Close", category="EXTERIOR_BLIND], channel="openwebnet:bus_automation:Screen10:55:shutter" }
Commands such as Raise, Lower, Increase, Decrease all work but Raise and Lower actually move the blinds in the opposite direction to expected. 100 = Close. So, ‘Raising’ the number moves the blinds down.
Amazon recently introduced the ability to use open, close, raise and lower commands for the mode, range and toggle controllers via semantic extensions. This support still needs to be implemented in the skill. So, for the time being, the recommended solution is to setup Alexa routines as a workaround.
OK, Thanks for that.I had read that and other info. I am already using Routines work around. I guess I am bit ahead of the game 
Actually, I had working for a while but as I said not consistently. Here you see the command but it appears in the log after being processed.
I am not sure to follow. Do you have a routine for “office blinds open” to set to another value than 0?