Disappointed with Openhab 2.2

Having started on 1.8 and being happy, changes in openhab 2.1 raised eyebrows, but the update to 2.2 takes the cake. Only 1 out of 4 starts is successful in the sense that there are no weird (wrong) messages like items that don’t exist (while they do, caused by rules starting execution before items are initialised, defined or whatever), systems started that get triggered multiple times (3 times in my environment), extraordinary long time to startup (anywhere from 3 to 10 minutes), unable to update a single file without breaking others all due to the fact that startup is total mayhem where timing issues are being exposed and on top of that any provisions made like start-up delays, booleans to ensure single execution etc. are undermined as well, due to things/components/bugs(?) eating CPU,resets (?) (I presume, from watching CPU behaviour at that time,and status of items after failed start/refresh) and other resources and as such creating massive mayhem at start-up (or rule refresh). This is no longer working for me, I have to fight it.

Now actively looking for alternatives, don’t consider openhab as a stable reliable platform any-more.

What hardware setup do you have?

Use a raspberrypi 2. If I would hazard a guess, it is a fight between the DSMR binding (looking at the logs under openhab 2.2) and the rfxcom binding (according to very occasional hangs, according to the logs in openhab 1.8). They both communicate on a serial bus via USB which is time critical (from experience, programming serial interface in the dim very dark past :slight_smile: ). But on 1.8 this never gave problems for other components opposed to what happens under 2.2

The order of loading items vs. rules has always been coincidential in OH2 because that’s how Karaf works.
Give another vote comment for this.

Try this: stop OH, move your rules files to a different directory, start OH, wait some minutes for startup to finish (see logs or if CPU drops reliably below 100%) and then move your files back. Expect UI to be laggy while OH process rules. That’s a known bug but just applies to the UI.

1 Like

Sorry, I am done with fixing issues due to lack of (or out of control) supervisor so I can trust the state of my automation, without having to check the logs after every start (if that was successful in the first place). Have been fighting issues for almost a year after the switch to openhab2 and now feel I am working for openhab rather then the other way around. Feel it has become a platform based on HAP (hope and pray), on which I cant build any further.

1 year of fight ! Did you share your problems on the forum to get help and solutions ?

In a home automation production environment, my opinion is that you should not have to restart and/or setup your system very often, maybe only few times per year when new versions are released or when you have new supported equipments added. Mine is restarted very rarely.

By the way, it is difficult to have 100% of happy users. Maybe we only have 99,9% of happy users :wink:

3 Likes

Well, I feel it’s no fair attitude and bad style to NOT contribute (which is as simple as making one’s problem public here in the forum or on GitHub), to then simply give up if nothing changes for a relevant period (be it a year or a release) and to then - worst of all - leave the impression others would have needed to invest more of their spare time to get him a working solution.
This is unfair and not how community engineered projects like openHAB can work.

OTOH, he’s hinting at a point that I also feel is not taken enough care of.
Reliability is a must if we want users to become and stay happy with OH, it’s way more important than any sort of new feature.
And there’s still issues in current OH such as the ESH #1896 I linked to above which I feel to be the root cause (or rather the solution to it) for a number of problems (and many user questions) that I would all call ‘reliability’ issues in an extended meaning.
These show up at startup, and I myself, too, have been seeing and having in OH 2 for a long time now. But I don’t feel this is being worked on because it’s importance isn’t properly recognized… there’s likely way more people to suffer from and be annoyed by these problems, but they don’t raise this to be a topic (whyever) and more or less silently quit using OH. @kai, @sjka, wdyt ?

4 Likes

I could have walked silently away, but didn’t think this to be fair. The massive changes in OH2, deserved to get time to stabilise, but that didnt happen with 2.2, if anything it became worse. The reliability issue @mstormi points to is the crux of the matter. Unreliable start and state made me look at other options on which I now spend my time. Spend already more then enough time going back and forth between versions and snapshot releases and couldn’t get a stable reliable platform.

On the issue of not talking about it before, I like this quote ‘if something happens once its not a problem, if it happens twice you may have a problem, if it happens 3 times you have a problem’ And since what happened most of the time wasn’t reproducible and was changing every time there was no use to talk or report on it.

Mind you I do appreciate the work the developers put in and they must have had ample reasons for changing the underlying structures of OH, the consequence however has been a massive hit on reliability.

For me, this problem ([Solved by itself] Unknown error when changing a number item) happens much more often with 2.2 than before.

I consider this to have a major impact on user experience as this breaks the “update” functionality on sitemaps in Basic UI (Items are not updated if they are changed, even if the item was changed by the user)

I enjoy similar problems, mostly it is the Channel not found for datapoint problem with my homematic items. I have about 50 of them, most of them radiator and wall thermostat with plenty of channels.

My first solution was to tidy up some rules triggers, which turned the problem to less existing, but not solved.

Currently i am working on a solution to remove the rules before startup and copy them back about a few minutes later. (Not really copying, but renaming)

Startup seems to be far cleaner and faster, the problem is currently not visible.

@pensionado
Since the problem is more visible on your system, if you don’t mind, could you please check if this approach would help you as well?

Here is my shell script for moving the rules:

#!/bin/sh

ORG=$1
NEW=$2
IGNORE=moverules.rules

for f in /etc/openhab2/rules/*.${ORG};
do
    OLDFILE=$f
    NEWFILE=${f%$ORG}$NEW
    mv "$OLDFILE" "$NEWFILE"
done

turn off rules:

moverules.sh rules rulesx

turn them on again after startup:

moverules.sh rulesx rules

@mstormi
Oops, i just duplicated your request. :open_mouth:
Should read more thoroughly. Sorry, didn’t mean to copy. :blush:

If only 1 out of 4 starts is successful, you could have easily raised an issue about “Unreliable startup”. :wink:

@mstormi

Hm… I created a ticket when I had a problem with OH2, (string variable defined in Items file caused GUI crash when updated by a rule, but number item did not cause the crash). @Kai just closed the ticket, was not interested at all. Used to work fine on OH1.8. I didn’t understand his closing comment, something along the line with “by design”.

So why bother reporting if that’s the attitude? I appreciate that not every bug is of interest, and developers can only work on stuff they are interested in and/or affected by, but why close the ticket if its not actually fixed?

JJ

Edit: Added Github link

May you share the corresponding issue with us?
I would like to get an own impression of the not interested at all

Sure, I’ve added the link to my original post.

1 Like

I’m not fully sure I got it right that quickly but I read Kais response as if a) there’s no NPE any more in most recent code (so it was likely changed/fixed between the version you used and the most recent one) and b) the server’s behavior is correct (you postUpdate() a string to the Image item, but the Image item requires this string to be a URL which it is not in your case, so the server’s 500 reply is correct).
You would need to put valid contents into the item if you want to get it properly displayed. The fact that it might have worked in 1.8 does not mean anything because that was just coincidence and not intended behavior (if you set variable contents to be outside of the spec, you can’t expect things to work).
While obviously a somewhat more verbose, explaining answer would have been nicer and beneficial to your communication, I feel this is correct. I don’t see any sign of “not interested” here either.

From https://docs.openhab.org/configuration/sitemaps.html#element-type-image

url is the default URL from which to retrieve the image, if there is no associated Item or if the associated item’s state is not a URL.

Just fyi, i added my workaround to the solutions section. Startup is clean now, no more “channel not found” problems.

I hope this workaround helps somebody until the real solution is done. (The real solution is far more complex than it seems at first and second sight.)

@johnjore : I posted an additional message in the Git issue. You should have asked first here because I have the strange feeling that you simply did not understand at all what should be the item in an image element.

Hm… it was used with a different client before, (rotini), and I wrote my own android client later on (Kala), and it worked correctly on OH1.8. the items file and url had nothing to do with each other. It was used to display an avatar (URL part) with status (item part) below. Both Rotini and Kala have extended the sitemap with extra attributes and are parsed very different to OHs native clients.

It was logged as a bug due to the NPE, but I probably muddled it with the URL part, as I thought that was the issue at the time.

However, we digress. The point I was trying to make was that when tickets are just closed without engaging with the me, the OP, then I loose interest in engaging with the community. For this one, I wrote a workaround by using a number item. 0=Work, 1=Sleep etc etc. and parse the number in my client. However, I never got to the bottom of why a String item, when updated by a rule, does not work correctly, but a number item does. That was ultimately the real issue I was trying to figure out.

Hmm. You created an issue, and after your initial problem was solved, you redefined the issue to a different problem. That’s not how it works. You should have opened a new issue then.