Openhab still provides many different UI:
HABmin: well, probably still existing just because of its ZWave network rendering (even though a bit pointless)
HABPanel: recommended as “control” and “visualization” UI
PaperUI: recommended as “configuration” UI
Unfortunately, PaperUI (built on top of OH’s REST API as far as I understood) introduced even another kind of configuration: JSONDB (ot really userfriendly and quiet badly documented).
Still, the excellent design patterns and many other examples found here built up upon the definition of the former textual files.
Isn’t it more counter productive to (1) provide such a diverse landscape of UIs and to (2) promote the “new” kind of configuration, while (3) provide a lot of good examples using the older text files?
Isn’t it about time to rethink the whole UI strategy of Openhab?
My motivation is: What’s the point in forcing the “first” configuration steps to be done within a UI (PaperUI), just to have to use the textual configuration, anyway (e.g. rules, maps, …)?
Well there’s a number of reasons why OH is like that today. There have been many lengthy discussions on this. It probably is going to be more streamlined with version 3, but that’s quite some time off.
For the time being, check out the docs.
Well, … this is ONE pattern. Not THE pattern. And the kind of seperation of “control” and “view” you’re talking about is probably not the issue I’m talking about.
And by the way, it would probably be better to have just ONE UI and seperate administration and daily usage by authorization.
I’m not going to address the specifics here. I think they have already been handled. But I am going to address what seems to be a common false assumption common to every one if these types of posts. That assumption is that the current state of OH was deliberately designed and implemented to be just like it is today.
Do you really think the developers thought one day “you know what, let’s have half a dozen UIs and two completely incompatible ways to configure everything.” No, of course not! That’s rediculous.
What is the case is we have a decades old project wholly supported by volunteer effort. Different parts of the system advance at different rates. So you are perpetually seeing a project in a state of transition. The transition is in general away from text based configs as the default towards UI based configs as the default. But
we got burned by PaperUI (contributed by an organization that had stopped supporting it and it is based on a framework those developers who are left don’t know). And not everything is implemented yet to make it possible to do everything through the REST API (JSONDB had nothing to do with PaperUI, configuration made through any UI it the Karaf console get saved there). But it’s all being worked on as developers volunteer to work on each issue in turn. A unified UI to replace PaperUI and ClassicUI/BasicUI is in progress. The next gen rules engine is undergoing lots of work too. There are issues open to REST enable the remaining stuff that cannot be implemented that way yet.
I never wrote or assumed that. However, it’s an architectural design decision to either cut the strings to legacy parts or to keep them alive. The OpenHAB architectural lead decided to keep them. That’s ok. However, we have now a mixture of both configurations. And the documentation and the forum is filled mostly with the legacy based example.
And that’s more or less my point here. It’s also an architectural design decision to use JSONDB as a persistance layer for Karaf (I guess it’s easier). But for users, like me, already having based it’s setup on JSONDB have a hard time to transform the textual examples given here and in the documentation.
And yes, OH is built by volunteers. But lead by an architectural lead keeping the project on track. And that lead made decisions about OH1 and the transision to OH2, maybe not so wise ones in keeping old horses alive…
Sorry for getting straight to the point here but then you complicated life yourself because you made a substantial mistake yourself in using (or considering) JSONDB as a UI.
JSONDB was never meant to, recommended to or documented to be a UI and not is meant to be accessed by users. It’s a purely internally used storage mechanism.
This apparently lead to a somewhat wrong picture of yours on the whole of OH architecture and you should get that right before pushing for a direction.
Effectively, there’s an older (v1) UI, files. And a GUI added in v2, PaperUI that is.
But you have not read enough on OH architecture. You have not even clicked on the link in my previous post where this is explained (a little).
While you have a point there and we all agree that the current side-by-side implementation (rather than one to integrate both of these) is an unfortunate design we ended up in, file based input is not legacy.
Single people deep into a GUI replacement have called this legacy but that it is not.
The format may or may not change, but text will continue to be a main means of input.
Not sure but you’re possibly also mixing config data with rules in your statement. As there’s no (working, usable) GUI available for rules, everything about rules on the forum is text. That’s not legacy either but the current programming interface.
Just think how forum posts would need to look like if we removed all “legacy” and everybody had to describe an all-GUI config or procedure … there’s a (fortunately smallish) number of such posts. Although it probably took the user hours to create his post with all those screenshots, at least I quickly give up reading after scrolling through a couple of those.
Wow, I never said I hack JSONDB file by hand (Jesus Christ, no!!!). And yes, I read the documentation and studied the architecture, thanks. All I did was to add my stuff (mostly ZWave and 433) with the help of PaperUI (as recommended in the docs). Thus, all that stuff ended up in those JSONDB files.
However, when reading examples like those design patterns (which I very much like) everyone’s using the “classical” way: textual configuration.
Yeah, they would refer to those unreadable JSON stuff. And I would not agree that those are just few examples. And I fully agree that those textual configuration file for items and things are far more better as used in tutorials than those messy JSON files.
Best solution in my opinion would be to ditch JSONDB and use only those classical text files.
However, I get the feeling this is not just about those many UIs anymore, but the fundamental setup of OpenHAB: classical text files versus JSONDB.
So, lets close this one and discuss it on somewhere else (maybe on Github).
I don’t think you did that well. You have not read that part of the docs even now that I linked to it.
You still didn’t get the point. JSON is NOT an input format. JSONDB is NOT a UI - PaperUI is.
Discussion was not about JSON vs classical text files but about text (as is) versus GUI or some GUI with extension to allow for import of text.
I won’t repeat that here, read up for yourself, it’s all in the forum archives.
As a brand new user trying to understand OH I am thoroughly confused about how to use the different UI’s. Although this seems to be a very flexible en truly open source application, this is not a program for non-programmers or novices to home automation. The setting up is so complex that it is only usable for a select few “techies”. There are several other products in te open source arena that have a far less learning curve than OH. I am not saying that they are better, just that they are far easier to setup and therefore seem to have more of a following with less technological savvy users.
To make it easier for new users it would be a great help if there was a clear instruction on how to add devices, configure the dashboard. Yet, the instructions currently are all over the place with a jumble of different applications and complex scripts.
After having read the docs from the start ?
Many OH beginners raise this critics in one form or another. But on asking closer, most have just been too impatient to read the docs. They started jumping around through topics before having understood the basics.
Still noone seems to have used my link in post #2 or to have read what it points to - although it’s just the pointer to one of the first chapters of the (only) official docs that ANY OH beginner should have seen and understood before posting here.
We can’t make OH simpler than home automation ultimately is at this level of functionality and flexibility - we can only improve documentation.
Let us know where exactly and how we would need to change it for you to understand.
No, the recommendation for Z-Wave is HABmin, not the Paper UI, although they both work. That is documented in the (apparently unread) table here. Configuration | openHAB
Use Paper UI to setup and maintain the openHAB base system. Use it to define which addons and bindings you want to install and to assign basic, static configuration (such as the device name of a ZWave stick or the IP address of a KNX gateway).
and further on:
Use Paper UI or habmin to manage ZWave things, but use configuration files to manage ZWave items.
And interesting enough is that some configurations of my zwave devices work better when done with PaperUI, some work better with HABmin.
Hi and welcome. That’s my point: The whole configuration thingy is quiet diverse. There’s a lot documentation about the architecture and the different recommended UIs to use, depending on what you want to achieve.
However, and OH is not unique in this, I miss the goal and end user perspective in it: What is it OH wants to achieve for the ordinary end user? It’s well engineered in many parts, but that’s about it. From the UX perspective its quiet a mess. And that’s true for many projects driven by a tech-savvy community (I’m bad in UX as well, thus I keep myself in backend development)…
Not to perpetrate this unnecessarily, I guess that, for many of us (naive users), we expect software installation to be something similar to installing Microsoft Office i.e., few mouse clicks and you’re done. While that is certainly desirable, that feature is not yet available in openHAB and it will take a lot of effort/time to develop, due to the shear number/complexity of all available hardware options out there.
Each of us has their own ‘take/needs’ for Home Automation. You may want to switch the lights on and close the windows shades as soon as it’s sunset … but other people have very different needs.
openHAB is FREE … whereas Microsoft Office is $$$ - Can’t have your cake and eat it too… as much as you really want to.
The people developing openHAB are volunteers … should be very grateful they’re pursuing this in their spare time.
I’m not making excuses for openHAB, though maybe in few years once it’s mature enough, we’ll be asked to contribute/pay and that’s absolutely right… To setup your own openHAB, specific to your needs and available hardware, there is one price to pay: lots of time and hopefully what you get out is rewarding learning. Heck, while installing smart switches in my home, I learned yesterday that there are ‘different/novel’ ways to connect ‘runners’ for lights controlled from multiple locations. Not sure I can put a price on that.
Since both use the same REST API, that makes little sense. I find that HABmin sometimes gives more data on the state of a device.
This is the goal, while not affecting stability & flexibility. Home Assistant, for instance, prioritizes getting a user started but is not stable. Many times they need to release patyches the same day as the software release.
Yes, even after having read many documentations and forum posts including yours. I have a background in technology, so I am not a complete novice, but even so (I may be dumb) a step-to-step example of how to set up a device and how to include it in a dashboard, or even how to set up a dashboard and control items (things apparently) would be an advantage. This is clearly a project run by techies who have no conception of how a non-technical person thinks. It is a shame, as I think this product has the potential to be far better than most home automation products.
If you think it is bad now, you should have seen it a year ago. We are recovering from a failed attempt to get some corporate development help through Eclipse Smart Home.
Over the past year, from 2.4 to 2.5, the developers have combined those two projects and totally updated the development & build system.
Ooo-kay … quite a debatable POV, but ok then show us. Document your OH journey, turn it into a tutorial to be understood by “ordinary” people, we’re happy to correct/complement it and refer to/include it with the docs.
… there’s a (fortunately smallish) number of such posts. Although it probably took the user hours to create his post with all those screenshots, at least I quickly give up reading after scrolling through a couple of those.