What about removing Basic UI from the wizard?
I assume it is still in there because of the dependeny of oh:icons. But that does not exist anymore so I think, it should be taken out.
Is this true? Isn’t BasicUI the engine behind sitemaps?
Yes, it is and should not be removed!
1 Like
Just to understand, the wizard is aimed at new users. Why do we want to confuse new users with an alternative and old GUI?
Maybe my perception is just wrong that sitemaps are included in MainUI for legacy reasons.
Agree, for a new user and a wizard, there is no reason to mention alternatives UI´s, at this stage.
Alternative UIs are advanced stuff (or alternative stuff), which would only bring bad things to a user not really knowing at this stage. He will have to spend time reading alot, before he can make a decision.
That is what a Wizard should avoid, in my opinion.
Keep it simple, and let the alternative options come into question, later.
1 Like
I agree with what Justin proposes but I will add some easy way to assign locations. IMO locations should be assigned to things, and when items are created they should pick the thing location.
Then another section in the sidebar could be used to build the model using existing locations.
Aggreed to not promote it to new users.
But just to highlight, Basic UI is well maintained and still used. In fact, it is our fastest UI on mobile devices.
Now that my question/suggestion was finally answered
what do I need to do next - open a ticket? I cannot make a PR as I am not a developer.
1 Like
I think basicui is a lot easier to use to create a working UI for beginners. We can even auto create a sitemap.
2 Likes
I like this idea since the Location field of Things are kind of pointless now in OH 3/4. It also ties Things into the semantic model better.
However, given that Locations are Items creating that relationship might be technically challenging. What if the Location Item already exists? What if it doesn’t already exit? What if it existed but later got deleted after being linked to the Thing?
What about a Thing that represents devices in more than one location (a common occurrence with bindings like MQTT and HTTP).
There are lots of details that need to be fleshed out but I think it’s a solid idea. You should file an issue. It think maybe starting on openhab-core, but I could also see this being wholly implemented in MainUI too so maybe start in openhab-webuis? I don’t know where is best.
Yes, opening an issue is probably the best that you can do in that case.
I think that sitemaps are a lot easier to use for people who already know sitemaps.
But then those new users compare Basic UI against Home Assistant I assume that many will go away just because the HA GUI looks better.
1 Like
done
1 Like
I suggest that OH ships with a very basic model (livingroom, kitchen, bedroom, garden, external providers) and users pick one of the available groups, or specify the name of a new group. Deleting / updating locations is something that can be done today (basically delete would leave things “orphan” without a location, maybe a widget to identify these orphans and help assign them to new locations)
Also, it may be good to also assign things to certain “technical groups”, such as “electric appliances” (whose group could be switched on/off), temperature setpoint, etc. so that items linked to channels of that thing inherit these groups.
I have a very simple setup, but regarding MQTT the coordinator is in one room, right ? Other devices will have different things and can be in other rooms.
Regarding HTTP, Astro, open wheather (and the like) should be in the group “external providers”.
It all depends on how the devices report. For example, let’s say I have access to an HTTP API that reports all the temperature sensors in the house as one JSON document. It doesn’t make sense to configure a separate HTTP Thing for each and every thermometer but then you have one Thing representing multiple devices in multiple locations.
The same can and does happen with MQTT. It often doesn’t make sense to duplicate a Thing scribed to the same topic(s) multiple times resulting in one Thing representing multiple devices in multiple locations.
I understand what you are saying. I use the Fineoffset binding and all my soil moisture probes appear as separate channels of the hub “thing”. But battery level is created in a separate thing, so I tend to create an “equipment” aggregating that thing with a certain channel of the hub. So we should be able to change the default location of items, not making them permanent.
I’m not sure preinstalled is really the best idea, but it would be fairly trivial to put some buttons on the model page that let the user select one of a couple of different pre-made location examples (One bedroom apartment, Single story house, Two story house with yards…) and those then could be auto-generated by the UI very easily.
2 Likes
I’ve been thinking recently that it would be awfully nice if we had the opportunity to create the location from the “add equipment to model” page. Maybe it’s as simple as adding a button there and here to “create location” which jumps out to the Location creation form and then back.
Then the start of the model could be built as you go.
1 Like
Not really, sitemaps are a core feature and Basic UI merely the primary web ui to show them (the mobile apps are other clients supporting them).
This is true - I see the point in removing Basic UI but I really don’t see the need. It’s barely a burden to have it installed whether you use it or not, and as sitemaps are still very much in use it’s convenient to have it handy when you don’t have a mobile device at hand.
Note that early on I wanted to implement sitemap support in the main UI:
It’s dead code, not injected into the final minified JavaScript, because I didn’t want the additional maintenance burden and figured Basic UI did the job well enough with a lighter footprint.
2 Likes
my PR to change the shopping cart icon got merged!
Oliver, I’m not a developer either but I still managed to create a PR and get it merged
2 Likes
So, how about we just include it and don’t make a first timer make a decision they know nothing about?