@jeshab is it possible, that it is not working for my becaus i use Proxy-Items for my Logo-Lights? That is the only difference i can see between the two metadata entries.
Sweet! Does the new skill support using the OH devices as Routine triggers?
1 Like
I have now changed the item to the {alexa=“Switchable”} syntax.
Now i get
{
“link”: “https://myopenhab.org/rest/items/Proxy_Logo_1_Q_3”,
“state”: “OFF”,
"metadata": {
“alexa”: {
“value”: “Switchable”
}
},
“editable”: false,
“type”: “Switch”,
“name”: “Proxy_Logo_1_Q_3”,
“label”: “Herd”,
“category”: “light”,
“tags”: [],
“groupNames”: [
“gErdgeschoss”,
“gLogoLightProxySwitch”
]
},
But i still receive timeouts from alex for the proxy-items.
Germany, 21:18 (=19:18, UTC+2)
Switch Innr_Light1_Toggle "Licht Esszimmer1 An/Aus" <light> (GF_Eating, Lights) [ "Lighting" ] {channel="hue:0210:xxxxxx:5:color"}
Dimmer Innr_Light1_Dimmer "Licht Esszimmer1 Dimmer" (GF_Eating) [ "Lighting" ] {channel="hue:0210:xxxxxx:5:color"}
Color Innr_Light1_Color "Licht Esszimmer1 Farbe" <light> (GF_Eating) [ "Lighting" ] {channel="hue:0210:xxxxxx:5:color"}
All the above items report “there was a problem” after switching OFF.
When you say “proxy-items”, do you mean you set these items with autoupdate=false by any chance?
The skill expects to get a state change after requesting a command. If there is no change or the state is not available (NULL or UNDEF), you would get an error response although the commands should have been processed.
at the bottom there is a button to delete all 
Unfortunately, you can only use OH devices as routine actions for the moment. For the same reason I mentioned just above related to proactive reporting. Routine triggers requires states to be pushed to Alexa.
No, my items are like this
Switch Proxy_Logo_1_Q_2 “Gäste WC” (gErdgeschoss, gLogoLightProxySwitch) [ “Lighting” ]
Switch Proxy_Logo_1_Q_3 “Herd” (gErdgeschoss, gLogoLightProxySwitch) {alexa=“Switchable”}
and i have a rule
val Functions$Function4<Object,SwitchItem,SwitchItem,SwitchItem,Object> LogoSwitchLogic = [
Command, RuleProxySwitch, RuleReadLogo, RuleSwitch |
logInfo(“DebugOutput”, “Rule start with:” + RuleProxySwitch.name.toString + " " + RuleReadLogo.name.toString + " " + RuleSwitch.name.toString )
switch(Command)
{
case ON: {
logInfo(“DebugOutput”, “Rule case ON”)
if (RuleReadLogo.state != Command) { // only if state changed
logWarn(“DebugOutput”, “Rule case ON:switching”)
RuleSwitch.sendCommand(ON)
Thread::sleep(400)
RuleSwitch.sendCommand(OFF)
}
}
case OFF: {
logInfo(“DebugOutput”, “Rule case OFF”)
if (RuleReadLogo.state != Command) { // only if state changed
logWarn(“DebugOutput”, “Rule case OFF:switching”)
RuleSwitch.sendCommand(ON)
Thread::sleep(400)
RuleSwitch.sendCommand(OFF)
}
}
default: {
logInfo(“DebugOutput”, “Rule case default”)
Thread::sleep(350)
if (RuleReadLogo.state != RuleProxySwitch.state) { // if state changed really
logWarn(“DebugOutput”, “Rule case default:state changed externally”)
RuleProxySwitch.postUpdate(RuleReadLogo.state) // update the state without triggering the rule
}
}
}
]
rule “Switch Light through Logo 1_Q_3” when System started or Item Logo_1_state_Q_3 changed or Item Proxy_Logo_1_Q_3 received command then LogoSwitchLogic.apply(receivedCommand, Proxy_Logo_1_Q_3, Logo_1_state_Q_3, Logo_1_state_VB_103_0) end
I didn’t see any error with the items you mentioned above. The skill is responding to each of the report state requests it received.
However, I can see errors for the Innr_Light1_Color_Temp item which seems to not have a defined state and is probably the reason for the error you saw.
Normally, any items you exposed to Alexa should have a proper state but there is a special implementation for color temperature-enabled lights such as hue. In order to do so, you will need to convert that color light using a group endpoint. Something along these lines:
Group gInnr_Light1 "Licht Esszimmer1" {alexa="Endpoint.Light"}
Color Innr_Light1_Color "Licht Esszimmer1 Farbe" <light> (GF_Eating, gInnr_Light1) [ "Lighting" ] {channel="hue:0210:xxxxxx:5:color"}
Color Innr_Light1_Temp "Licht Esszimmer1 ..." (GF_Eating, gInnr_Light1) [ "ColorTemperature" ] {channel="hue:0210:xxxxxx:5:color_temperature"}
1 Like
Based on the skill logs, the issue here is that your group gErdgeschoss is tagged and therefore considered as a group endpoint. In that setup only one light can be linked to that entity and all the other ones will be discarded. Here, it’s the Proxy_Logo_1_Q_12 item which was associated to it (probably because it’s the last light of that group).
My advice would be to remove that group tag and trigger a rediscovery.
Thank you, it’s working now again perfectly 
1 Like
No worries 
I forgot to add that if you want to control all the lights as a group, you can set them on the Alexa side. Or, if you want to achieve this on the OH side, you would need to give your group an item type. In that setup, the group would not be considered as a possible endpoint and all its members would be discoverable.
Group:Switch:OR(ON,OFF) gMyLights "My Lights" [ "Lighting" ]
1 Like
My skill is working again, but i came across some unexpected behavior in my alexa app:
When i open the a group all lights indicate a problem:
When i go to detail of a lamp i shortly get the same “problem” message:
But shortly after i get the correct state of the lamp
And if i go back i can see the correct state for this item in the group
Thanks Jeremy, great job! Looking forward to the proactive reporting implementation. I would love to be able to trigger Echo’s music with an OH rule.
1 Like
I just checked my Alexa app and I am experiencing the same. I am running my own skill and I don’t see any poll requests coming in unless selecting a specific device. Hopefully, this is temporary issue on their end as I don’t recall behind that way in the past.
Hi,
I am looking into the new v3 documentation and I must confess I got a little lost, could your provide an example using the item below as to what I can do to support both old v2 categories and the new v3 format.
Number BR4_Temp "Temperature [%.1f °C]" (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) ["CurrentTemperature"] { channel="mihome:sensor_weather_v1:158d0002789d27:temperature" }
Thanks
Paul
I am sure exactly what you mean by supporting both v2 and v3 format. The example you provided works fine as it is if you don’t want make any changes. If you want to set Alexa v3 metadata settings just for learning purpose, this is how it would look:
Number BR4_Temp "Temperature [%.1f °C]" (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) ["CurrentTemperature"] { alexa="TemperatureSensor.temperature", channel="mihome:sensor_weather_v1:158d0002789d27:temperature" }
Keep in mind that you can keep the v2 tag unchanged for other assistant integration but it won’t be proceed by the Alexa skill once the metadata parameter is configured.
Thanks, you answered perfectly I was referring to the v2 way as catorgeries needing to stay as we often have other systems that use those tags.
Now that I see the {} squirly bracketed stuff can be a comma separated list I would guess the below is also valid?
Number BR4_Temp "Temperature [%.1f °C]" (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) ["CurrentTemperature"] { alexa="TemperatureSensor.temperature" [scale="Celsius"], channel="mihome:sensor_weather_v1:158d0002789d27:temperature" }
I just added the option in the square brackets for the scaling to be used.
Can the square brackets be defined anywhere inbetween the {} brackets or must is be along side the ‘alexa=’ definition?
e;g; is this permitted?
Number BR4_Temp “Temperature [%.1f °C]” (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) [“CurrentTemperature”] { alexa=“TemperatureSensor.temperature”, channel=“mihome:sensor_weather_v1:158d0002789d27:temperature”, [scale=“Celsius”] }
Thanks
Paul
No it has to be specified just after the metadata value like in your first example.
Related to the scale configuration, it is now determined automatically using your OH regional settings. So unless Celsius isn’t your default setting, you don’t need to specify that parameter.
Thanks Jeshab,
I am working my way through the documentation, theres a lot 
Well written too.
I am sure I will have more strange clarifications as I read and play so far after initial issue not knowing about the v3 migration and all my devices (180) failing it has been a great journey.
I have noticed one thing now I come to think of it that may not be the new skills issue but let’s bring it up anyway in case others have seen it too.
When I expose new items to alexa in openhab and then ask her to ‘discover devices’, she always says “no new devices were found” and yet they are added correctyly to her list in the amazon app. Any ideas?
Regards
Paul