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.
1 Like
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.
It’s not that simple, read on here:
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.
1 Like
You mean they need to VOLUNTEER?? That is more work than complaining… 
Thank you, very useful link.
And that was in opinion the biggest mistake ever… Will be a long way to get rid of that eclipse stuff.
That is where the Paper UI cane from, I believe. Now none of our developers can properly support it. We are basically stuck with it until OH3.
Well, don’t forget this OSGi stuff and Apache karaf build on top of it. I personally don’t liked it (OSGi) in WSO2 and I don’t like it in OpenHAB either. However, that’s an architectural design decision someone made in the past…
1 Like
Maybe, because not everything possible with the REST API needs to be exploited in the UI?
Yes, I did. And that my point:
For defining “things” PaperUI or HABmin is recommended ===> JSONDB
For defining “items” the textual configuration is recommended ===> classical text files
Example and solutions provided by the community ===> classical text files
The only reason I see NOT using the text files i ZWave. So why not fixing this and ditch those JSONDB files?
WTF: How could you come up with such a claim?
Well you have been and still are exposing quite some misunderstandings of OH (such as comparing the function of JSONDB with that of classical files) that I thought would have been cleared up if you had read that. Sorry for assuming and claiming that, you obviously did.
1 Like
Yeah, well, I read this one https://www.openhab.org/docs/administration/jsondb.html as well as this one https://www.openhab.org/docs/configuration/#textual-vs-graphical-configuration.
Don’t know what to missunderstand here:
Things and Items can either be defined and managed in configuration files or handled by Paper UI in a system-side database
JsonDB provides a system database for storage of configuration data.
That’s because it’s not yet possible to do everything through the REST API. You can’t “cut the strings” until you have a replacement. And there is a very good argument to be made in not pissing off your users by forcing them to do a lot of extra work.
Shall we scrub all the stuff that has been posted for the many years that the forum has existed?
As for the documentation, both approaches are documented and if not, please tell us so we can fix that.
This too is in work to be addressed. For example, the new UI that will replace PaperUI already has the ability for you to paste in an Item definition from a .items file, or forum posting or where ever, and it will import it into the JSONDB. For certain things like Rules this will not be possible. But for Rules we will be moving towards Rules becoming something you install and configure like a binding rather than something you have to copy/paste/edit from examples.
The Design Patterns are being updated as time allows to include alternative approaches. But realize that more than half of those design pattern posts were written before there was an OH 2. And as Markus points out, the UI for building Rules isn’t very usable right now and will be completely replaced for OH 3 so there is no point in showing that approach right now. One thing you would notice is for many of the DPs, where it makes sense, a library was created in Jython which, once reviewed and merged with the Helper Libraries, means you don’t even need to look a the code. You just “install” the code and use use it.
I can imagine no way that will ever happen. The licence of the source code requires it to be open and the openHAB Foundation is established as a certain type of non-profit in Germany that precludes the selling of software or services by the foundation.
Bruce’s point is that both HABmin and PaperUI interact with the same REST API end points and therefore activate the same code. So how can one work differently from the other if they are using the same code?
You cannot use automatic discovery of devices with text based configs. Zwave is not the only binding to use automatic discovery. In fact only a tiny minority of bindings don’t use automatic discovery. Even bindings like Astro and OpenWeatherMap use automatic discovery and creation of Things.
And this is because PaperUI doesn’t support everything necessary one needs to configure on a Thing. In particular, you can’t add tags nor metadata to Items through PaperUI. And we won’t be able to because PaperUI is basically abandonware.
As soon as the PaperUI replacement is done, I will personally go through the docs and change that recommendation. In fact, I and others (Confectarian is already starting some of the work) will likely do a complete rewrite of the docs to put the new UI as the first/default approach with the text configs as “and you can also use text files.”
It would be too much work and hugely destructive to go through the forum and remove all the old legacy stuff so that’s never going to happen. And that’s OK because the new UI will let you import the text based configs where possible. Perhaps there will even be an export possibility too, though it likely will need to be some other format as there is no writer for the custom format created for .items files and .things files.
1 Like
Good to know.
I think the main problem stems from the fact that the OH team (whatever that means, I haven’t really delved into the project’s management specifics) hasn’t made clear what they want OH to be or to become. I don’t know if they know it and haven’t communicated it correctly, or they just don’t know themselves, or they just can’t agree due to a lack of leadership.
Do they want OH to be a fun/hobby project that covers their own needs and those of a small community of developers?
Or do they want OH to become the de facto standard for open source home automation?
Both options are equally valid, there’s no right and wrong answer. But they do have implications.
For example, if the second option is the goal, attitudes and statements like those from @mstormi are downright unacceptable.
Have you ever considered how many users OH is losing, for each user that gets into the trouble of signing up to the forums and posting a “complaint”? Let me tell you that it’s A LOT. And, instead of trying to figure out what’s leading to those complaints (regardless of whether these specific users are expressing them correctly or not, are polite or not, are hurting your feelings or not etc.) so that we can keep not only those users but also the ones we never hear from, we’re telling them “you’re doing it wrong” (this can take many forms, i.e. “you haven’t read the docs correctly”, “you don’t know which UI to use” etc.) or “that’s just the way it is” (due to historical reasons or whatever).
Of course, if the goal is the first option, then that’s fine. And in that sense, maybe OH is just the victim of its own success. Maybe it was never intended to be the second one, but because it’s featured and suggested in a lot of articles regarding home automation, people come here expecting to find something different. Still, I don’t think it’s hard to let these users know what they’re dealing with and steer them away from OH, either through the homepage, or the doc’s introduction etc.
But again, if we want OH to become a proper mainstream solution, we need to move away from amateur(ish) handling of such issues and take examples from professional projects. Do you think that any professional team would post these kinds of responses to user feedback (yes, complaints are feedback)? Digital companies/products/projects are DYING to get user feedback and go into great lengths and costs to acquire it (market research, surveys etc.) and analyze it in order to gain actionable insight. And here it’s offered freely but is mostly dismissed.
Of course, not all people here share this attitude. For example, @rlkoshak is always helpful and constructive and I feel the need to mention it and thank him for that. But unfortunately, this isn’t enough.
Come to think of it, maybe the main problem may be indeed a lack of leadership. There needs to be someone setting the tone and setting the course, sometimes making hard decisions that will definitely alienate some (maybe long-term) users but will help the project meet its goals in the long run. From what I’ve experienced with OH, this doesn’t exist.
The above is not to demean what OH has achieved. I, for one, use it for two years now and I thank everyone that made it possible. And, for what it’s worth, I’ve never complained even though I’ve been frustrated a lot of times. This is because I understand the project’s difficulty and intricacies, I understand the devs’ point of view and I understand what it means to be an open source vs commercial project. But the reason I understand the above is because I’m a developer myself. As it happens though, I’m also a marketer professionally and can therefore understand the user’s point of view. And that’s the reason for writing the above, because I feel the user’s point of view isn’t being taken into account, or at least not in the right way.
Sorry for the long post (and for coming a bit late to the party).
3 Likes
Or, they made some poor choices that did not work as planned and, rather than just abandon the project, they are working to correct those choices carefully minimizing existing user impact while planning any major breaking changes for a future version, as they have stated publicly. Why do you not believe what has been posted plainly by the project leader, @Kai ?
OpenHAB values stability and flexibility which, unfortunately introduces complexity that does not lend itself a “one size fits all” tutorial. The expect adults using this product to think for themselves and not be mindless robots.
If you want to see users frustrated, try Home Assistant. When I moved over here, I felt like I moved from the “kiddie forum” to one composed of reasonable, helpful adults.
Big corporations will never permit a cross-platform solution to become “mainstream”. When entitled people complain about strictly volunteer efforts without constructively contributing then such handling is appropriate unless you would expect them to be banned from such discussion.
Unappreciated volunteers who have some uninformed individual trash they hard work are rightfully offended.