[voice] Reduce collisions on exact match and use item synonyms

[GiviMAD]

Hi openHAB maintainers, I would like to add this changes to the StandardInterpreter so it uses the item synonyms and to reduce collision between items labels in case of single exact match. I think the changes can be seen as a bug fix as the current item resolution method is unchanged an takes priority in case of succeed.

Note that I have added a test suite for the StandardInterpreter with tests cases for the changes included and also some debug logs to the AbstractRuleBasedInterpreter getMatchingItems method so users have a way to know what the collisions are.

Hope everything is in place.

Best regards

[GiviMAD]

I was testing the proposed changes at my home over the last snapshot and realize those didn't work well with groups, I have to introduce more changes to fix my problems.

I think with the latest changes name collisions are better handled. With that and the item synonyms seems like I can fine tune how it works without so much trouble.

For example now I can have multiple groups items whose labels collides like "Big Lamp" and "Small Lamp" and by adding a synonym to one them control what is the target when I use the command "turn off lamp" instead of getting an error saying two or more items have similar names.

And the debug logs help a lot to understand the collision problems.

[lolodomo]

Code looks good but is very difficult to understand due to such undocumented object Map<Locale, Map<Item, List<List<List<String>>>>> itemTokens !

[GiviMAD]

Code looks good but is very difficult to understand due to such undocumented object Map<Locale, Map<Item, List<List<List>>>> itemTokens !

True.

Having a group item labeled as "Samsung TV" with synonym "Smart TV" which contains a switch item labeled as "Power" the object will look as:

{
	localeRef: {
		groupItemRef: [
			[ ["Samsung", "TV"] ],
			[ ["Smart", "TV"] ],
		],
		switchItemRef: [
			[ ["Power"] ],
			[ ["Samsung", "TV"], ["Power"] ],
			[ ["Smart", "TV"], ["Power"] ],
		]
	}
}

The first list level are the alternative paths to the item, the second level is a path to the item conformed by collections of tokens for the different parents and itself.

Not sure what is the best way of document this, maybe I can add that example to the getItemTokens comment (which is outdated after my changes, I didn't realize before).

[GiviMAD]

I have updated the method comment with the current behavior.

[J-N-K]

Why is that important? And I believe this is not true in general:

• labelFragments [a, b, c, d]
• segments: [[b], [c, d], [a]]
• first segment, there is [a, c, d] left
• second segment, there is [a] left
• third segment matches everything that is left, so exactMatch = true

Is that intended?

[GiviMAD]

Thank you for the review, and sorry for taking so long to answer, it caught me in the middle of another task that took more than expected.

Maybe I don't understanding the question but I think the code ok.
Each segment is compared against lowercaseLabelFragments which is never modified, checking if some segment in the path is an exact match agains the label extracted from the voice command. Each iteration I'm trying to remove from unmatchedFragments but that is a different list initialized with same strings.

I have renamed the segment and parts variables trying to make that part easier to read.

[J-N-K]

Thanks.

[GiviMAD]

Thank you!