Next generation design: A Paper UI replacement proposal

(David Graeff) #21

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)

(Stefaan Bolle) #22

Sounds logic, thanks for clarifying!

(B K) #23

@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:

  1. Agree with @5iver about item/thing display (I also have hundreds of each); would like to see more filtering options as well…
  2. Would like to see a “dark theme” - the current PaperUI is hard on the eyes in the evening
  3. YAML also hurts my eyes (and brain) :wink: 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).
  4. 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) :slight_smile:
  5. 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).
  6. 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!

(Salexes) #24

I really love the design study. I think it looks great and would love to use it in future.

I only noticed one thing. On big screens (high resolution there is a lot white space on the left and right. Shouldn’t we make use of that space?.

A dark theme could look like this:

(Tomibeck) #25

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!

(David Graeff) #26

I’m using the bootstrap css toolkit and no hardcoded colors. So changing the theme is basically replacing just the style sheet. On 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.

(Sebastian) #27

I agree - YAML is for configuration but not for rules.

This! Z-Wave is openhab greatest strength and it should be seamlessly integrated.

(The Squid) #28


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.

Just m y .02


(David Graeff) #29

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”?

(B K) #30

That’s where I would imagine it goes - under the “Configure” button.

(marcel_erkel) #31

Could the location of the log timestamp be made configurable so that I can place it to the left side. I’ve never come across log files that end with the timestamp of the event, the log lines always start with the timestamp. Having them on the right side feels awkward.

I have a 42.5" (the .5" makes the difference :wink:) 4k monitor. The middle section could indeed be a bit wider.

(Scott Karns) #32

Great start!

I agree with others who don’t much care for the look of the YAML. The readability of the YAML view and output could be improved with pretty printing, e.g.,

  label: 'Generic MQTT Thing'
  bridgeUID: 'mqtt:systemBroker:embedded-mqtt-broker'
      label: 'Test Text'
      channelTypeUID: 'mqtt:String'
        stateTopic: test/text
      defaultTags: []
      id: testtext
      itemType: String
      kind: STATE
        - mqtt_topic_3edb5737_testtext
      properties: {}
      uid: 'mqtt:topic:3edb5737:testtext'
      label: 'Test number'
      channelTypeUID: 'mqtt:Number'
        commandTopic: test/number/set
        stateTopic: test/number
        step: 1
      defaultTags: []
      id: testnumber
      itemType: Number
      kind: STATE
        - mqtt_topic_3edb5737_testnumber
      properties: {}
      uid: 'mqtt:topic:3edb5737:testnumber'
      label: 'Test switch'
      channelTypeUID: 'mqtt:Switch'
        commandTopic: test/switch/set
        stateTopic: test/switch
      defaultTags: []
      id: testswitch
      itemType: Switch
      kind: STATE
        - mqtt_topic_3edb5737_testswitch
      properties: {}
      uid: 'mqtt:topic:3edb5737:testswitch'
      label: 'Multi State'
      channelTypeUID: 'mqtt:EnumSwitch'
        allowedStates: 'AAA,BBB,CCC'
        commandTopic: test/multi/set
        stateTopic: test/multi
      defaultTags: []
      id: multistate
      itemType: Switch
      kind: STATE
        - mqtt_topic_3edb5737_multistate
      properties: {}
      uid: 'mqtt:topic:3edb5737:multistate'
  configuration: {}
  thingTypeUID: 'mqtt:topic'
  UID: 'mqtt:topic:3edb5737'
  label: 'testname (HomeAssistant MQTT Switch)'
  bridgeUID: 'mqtt:systemBroker:embedded-mqtt-broker'
  channels: []
    baseid: homeassistant
    deviceid: testobject-node
    nodeid: node
    objectid: testobject
  thingTypeUID: 'mqtt:homeassistant'
  UID: 'mqtt:homeassistant:embedded-mqtt-broker:testobject-node'
  label: 'MQTT Broker'
  channels: []
  configuration: {}
  thingTypeUID: 'mqtt:systemBroker'
  UID: 'mqtt:systemBroker:embedded-mqtt-broker'

Keys of mappings could be sorted as well (except here I’ve put the label key-value pair at the start of each mapping.)

(YvesHanoulle) #33

I was in these discussions that is exactly why I ask.

for example a backup service that can export/import yaml files. But every existing part of the core is untouched.

a backup service does not work for me to maintain two different systems with the same configuration yet different openhab versions. Which is what I do for testing upgrades.

I really want a way to configure my files in my own editor everytime and go from there .
I understand the need for paperUI, yet so far I have not seen anything that I need or want.

(Sebastian) #34

It also adds unnecessary complexity. There are use cases that rely purely on file distribution which can not be met with import/export.

(Christian) #35

My experience with YAML is not great, is it possible to consider XML instead? It should be familiar for most users as well.

(David Graeff) #36

The markup language can be any as the visible content is internally generated from the json that openHAB returns. This is done on the client side and does not depend on additional openHAB services. Someone would just need to add a json->xml adapter.

You can always just distribute the jsondb file. That is the latest openHAB state you can get.

You need a synchronize core service and not files, I assume.

Right click -> Format in the editor window. The current json-yaml library that I’m using does not support pretty printing and if I’m getting lost in small feature details, the overall design study will not finish. Bear with me, please.

(Scott Karns) #37

Fair enough. I’m very much looking forward to the realization of this significant improvement to OH.

(YvesHanoulle) #38

You need a synchronize core service and not files, I assume.

No. These two systems are never be up and running at the same time.

(YvesHanoulle) #39

You can always just distribute the jsondb file. That is the latest openHAB state you can get.

I assume that will always be related to the installed version of OpenHab.
It would make testing an upgrade very hard.
That is when we upgrade, we either save the new json file and upload it to a source control system, yet we loose all changes done later or we loose the option to go back.

I now install snapshots very regularly, play around it with an evening, to test if it solves a problem, if it doesn’t or gives me other problems, I just go back to an older install, yet all the changes I made to any configuration I don’t loose.
If I can’t do that, it would limit my tests to snapshots to moment I have a lot more time. That would mean weekends, which limits it typically to 1 weekend a month or so.

(where it’s now more or less once every week)

So it slows down feedback loops from my and probably a lot of others.

(David Graeff) #40

Thank you for the use-case description, that helps to clarify your needs.
I still don’t see where that conflicts with an import/export pattern. Should be discussed in a topic about textual configuration needs.

(This is off-topic here, of course. I forgot to mention that a few posts earlier)