Configuration of openHAB


(Sebastian) #1

The way things are configured are very inconsistent at the moment. Configuration through a GUI has the advantage of being newbie friendly, but is very time consuming and has many restraints.

I strongly advocate that textual configuration becomes the preferred way of configuring openHAB again.
Operations and changes are very fast and easy to make and can easily be shared across multiple instances.
Most configuration problems and questions with openhab1 have been about the configuration of z-wave devices. The device database effectively solves these problems. Also there are many posts asking for textual configurations.

A nice compromise could be a configuration format which is human and machine readable (e.g. yaml).
The configuration GUI could then just create/modify those files. More advanced users can create files directly while newbies could use the GUI to create the files.


Web UIs for openHAB 3 - Contributor perspective
Next generation design: A Paper UI replacement proposal
Removal of the OH 1.x Compatibility Layer
(Rolf Vermeer) #2

I couldn’t disagree more. Textual configuration lacks a lot of the new and nice features. Think of discovery of devices, think of automatic channel linking, think of searching through/filtering items, and so on.
Also you would increase the boundary for new users that have less affinity for doing things in code.

Next to that, you can already do everything with textual configuration if that is your preferred way, so why the need to make that the general preferred way?


(Vincent Regaud) #3

And I strongly advocate the other way around.

(I personally use the GUI for all my Things. Easier and (almost error free) So what if there are plenty of them. I only need to do it once)

Default is GUI. It would modify the config file (yaml. json or whatever)
Advanced users have the option of using text based config.

If the default is text based, newbies will turn away and we want more users not just keep the existing ones.


(Udo Hartmann) #4

This would be a nice solution, but a straight solution would be JSON as openHAB does already use JSON…

In fact, if a device is supported by autodiscovery, a GUI is much simpler than a text file, but e.g. for knx, one has to type all parameters to different input boxes, that’s disgusting. It’s way more efficient and easier to type a simple line in a text file and duplicate it, then change some parts of it. In fact, all of my configuration is more or less copy&paste, as there are only small differences from item to item (or channel to channel) .


(Alex) #5

Here is a little poll, maybe this helps to find a decision?

Question: How should the configuration be done in future?

  • GUI only
  • Textual only
  • Both (GUI and Text)

0 voters


(Sebastian) #6

That is not true. e.g. manual configuration of Z-Wave things does not allow setting of parameters.

That is what I am suggesting - that the gui is a frontend for readable configuration files.
Currently this is not possible.

Exactly!

I definitely see the need for auto-discovery and other nice features but why not have these just (pre-)create the configuration files. This way we could have the best of both worlds.


(Jerome Luckenbach) #7

One point i remember from other discussions was the ability to have group/mass edit functionality via UI too.
Copy & Paste works flawlessly most of the times, that’s right.

If a future UI could handle several items/things parallel that would be a huge improvement.


(Stefaan Bolle) #8

I still use 1.x bindings due to the hardware support of my lights system. Therefor I need to use text files. However, a GUI based config would be preferred if all can be done via the GUI.


(Rolf Vermeer) #9

No: you cannot set parameters in the .things files. You can set them via REST API calls though.


(Sebastian) #10

No - these api calls get ignored because it’s manually configured.

Received HTTP PUT request for update configuration at 'things/zwave:philio_pst02a_00_000:controller:node35/config' for an unmanaged thing 'zwave:philio_pst02a_00_000:controller:node35'

(Vincent Regaud) #11

GUI: +1


(Rich Koshak) #12

To avoid rehashing a lot of discussion that has already taken place, please review the following thread as well as this one. Most of this has already been hashed out.

The tl;dr is:

  • there needs to be a migration path for users to move from GUI based to text based
  • this requires changing the format of .items and .things (eventually .rules) files because there is no library to write out files in their current formats
  • there needs to be “one source of truth” for the configs (we now have two)
  • the UIs need significant improvements to make create/copy/edit/paste of stuff through the UIs more closely approach the ease of doing so in text config files

It think the consensus from that thread was there would some sort of import/export tool that can be used to read in files of some standard format on request (not file system polling) and create the necessary entries in the JSONDB (one source of truth) and a way to export from the JSONDB back to files of some standard format.

There was talk of being potentially being able to support multiple file formats with an approach like this.

And the UI improvements need to be made regardless.

This was my understanding. I could be mistaken.


(Hailo Thanks) #13

HI, I’m a new user.
I’m playing with Openhab a couple of weeks now
Configuration through GUI or config files are both OK
The most difficult thing I found is ZWave configuration. I guess it has to do with the protocol itself
So many time, I gave up
I’m using the Aeon Z-Stick GEN5 and a couple of fibaro zwave and danfoss devices
I spent a lof time reading here and there and still struggling
I like the product and I guess that explains why I’m still here
I hope this newbie view can help


(Rich Koshak) #14

If you haven’t already post a new thread to ask for help. In my experience, when using automatic discovery of Things the zwave binding is one of the easiest to set up and use. Pair the device to your controller, look in the inbox to see all your nodes. Accept the Things. If they are battery powered wake them up (sometimes a few times) until they are recognized. Then link Items to Channels.


(Hailo Thanks) #15

My mistake, the zwave discovery is working perfectly well
Devices are quickly discovered and added as things
The only matter is “Unknown Device”


(David Graeff) #16

I will release my Paper-UI new generation (NG) design study tonight.
Something to play around with over the weekend.

It is so much easier to discuss where we want to go with something to talk about as a start.

Cheers, David


(Mark) #17

Start a new post (tag it with zwave) with some specifics on the devices that are causing you trouble. We’ll help you get it sorted out.

Also read here about the device database.
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide

And here to learn what to do when things don’t go as planned.


(Hans-Jörg Merk) #18

Did you publish your design study?


(Hakan Tandogan) #19

Could an Admin move that discussion into this Category? “Development” seems more appropriate now, maybe even “Development” -> “Core” ? @Kai ?


(Vincent Regaud) #20

Done