Whining about (non)functional status of OpenHab

For me: no, I won’t.
If someone asks a specific question, fine, I try to answer.
If someone writes tens of lines with mixing content about different bindings, I even don’t read it.
If the headline mentions words like “whining” or whatever: I don’t read the content of that post.

We have a growing number of users who seems to be very knowledgable, but they keep posting hundreds of lines of text about things the can’t change (this is not targeted to @dakipro).
That’s fine. I can’t stop that.
But don’t expect me investing any of my valuable time in that.


Public venting and whining in general is useless and a waste of time (mine, ours and yours).
Even more so as developers and steering people rarely read the forum, their discussions are taking place on Github. So you’re even failing to reach your audience and thus sole purpose of the post.
Better meet with your psychologist, @rpwong or his sister :wink: if you feel you need to.

And yes, to us (OH lovers, forum supporters) this feels like an attack.

That’s not right because you are not running the stable release only. You scattered the information across various posts so I’m not sure I got it right, but you use snapshot bindings, Docker and unsupported devices or features. So by definition this is not the stable release.
Yes there can be dependencies so you may not arbitrarily combine these building blocks.
And last not least “stable” does not imply “bug-free”.
Another important point is language. You have not defined/explained what you mean by “(in)stability”. Lack of (full featured) support of devices is not instability. Incompatibility is not as it takes two to talk to each other and if they don’t understand it’s not clear who’s causing that but given the asymmetry of the situation - Ikea doesn’t care about OH integration and users, it’s merely the opposite -, it’s not fair to blame OH in the first place. Same goes for samsungtv binding.
As @matt1 proposed just drop those devices for the time being or apply the workaround.

1 Like

Just thinking out loud here, is it possible that some folks simply lose track of what release of binding they’re running and end up confused about the whole setup? (I know I’m certainly prone to this). I wonder if there were a simple script or something in the UI that could display a summary of pertinent info that OH users could copy and paste into their posts to indicate what exactly they’re running?

I believe if it were simpler to switch between snapshots/stable/dev versions it “might” make things easier. Maybe I’m talking through my arse though (known to happen)

With OpenHABian it is easy to switch BUT you are only supported switching to a newer version.

There’s so many ways, options and dependencies in running OH that any attempt to streamline this is so likely to break some installs that the attempt isn’t worth it. As some wise guy once postulated,
programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

You can switch between release, testing (milestone) and snapshots.
And you still can install any version from CLI but you have to do that manually.

I believe going backwards is not recommended though. That is why I reinstalled when I moved from a snapshot to 2.5M1.


1 Like

Problem could be to find the 5% which makes the whole system (OpenHab) unstable.
Pointing at snapshots seems to has become the standard answer. In my opinion and experiences, thats not always correct.

Most certain…
Because of the structure (core and bindings) and because some of the latest snapshots (bindings) contain features which stable doesn´t have, but may be required. I believe most users who are using newer devices and/or popular devices feel encouraged to update without even thinking about they´re going towards a greater risc for something going wrong. Maybe, like me, they hope/see/feel, if anything goes wrong, the developer is there to help fast.

I´m very possitive this is the case for alot of users.

It’s generally not recommended neither on OH nor any other SW. If data structures change there’s usually a migration path up but none down. But you can roll back, i.e. restore the old system from backups.

1 Like

In my case I had no older backups. :frowning:

You mean something like this? (grabbed from another thread).


No backup - no pity :smiling_imp:

(literal translation - I’m sure there’s a more suitable saying in English)

1 Like

I started with snapshot due to zwave support for my devices. I left when the api documentation broke (again).
I was not looking for pity anyway. Just stating fact as I understand them.

Yeah, but what I meant was a one-stop shop that would not just show the OH version but perhaps the other pertinent info too, bindings (and their versions), etc

Karaf console, info and bundle:list commands

But we’re getting off topic, please restrict your posts to on-topic

I am really struggling to understand how are we talking so much one beside another @mstormi . I gave short story, was asked for details which I provided in links, then explained it again in the longer post, but I am still failing to get the message across.

Here is the short resume:
I installed openhab around 2 years ago on stable 2.2 (or maybe 2.1, irrelevant).

  • On my first update samsung tv binding stopped working. I purchased harmony remote and “solved” the problem. All is on stable branch.
  • on the next update mqtt stopped working (reason is not important in this context). For z-wave we got info in advance that there is braking change, so that was great. This is also all on stable branch
  • Device that was supported in openhab was working unstable for me, so I was advised to install milestone branch as it fixes stability (against my will to go off the stable branch). Now each time openhab starts I must manually go in console and restart z-wave. So after each power outage none of my z-wave devices are working.
  • Then ikea binding stopped working, probably as you mentioned Ikea messed something up, fix is either on its way, or somehow only 6 of us are affected
  • few days ago myopenhab remote access stopped working. And now if I restart it, I should hope that it is “only” z-wave that needs manual handling.
  • I guess new update is due soon, based on my former experience I will be quite reserved towards updating it.

How do you not see stability and reliability issues from user point perspective, when on two updates two thing stopped working, and new fixes introduce other issues?

It could be that finding exactly right word is challenging for me as English is not my primary language, but if it is not stability issue, then is a bug, if not a bug then it is reliability, if not that then is non-functional status of openhab, if not that then it is incompatibility. We can call it however we want to, but I (and few others on this very topic) are not experiencing openhab as stable as some do, not by our choice. Thus this post.

I feel like I am being persuaded that my system is actually working fine entire time, because it is working for majority of the users here.

5% of my system might be this one sensor, but since it has temperature and luminosity, it is actually controlling my lights in the house and also winwods shades (thus temperature). So that is pretty much my entire system. And since lights do not work already, pretty much 95% of my system is unusable, only thing working is some xiaomi sensors.

Btw, what was point with mentioning psychologyst or @rpwong sister? I will take this as a internet misunderstanding, as I am not expecting moderator on any forum to provoke people, as they should do quite the opposite, guide the discussion and stop people from being impolite to each other.

Also, you do not have to use time on this post if you do not want to, if you are annoyed by all the posts where people just whine like little kids, perhaps that means something, maybe it means that there is some stability problems (bugs, missinformation, documentation issues or whatever)… just maybe.

Not everyone is that good at expressing themselves, but that doesn’t mean they do not have something to say

I completely agree with this.

I don’t agree that this is the “only” possible solution, but given the responses I think it’s highly probable that people will choose to make it the only end point. And I don’t mean that as a criticism of anyone.

For me, this is the right attitude to take. There’s no rule that requires any of us to read or respond to any post. I’m personally grateful for the time and energy that so many of you put into it already, and have benefited much from the contributions of people in this thread.

I obviously don’t think venting is a waste of time, but I appreciate that others do feel this way. I’m just looking for ways for these two perspectives to co-exist so that we can all enjoy ourselves more.

My sister is way smarter than I am, so I’ll refer any psychology requests to her. :wink:

I took this as a joke meant to lighten the mood, but it can certainly be read differently.

I was hoping to bring this conversation to a conclusion that’s reasonably satisfying for everyone. Doesn’t seem like that will be the case, so I’ll leave it at that and move on.

Enjoy your weekends, friends!

That’s definitely contributing to misunderstandings. And so does that you mix issues.
MQTT2 to replace MQTT1 (which is still available) was accidental, it has nothing to do with “unstable”.
Myopenhab is yet another issue and while you might call it unstable, it is even not part of OH but a free, optional service.
The ZWave binding in 2.5M1 is rock solid, problems with ports not found on startup were introduced later. And you mustn’t restart OH anyway so any eventual problem when doing so will not show up.
If one device does not work for you OH isn’t “unstable” either.
Incompatibility would have been a better wording, but unlike what you’re saying “instable” clearly means something completely different than “incompatible”.
“Instability” would have meant OH crashes or locks up.
But for incompatibilities it always takes two, and it makes for an important difference if the problem is with OH or with Ikea, with the ZWave binding in OH or with the ZWave device manufacturer.
I know to you the result is the same, but to an OH supporter or developer it is not.
OH devs put a lot of efforts into reverse engineering how Tadfri lamps and Samsung TVs work because the vendors don’t want to tell us. So it’s highly unfair to blame OH if it doesn’t work out in every case. You actually can’t even expect that to work. You’re annoying people when you do.
Final point: you deliberately chose to upgrade at some point in time. You didn’t have to upgrade … ok, you hoped for improvements of whatever, but now that you know that it’s not what you hoped for, you can always go back to that stage before the upgrade, so why don’t you do that ?
Or move to 2.5M1 - it does not have those ZWave issues.

Oh dear. It was meant to be a joke, of course, hence the smiley.

Yes, have a nice weekend, all of you.

1 Like

This is by far my favorite answer. I think you’ve hit the nail on the head.
I’m running snapshot #1628 because I needed the latest Z-Wave binding and some other fixes. There are some MQTT issues which are annoying but I know where they are now, and by using a divide-and-conquer approach (two MQTT broker connections to the same broker on one openHAB), things are stable and work.

If something was causing instability for me, and this something worked in an older version of openHAB, I would go back to my older version system image (and you’d better believe I clone my entire drive before I dare to update to a new version!) onto duplicate hardware (RPi’s are cheap) and delete all the things and items that I don’t need from it, keeping only the ones that caused problems in the newer snapshot version, and then finally run the two openHAB’s in parallel on separate machines, probably communicating by MQTT for the few things that need it.

I’m not saying that I’m not looking forward to the next stable release of openHAB, far from it. But, in the end we’re using openHAB because we want to accomplish a goal. Sometimes the path to the goal is not straightforward, but isn’t it better to implement a quick workaround that gets the job done, rather than torturing ourselves with a poorly functioning system while waiting for that mythical new unicorn build that magically fixes all the issues at the same time? That basically never happens even with commercial products. :slight_smile:
I’d much rather implement some workarounds and get on with my life. My copy of openHAB is only running here, in one place, I’m not building a product based on it. That makes it very different from the quality I require of myself when I make products. If openHAB runs and does what it should and doesn’t crash, I’m pretty happy, even if I had to implement some ugly workarounds to get it there. I promise those workarounds are nowhere near as ugly as what I had to do to Fibaro HC2 before I got here!

1 Like