As far as I know, that feature was disabled. People were exposing all their items. overloading & crashing the server. You can set up your own hosted cloud server though since the code is freely available.
For using your items with Alexa ONLY, you DO NOT HAVE TO EXPOSE ANY item.
In openhab you must tag your items properly or use the new metadata. You have to put them either into an .items file or if you create and link items to channels via PaperUI, you can add tags via REST API. How to add metadata using different way than via .items file, I don’t know actually.
All items (tagged/metadata or not) can be found here:
https://myopenhab.org/rest/items/
You can just open it with your web browser.
You can search for your item labeled with “A Lamp” there.
Most important are your labels. They have to be unique and EVERY item you want to see in Alexa needs a label.
1 Like
No. Both is possible. For testing I would use this:
Switch IlightsLamp "A Lamp" <light> [ "Switchable" ] {channel="osramlightify:power:99-99-99-00-11-5E-1A-09:switch"}
You should use [ “Switchable” ] with a space between the brackets and the quotes.
Ok, then I’ll revert my changes to the from state. Is rebooting or some refresh at any other service required for testing? I’ll do a rescan of my devices after a reboot of openHAB.
First get rid your exposed items from “Openhab Cloud Connector Configuration”. Then restart the “Cloud Connector Service”.
Then search in
https://myopenhab.org/rest/items/
for your word: Swichable
If it is there, then search in Alexa APP.
I though “Switchable” is a tag which defines the modes of operation on this item. The addressable name for this item should be “A Lamp” afaik. For finding the item in myopenhab.org I can look it up via https://myopenhab.org/rest/items/IlightsLamp, right? Should I check specific attributes?
No. You should search for Switchable in:
https://myopenhab.org/rest/items
Best you search for the phrase: “tags”:[
Then should be there: right beside the word Switchable, and left beside your label: “A Lamp”.
If there are OTHER tags inside, see if there is also a lable and a keyword like Switchable or Lighting or heating in the same line.
To what purpose? As written in my initial post, I cannot rely on the response of that REST call, since it exceeds a 64KB-Limit, i.e. resulting in truncating the response. That’s why I’m asking what exactly I shall look up – I was guesing I shall look up something of the item to control via Alexa: IlightsLamp.
To find out if there are any tags without a label and/or keyword.
Alexa finds only “devices” when a label and a keyword like Switchable is bound to an item. If a label is missing, Alexa finds nothing. E.g. you have 25 tags and 24 have a label, then it doesn’t matter having them all correct. The one without the label is the breaker.
See also this:
Ok, I’ve come closer to finding out what the problem is:
Despite my claim that there’s a 64KB limit to the REST-API, which is in fact wrong, there is a problem with the REST-API which conflicts with the Alexa skill for openHAB.
When retrieving https://myopenhab.org/rest/items with Firefox, Chrome or even curl from a Linux machine I did not get the full JSON back. It stopped somewhere at a 8KB boundary. Curiously, when repeating the HTTP request, it sometimes stopped at another size (but always at a 8KB boundary).
I’ve searched for similar bugs being reported and came to https://github.com/openhab/openhab-alexa/issues/253, where a “fix” was committed in https://github.com/openhab/openhab-alexa/pull/273/commits/ffcfa53b33a3846a646baf5e29d9c67f3e70899d. The fix consists just of a retry to increase the chance of a succesful retrieval of the items.
Knowing that I’ve removed all items from my configuration except one test item with proper tagging. Still, due to a lot of things configured (which implicitly created items due to a setting in PaperUI), over 400 items are contained in this JSON, but few enough so that refreshing a couple of times in my browser led to a complete JSON response.
Now I re-triggered a device search via the Alexa app and it found my test item. I could see in the log viewer that when performing a voice command with Alexa for the test item, its state changed.
So I conclude, that the same problem I’ve refreshing the URL in the browser, the Alexa skill has, too. I cannot confirm this without having access to logs, but I find it very likely.
Unfortunately, this limits my options. All I can do is file another bug report on GitHub.
What about splitting your .items file.
According to Openhab docs you can create as many .items files as you like.
I would then put all tagged items into one special file e.g. alexa.items.
My items are already split into many files. Regardless of this and regardless of tagging, ALL items are synced to myopenhab.org. Is there a way to specifically sync items to myopenhab.org?
I’ve created a GitHub issue for this: https://github.com/openhab/openhab-cloud/issues/284
I’m not sure if it will be accepted, but I gave it a try.
1 Like
400 items (are synced) even with only ONE item in .items file?
This sounds like you have set “Simple Item Linking” in PaperUI --> Configuration --> System
If you have .items files for ALL your items then you don’t need that. But you maybe have to change your ThingIDs in .items files.
Yes, Simple Item Linking is the cause for these implicit items. I could change it, of course, but this requires a tremendous amount of work. Or is there some converter / converter script?
A possible workaround could be to put all Alexa relevant items into a single file, temporarily delete all other item files, have Alexa discover the devices and then then re-integrate the deleted item files. The Alexa skill seems to require access to the full list only for device discovery. I can control the one discovered device right now via Alexa.
AFAIK, no.
But it is just a search and replace of the ThingIDs.
Any simple Editor has this function.
I think I’ve to create thing-files on my own, don’t I? Will turning of simple linking mode just stop the implicit creation of items, or does it interfer with my things as well? If not, why would I have to adjust thing ids? I’m not familiar with manual creation of most of my things – this is why I would prefer an automatism 
If you go at the end of the issue you linked, you can see that all the workarounds that were applied didn’t resolve the root cause and that it seems that the default buffering feature on the cloud connector nginx instance may be the culprit.
This is unfortunately the only workaround for your issue.
This is correct. During the discovery process, the full list is required to determine which items are Alexa-enabled.