Not to make this worse, I’m still hanging on to OpenHAB despite my friends getting frustrated with some issues. The worst OH experiences for me are the breaking changes on upgrades. I converted a few people from Smart Things over to OH2 and they gave up after upgrading to new dot releases only to find that things didn’t work. My answer to this is the same, as @s0170071: I don’t upgrade very often since my current OH2 system works. I have ignored OH2.5 and have built a new hardware setup that I’m going to load with OH3 to get working. Other than the pain of upgrading, OH just works once you get it to the state that you want. I rarely, if ever have to restart my RaspPi and hope I have the same stability with OH3. 
3 Likes
At least 18 months ago over at Home Assistant breakage would often occur with each release. They released every 3 weeks with sometimes patch releases the same day to fix major breakage. I know they are more newbie friendly now, but still suspect a lot of breakage. Many people there stay back on ancient versions for stability.
Any particular reason why it took you forever to migrate?
In order to change something, someone need to analyze whats the cause. Thats why I ask.
1 Like
Let me clarify a bit. I really like OpenHAB and the fact that it is open-source. That is why I have resisted other solutions such as closed-source Hubitat. I’ve been burned too many times by abondon-ware or changing terms of use. I also have developed software/hardware for decades so I have productization experience. If I had just 1 suggestion that may reduce frustration with users that are not tracking every change it would be: Have a better configuration migration strategy from deprecated configs (plugins, OH base, etc). This is what I really meant when I mentioned breaking changes. I have been bitten by MQTT changes and some others. I figured it out after finding the right post for the right dot release. Many people wouldn’t be as persistent. A configuration migration strategy isn’t always trivial or the highest priority with volunteers putting in their time to make this project great. It takes a while to get a configuration the way you want it if you are doing non-trivial behavior and including a large mix of technologies so a breakage in config can be quite discouraging. My $0.02 on that.
Knock on wood, I have not seen any major reliability issues on OH and I’m not interested in HA as I’m more of a Java person than a Python person.
1 Like
i really know what you mean. the biggest problem with OH is stability and lack of support for previous versions. for examples, i am happy with how 2.5 works and would expect for it to become LTS version (similarly to Ubuntu releases) and would expect addons to be frequently updated for it. right now what we get, is that with each new major version, addons structure is changed and they are mostly incompatible with the older version of the openhab, so you get yourself into an update loop - if you want to get new addons - you need to update openhab.
PS: Please, I do not want to start a discussion, that all of us work for free and be happy with what you get - so please keep this to yourself.
That is close to my current main gripe. IMO OH developers to not value the user experience, especially the new or inexperienced user experience, as much as they should. That is my personal opinion.
There are some really conscientious, skilled developers who are definitely user-focused but many of the developers controlling the features & release get too wrapped up in the details to focus on the user.
Currently, the main reason I am still here is because of the user-focused developers and a hope that now ESH is history, there can be a more user-friendly fork of OH.
I have not seen any major reliability issues on OH and I’m not interested in HA as I’m more of a Java person than a Python person.
Fair enough, I worked on Sun equipment when Java was released and have nor got involved with it because I view it as a resource-hungry system designed for OS compatibility. More recently I have had to learn Python. I may end up looking closer at more modern Java.
1 Like
Here’s how you would define a new generic thing based on MQTT topics:
You can just go to the Code tab and let the autocompletion drive you; I have invested a lot in this.
12 Likes
Thanks for asking.
Like I said, debugging OH is just a nightmare. And at least for MQTT differentiating between things and items it does not make any sense.
1 Like
@ysc Didn’t recognised the code tab yet. That is nice, but now we have three way to define a thing: The Ui, The yaml in the ui and the plain text files. This is from my point of view a little over done and confuses newbies. On the other hand the is no was to setup up transformations line *.map files from the ui. There we are still with test files.
Nevertheless great work so far, but i really appreciate the work. By the way i decided to move back to test files, beacuse mass editing or copying or templting dore not work in UI
1 Like
OH was designed to be flexible where that makes more sense. for instance, Z-Wave Things have many channels and usually only a few are interesting enough to create Items.
1 Like
Very impressive - this is a massive update.
Thats what worried me in your original post.
I use things and items file. I find it very obvious how they´re created and dependable on eachother.
On the other hand, for MQTT (and modbus), I simply dont get it when using PaperUI. I´m totally lost and tend to give up very fast, mainly because I see the exact same problem like you. But thats when I use PaperUI. Some might say this is a matter of working with it. But I see it quite different. Going from seperate config files like things and items to PaperUI, its like starting all over with a totally new principal. I simply havnt got the patient for something like that.
I somehow wish there would be a more obvious or simular way between those to options. Maybe its just the design of PaperUI which need to be reworked.
Anyway - If thats your issue, sometimes it might be worth looking at it from the other side (ie insted o using PaperUI use things/items files or visa versa).
3 yrs old but still valid (even more so today) :
1 Like
Oh yes, it does, because thing (channel) and item are two completely independent objects. The former is a hardware abstraction, the latter is part of the openHAB bus.
Please keep in mind, that it’s possible to link more than one channel to one item (and it’s possible to link more than one item to one channel, too). In combination with profiles this is a very powerful way to link hardware without the need of rules. And thanks to the thing model it’s absolutely hardware independent.
can you give an example, please?
Sure
DateTime Buszeit "Zeit und Tag" {channel="knx:device:bridge:Virtuell:wochenzeit",channel="ntp:ntp:home:dateTime"}
This item links the ntp time to my knx bus. this would also work for mqtt 
but I don’t have a mqtt clock yet 
I tend to agree with the Op… And trying to read the help sections is a nightmare, multiple links to other information and sometimes the instructions don’t work with different user results to those documented.
I set up OH1.1 a few years back and thought that was that for my home automation… It was a huge and steep learning curve for not only the device setup and Tasmota installations, but getting things to work in OH…then I went away and made use of the home automation for a while. During that time things changed and “improvements” to OH were made…only anyone not heavily reading the forum would have known. Then thinking that a simple upgrade would be a good thing, certainly not expecting nothing to work afterwards was a huge shock. It caused days worth of time and lose of sleep.
Summary: OH is not for beginners and novices or people that just want the system to work “out of the box”. Too many of the forum members, although helpful have that “we will make you think about it before giving easy step solutions”. Sometimes marriages depend on something faster
Another example of poor documentation is for “secure access” to the OH server, preventing unsecured access to my Raspberry Pi…note I can’t even access it remotely and have up after trying to sort it 3 out 4 times.
So not to belittle all the hours of dedication and time spent by the creators and developers, you did a good job and clearly the majority of forum members are able to fully utilise its benefits…the rest of us just fall by the wayside and shuffle off to another platform.
1 Like
That is why there are paid solutions available. Volunteers are not beholden to maintain your system,. If we give a complete solution we are committing to supporting it on your system.
Thanx Bruce,
You simply reconfirm my statements above. No I don’t expect you to maintain my system, but I also don’t expect you to f with it on upgrade or at the very least to place a warning on the upgrading process so that I know nothing will work after the update.
I can appreciate there are many of these types of user’s which is why there is more than one platform. I think openHAB need more user’s like you helping out editing the help sections and writing beginner tutorials.
It is extremely hard to unlearn something and some users start with a binding that someone has written with hardly any documentation assuming this is not your first one. I think its mainly a UI problem that OH3 may fix with the help of beginners giving specific feedback.
This can’t be further from the truth. I will give the support I want to and feel no obligation to support their system any further. Some Maintainers may feel obligated to JUMP to action when there is a issue witch may not be expected as tone is never conveyed well over text.
It really depends on you, I am a person that receives a text message for work “everything is burning” and have a shower before heading in. I tell everyone at work if you break something tell me because there is nothing you can break that I can’t fix and it only pisses me off if I find out the hard way.