The link was https://myopenhab.org/rest/items?metadata=alexa,channel,synonyms&recursive=true
I do use the alexa control binding also - sorry for the confusion.
My setup was working until the V3 update. Then when I asked alexa to turn my lights on it would respond “hmm lights are not responding”. I removed my devices from alexa and now it doesn’t find them after a discovery.
Any ideas?
If it takes more than 10 seconds for the content of that link to be output, then this is a known issue with large item collection setup and we are working to resolve this one very shortly.
@Scotsman So I have taken a closer look at this and I actually noticed in the skill logs that a bunch of users have been getting the strange error message you listed above when requesting a discovery.
@michi any idea why the Amazon Echo Control binding would interfere with a rest api call?
I have deployed @jeshab changes for the discovery issue to production. @omatzyo and anyone else having discovery issues, can you try again?
Hurray! it works! You guys are the best. Thank you. I’m looking forward to digging into V3 soon.
FYI, regarding above. I also use the Amazon Echo Control binding on my two systems and have not had any errors.
Yes, this was an issue in the 2.4 release, there was an REST call in the StateDescriptionProvider. But this is already fixed in the 2.5 release.
Thanks for confirming. So the recommended solution for the affected users is to either disable the binding when using 2.4 or update to the latest 2.5 milestone?
It works, you are the Best!!!
Hi,
looks like I have to report a nother issue.
Since the skill update most of my lights are not working anymore. I have some lights with a TPLink-Plug they work still fine, but all my lights on my Siemens Logo are not available via alexa.
They work via the openHAB interface - I already updated to M2 but that did’t help.
I have done the search for new devices several time in the alexa app and with a echo device.
What i can see so far is the following metadata difference (from https://myopenhab.org/rest/items?metadata=alexa,channel,synonyms&recursive=true):
Working item:
{
“link”: “https://myopenhab.org/rest/items/TPLink_Whz_Stehlampe”,
“state”: “ON”,
“metadata”: {
“channel”: {
“value”: “tplinksmarthome:hs100:6F9012:switch”
}
},
“editable”: false,
“type”: “Switch”,
“name”: “TPLink_Whz_Stehlampe”,
“label”: “Stehlampe”,
“category”: “light”,
“tags”: [
“Lighting”
],
“groupNames”: [
“Erdgeschoss”,
“gLogoLightProxySwitch”
]
}
Not working:
{
“link”: “https://myopenhab.org/rest/items/Proxy_Logo_1_Q_10”,
“state”: “OFF”,
“editable”: false,
“type”: “Switch”,
“name”: “Proxy_Logo_1_Q_10”,
“label”: “Wohnzimmer - Gartenseite”,
“category”: “light”,
“tags”: [
“Lighting”
],
“groupNames”: [
“gErdgeschoss”,
“gLogoLightProxySwitch”
]
}
Any ideas?
My Alexa APP is telling me that “Openhab Smarthome Skill” was updated 3 days ago (to v3). I did not force a rediscover of my devices. Everything is controllable with the voice, but the “devices view” in Alexa APP is flapping. You also can switch the devices there, but many of the devices reporting then (although it was switched correctly) “there was a problem”. And some states (ON or OFF) are not updated correctly.
Should I rediscover devices? Or what else to do?
Are you initiating the commands vocally while having the Alexa App opened to monitor the states? If so, this is a known issue. The skill currently only provides state updates when Alexa requests them (polling).
There are plans to implement proactive reporting in the future which would allow state updates, along with item configuration updates, to be pushed directly from the OH server. Until that, the states in the Alexa App may not fully reflect the current OH state especially, if you currently have the app opened and you don’t force refresh.
Would you be able to provide with a distinct item name that experienced the problem you observed along with the time you issue the request and your country location? I will try to see if there are any errors in the skill logs.
@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?
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"}