I would personally be fine using textual mode, but I think a big part of the NGRE, and basically of what you are displaying in the “Rules” section is aimed to be a system where you do not have to use code, to aide the users not comfortable with coding. Of course you can use two tabs, but you would have to take extra care that such a construction would not cause issues. I have seen several applications that start to behave very unpredictable when you are working in two tabs in parallel.
And then you’d still like to be able to copy things probably.
I commented on this because it is something that @David_Graeff showed in his design study, and the things I suggest might be of relevance to how to further develop this in the future.
See the discussion link in the first post This design study is really just the frontend. It requires some additional services like for example a backup service that can export/import yaml files. But every existing part of the core is untouched.
For OH 3 I would of course stand up for the idea of making all Xtend/XText (.thing/.item/.rule files) based parts of the core optional/deprecated. But that’s another topic.
David, first off, bravo for an excellent and well developed design study. I am amazed at how so many of the community’s suggestion were incorporated such as the log view and also the progress you made since I last checked out your preview version maybe two weeks ago.
I think this shows new and old users alike what this platform could be with a unified polished front end and still function with all the versatility that we all want from openHAB.
I have been digging around for 20 minutes trying to find the graphical rules engine project… what is it called with the node red type rules interface. That is what the rules engine should be in a ‘blue sky’ user interface IMHO. Some thing akin to IFTTT or stringify where folks with zero programing ability can piece together basic rules… someone please link but anyhow subject for another thread…
As Kai says (paraphrased not quoted) we need to structure our discussions a little better
A very good evolution of the GUI! Thanks!!
Imho, a floorpan integration with controllable item icons would be great (cfr habmin)
Additionally, a way to integrate/edit the v1 textual configurations trough the GUI (syntax cracking?) would make things easier
habmin is not discontinued, only Paper UI. I suggest a clear separation of concerns:
Paper UI: Administrative tasks, configurations, addons, manage Things, Items and Rules.
Habmin: Floorplan, Sitemaps etc
Habpanel, Android App, iOS App: Control interfaces
There is no official or community decision yet, but if its going my way, the old textual configuration syntax will vanish completely. (Import tool will exist then of course)
@David_Graeff - excellent design study, I love that I’m able to play with it and see how it will affect my (and other users’) usage of the Paper UI. I appreciate how much effort you’ve put into this! Here is my take/comments on it from using it for only a few minutes:
Agree with @5iver about item/thing display (I also have hundreds of each); would like to see more filtering options as well…
Would like to see a “dark theme” - the current PaperUI is hard on the eyes in the evening
YAML also hurts my eyes (and brain) but I’m OK with it for light usage like item/thing configuration (less so for rules, where I prefer the Rules DSL, which is in my personal opinion the number 1 advantage we have over Home Assistant).
I appreciate the use of a VSCode control for the textual configuration (e.g. for familiarity with my current daily use), but will it allow the inclusion of the awesome openHAB extension from @kubawolanin? Or any other extensions/code helpers like VSCode does? Also, see my point #2 (dark theme)
Would like to see Zwave-specific functionality built in/carried over from Habmin (mesh/device viewer, controller reset, network heal, etc…), so it’s a one-stop-shop for all my configuration (the integrated log viewer is already a great step towards that).
As @5iver mentioned, there is a lot of wasted screen real estate on higher resolutions. I use an ultrawide monitor, at a resolution of 2560x1080, and would love to see the middle column extend to fill the screen (perhaps even add another column to the grid views, so more things/items/rules are visible on the screen at the same time).
In all, I love the functionality and improvements over the current PaperUI, it’s a huge step forward! Thanks for taking this on and allowing us users participate in the design process!
That is amazing work! I think you tick a lot of boxes with this Design study. This already simplyfies usage of three tools into one modern fresh looking UI ( PaperUi, frontail, PiMonitor). I also think that a a fully functional graphical Ruleeditor is absolutely necessary to have a chance to make OpenHan a more “mainstream” Solution. Most people in this Forum will be fine with writing either DSL Rules, Jython or whatever. But the market of Opensource and closed source Homeautomation Platforms is so fragmented right now which will probably change a lot in the next few years. To stay relevant OpenHab needs to appeal to more entry Level users. They will eventually become more advanced users if the FIRST impression of OpenHab is a good one.
This is massive step into the right Direction. I also liked your ideas and thoughts from the Next Gen Design Thread!
I’m using the bootstrap css toolkit and no hardcoded colors. So changing the theme is basically replacing just the style sheet. On https://bootswatch.com/ you can find bootstrap themes. But yeah theme changing is also a must for me, I really detest pages that don’t offer themes (btw. Dear admins: the community forum doesn’t…).
I have a super wide screen monitor as well. And you must constrain the middle part and also the context help part. Otherwise you have super long text lines, not easy for the eyes. But I can imagine to widen the middle part a bit. It is currently fixed to 900px or so, I think.
“Modern” OH scripts are at the moment written in Javascript and Jython. I’m only going to support those in the design study.
Couple of questions in regards to OS compatibility…
I noticed the backup status and saw mentions of Frontail. From my current understanding both the backup script as well as Fronttail do not run on a Windows platform.
Would hate to have an interface as powerful as this with features missing for some users.
This is really just the frontend part. But for the core parts, neither the backup script nor frontail are what I imagine to be used. Those functionalities would be realized by two services integrated into the OH core.
We would need a well defined interface in the core for exposing zwave/zigbee/other-mesh-networks to a frontend. I haven’t thought about that yet. And I don’t really know where to put the UI. Maybe under “Binding configuration”?
This design study is really just the frontend. It requires some additional services like for example a backup service that can export/import yaml files. But every existing part of the core is untouched.
but I’m OK with it for light usage like item/thing configuration (less so for rules, where I prefer the Rules DSL, which is in my personal opinion the number 1 advantage we have over Home Assistant).
