habmin is not discontinued, only Paper UI. I suggest a clear separation of concerns:
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)
Sounds logic, thanks for clarifying!
@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:
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).
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!
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:
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.
I agree - YAML is for configuration but not for rules.
This! Z-Wave is openhab greatest strength and it should be seamlessly integrated.
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
Squid
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”?
That’s where I would imagine it goes - under the “Configure” button.
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 ) 4k monitor. The middle section could indeed be a bit wider.
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'
channels:
-
label: 'Test Text'
channelTypeUID: 'mqtt:String'
configuration:
stateTopic: test/text
defaultTags: []
id: testtext
itemType: String
kind: STATE
linkedItems:
- mqtt_topic_3edb5737_testtext
properties: {}
uid: 'mqtt:topic:3edb5737:testtext'
-
label: 'Test number'
channelTypeUID: 'mqtt:Number'
configuration:
commandTopic: test/number/set
stateTopic: test/number
step: 1
defaultTags: []
id: testnumber
itemType: Number
kind: STATE
linkedItems:
- mqtt_topic_3edb5737_testnumber
properties: {}
uid: 'mqtt:topic:3edb5737:testnumber'
-
label: 'Test switch'
channelTypeUID: 'mqtt:Switch'
configuration:
commandTopic: test/switch/set
stateTopic: test/switch
defaultTags: []
id: testswitch
itemType: Switch
kind: STATE
linkedItems:
- mqtt_topic_3edb5737_testswitch
properties: {}
uid: 'mqtt:topic:3edb5737:testswitch'
-
label: 'Multi State'
channelTypeUID: 'mqtt:EnumSwitch'
configuration:
allowedStates: 'AAA,BBB,CCC'
commandTopic: test/multi/set
stateTopic: test/multi
defaultTags: []
id: multistate
itemType: Switch
kind: STATE
linkedItems:
- 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: []
configuration:
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.)
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.
It also adds unnecessary complexity. There are use cases that rely purely on file distribution which can not be met with import/export.
My experience with YAML is not great, is it possible to consider XML instead? It should be familiar for most users as well.
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.
Fair enough. I’m very much looking forward to the realization of this significant improvement to OH.
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.
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.
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)