No, synonyms should work on items tagged Room - they are locations too.
The basic problem with custom synonyms is that they are often not part of the original training data for the entity extraction part of the NLP - for the get-status intent in German, it’s here. The idea with machine learning algorithms like these is, the more training data, the better it will perform. As you can see currently it consists of 50 sentences (only), and the algorithm is supposed to learn how to recognize this intent AND extract entities from that. I should add, labels and synonyms of tagged entities are fed to the trainer at runtime to aid in their recognition, but even with that, it might not always be enough…
That’s right, to add to the training data you simply add as many sentences as you can come up with to the .txt files of the corresponding intent. This has to be done with a PR on GitHub however, with an associated test suite (https://github.com/openhab/openhab-webui/blob/master/org.openhab.ui.habot/src/test/java/org/openhab/ui/habot/test/TrainerDeTest.java) for the language - adding more training data for one of the intents might decrease the accuracy of the recognition for the other intents, so we must be careful. One day I will add the ability to read text files from the local filesystem so that users might experiment and influence the training without having to recompile.
Yes, Equipments are normally set either on individual non-group items, or on group items with members tagged as Points, so we can’t propagate the Equipment tag to members or those members would be both Points and Equipments, which isn’t supported by the model. The only thing supported by the semantic service right now is “is this item in this location”, which will use the group hierarchy.
However (this is a purely HABot-specific behavior, not a feature of the core semantics package) if the semantic query resolves to a group item, then the group will be expanded to its member items in the resulting card.