Semantic model idea

I’ve been playing around with the semantic model to know in detail what are the strengths and weaknesses of the concept, and wanted to share this idea:

The model and what it achieves (mainly the creation of a consistent UI with all the items organized in various ways) is very good! Having a process of putting up together an UI without designing anything is great!

And once one starts the model, the goal is to model as much as possible. Except for the proxy items, I don’t see no reason why we shouldn’t go for the 100%. The problem, is that there are missing locations (no matter how many are included, some more will be lacking); There are missing classes (for example there are Lightbulb and LightStripe, but no LightTube, or simply Light); There isn’t a property that can be related to a regular wired Window magnetic contact (at least I didn’t see it); Arguably the users may want to not use English to model the installation; …

So I just wanted to make the suggestion to make the semantic locations, classes and properties editable so that anyone can use whatever they like, instead of trying to be as comprehensive as possible. A .csv file, .json file or .xml file to edit would be good enough for it.

Just my 2 cents.

I’m not sure I would go that far. One should model as much as makes sense. Some sensors and actuators may have no interest or even should not be exposed to end users. They may be admin related or only certain rules care about them. Those shouldn’t be in the model at all, even if they are linked to a Channel.

In other cases, assuming you are just using the model for the Overview Tab, one may have a custom default list item widget defined that combines the status and control of many separate Items on an equipment (e.g. a playback widget that shows play controls, current track, artist, etc. all on one widget). In that case, only one of the Items should be in the model (or you can edit the visibility on the other Items to not show them which, if all you are using the model for is the UI is essentially the same thing as leaving it out of the model).

The model should represent your home automation from the end user’s perspective, not the administrator’s perspective. As such, many many Items do not belong in the model.

In fact, I would argue there are too many locations, at least for how the semantic model is used today. What’s the difference between a Livingroom and an Office semantically? Nothing really. So why not have an “Interior Room” and use the Item’s label to distinguish. Having these as separate tags doesn’t really provide any useful information and duplicates information already required and captured in the Item’s label.

Here I would agree, ‘Lightbulb’ is missnamed. However, there is already a Light property tag so we can’t use that. ‘Lightsource’ would be more generic perhaps but that’s why it’s called ‘Lightbulb’, there’s a naming conflict. You can’t have two different types of tags with the same name.

Window is the equipment tag and OpenState is the Point tag for the contact under the Equipment. There really isn’t a Property that make sense to pair with OpenState unless you start to mix Equipment and Property tags which is not allowed. The fact that it’s a wired sensor is irrelevant to the model.

Agreed and I believe there are already translations of the model tags into many different languages.

The problem here is that the model isn’t just used to drive MainUI’s Overview page, even though that is how some users are using it. It is based on an ontology (the Blocks ontology to be specific) and it’s core to HABot’s ability to do natural language processing to allow one to issue a command like “turn off all the lights in the kitchen” and HABot knows what Items to send the OFF command to. If you allow anyone to create their own ontology HABot loses all ability to do this reasoning.

The semantic model was first and originally implemented to serve this purpose. MainUI came along later.