Thanks for trying to help. You’re right I should have stated what I used, I now added that.
But I think your input is not addressing my problem.
Adding one-by-one is what I did in the beginning, but it is not feasible with a large number of items and now I’m at a point where, as I wrote, I see no “duplicates” in my config but Alexa obviously does and so I’m struggling to find out where that duplicate is originating from.
For the time being, I have a single Alexa only hence I cannot assign multiple Alexas to different rooms (through the web interface). I know that if I was to give a command with no room indication she would deduce what room I’m in and use that room.
I suspect that room assignment inside Alexa settings may be needed with my single Alexa, too.
I just tried “set Deckenlicht on in Markus”. There is a single (Alexa-exposed) item labelled “Deckenlicht Markus”. It is definitely the only item to have “Markus” in its label. But again, she asked back “which one”. I responded “Deckenlicht” and she turned on the Deckenlicht - but not in the “Markus” room but on the toilet which has an exposed item “Deckenlicht WC”. Funny but not what I want .
So she didn’t remember the “Markus” part and continued using that in searches for matching.
Seems she has no room concept.
So, question: is there any means to set that room concept INSIDE OH (OH groups?)
Does it work to apply a strict naming scheme to all labels (such as “Deckenlicht Markus”,“Deckenlicht Wohnzimmer” etc) ?
Or must I use the Alexa web interface to define rooms there instead ?
When I use some Alexa-exposed device of a different kind such as a thermostat, I think it actually knows to distinguish that from lights (probably because of the controller type given in the config).
I don’t thing that you must use the room assignment with only one Alexa. A connection betwwen openHAB groups to establish a room concept is not there.
The strict label concept should work i have it applied automatically in my system by seetings the lables with a meanigfull name and added the room automatically from metadata. And i have no problems to address a specific item (Around 50 or something like this).
Maybe you should clear all item in the alexa app and rediscover them. Should be no big deal, because you need not to assign them to rooms again.
I think it only works when/because you match FULL item labels.
Example for my item (to have the label “Deckenlicht Markus”):
it’ll work to say “turn Deckenlicht Markus on” because it matches a single item label, but
it’ll NOT work to say “turn Deckenlicht IN Markus on” because that will require the room concept to be available to Alexa (italics = label text). Well unless you have a single item only to have a label “Deckenlicht”. If you have multiple, Alexa does not know which one is meant and asks.
But that’s how people talk to Alexa, in particular those that are unaware of the implementation.
Did that multiple times already. Still some “hue” items to reappear.
Now i checkt the different options and ways and i got suprisingly the same behaviour as your setup.
The little fillwords ar irgnored. If i command “Alexa schalte das Fensterlicht ein” i got the question “Es gibt verschiedene Dinge mit dem Namen Fensterlicht. Welches möchtest Du?”. If i answer “Büro” the light is switches on. At the end there are only labels with "Fensterlicht "
If i command directly “Alexa schalte das Fensterlicht im Büro ein” the light is switched on.
So it seems that this should be the expected behaviour.
Is tha behaviour only with “Deckenlicht Markus” or with other ceiling lights as well? You mentioned “Deckenlicht WC”
Regarding Hue devices that were still found it was because there still existed /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.items.Metadata.json. It had several ‘HUEEMU:’ entries. Seems that didn’t get uninstalled when I removed hueemulation. Just remove it.
But this still left me with a couple of devices to appear again and again. The solution there was in the Echo. It had discovered and apparently stored those. Resetting the Echo did the trick there.
Hope that helps if anyone should encounter the same problem.
@jeshab sorry to bother you directly but maybe you can shed light on this. I have not found any proper explanation elsewhere.
Could you please explain how matching of voice commands to “rooms” works ?
Is it Alexa to match the label ONLY so I have to label all my lights “roomX ceiling light” as written in https://github.com/openhab/openhab-alexa/blob/master/USAGE.md#item-labels ?
Is the label interpreted as a single string ? What if I ask Alexa with word order reversed, i.e. to “turn on ceiling light roomX” or even “ceiling lights in roomX” ?
Is it really that “filler” words like in/at/… are ignored even if they are inbetween the two halves of the label string ?
I always thought that’s sign of semantic parsing, i.e. Alexa to separately recognize “ceiling lights” as an item and “roomX” as a location or group, then looking for all items to match “ceiling lights” in the first place and then to select from these the one to match group roomX best.
Would it make sense to duplicate items with a label to have an inversed word order label?
Do I have to use the Alexa group function with the skill in one way or another or is that just a useless duplication of OH group functionality ?
Correct you need to label each of the item exposed to Alexa with a unique name, otherwise you will run into duplicate issue as you experienced if you have two labelled the same. Also, keep in mind that the uniqueness isn’t just with the OH items but any smart home devices discovered on your Alexa account via other skills or locally via a hue bridge.
The Alexa language processing can understand different permutation and even missing words as long as it can still determine a unique device. For example, a device labelled “Kitchen Bar Lights” can be controlled by just asking “Turn on the bar” if there are no other device on your Alexa account that are named with the term “bar”.
There is no room concept at the device level. However, you can create Alexa group based on room and take advantage of the room awareness feature. But it would be limited to functionalities, such as turning on/off all the lights of a given room, and not per device as you seem to want.
In the end, as @Dibbler42 mentioned, it is very hard for us to troubleshoot your issue and provide you specific guidelines if you don’t give some details such as an item definition and how you tried to interact with that giving device.
I think it would be worth to document that somewhere prominent.
I guess there’s many who are as confused as I am.
That’s also very important to point out.
I think my problem with phantom hue duplicates (to result in 2 OH item/Alexa devices to have identical labels) contributed a lot to the situation.
I tried hue emulation first (and got it to work) until I realized that I cannot control thermostats that way because Hue does not know them
There’s also Homekit (to support thermostats).
There’s probably more people to face the same confusion and decisions and hit the same pitfall when they “just” want to get Alexa to work for the first time.
on a sidenote, can I get away without that, too? Can I have rules triggered by Alexa and determine which Echo unit the request came from then act based on that (i.e. select item to match the room).
Thanks. I’d suggest to give a hint at homekit integration, too.
Please also add your explanations on languge from above to the guide.
You can in combination with the Amazon Echo Control binding, as per the tutorial below. But if your intention is just to control the lights of a given room then I would recommend using the Alexa groups.
What do you mean? Did you want to say “Hue emulator integration”? If so, I mentioned it under the term “Philips Hue Bridge” local integration. Actually, what are the steps you took to resolve the hue emulator devices still being discovered? You mentioned a JSON db file but not what action you took.
That part is more a general understanding of how Alexa works and not particular to the skill itself. I would expect a user to understand that concept when experimenting with voice commands, through trial and errors. I think in your case, because you had duplicate issues that you couldn’t comprehend, it forced you into thinking the requests needed to be more rigid.
No I really meant Homekit. While I didn’t use it, others may, and I believe it may result in duplicates, too, just like Hue emulation did for me. It also uses some v2 tags to overlap with this skill’s config.
The v2 tags overlapping is done on purpose so you can use one tag to rule them all. This is why all voice assistant integrations still support Homekit tags. So I am unsure what kind of duplicates could happen in this use-case.
I am aware of that post. I was looking for more detailed steps you took to resolve the matter. Did you delete the file? Did you edit the file? If the latter, what type of edits did you make? The reason I am asking is because I think that part should be added to the troubleshooting guide as I have seen that issue on many occasions for users migrating from the Hue emulator to the skill. Ideally, a feature request should probably be opened for the Hue emulator binding so it properly cleans up its configuration when getting disabled.
Can’t try myself because I don’t own any Homekit devices, but what happens if both, Homekit and your skill, are enabled ? Will those Homekit-tagged items appear twice ?
Lighting items including color groups now work fine. Thanks for your help so far.
Unfortunately I’m still having a problem to retrieve temperature from my thermostats. I can set the target temperature and on doing so it also announces the current temp (due to itemsensor), but Alexa does not find or query the item that I tagged as the TemperatureSensor just as used in the example in USAGE.md. I can ask her whatever, she does not know.
What’s wrong about this ?
Why are you using an item sensor in this case? Target and current temperature shouldn’t return the same state.
Group endpoints are considered as a single device on the Alexa end that includes a bunch of functionalities defined by each associated Alexa-enabled items. So your temperature item is accessible via that device.
Ok, I managed to get Alexa recognize most of my thermostats now, too and yes, I omitted the itemSensor.
Turned that my Echo itself had apparently cached a number of devices. That at least was the reason for them to keep reappearing although I had deleted the metadata file. Resetting the Echo did the trick.
Probably another info worth adding to the docs.
One thing I’m still missing sufficient information on is thermostatMode. The skill docs say you can add [binding="bindingname"] but it doesn’t explains neither what that does nor what’s valid binding names (except Nest).
Another thing I struggle is to raise/lower my blinds. Open+Close finally works, but I had to make use of the generic form rather than “blind” to completely reverse the definition.
What still does not work is to raise or lower by 10%… Alexa’s understanding is erratic here.
I tried to also reverse Raise/Lower parameters but the same command sometimes seems to raise blinds and sometimes it lowers them.
ButI wonder why as she’s always applying to the right blinds so at least the OH item was properly identified.
Lastly, I’ve just added some scenes. While this works as simple switches, the skill docs say to eventually add [category="SCENE_TRIGGER"] to switch(?) devices right away (without a rule I guess), but there again I have not found any explanation how that is supposed to work.
.