This is probably the main point, and it would satisfy my needs. Clearly, no one should be hindered in adding UIs, but there should be one one-stop shop that is capable of doing everything, and no need to switch to HABmin to configure Z-Wave properly.
What I experience today: Use PaperUI for all configuration tasks. Hmm, maybe not for Z-Wave. Regarding control, use again Paper UI if you like. But you want to use the Android App, write a sitemap and create your UI logics in BasicUI. Well, if it should look nice, again start from scratch and design a HABpanel…
It is probably the current decoupling of the different design processes that makes me feel uncomfortable: It needs double work. Concluding - and I probably needed this discussion to come to this point - I am not against multiple UIs. But I am in favor of a unified engine (or better description language) behind to create the UI logics only once.
Don’t get me wrong: I am just giving my personal experience, and I respect all the work done so far a lot! As I am no developer, all I can contribute is an opinion
Thanks Kai, I’m certainly happy to participate. I’ve been away for the past few weeks and am still catching up on things (it was my first holiday with no internet for a long time ).
The decision for the AC is more complex than it initially seems to be, maybe the question is too broad.
As far as I have seen from all the responses, everybody is agreeing that classicui/basicui/paperui (the control part definitely) need to be unified (and habmins valuable pieces are moved over to a new generation UI.)
Mobile apps are out of the discussion (as they have their separate mobile store anyway).
But there is no agreement or open questions about habpanel, where sitemaps belong to, if an “admin role” interface is to be seen as a totally different UI experience than a “user role” interface. And where the dashboard functionality moves to. What are the opinions about the dashboard anyway? I think a similar listing functionality should be conserved but can be part of the main UI solution.
But here is the problem. HABPanel and sitemaps are fundamentally different. You will never have a case where you can define the UI only once and have it work for both cases.
So even if everything is possible in one UI, if you don’t like that UI (“if it should look nice”) you WILL have to start from scratch again. There is no working around that.
I don’t think we can completely throw them out of discussion in so far as if there is a radical change to how UIs are defined (i.e. no more sitemaps) it breaks the phone apps. So we need to at least be aware of and recognize the impact to the phone apps should some radical changes be made. I do agree that we are not talking about changing the phone apps themselves here, but I don’t think we can completely ignore them either if decisions made here completely breaks them.
I completely agree. Where it fits is an open question but merging it with the main UI makes a lot of sense. Just from a personal usage perspective, I would find it more convenient if I could get at the other UIs, particularly the REST Docs, from PaperUI rather than needing to keep another tab open to the dashboard.
That again would be a user preference I presume, some users might want to enforce logging in no matter what, as soon as there is an opportunity to do so.
Understood, but what I tried to imply: Some user will want to use a Habpanel-like interface, some a Basic UI like interface, and so on. So I completely agree with your comment:
The challenge really is, and always will be that ideally OpenHAB should provide maximum flexibility and freedom for users that want to use that to the full extent, and at the same time be very clear, intuitive and complete for users that want to have a single point of contact to their home automation system.
And to be clear: I do not have the solution to that or try to steer in a specific direction, I just try to voice what I believe could be the range of users and their demands, and thus the range of solutions OpenHAB ideally should provide. So in that sense I might be contradicting myself between different reactions, but that might be inherent to my “aim”.
As I said, that’s a detail to be decided by the devs who implement this. But I agree, I would expect this to be a preference.
Assuming they go full RBAC on this thing, a user could create a guest role and if you want to always have a log in, give no permissions to guest or disable that role. Or have a little flag to enable/disable.
NOTE: sheesh, auto correct did a number on my postings once again. You can always tell my posts that were written while I’m being distracted by something compared to those I have time to review. I gotta try a different keyboard on my phone or something.
Although ‘not “supported”’ sounds a bit scary, like “use at your own risk”, I think I see what you mean.
The first thing you have to do when setting up OpenHab 2.x, is selecting which package you want to use. I very well remember being lost right there and then, because I had no idea what to pick and what the implications of that choice would mean. Both right then and in the later future. So in that sense, starting with an UI like the one presented in this topic definitely is a clear improvement.
My plan is to finish this application over this weekend. This includes a new market-space like extension to list UIs from the npmjs.com repository (including this one of course).
All elements (context-help, editor, rule-editor, etc) are web-components, so embed-able in a future, common UI.
The list is generated from the REST interface (at least in the future, it is a fake REST call for now) and shows only example entries.
I have also added a small advertisement area to advertise binding/ui development on the left (grey scale to not distract from the center). I think a future UI should remind, at least in the admin interface, that a user can always participate and not just consume.
Open questions:
What do you think of such an advert area?
If you generally agree on having such a think (probably only on the start page anyway), what should be advertised? Development involvement, foundation support, something else?
And a design question. The current look is a bit overwhelming, there is too much going on. What can be left out, or moved. Maybe “Latest announcements” might move to the middle section and get reduced to 2 or 3 elements only. The rest is quite old news anyway. Not sure.
I would remove the paperUI from there if it’s going to go sooner rather then later and maybe put simpleUI as the sitemaps are here to stay for a while at least
I love this idea. But don’t forget that participation involves more than just code. Providing support on the forum, donating to the foundation, and contributing to the docs are other and equally valuable ways to participate and there will be a wider audience of users who can participate in those ways then in just binding development and UI development. Hopefully when 3.0 comes, Rules Template developers will also be needed.
Obviously taking up all that room advertising all of these things would be too much room on the screen. Maybe a rotating or random selection and only show one at a time with a different one being shown every time you load the page would be possible?
What happens if there is more than three UIs installed? Maybe it will help to make that a list along the left and move the advertisement down to the bottom. Both should be shrunk a bit perhaps.
I would hate to lose the Latest announcements but agree, it is a problem the way it is currently presented. I like the idea of moving it to the center and would be happy even if it only showed one announcement. Announcements don’t happen that frequently, users are unlikely to miss one I think. And if we are concerned about it, maybe make it a link that sends the user to the announcements page online to see what they missed.
I’m not UX specialist so my recommendations are not worth all that much.
Some advertisement on the left, announcements and events on the right.
Installed control interfaces appear very central now.
“legacy” and “developer” interfaces will be rendered as small boxes only.
Especially the charts are a tricky part. But I think I caught all static “white” parts and the page can now fully adapt and switch between bright and dark mode.
My initial idea for “scheduled tasks” were to expose every internally scheduled task of our openHAB Core Scheduler. That way I could display also Scheduled Tasks (Timers) that are created from within Scripts.
I changed my mind though. Instead I will use two approaches to satisfy all timer needs.
Items will have an “expire” namespace as metadata. That will pretty much work like the current OH1 expire binding. You can assign as many “expire” timers on an Item as you like. An expired timer can either change the items state or execute a rule. Every of those timers must have a unique ID and can have tags. That way you can influence (read: stop/restart) expire timers with a given ID or given tags.
The usecase I have in mind: “Turn off a light 3 minutes after it has been turned on. If a motion sensor registered a movement in the meantime, reset the timer”
Use rules for timed tasks. The calender view above will find all rules with the tag “alarm”. You can create a new timed task by clicking on any date/time. A dialog popup will ask you if you are going to create a recurring or absolute timed task and you can select from a list of pre-defined actions.
Internally a rule will be created.
I have no idea how user roles are implemented at the moment. But personally I would like to set which REST endpoints a user can access (via REGEX expression) and which Items can be accessed.
In the above example “Grandma” for example can only access “Items” (so no configuration, no inbox, no rules etc) and only Items with the tag “kitchen”.
That should be sufficient for user roles or did I forget a usecase?
Small changes and fixes
Configurations are now rendered correctly.
Logview is live. If a websocket connection can be found, it will display received data. Otherwise example data as before.
The graphs on maintenance are now live. If a websocket connection can be found, those will display received data. Otherwise example data as before.
And that’s all I got time for this week. On my agenda are still semantic tagging and rules.
As usual, if you want to support me with this OH vision, please consider donating or helping out.
Thx david for this greate desgin study.
I think if this will come to the core i will switch from textual config to this
The “calender” looks greate and it is one function in OH what i always want to have.
But did you thought about a google calender feature/Integration or something like that.
So we don’t would need the caldav bindings anymore.
CalDav-OH2 will offer a NGRE Rule Trigger that triggers on when a Google calendar event happens.
With a NGRE Rule Condition you then decide within a Rule if the calendar event is relevant and if the Rule Actions should be executed.
But that also means, that we cannot show those events in this calendar view. Hm, maybe we can, for convenience reasons, but you would not be able to edit those events. But you have the Google Calendar app anyway.
Yes, I’m refactoring at the moment, to get the list of REST endpoints and present them to the user in a list like fashion. No regex anymore. The idea is with this user interface to reduce support needs here in the forum and the regex -oh-my-word- would cause a lot of support questions.
).
