Hmm, actually it seems that it is “allowed” (as far as MainUI goes) to have a point that belongs in one equipment + also in one location that is different to the equipment’s location.
This is probably a “bug” because this makes the location of the Point ambiguous.
old man crawls out from under rock…
‘because we tried it once (a thousand years ago) and it was a terrible failure’
totally ignoring the flaws in the original implementation
auto generate items is a naughty word around here
Eww…I don’t like that…that sounds more like a workaround than an mature feature. I expecting the kind of user who might not understand the importance of the point tag to have properly configured the state description is, in my opinion, not reliable.
I think that’s pretty reasonable.
There’s nothing in the badge code that I see that would prevent this, and I could construct some (admittedly fairly artificial) scenarios where this would be the users desired setup. But I think a mild warning might be appropriate because more often than not I suspect this would be accidental.
100% agree. But is that because it HAS to be confusing, or is that just because we haven’t done the best job demystifying it for the new user? I have an answer to that question. But my gut says closer to the later. Most users went through at least a 3 step process just get to their device operational outside of OH first, so three steps doesn’t really seem like a big ask.
Yep. that was what I was going to say. BUT…I was going to use that to point out that while such automatic configurations do appear to solve one problem, what that experience with OH2 auto-linked Items really showed is that it just moves the pain point down the line. It’s not that there’s anything inherently wrong with it (ok, there is for me personally, but I recognize that is a personal preference), it’s that it leads to no actual understanding. So instead of getting “How do I create a new light in my OH?” you just get “My one light does X and my other light does Y and I can’t figure out why?”
There’s no way to take all the complexity out of smarthomes (yet). At some point a user has to be willing to gain some understanding to get beyond “I poke a button on my phone and this one light turns on.” If this were a reasonably tractable problem it would have been solved by now, and from what I see when I look around, it has not.
So, in my opinion, this comes down to a philosophical difference with no concrete right or wrong side. Where in the process to you expect the user to learn? From my experience teaching in the real world, I find that starting with understanding slower but better in the long run. YMMV.
So:
A. We don’t have autoconfig
or
B. We have autoconfig
I don’t know how or what this autoconfig is going to look like, but maybe it’s worth exploring this again. Many improvements have been made lately, e.g. suggesting bindings based on system probes (forgot what it’s called - @mherwege’s great work!)
Not the dichotomy I was trying to describe.
We currently have A, that seems to be a fairly broad consensus. This is also a discussion among people that seem willing (and have shown themselves willing) to put effort into improving the situation. So A → no effort seems like it isn’t currently on the table. The dichotomy that I was proposing is:
Starting from A do we put our effort into A → B or A → C with
C. We improve the intuitiveness of the binding → thing → item UI pipeline, the model UI, and the docs
Notably, of course, B and C are not mutually exclusive, but effort (and time) is still a limited resource, so a discussion about which is the best use of limited resources is potentially worthwhile. My personal opinion is that C is the better option because, in my experience this:
is rarely how things goes for experienced users (see my footnote earlier about HA being a PITA). For me, nearly all software that attempts excessive autoconfiguration makes incorrect assumptions about my usage and it is more time consuming for me to try and work out how to undo those autoconfigurations then it is to learn to do it my way to begin with.
You mean when I add a matter device to homekit and it works 10 seconds later and I can control it from any where in the world and do simple automations in a couple of seconds. Ya, that sounds like a bad idea to me.
Maybe not “fully autoconfigure” like HomeAssistant where it would go ahead and populate your installation without being asked to do so, but something that you can sit and click to “Generate X for me”. Which… I apologise, I may be totally blind here, that’s what we’ve already got, somehow? My lack of familiarity with the UI is showing here 
- I’ve never touched the stuff to the right of the UI’s Model screen.
Thanks for the feedback. How about this:
Item ‘TestTag’ has an invalid combination of semantic tags: Switch (Point) and Control (Point). Only one Point and optionally one Property are allowed.
Item ‘TestTag’ has an invalid combination of semantic tags: Power (Property) and Level (Property). Only one Point and optionally one Property are allowed.
Item ‘TestTag’ has an invalid combination of semantic tags: Lightbulb (Equipment) and Control (Point). Equipment and Point cannot be used at the same time.
Item ‘TestTag’ has an invalid combination of semantic tags: Level (Property) and Lightbulb (Equipment). Property and Equipment cannot be used at the same time.
Item ‘TestTag’ has an invalid combination of semantic tags: [Control (Point), Level (Property), Lightbulb (Equipment)]. Only one Location, Equipment, or Point with an optional Property is allowed.
Item ‘TestTag’ has an invalid combination of semantic tags: Kitchen (Location) and Control (Point). Location and Point cannot be used at the same time.
Item ‘TestTag’ has an invalid combination of semantic tags: Level (Property) and Kitchen (Location). Property and Location cannot be used at the same time.
Item ‘TestTag’ has an invalid combination of semantic tags: Lightbulb (Equipment) and Kitchen (Location). Equipment and Location cannot be used at the same time.
Item ‘TestTag’ has an invalid combination of semantic tags: Lightbulb (Equipment) and Speaker (Equipment). Only one Equipment is allowed.
Item ‘TestTag’ has an invalid combination of semantic tags: FirstFloor (Location) and Kitchen (Location). Only one Location is allowed.
Please don‘t go this direction of posting.
This will not bring uns anywhere.
What I see as missing is that not all Bindings suggest the right semantic tags when using „create equipment from Thing“.
It will be much effort, but this should/could be added.
Do you know which bindings do it right now?
Then we can start from the more popular ones first. In my case, the bindings that I do use myself.
What about a setup guidance for few typical use cases that can be invoked from the main UI. This would help first users to grasp the pipeline. For example the user could select „Add a lightbulb/in-wall light switch“ or „Add a color light“ and the user is then presented with a list of locations („In which location do you want the item“?) in the next step the user is provided only the channels that match the use case from the current autopopulation of fields already existing. Finally: „Do you want to add this to a specific group of lights?“
Or ist this already way too complex?
Not really, need to check. Just had a quick look this morning…
I tested the semantic validation on my actual openhab installation, and it identified two problems:
Item ‘LivingRoom_Aircon_Zone’ has invalid semantic structure:
It directly belongs to location(s) [lLivingRoom] and equipment(s) [gAircon]. It should only directly belong to either a location or an equipment, not both.
I have a ducted air conditioning system for the whole house, so the equipment gAircon is set to location Indoor. However it has a zone control for each room, e.g. LivingRoom_Aircon_Zone. For this Point, I set it to be a member of both gAircon, and the Location LivingRoom, which triggered this warning.
Now, I think I’m happy with this current arrangement though.
So this is basically an extension to the situation @JustinG mentioned above. The only difference here is the equipment doesn’t exist in the same location.
If anything, the direct Location of the point is a sub-location of the location that the Equipment belongs to.
Maybe allow a common root location? I will just not warn about this scenario: A Point that belongs to one location and one equipment, regardless of where this equipment is located. As we’ve discovered there are now two scenarios where this is used intentionally.
But, this could also be one of the easiest inadvertent mistakes to make, thinking that a point has to be assigned to a location as well as equipment.
The second issue is with a Switch item. It controls two lights, say Light1 and Light2. So I set that Switch item to be a member of both lights (one point belongs to two equipments)
I guess I’d need to create a virtual equipment, and make Light1 and Light2 to be sub-equipments of it, and set the Switch item as a Point of that virtual equipment too?
Basically this prompted me to rearrange them in a more logical manner
I figured, but for the most part the UI prevents you from making many of these mistakes. For managed Items when will the checking and error reporting occur? On OH restart or after saving changes to an existing Item?
I didn’t mean to imply it’s foolproof. But it’s pretty darn good. Mucking about with the REST API is the same as editing file by hand though.
Indeed. I thought there was a check added a long time ago to terll you if you’ve tried to do that and MainUI would popup an error though. I just tried it and no such error appearred so I was misremembering.
There’s an open issue I linked to above.
I’m with @JustinG, I don’t like that at all.
Yes.
I don’t think any of us replied with “Everything’s fine”. What we were areguing against was the speciific proposal to change things which, as we’ve shown, doesn’t solve the problems identified and wasn’t really different from what we have now.
Which is why Getting Started was written. To walk the user through this flow.
Is this not what “add equipment to thing” already does?
Everything you list is there only it gives the opportunity to override the default stuff. Since renaming of Items isn’t really a thing in OH, giving the user the opportunity to choose their own names is important at this stage. But al lot of the other other options could be hidden under an “Advanced” section. And there always was a plan to make that form into a wizard.
But again, this is going to only work for managed Items since such a wizard can only create managed Items in the first place.
That’s the whole point of “add equipment to model”.
From the Model page you have “Create Equipment from Thing” which essentially does the same thing.
Let’s walk through the process with screen shots. Let’s pretend I just accepted a new Thermostat Thing in the Inbox. With another change @jimtng just added to OH 5 this will now take you straight to that Thing’s page so we start with:
Potential Improvement 1: Maybe have thge “add equipment to model” option on the main Thing’s page and not just the Channels.
Click Channels and we see all the stuff this Thing supports. We also have “Add equipment to model” at the bottom.
Potential Improvement 2: Maybe these should be at the top instead of the bottom.
Click “Add equipment to model” since we want to add this “new” thermostat to the model. I put “new” in quotes because you can clearly see I’ve already added it.
From here I select the Location where I want the equipment to appear on the Model.
Potential Improvement 3: Only show the Location Items.
Potential Improvement 4: Let one create a new Location from here.
Next we configure the Equipment.
Potential Improvement 5: Have the binding recommend an appropriate semantic tag for the Equipment.
Note the name of the Equipment is used in the names of the Items that will be created.
Select the appropriate semantic tag:
Notice only Equipment tags can be selected here.
Potential Improvement 6: Let the user create a new semant tag from here.
Now select those Channels you want to include in this Equipment. Often there will be more Channels here than one wants, in cases like Astro or OWM there can be many more Channels than wanted.
For each selected Channel you’ll get a form to override the configuration for the Items that will be created. Obviously you have the option to just accept the defaults.
Potential Improvement 7: Let the user select and modify already existing Items and not just the option to create new Items.
Most of the time, the defaults for the Item are reasonable. The name of the Item will be <Equipment Name>_<Channel Name>.
Potential Improvement 8: In an advanced area let the user apply a Profile to the link that will be created.
At the bottom there’s an “Add to Model” button. Clicking that and the Equipment Item is created, made a member of the selected Location, and new Items will be created for the selected Channels and made members of the Equipment.
On the model view it’ll look like this when you are done:
Potential Improvement 9: Go to the Model view when done with the newly created Equiopment selected.
It’s definitely more manual than it needs to be but all the steps are there.
Potential Improvement 10: Let the user delete an Equipment which also unlinks and removes the Point Items under it from the Model view.
This ins’t the same thing as what we had in PaperUI. That solution didn’t work because if you chose to do that you couldn’t even see that you even had Items. All that was hidden from you. You had no control over which Channels got Items created for them. Accept an Astro Thing and surprise! You get nearly 100 Items, though youu don’t realize it until you look at events.log and see all these weird Item change events to Items with random and meaningless names.
The end user had absolutely no control over when, how, and what got created nor any insight and control over it after it got created.
If the user has control over the process and what gets created thee is no problem. And in fact, user directed autocreation of Item has been a part of OH since OH 3.0.
I think we are closer to B or C than most realize. Piece parts are there already, they just need to be put together.
Potential Improvement 11: Accepting a Thing from the Inbox starts a wizard which leads through configuring the Thing (name, properties) through “Add equipment to model” in one guided flow, perhaps with some of the potential improvements implemented to give the end users control over the process.
We have piece parts and I assert we have a lot more than is being given credit for on this thread.
I like these much better. They give actionable information to the user so they know what they can do to solve the problem.
I know the Honeywell binding on the marketplace does that. I don’t know which other ones do. Low level bindings like MQTT and HTTP almost certainly don’t. Open WeatherMap seems to suggest reasonable tags for the Channels I spot checked.
This has been suggested in the past and some work towards this has already been done. I’m not sure the status of that work through.
So isn’t that what a warning is for? I understood the other “warnings” to be errors in disguise, and they should stay like that so users committing those errors are not forced to fix them to have their .item files integrated.
Perhaps the explanation for that condition should not be of the form
Item ‘TestTag’ has an invalid combination of semantic tags…
but more like
Item ‘TestTag’ MAY have an invalid combination of semantic tags:…
or any other wording that makes it easily identifiable.
Have you looked through the Quick Start help panel? It doesn’t include the semantic model, but it takes a user through nearly every single UI click they would have to make to go from installing a binding to having an item widget on the overview page.
That’s not quite a series of dialogs that does it for you, but it comes with the benefit of teaching the user how to do it while still not requiring a full understanding.
Yeah it’s still 20+ steps for that whole pipeline, and there are surely areas where that can be streamlined, but if 90% of those steps are just “click here” that’s already pretty easy…I think I’m not being too experience blind there…but maybe I am.
Along the way through the quick start there are links to all the appropriate docs and the appropriate pages in the Getting Started tutorial where concepts are explained in better detail if something doesn’t make sense.
Certainly, adding a quick start section that covers the model as well, could be done reasonably easily.
I actually tend to agree. In fact, as much as there is absolutely a tendency for more experienced to users to lose sight of what struggles a new user might have, I’m also seeing through this whole thread a lot of comments from experienced users who, because they are starting from an already mostly or partially configured system, actually haven’t encountered many of the newer guardrails meant to guide new users.
I know I certainly haven’t actually looked at a brand new, bare bones OH install since I created that model template page several years ago, so I’m sure there are other 0-experience, new-user help features that I don’t know about.
Disclaimer: I’ve been using OH for quite a while and I mostly use a text-based configuration, except for the things. I also like reading manuals.
However, if I try to think like a new user who is not very tech-savvy and doesn’t like to read manuals, I’d say the following:
Regarding the Semantic Model, this might be the main blocker for the entry point. The Semantic Model is quite “recent”, so to me it’s understandable as it continues to be improved, but new users might not go that way unless guided.
I agree that the parts seem to be there; however…
what the heck is the “Model” (remember the persona I’m impersonating)? I don’t know what it does or what it is, why should I click on “Add Equipment to Model”?
Besides, I didn’t like the language class back in school, and the word “Semantic” just makes me run right away.
Back to myself, I would put this improvement higher on the list.
Because as a new user you should have reviewed Getting Started. You don’t have to read every word but you should at least look to see what’s there and go back to it when you run into “what next” questions or problems.
No collection of wizards and hand holding is ever going to be enough to fully replace the need to look at the docs. That doesn’t mean we shouldn’t try to make things easier but that new user who is allergic to reading the docs is never going to be successful no matter what we do.
The order of the suggestions do not indicate priority.
it was a joke 
