I used openhabian-config to switch to the TEST version. Everything has been done automatically.
Btw. If I access this link https://myopenhab.org/rest/items?metadata=alexa,channel,synonyms&recursive=true
it takes more than 10 seconds to load. ~15-20 seconds. I have a lot of items.
Could this be the issue?
If so, will this be fixed?
Could you please post an update, when this issue has been solved?
I guess, that this is, why I’m having issues.
This has been already fixed:
You can follow it on github:
Yes sorry copy and paste mistake on my part. Looking at the example I gave you and the hue binding documentation, you may need to add the power to the group as well. Can the color channel control the power meaning that 0,0,0 state would be considered as power off command?
If this is the case, this actually means that all the devices discovered were already present on your account already. Keep in mind that the skill sends unsolicited discovery requests once in a while. So maybe your devices were already discovered.
You can refer to the Alexa Smart Home Skill API documentation.
We already released a fix for the problem you reported. So you should be all set.
hi!
is it possible to configure this with the new binding or do i need to do this via the alexa app?
Hmm, I really don’t know, what the issue could be.
I just saw, when I do a search for devices on my alexa device, I’m getting a lot of log entries on my OH with this message:
2019-08-17 21:49:52.593 [WARN ] [thome.io.rest.internal.DTOMapperImpl] - Field ‘editable’ could not be eliminated: Can not set boolean field org.eclipse.smarthome.io.rest.core.item.EnrichedItemDTO.editable to null value
as background info: I really have a lot of items and there are even items, which do not have any value (uninitialized). That is, because I’m using it as a smart meter and I’m storing my historic values per day.
Can that be the problem? And how could I possibly solve this?
That error wouldn’t prevent the skill from working but nevertheless the change we pushed to fix the Lambda timeout on large collection item exposed a bug in the rest api when using the field parameter.
That error is generated for each item you have setup on your system when requesting a discovery. So this will generate a lot of unnecessary logs.
I have already added a workaround and should be pushed to the live skill very shortly.
The fact that you are getting these errors is a sign that the skill is able to query your OH server. So now we need to figure out why you apparently don’t see any discovered devices.
First, can you please confirm if you see any devices in your Alexa Smart Home console. Secondly, can you please provide an exact timestamp when you tried to request a discovery, your location and a distinct item name that should be discovered?
Syntax looks good. Can you please provide the information I requested above so I can take a look from the skill logs?
What is the OH item name for that command?
Wow, just want to say a big thank you to Jeremy Setton, and all the individual binding developers, for working so hard on this software that the rest of us get to use and enjoy. Bravo
112 posts in 5 days
Switch xtree_two “heat recovery” { zwave=“13:1” }
Accordingly to your skill logs, that device is still considered as v2 while I can see included in v3 discovery response. Can you confirm that you can control other devices and if you have any duplicate in your Alexa Smart Home devices console? You might need to unlink and link the skill again.
So, I just tried a discovery again. At 07:53 (CET). Distinct Item name is for example: Ambilight or Sofa
Location ist: Germany, Niedersachsen / Lower Saxony, Lingen
In my log I can see, that there is also another exception at the end of the logs (removed stack traces for better readability):
2019-08-18 07:53:55.715 [WARN ] [thome.io.rest.internal.DTOMapperImpl] - Field ‘editable’ could not be eliminated: Can not set boolean field org.eclipse.smarthome.io.rest.core.item.EnrichedItemDTO.editable to null value
[…]
Caused by: org.eclipse.jetty.io.EofException
[…]
Caused by: java.io.IOException: Broken pipe
[…]
In the Alexa Smart Home console, I can see the Ambilight Device, but it shows as offline. And the Sofa device doesn’t show up.
The Ambilight is the only device, which is showing up. All other devices are all missing.
-36.125708881727164,174.43075684702714
Dimmer LoungeDimmer "ZWave Dimmer [%d %%]"Thanks
.
I need the exact OH item name for these devices opposed to their labels.
Thanks but unfortunately I cannot pinpoint your request with that information only without including the second. It’s pretty hard to do so for the European users as they are a lot of requests coming in at the same time.
Since you have an offline Alexa-linked device, you should be able to ask to turn on/off that device. Would you be able to do so, trigger a discovery query and provide me with new timestamp?
I found your discovery request and I can see it is timing out. Please refer to the updated part of my previous comment. Let me know what happen when you click on the updated link and how long it take to get its content. Also, how many items do you have setup in your OH server?
Hi jeshab, thanks for your response. See my remarks below:
These are the distinct item names.
See my item configuration:
Switch Sofa “Sofa” {alexa=“Switchable”}
Switch Ambilight “Ambilight” [“Switchable”]
I have switched ‘Sofa’ to the new V3 Syntax, but with no success.
The exact timestamp was provided in the log file. But I just tried it again at 20:23:45 CET.
When I try to switch on/off ambilight via Alexa it just says, Ambilight it not reacting.
Doing a new discovery returns with ‘no new items have been found’.
It’s really weird, because it used to work with this configuration for several months and now since a couple of days it’s not working any more.
I already tried to remove the alexa OH extention and also the Cloud connector in OH. But nothing helped.
Hi Jeshab, All sorted, spent the day upgrading to OH2.4 and configuring everything through VS Code, all up and running with the new Alexa skill, thanks for your patience : )
I was able to pinpoint your discovery request thanks to your “Ambilight” failed request 
So that request is timing out after 10 seconds.
While we pushed a fix a few days ago to optimize the discovery rest call, it seems that some users are still experiencing an issue with it. Can you please go over what I mentioned in my last comment to @csdcc? Trying to figure out what’s the bottleneck here.