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.