Unless you really want both .items files and the Overview tabs in MainUI to be populated (or you use HABot or might benefit from them in your rules a lot), I do not recommend using the model. It’s just too hard right now and the benefits are not that large.
If you use managed Items, right now it can be even more painful to retrofit your existing Items into the model because there is no easy way to change the tags and Group membership on a bunch of Items at once and that’s all the semantic model is, tags and Group memberships.
I find it ends up being a lot less work in the long run to just delete the old Items and create them again through the “add equipment to model”. You can use the same names but you’ll have the opportunity to pick the appropriate semantic tags. Once done you’ll have new Items with the same old names but they will have appropriate semantic tags and Group memberships and all the Items for a given Things are done all at once. You can do this on a Thing-by-Thing basis instead of needing to do it on an Item-by-Item basis. Usually there is a one-to-one mapping between Things and Equipment so this saves a lot of work. This is IMO currently the only way to reasonably apply a semantic model.
When drag and drop on the model view gets completed and merged, you’ll be able to build your hierarchy just by dragging Items around (e.g. put a bunch of thermostat Items into an Equipment and put that Equipment into a Location just by dragging them around instead of needing to go into the Item and manually change the Group membership). This will make it much easier to retrofit your Items into the model.
I also have an issue open to allow us to select existing Items from the “add equipment to model” and “add points to model” page. This should let you choose a Location, create the Equipment and then modify the settings of the existing Items (i.e. add tags) and when you hit save it applies the tags and Group memberships to your existing Items instead of creating new ones.
I’m not really sure how to help file based users though. Part of me wants to say TANSTAFFL and the complexity is what you sign up for be using .items files. Needing to look up the proper tags to use in the proper place is all part of the job you’ve taken upon yourself when using files.
But I do think there are things that can be done to help even those users. I’ll reiterate them:
- Make the VSCode extension tag aware; there is a REST API endpoint that can be used to facilitate this.
- Generate errors when parsing an Item that includes nonsensical tags or Group memberships (e.g. using an Equipment tag and a Property tag on the same Item, more than one Equipment tag on the same Item, etc and one Equipment or Point in more than one Location)
Beyond that, short of massive changes to the syntax of .items files, I’m not sure what we can do except improve the documentation.
Those syntax changes, btw, would be to let users define their .items file hierarchically. I’m thinking something similar to how you can have Things inside a Bridge Thing definition in a .things file. You’d have Items defined inside of Items to represent the hierarchy. I’m not sure how feasible that is to do with the current DSL. It should be easier if we ever get to a YAML or some other “standard” based file format. There’s lots of work going on this front as well.
I’ll note though that I don’t use that in practice (as you should be able to see in my screen shots of the model view). I used them in that one place in the post above for explanatory purposes. Generally, the name of the Item is sufficient to identify whether it’s a Location, Equipment, or Point and if it’s not, the Model view makes that clear. But if using a prefix is useful by all means use it.
That’s exactly what I mean by making the semantic model more available to UI widgets. Right now only oh-repeater has access to this info and the way that works is far too inefficient to have more than a few on a given page at a time.
If it were possible to navigate the semantic model from a UI widget in an efficient manner, then most of the problems identified in the OP wouldn’t be a problem. It’s not an easy problem to solve technically though.
