Why I can't currently recommend openHAB to my neighbours and even don't know how to contribute to change this

Tags: #<Tag:0x00007f2fbb7e64f8> #<Tag:0x00007f2fbb7e6340>

Let me give you a bit of background:
I have started powering my smart home with z-wave components some years ago.
But I always just used basic functionality to have some smart lighting and be able to measure energy consumption and trigger some devices remote.
Nothing fancy because I never wanted to invest a lot of time in it as a hobby.

And as I had to work on java backend code as part of my dayjob I really never wanted to continue it in my spare time. Still I had a look into openHAB 1 a few years ago and decided it begin to technical for my demand.

My last controller was a zway which really had performance issues with the hue binding, since I abandoned my z-wave only attempt for colorful lights some time ago.

Looking for a new controller I revisited openHAB - now in version 2. And the currently presented screenshots of PaperUI looked clean and totally fit to my demands.

So I switched all my devices (around 50 z-wave things) and was happy with the control view.
Trying to recreate my simple DoorOpen/Movement->Light rules I first realised, that I will have to fiddle with textfile configurations anyway.
But the options looked promising and the syntax looked easy enough to be used by my neighbours.
They have been mentioned in the topic and they play around with smart home components too. But being much less tech experienced they struggle a lot and one of them has his components still uninstalled in a box since he moved in.

From the first impression of PaperUI I thought I might be able to recommend openHAB and help them with the more technical issues.

But I won’t at the moment. I have been down the rabbit hole of all the wild complexities openHAB has developed over time.

And I am not even having any issues with old 1.x addons.

It is just, that the PaperUI auto-items (which I liked in theory) are not usable for sitemaps and rules.
They can be used in rules technically, but the names of the items are so cryptic and can’t even be copy&pasted easily.
Room/Group is by thing not by item, so the integrated control does not work.
I downgraded to Habmin but items can still not be added to groups in the webui - or at least I haven’t learned how. (I even reinstalled on a new pi with the openhabian to exclude issues with my previous setup.)

So I built an Excel file to create my items and be able to easily reconfigure them without manually changing in the .items

All this already excluded my neighbours. No way I could suggest or even recommend the text configuration.
But I decided to not give up as I always liked java as a server and the fundamental principles.
I wanted to invest some time to contribute to get to a version I could recommend.

So I learned about some of the big issues from the past and the even bigger challenges for a version 3. Nowhere I found some consolidating guidelines or roadmap or a mission statement for the next step. The topics discussing this issues like backwards compatibility of upcoming UI or replacing configuration text formats all seem to end in disagreement.

In one thread I read something like: If we address the 90% of the questions, some other 90% of questions will arise like it is a Sysiphusian struggle. Well no, because it may still be 90% the same stupid questions but from a much larger user base, because the software is more approachable.

But without some kind of common understanding it is hard to see a point where small contributions would help.
So I am stuck with my planned effort. “Luckily” I spend so much time learning that this is the state of the project, that my allocated time budget for the upcoming weeks is somewhat drained anyways.

My first try to contribute was already discouraged a bit. I realized an - from my perspective obvious - log spamming and raised an issue:

I learned, that this is a default behaviour and most likely more bindings with high frequent events will suffer the same issue. But 2 out of three comments do not even see a problem when 1h listening to your smart music creates 3.6k log lines by default.

I can assure you, my neighbours would not want to learn the hard way that the log settings must be changed for a production server. (They would not even think of any other usecase as production.)

But should I have raised a new issue in the core? I actually wanted to change that myself, but from that first reactions I would have to face a lot of new discussions when arguing for a different default setting.

So finally I have reached a point where I actually do not know how I might be possible to make an effective contribution with a planned investment of 4 to 8h a week.

2 Likes

My understanding is that the PaperUI is currently mot maintainable and us recommended only for configuration. HABmin is still the recommendation for Z-Wave configuration though. People are using the Basic UI for day to day usage.
Between 2.5 M1 & 2.5M1 there were may major changes. First, it was decided to abandon the Eclipse Smart Home development and to integrate it into OpenHAB. Around the same time, it was decided to totally revamp the build system for OpenHAB. 2.5M2 has not been released with all those changes.
Plans for 3.0 include a new default UI and removing the v1 compatibility layer so OH can move from Java 8 to 11.
If you have some spare time where you would want to help with the Java backend, Chris is having issues getting the Z-Wave binding to compile well in the new development environment. Zigbee & Z-Wave binding development are on hold until this gets resolved.

@blilleike thanks for your post.

I understand your frustration as I tried to contribute a couple years ago to docs and got a similar response. I did stick it out and I am here today to say openhab is a great product.

I ask give it this thought. It is “not thy neighbors tool…”

I say this as I love openhab, but I do struggle how to convince the untechnical neighbors to use it. What I realized is they won’t! In fact they probably won’t use hubitat, smart things, or home assistant either, why?
Well cause it’s all too much work.

We on this forum are a unique breed. I encourage you to give openhab a try with an open mind. In the end once you get your head wrapped around it all you will fall in love.

If not, then there are other products out there have a look at the three I mentioned.

Either way, Thanks for expressing your opinion and thanks for your contributions!

1 Like

This is an open source project. There is no such streamlined agreed-opon single next step. It’s whatever contributors are willing to contribute.
Other than that, see https://www.openhab.org/about/contributing.html and what this links to.

Technically, from an advanced OH user’s perspective, I share the responder’s view. It’s eventually annoying but not a problem. Several means available to work around. Logs get rotated. And any non-technical neighbour would not even look at the logs - so what.

But I’m hearing your point (I think).
You unfortunately approached openHAB from a let’s say very narrow-angle corridor (squeezebox).
First, this is a bit of an edge case. Few people to use squeezebox with a smart home context, and it’s just one binding out of ~350. And it does the job although playing music is just a tiny fraction of what openHAB can do and what people use it for in their smarthomes.
And unlike most “competition”, openHAB is not a vendor and is not targeting point&click newbies in the first place. Well we aim to get there long term but as we want to keep the huge amount of functionality and flexibility we have - which is the main reason for people to start using openHAB -, making it “simple” to use is a task close to impossibility as your little example with autogenerated item names shows. If that’s what your or your neighbour’s primary expectation is then you would be better off with one of the commercial products to have a fancy UI but way less flexibility.

I hope you get to see that your impression is just a fraction of the picture others have (BTW a number of core developer have responded to your request) why this is not log spamming and therefore does not justify changing the openHAB core (which would have vast dependencies & effects you cannot even oversee as a non-core contributor).
So opening another issue there would likely have discouraged you even more.

I understand it can be frustrating but don’t take it personal. My own and probably most of today’s contributor’s experiences were more or less the same.

But this does not mean we do not appreciate your contribution. Keep hanging on, please.
Thanks for using openHAB and your willingness to give back.

5 Likes

@mstormi
No, you totally misunderstood my point.
I have very deliberately decided to stick a bit longer to openHAB even knowing that it demands jumping into development to get it to a point I could recommend it to my neighbours.
So I chose to focus on what would contribute to that.

The squeezebox logging issue is only a tiny example how the project is not thought from an possible common end users point of view. If they don’t typically even look into the logs, why flooding them with thousands of entries per binding as a default. Even a default, that can not be circumvented by a binding developer who has a highly responsive thing to implement because it is a core functionality.
Just set LogLevel to warning as a default so you actually can find an error in it if something bad happens.
It is a small thing to expect from an advanced user to decrease the log-level for more advanced stuff then to expect a casual user to understand log levels at all.
I haven’t read any argument, why it has to be this way. Mostly workarounds and descriptions how to change it in a single installation.

If there would be a common understanding, that it is a common goal to encourage non-technical users to use openHAB then there wouldn’t be a different discussion about this.

Which brings me back to my second point: The work in progress is intransparent.
You linked the Contribute page. This links to the developer page. Latest here could be a section to explain what is the medium term goal and what core parts are worked on.
So it is easier to understand, what kind of contribution is most valuable.

Well, I would have started working on changing something like these better auto naming - if I had not learned by digging through the forum, that a new UI is in work. Which is - as far as I understood - not part of the official repositories yet so contributions to it are not possible.

My main reason to go through all this trouble is, that I won’t surrender home automation to cloud and big corporations without an alternative. But an alternative, that is not available for point&click newbies, is no real alternative.

With all the existing complexity in place, making the access easier should really be a main goal. Without sacrificing functionality and I understand this is a big issue at the moment.
And making it easier to help on this goal should be made easier.
I am willing to help on that, if it is seen as a first useful step. But I don’t see me in the position to take that hat and lead on it on my own.

then why not ? Same argument the other way.

A lot of your statements are pretty subjective that even I - being a user, not a developer - wouldn’t agree to. And most of it you cannot understand without knowing the architecture and core on code level. It’s only to a lesser degree where to go. It’s more the question how to get there best as we do not start from scratch.

Oh no, there would be. A common goal and to agree on a common path that also works is very different things. Even more so in an open source project that is as flexible and complex as is openHAB and only staffed by volunteers that each and everybody for himself decides what he wants to work on.

I agree for the most part but that’s in part due to the nature of open source. And it isn’t what the forum is for. Most of core development discussion takes place on GitHub.

I wasn’t going to respond to yet another “openHAB is too complex” post. I’ve said it all on the many many similar posts. But there are a few things here that warrant a response because there are solutions to some of the problems you site.

I freaking hate the Control view in PaperUI. It looks like something useful but it is not and never was intended to be. It’s strictly useful for administration and situational awareness. You still need to create your own UI presentation for day-to-day use, either by defining a sitemap (text based configs) or HABPanel (can build everything in the browser) or HABot which is more like a smart chat bot, no real configuration necessary.

Given the current state of OH 2.x, you will have to use some text based configs. But it’s getting better.

You can (and I recommend) define all Things in PaperUI or the REST API.

You can define all your Items through PaperUI or the REST API but only if you are not using openHAB 1 bindings and even then there are some features that can only be managed through the REST API. So most users have to use .items files.

There is some very primitive support for defining Rules through PaperUI if you install the Experimental Rules Engine, but you still have to work with code. For anything complex though, you will need to be writing code in text files.

For sitemaps the only choice is text files, but as I mentioned above, there are other options like HABPanel.

For persistence, the only choice is text files.

For openHAB 1 add-ons the only choice is text files.

I hate this even more than I hate the Control tab, for exactly the same reasons you site. It’s a half solution to a problem that I personally don’t think should even be solved. It’s worse than useless because it causes so much confusion and rework for so many users.

HABmin hasn’t really been maintained over the years. It’s still great for zwave and zigbee administration (e.g. for setting configuration parameters on a zwave device, looking at the zwave network, etc) but large parts of it have not been upgraded or maintained (e.g. the Rule builder only builds OH 1.x compatible Rules).

The real solution to this problem is to turn off Simple Mode and manually define your Items, either through PaperUI or in .items files. Just don’t mess with Simple Mode.

This seems excessive. Just turn off Simple Mode and create your Items in PaperUI. You can name them anything you want to (choose something meaningful), create Groups, and all that, but only when Simple Mode is turned off.

Home automation is hard. It is inherently complex and technical. If your neighbors will be scared off by editing config files, then I don’t think openHAB will ever be for them even when some of these problems are addressed (NOTE: everything mentioned is actively being worked, there is nothing new here).

As mentioned by others, openHAB is an open source project that isn’t structured in that way. It’s entirely volunteer effort and the volunteers only work on what they choose to work on. Furthermore, there are different groups of maintainers that are “in charge” of different parts of OH so even if there were the ability to create a roadmap, there would be roadmaps, not just one.

Honestly, ignore those threads. For the most part developers were not the ones contributing to those threads anyway. If you want to see where openHAB is going and what the maintainers think are important and are working on, look at the Issues in the repos. Those are the discussions that actually matter since those drive the actual work.

Believe it or not, that is a goal. Personally, I don’t think it will ever be approachable enough for your neighbors because, as I said before, home automation is hard. Glossy web based UIs and point and click wizards can only address so much of that complexity.

Small contributions always help. And it’s through the small contributions that you gain a reputation with the maintainers and through that you gain more trust and perhaps become a maintainer yourself.

Unfortunately, I think your issue stems more from a misunderstanding of what the events.log is for. That is a log of the Event Bus. All Item commands, updates, Thing status changes, and with the NGRE Rule events (idle, running, completed) events get logged to that file. That’s what it’s for. You can’t just change ItemStateChangedEvent to DEBUG level without effecting each and every binding and potentially breaking events.log for those who rely upon it logging those state changes. The events.log is behaving exactly as designed and serving it’s purpose but logging at the INFO level all Item state changed events. It’s just that that Item changes every second while you are playing something. That doesn’t make it spamming.

There are work arounds of course, including turning off the events.log entirely. You could also file an issue with the Binding to have it not change the currentPlayingTime Item, but of course that would break that functionality of the binding.

So in short, unfortunately, the only way to fix this “log spamming” in openHAB core is to break the entire purpose of events.log in the first place, and break it not for just that one squeezbox binding but for all bindings.

Unfortunately, your lack of experience with OH and what events.log is for lead to propose a code fix that would be a breaking change.

I don’t either. If this is a problem for you and you are looking at events.log in the first place, you are a technical enough of a user to apply one of the work arounds, either filtering out that Item’s events from events.log or just shutting events.log off in the first place. A code fix can not be the solution because this log spamming is expected behavior. events.log is showing exactly what it’s designed to show, all Item changed events.

One can argue that perhaps events.log should be turned on by default. That could be a good conversation in an Issue and I think you might get more positive discussion as a result. But sadly what you proposed would break events.log so it cannot be made.

If you don’t want to use events.log for it’s purpose, to log all event bus events, then just turn it off for your production server. It’s a pretty simple setting. But honestly, your neighbors would probably remain blissfully unaware that events.log even exists. Even when there is a problem with OH, events.log is only rarely useful to consult.

And proposed change will result in a lot of arguing. That’s just how open source works. Indeed, the issue would need to be raised in the core because the binding has no control over events.log. That log is generated by the Event Bus. And, for the reasons I already outlined, this particular change would be rejected because it would be a breaking change.

There are lots of ways to make a contribution. Did you find errors or something confusing in the Docs? Please submit corrections/clarifications. Spend some time on this forum helping users with problems. Is there some other potential bug or problem encountered? Submit an issue for that (it might be worth opening a new thread here first to see if there is some reason why it is the way it is like the above, the result of a misunderstanding, etc).

This kind of statement makes me mad so if I sound heated here I apologize.

There is nothing said in a post like this that is not known.

The developers and maintainers do “give a thought” to end user’s point of view. Why do you think OH 2 even exists instead of OH 1.25? Just because the project isn’t yet a nirvana for new and non-technical users doesn’t mean we don’t give a s#%^.

Every single one of these posts have the same attitude which pisses me off. “OH is too complicated right now so the maintainers just don’t care about non-technical users and are happy with all that complexity.”

Frankly, the common end user wouldn’t be looking at events.log in the first place. Any “fix” to this behavior would break the very purpose of events.log for those of us who do use events.log. As I said above, if you want to fix this problem, open an issue to turn off events.log by default.

That stuff goes in openhab.log. All that you have described applies to openhab.log. I’ll say it again, events.log is the log of what the Event Bus is doing. Items changing state is an event placed on the event bus. Therefore it should be logged to events.log. The Event Bus is a component of openHAB that is wholly separate from the bindings. Of course binding developers should not be able to change how that component logs. The Event Bus get’s to decide what level it needs to log what statement, and Item change events are rightly logged at the INFO level.

This whole case boils down to the fact that you have a misunderstanding of the purpose for events.log is for and where it get’s logged from.

I expect the casual user to never even be aware that events.log exists. In some rare cases, when that user experiences a problem, someone on this forum or on github may ask that user to look through events.log to help understand what is happening around the time of an error (NOTE: you will never see errors in events.log) or to diagnose unexpected behavior.

But that begs the questions, is it even possible to have a casual user of any home automation system? I’m with @Thedannymullen; I say no.

Then see above. You do not understand the purpose of events.log and your proposed solution to the “spamming” problem would break it’s purpose.

That’s because, if you as an individual user knowingly decide to break the purpose of events.log for your own purposes, you should have the right and ability to do that. But only for your own setup. You don’t get to make that decision for my openHAB configuration and setup.

And as I said, this is a non-issue for the casual user because they can just remain ignorant that events.log exists. Or you can make an argument that events.log shouldn’t be turned on by default in the first place and let the more technical users turn it on themselves. That could be worth discussion, as I mentioned already.

First of all, it is a common goal to encourage non-technical users. But we are not there yet.

If you had an understanding of the purpose of events.log there would be a different discussion about this too. This sited issue has nothing to do with encouraging non-technical users. Its all the result of a misunderstanding of the purpose of events.log.

Any contribution is appreciated. But realize, the maintainers have more knowledge about what is in work, conventions, expectations, and the over all technical and policy constraints of the whole ecosystem than you do. Your Issue and PR will always be hugely appreciated, but it may not be accepted. And that’s OK. Try to understand why and take it as a learning opportunity and keep on contributing!

I don’t think that’s the case. You can contribute to any public repo whether or not it’s part of the official OH repos.

IMHO, elimination is the only solution. Items should have meaningful names that are relevant to you home automation (e.g. LivingRoom_Lamp). It’s impossible to do this through auto naming.

Then there is no real alternative in existence. Period. Not even the commercial offerings can meet that requirement.

I think @ysc posted a link to the repo where it is being developed on another thread but I can’t find it.

What makes you think it isn’t? But what constitutes “making the access easier” is open to interpretation, disagreement, and discussion.

7 Likes

A very well-written post, as usual, @rlkoshak

One thing to clarify, however. The logging to events.log of the currentPlayingTime state change event can be disabled simply by not linking that channel to an item.

1 Like

This is exactly what I was arguing for after I did understand that events.log is filled with core functionality. Maybe it was not clear enough to only change the log-configuration for this Eventtype.
I raised the issue now in core and hopefully it is clear in intention and argument now.

I would argue, that a name is given to a thing in the inbox and this name can be used as the base string of the auto generated items.
Of course the thing name has to have a unique checking - and still in edgecases an autogenerated name may already be in use and has to be overruled.
But all then is to leard are the channel names, the rest sounds familiar. And a unique Things name should be a good idea anyways.
So I would disagree, that autonames are to be eliminated.

Well, that being the point in: There is no information about what is coming in the future.
(I have not seen any project or sticked issue or issue with openHAB3 in the github. I listen, I look where told).

So should I work on documentation of tutorial when there is a v3 coming?
Should I start working into PaperUI (which would be my favourite) after learning it will be put to rest?
I have no issues with bindings and I have seen no open issues on my main components z-wave, which has been mentioned in one of the first replies.
I am willing to help there if needed, but hardware is not in my primary skillsets yet.

It is my first open source project I am willing to spend time on. So I can’t compare to other projects.
Still I started time-tracking a lot of hours into trying to understand the status quo to be able to limit and focus my time investments.

And to say that, I still have no idea how to effectively contribute.
I don’t really care what to do as long as it contributes to the (personal) goal to be able to recommend this to my neighbours.
And I know it is possible, the version 2 was a huge step in that direction.

So is there a way to contribute to version 3?

You have realised, that this does also break that functionality?
Or can you display a channel without linking it to an item?

I thought that is what Home Builder was for. To make sitemaps.

2 Likes

But it still creates text files for your sitemaps and is not capable of more complex designs.

1 Like

I thought that is what Home Builder was for. To make sitemaps.

I forget about HomeBuilder. That is actually to create sitemaps and Items. But if you don’t like what it produces or want to tweak something after the fact, you have to edit the .sitemap file by hand.

1 Like

Yes, well aware. It’s the tradeoff between the value of the functionality versus the reduction of state change events that are logged as a consequence of that functionality.

No.

It’s there in the Issues and the PRs. You won’t find it here. What’s coming in the future? Find the open PRs that are actively being worked and you will have your answer. Someone can plan as long and as detailed as they want, but in a project like this, all that gets done is what some developer volunteers to implement. Some important issues remain open for years (e.g. built in authentication). Others get written and merged in days or weeks.

OH v3 is at least six months, probably a year away. And there will be tons of overlap. Working on the tutorial would not be wasted effort.

Probably not since you know it is going away. But you can work on it’s replacement.

One big need is for developers to help reimplement OH 1.x bindings as 2.x versions as there is talk of dropping the compatibility layer in OH 3.

With any open source project, I think starting small and building a reputation and experience is the way to go.

I don’t know if there has been a 3.0 branch created anywhere yet. So contributing to 2.5 would be contributing towards 3.0.

I always get some popcorn and watch people wasting their time :bomb:

4 Likes