[Main UI] Define the new architecture and technology stack #24
Comments
|
FWIW, I think it makes a lot of sense to keep the used web technologies in openHAB limited. As we already have HABot and our website being based on Vue.js, this sounds indeed like the most natural choice - but I am no JS/web developer myself, so take my opinion with a grain of salt. |
|
Alright, here's my suggestions to kick off the discussion:
I'll give an in-depth comparison of Quasar and Framework7 in a future post. |
|
Some small additions: |
|
Vuetify ... great ! |
|
👍 @ghys sounds great
Thanks again for this @ghys, this sounds really promising. |
|
Just my 2 cents: When considering VueJS, please take a look at Nativescript VueJS. If you design the UI right, you don't need a Cordova hybrid app, but can release a native app. Greetz |
|
Secure by design - https only. |
I agree with your reasoning. While it's a great language that takes all the goodness from JS and adds strong typing on top of it, I think it would make contributions reduced because of a little bit steeper learning curve than plain ES6 and beyond. I would really love to see some tests, though. This is why I'm more leaning towards Quasar. Its Testing monorepo has everything preconfigured right our of the box. You get Cypress, Jest, Lighhouse and more - everything nicely packed and ready to go. More docs on that can be found here. |
Not sure if Quasar or f7 comes with something alike, but I would add date-fns to the collection. Lightweight alternative to moment.js. |
|
Can't personally vouch for it but have read about Day.Js as an alternative ⏰ Day.js 2KB immutable date library alternative to Moment.js with the same modern API https://github.com/iamkun/dayjs reference: moment/moment#2373 (comment) |
Vuetify was on my mind of course, I feel it's lagging behind esp. Quasar now.
I like NativeScript, have done a prototype for a customer (but with Angular), even if we find a project template to build both a webapp and NativeScript apps with the same code I'm afraid we won't have the development power to maintain both versions of the UX, even if we could share some code. Today's web frameworks and devices are IMHO fast enough to make a Cordova app "good enough". Good suggestion though.
agreed! 😄 Moment.js is bloated! Day.js is interesting as well. |
|
So I have continued to evaluate Framework7 but have also ported part of the same app to Quasar 1.0 beta for the sake of comparison, and just made public the 2 repos I made with both prototypes, there are also releases you can try on your instances and deployed demos:
(note: I haven't reimplemented all features in the Quasar version, just a few screens - sitemaps, settings menu, things/items lists w/o details, addons, service configuration - the goal was to get a feeling of the framework with an app as scaffolded by the official CLI vs. the same with f7). Here are some thoughts: Development environment & toolingBoth apps scaffolded with the frameworks' CLI have roughly the same structure modeled after Vue-CLI, offer a webpack-based config and a development server with hot module reloading. Quasar abstracts away all the webpack wiring with a custom configuration file (quasar.conf.js) and plugins - which also helps with the treeshaking which is the standard, all used components must be added to that file, while Framework7 is more "bare-bones" with a standard webpack config and includes a bundle with the whole framework by default (treeshaking is however also possible). Compilation or linting errors should they occur are also displayed on an overlay over the app on Quasar, this is a nice touch while not really that useful. Overall, while I had a pleasant experience with both (hot reloading etc.), clearly with its bold choices, sensible defaults and great tooling Quasar is a step above in this area. Features & componentsAgain both frameworks offer a wide range of functionality, but as you can imagine the devil is in the details ;) Quasar is a Vue-only framework so it respects the Vue overall philosophy best ( Overall, I would still say Framework7 wins here. UX (desktop and mobile)A very subjective topic... while the app Quasar feels lighter (perhaps due to the code size and the lack of transitions and animations by default), the f7 app feels more "fluid", "smooth" and modern in my opinion, it mimics the look & feel and transitions of Android & iOS nearly perfectly. Having a good quality UX could be in my view a key differentiator to make openHAB appealing to more users, so I'd say we have to take this very important factor into account. For example, using a f7 Smart Select popup in https://habot-demo.azurewebsites.net/#!/settings/services/org.eclipse.smarthome.core.i18nprovider vs. a QSelect in https://habot-demo.azurewebsites.net/quasar/#/settings/services/org.eclipse.smarthome.core.i18nprovider for the region/language/timezone makes a big difference, especially on smaller screens. Having a good "native" feeling on iOS devices too is a differentiator, not only another "generic" (!) Material Design app which we can see everywhere now - especially since both frameworks can build fullscreen apps and that could become a nice way of interacting with openHAB.
To me, Framework7 wins here too. Documentation & communityBoth documentation sites are well thought out, with Framework7 you sometimes have to deal with the core JS docs as well as the Vue.js components docs, the new Quasar docs are really well done, and the community on Discord and the forum is very friendly. Framework7 has an active Discourse although you might encounter some Russian ;) Both project leaders are friendly and available and fix bugs swiftly. -- In a nutshell, I think Quasar has the best development experience, and f7 the best feature set (at least for now) and the best look & feel. I'd say we should try to bring some of what Quasar offers with its tooling and its general "sensible defaults" approach to the f7 prototype and give it a shot, so we could get the best of both worlds - IMHO it's easier to port some configuration from Quasar to f7 than components from f7 to Quasar. I don't expect we'll hit a roadblock and if so, it's not too late to switch to Quasar (or Vuetify or another framework), like I said all non-UI related code could be reused - Vuex store etc. Feedback appreciated as always, before @openhab/webui-maintainers can cast their vote ;) |
|
I see a lot of 👍 here and no vetos or other suggestions, so I'd say: Go for a formal vote and start realising it! |
|
Does this UI stuff in any mean fit to or contradict what @davidgraeff is piloting? |
|
It is not related :) |
|
Not sure I can fully agree here as I see the primary value of open source in the way it fosters collaboration. Competition is something for commercial solutions... |
|
I'd agree usually. But here we have no choice. I fully disagree with Yannicks proposal and I think he is heading in the wrong direction. But I'm not involved in this repo or decisions taken here. I'll advertise my solution to people that are interested. |
|
@davidgraeff so what do You propose? I'm not suggesting to drop development of Your UI, that's too much hard work to be throw away, but maybe try to settle on the technology and merge two UI's into one that will become the default one. I'm not saying that one is better than other, colors, looks, animations, etc are a matter of individual preferences. Try to think about what will be better for a new user. OpenHab is awesome, new fresh and unified UI will make it even better 😊 |
|
@Misiu You got a few things wrong here. I have never developed an UI that is capable of replacing all existing Web-UIs for control & setup of openHAB. I have developed a design study to find the shortcomings of openHABs API. And I think Yannick did the planning wrong here, because he did not fix the messy REST API situation we have at the moment first. (I have written about this in detail in several community posts, if you are interested in details). That means as soon as we start breaking for OH3 (which in my idea includes breaking the REST API to finally bring it back to a consistent state) the UI need adaptions all over the place. Currently there is no mechanism in place to install UIs in an easy fashion. I'm discussing this in the core repo already. That's what I'm saying here, nothing more. I want it to be easy to install something else, because Yannicks solution will break down. My personal opinion about this UI is a different topic and does not matter here. Briefly: I don't think this UI is suitable for "Configuring your smarthome" with all potential that OH includes. And there are no thoughts put into repo-management, user-management, security-management like I did in my design study. Remember that I'm assuming that we remove .thing, .item files at some point (maybe exposing the internal database to user-editable files). So the UI MUST be capable of allowing the user to edit all kind of configurations via text interface, next to a graphical one, at all times. This UI here does not provide this advanced editing. And that's fine. You cannot have everything in one project. That's also what I'm saying, separation of concerns. This is more of a control UI that allows a few configurations to be done on the way (like approving Inbox things etc). And I very much appreciate that this UI is developed, because all other projects in this repo apart from HaBot are absolutely outdated. |
GitHub is perhaps the better venue for discussing technical matters, the forum is more suited to end user support and general community talk.
I think the REST API is rather clean right now (being mostly RESTful, relatively well documented thanks to Swagger etc.) and actually a strength of openHAB compared to other open source home automation software I've seen. What are you referring to?
Why the negativity? The whole point of this issue is as much trying to settle on a visually appealing look & feel for openHAB's UI to get that "wow" factor (I won't deny I still think it's important for the overall "reputation" of the project) as trying to rally potential developers around a common set of standards that will make the UI as easy as possible to develop in conjunction with the changes in the core and other areas. The easier it is to get into code-wise (so a well-organized folder structure, Vue's single file components and other niceties, a baseline components framework that's easy to grasp and actively developed and a test infrastructure will help a lot here), the less likely it is to "break" because more people will be able to make sure that doesn't happen. This isn't supposed to be a competing personal project, or a personal take on what openHAB should become like your design study, rather the way to develop the UI to guarantee it's viable as a mid-term "face" of the project as it is evolving as a collaborative effort. When changes in functionality to the core are agreed by all stakeholders after cross-team discussions, and then introduced, I don't see why the UI wouldn't follow suit. Regarding the installation of other UIs and functionality, that's another strength of openHAB, they can be installed easily because of the add-on paradigm; it's not any more difficult than installing other kinds of add-ons like a binding or a persistence service. If you need specialized UIs like HABot, HABPanel or a more advanced administration UI (maybe something like https://github.com/hassio-addons/addon-vscode to edit configuration in a browser-based embedded VS Code, a Z-Wave network viewer, or your design study which might become "the new HABmin"?), it's already easy to install them. The goal is to let users have a basic experience they can already do much with, and let them discover and install more powerful UIs when their needs evolve. Finally, I'll grant you that this project has a less ambitious goal to only become a more modern replacement for the Paper UI (+ a sitemap viewer), because its concept wasn't bad IMHO, it has only been outdated in terms of web development standards, so it's time for a fresh new take on it for openHAB 3.x as will probably happen again in a few years for 4.x. |
|
And I'm very thankful for your UI.
I have this discussion in core in the Issue about Extensions. I think java bundles are not the way to distribute webuis. tl;dr of that discussion (please head over for your valuable comments): I like npm to be an official ExtensionService for retrieving additional web-uis. That should attract frontend-developers.
Problems with the current REST API
REST API for user-interfacesIn HabPanel you stored a big json blob as configuration value via the service. In HaBot you introduced the cards REST endpoint (with CRUD capabilities). I first considered that we should just have multiple endpoints for different kinds of UIs (cards vs panels etc). Because we would use a - habpanel#myFirstPage
name: Main Page
description: My main page for the living room
widgets:
- w1: ...Auto generating RESTSwagger is nice, true. But in the end it tells you the same:
Now that I know the core code in detail (and after I spend some hours to modernize our current REST code via using the OSGi R7 whiteboard pattern, see the PR in core), I would remove all specific REST classes actually. We automatically have a harmonized and consistent API if we create CRUD REST endpoints automatically for each And yes I was also thinking about GraphQL and made a small proof of concept build. GraphQL allows "joins" and could allow a Setup&Maintenance UI to retrieve exactly the fields and cross references it requires. In both cases the swagger/graphql documentation can be auto-generated if we annotate our registries (like "name", "description") and have our DTOs annotated. Our REST interface is nothing more than what we call an "IO Service" in openHAB. Just like the Hue protocol or the HomeKit protocol that we offer for external services. If we auto-generate: That would happen in a single bundle very analogue to the mentioned bundles and not distributed all over the place in different bundles like it is now. PS: I'm not subscribed to this topic, please reference me for responses, thanks :) |
|
Thanks for your detailed breakdown of proposed changes in the core, that's very helpful and valuable. Cross-references and parallels to GraphDB are fair.
HABPanel's storage was kind of an afterthought, it works but technically I'm not proud of it. With HABot it's cleaner but still too tightly tied to the frontend framework's capabilities (Quasar in this case) so it was a good call to keep it separate from the core at the time, Sitemaps have their problems but they're what we have and still a good concept for generic UI regardless of the underlying implementation. Your "generic store" idea for UI artifacts is very interesting though and it'd be very cool to have it come to fruition. It'll come in handy for the "card+minisitemap" idea I'd like to being forward eventually. Off-topic, but for writeback or lack thereof in general - I've read the community threads - my preference would be the JSONDB to become the single source of truth then have something like Kubernetes' declarative configuration for the textual part i.e. "apply" your textual configuration (in YAML or even the current syntax with a custom parser so that the docs don't become obsolete overnight) with an API to send the file and ideally a similar command-line tool (" |
|
In the blog post of the 2.5 release I read the following: |
|
I think what @kaikreuzer meant in the blog post is that the UI will replace the 2.x "dashboard" with something which could handle the main use cases (day-to-day operation and administration, the latter behind some kind of protection), but it will also still offer the ability to launch other UIs if desired. It is not in the plans to deprecate HABPanel or HABot or the Swagger UI for the API, or even Basic UI. Launching other UIs is less emphasized in the current design than in the current dashboard, it's hidden behind a button on the home page, but it still exists (the design can of course be discussed and changed): Currently UIs are distributed as addons and can be installed like any other addon, and are responsible for registering a DashboardTile for themselves, and tiles linking to external programs can also be added to the dashboard by the OS (e.g. openHABian). If there's a viable and agreed upon alternative coming up, it could change, otherwise we would only need a REST endpoint to get the available tiles. |
To be discussed to be honest and we already spoke about this a while ago. HABPanel uses a different technology and has its own ecosystem already, so this will have to stay. But HABot and Basic UI could be merged (and that would imho be very desirable) into the new UI. We said that as a prerequisite for this, we will definitely need role-based authorisation support ready. Note that in the description of this issue you mention as (2) the feature parity with Classic/Basic UI 😎. |
@Hilbrand That would be excellent, because what we definitely want is to have a team of people being able to maintain the new UI! |
Yes l agree, HabPanel has its own ecosystem already but needs major overhaul. I have posted several TODO's openhab/org.openhab.ui.habpanel#286 in the old repo. It still have inline styles in many areas, something in most organizations will simply not pass. There's not a single unit test, no linting rules, no public method documentation (JDoc, etc). The multi-language support was a headache, you need to know which key was previously used in what context. Kudos to @ghys , but these are some of the reasons I stopped developing for HabPanel as I used to, and simply refer people to my fork. I believe I still have some PRs in the old repo that were rejected because of coding styles. I believe the biggest setback was that there's a single reviewer, a single person who approves PR. For that PR to get approved, you would need to please that single reviewer to the T. |
|
I got to that page from @kaikreuzer OH 3.0 announcement and I found it very interesting. One doubt I have is if the new UI will contemplate some extension system to display custom widgets. For example, I'm thinking about the small card library from HomeAssistant that is provided as an extension there. It will be very nice for me to be able to adapt it, and possibly a simple adaptor on top of its config parameters will do the job. |
|
I hope this is the right place for adding wishes for openHAB 3 and the new UI. I am no developer and from the time line of openHAB development a fresh user with round about nine months of using openHAB 2.4 and 2.5. From one view, the text based setup was nice to grow a openHAB installation step by step and solve one problem after the other. But I run fast in limitations I did not know how to solve and for some things I found the message, that there is no solution. Example 1 -> Basic UI and long text items. I use the binding from "DWD Deutscher Wetterdienst" and actual there are some warnings with additional information. The Basic UI and the openHAB iOS app can't show this text completely. Only in a browser it is shown as an mouse tool tip when I go over the item and the Paper UI shows this also. But here I had to much room definitions that the horizontal room list is not readable. Example 2 -> Definition of items from a binding. The DWD binding offers also a number if there is more then one warning. But items are defined in the text file. As the result there is no dynamic way to create items and there UI parts. In comparison to the other smart home project ioBroker they create in there database the "items" like they where fetched from the service. And the user has a more comfortable way over an GUI. And this is the second wish for the new UI in openHAB 3. A more graphical way for creating rules. I tried out the Next Rule Engine in openHAB 2.5. But there are many problems with truncated text and it is not so intuitiv like the Blockly way in ioBroker. I saw that there is a Blockly in HABmin but also in the forum are some entries about non functionality in the actual version. Example 3 -> reading and offering lists for users. A little bit frustrated I had the last days a look to Home Assistant and installed it in a virtual machine. It finds in second things like my Sonos Systems, offered a nice UI and added also a choosable list of our favorite radio stations without one click of programming and defining something. Finally I must say, that I like certainly the way over text files, because of backing up before changes. But the best for the future would be a way that the UI creates the textfiles, changes would be possible over the ui and the files and the the inflexible display system in the Basic UI gives a way to a modern responsive UI. |
ghys
changed the title
|
Hi :-) I don't know of I'm in the right place here, but as Habmin ist already removed a long time, I wanted to ask the status of the new ui...Habmin was very usefull for Z-Wave devices... |
|
@ghys I guess we can close this issue, since the new UI is established, fully functional and part of the openHAB 3 snapshot distro, right? |
|
Agreed - on the new UI being feature-equivalent to HABmin, Paper UI and others, I believe good beta-testing will be crucial in identifying the major pain points so we will hopefully be confident of having a working replacement by the time openHAB 3.0 is released. |
Context
(scroll down to the next separator line for the actual purpose of this issue)
The openHAB Architecture Council (@openhab/architecture-council), after some deliberation and having taken into account the many views expressed around Web UIs - including, but not limited to the several topics in the community forum - has reached the following conclusions:
Therefore, in an unanimous decision, it has agreed on the following:
Which means, in terms of functionality for this new app, it roughly translates into:
1. Dashboard feature parity:
a. Helping the user configure openHAB with a basic setup when starting it for the first time
b. Presenting a list of the current "dashboard tiles" representing other UIs (and tools with a frontend) and offer a way to launch them
2. Basic/Classic UI feature parity:
a. Displaying sitemaps - updated in real-time and with all available controls
3. Paper UI feature parity:
a. Listing, installing, configuring and uninstalling add-ons (presented by type: bindings, actions, etc.)
b. Configuring the services which have "config descriptions"
c. Managing the Inbox and the discovery: starting a new scan (global or by binding), listing the inbox entries, ignoring/un-ignoring/deleting entries, promoting a discovery result to a full Thing
d. Managing Things: create manually, list/search, enabling/disabling, delete; show details: configure settings, list channels, link/unlink items from/to a channel with an eventual Profile
e. Managing Items: create, list/search, delete; show details: configure basic settings, assign groups, tags/semantics*, metadata, (linking to a Channel?)**
*Note: tagging is not actually a feature Paper UI currently offers but it probably an oversight, so we can safely consider it already
**Similarly, not a feature of the current Paper UI but defining a Link from the Item page may also make sense, so let's consider it too?
f. Managing Rules (from the new automation engine a.k.a. "NGRE"): create, list, enable-disable, delete, run now; show details: manage triggers, conditions and actions (add, reorder, configure, delete)
4. Essential features from HABmin
a. Interactive chart display for persistence data
b. Z-Wave network management: visualization, actions on nodes (heal, pair, unpair...).
(please let me know if I forgot something)
This is not a definitive list (having HABot and Home Builder reintegrated is on the roadmap as well), however, this is, in my view, the agreed set of functionality we should focus on before adding new ones, in order to achieve the goal stated above - merging the quintessential experience for the average openHAB user into a new "default" app which would appear in lieu of the current Dashboard. There are surely some unknowns about the future of some specific feature, whether it should be considered or not (firmware management, rule templates, Eclipse Marketplace?) or how it should be implemented/how close to the current look&feel it should be. Those would be addressed in additional, separate issues.
Therefore, may I please ask for your understanding, and for the sake of keeping the debate here on topic: this issue is not another discussion venue for ideas of features the new default openHAB UI should have. There are multiple topics already opened for that purpose in the discussion forum, where everyone can take part - rest assured they are read and taken into consideration by the stakeholders here (@openhab/webui-maintainers).
The purpose of this issue is to reach an agreement on the technical aspects of the implementation of this new app, with a focus on trying to bring up a friendly and experience for potential new contributors, with as little barrier to entry as possible, namely we have to decide on the following:
The development language - Which flavor of Javascript, transpiling yes/no, and should we consider TypeScript?
The general-purpose framework choice - Angular, React, Polymer or (most likely ;)) Vue.js
The design patterns and overall architecture, folder structure etc. - which will depend on 2., for instance Vue has single file components and probably also on 10. below ;) I'd recommend we should stick to the best practices and tooling provided and maintained by these frameworks (most of them have a CLI to scaffold a new app in a standard, predictable way), to minimize custom code & headaches for new contributors;
The coding style - Standard or Airbnb. We should set up a linter and one of those two will be used as a basis. Additional recommendations welcome!
Which CSS preprocessor - LESS, SCSS, Stylus?
Webpack?
To what extent we focus on a great mobile experience (incl. phones and tablets) as well as the desktop - influences the choices below;
Whether or not we should consider building Cordova apps for iOS (mostly) and Android (possibly) with the Web UI's code (Android can "add to homescreen" with PWA features which are IMHO a must and shouldn't be up for debate). Note that this is not a push to replace the current native mobile apps for sitemap viewing, rather an interesting option we can keep in mind to bring the other features esp. the administration features to the mobile world;
What UI theme(s) we choose - a variant of Material Design is likely, it was already the choice for Basic UI and Paper UI, and it will fit desktops and Android very well but depending on the decision on 5. we may decide to provide an iOS theme as well;
An overall frontend framework covering at least Material Design - may also depend on 2. Examples include: Quasar, Framework7, Ionic, something else?
The libraries we settle on for:
a. API calls and AJAX (Axios...) - the framework chosen in 10. might also provide one for us
b. State management (Vuex, ngrx, Redux...) - depends on 2. and maybe 10.
c. i18n/l20n - if we consider it at all - depends on 2.
d. Charting: echarts (used in the HABot analyzer), chart.js, ...
e. Maps: leaflet, ...
f. Icons: Material Design Icons probably, the framework chosen in 9. might also provide additional sets...
f. others, tbd... Minor library choices can be decided by the developer
(optional at this stage but still to keep in mind) How to plan the restriction of certain features to authorized users, which will obviously be influenced by the choices made in openhab-core (RBAC system of similar)
I'll offer my personal preferences in a separate post below this one, to make it clear they are not to be considered as the final choices. A word about the decision process: @openhab/webui-maintainers will be responsible for these choices and will make a final decision when there's a consensus on each of the above questions, according to the governance rules in place, with a possible escalation to @openhab/architecture-council only when necessary.
The text was updated successfully, but these errors were encountered: