Disappointed with Openhab 2.2

Who the hell am I to comment? That’s what I keep asking myself. No one really.

@pensionado Free, open source, community driven software and openHAB isn’t working for you? You’re working for openHAB? I’m not sure I see the results of your ‘effort’. You could have walked silently away. You would have achieved the same results (of ?). I guess you feel we should thank you for identifying a problem. Correction, identifying that a problem exists, you haven’t actually identified the problem.

@johnjore I think that @Lolodomo eluded to the issue with your comment. Github issues would indicate that you have identified a problem (or want to request/suggest a feature). The community is to discuss the problem you may or may not be having. While Kai’s response may seem cold, I think it’s appropriate as a ‘business’ response. (Don’t confuse business with financial) GitHub isn’t the forum to teach. I don’t think you should shy away from submitting issues but maybe check here first.

@awsnap,
You do know that my initial post was a response to post 7 here?

@Lolodomo,
As I created my own sitemap format for my own custom client, using the API I could see something was not right, the NPR, thinking this was the problem. It probably wasn’t the real issue I was trying to figure out and I probably muddled it with the URL part when I simplified the problem to remove my custom client components. When Kai closed the bug report without really understanding the real issue I was struggeling with, I kinda lost interest in the contributing aspect and implemented a workaround. Anyway, my initial post here was a response to post 7.

@job,
Hm… no. I believed I had one issue, and it got closed without getting resolved. If there are multiple issues, then sure, another bug report could have been made, but from Kai’s response, I interpreted his response as its “by design”, no further action warranted. (I did post an update after it was closed trying to explain I thought something was still wrong, but there was no response.) And again, you do know that my initial post was a response to post 7 here?

And apologies to the OP, I seem to have hijacked the thread. That was not my intention, it was a response to post 7, and contributing. Or not. Lets leave this as it is, many have chipped in with their opinions, and I can see some have spent more time than others understanding the background for my initial post. All good feedback.

@johnjore,
I think you should reread your issue.
Your issue was a NPE, “Sitemap / Item with Image causes NullPointerException”. The posts from October 10, show that this NPE no longer exists and the exception thrown is an “IllegalArgumentException: Invalid protocol null”, because no protocol was provided.

Your issue was resolved and therefore the issue was closed.

With your next posts, you want to turn the issue into an issue about behaviour of Number and String items.

For sure not all your issues are solved, but the one this ticket was about was indeed.

Thankyou for that. I had to implement something similar for OH1 in a Windows desktop box, which simply would not load rules clean due to race conditions. When I go to OH2 I think I’ll need this idea,

1 Like

Please keep in mind, that my solution is just for Linux (i use openHABian) and similar systems. Maybe it is possible to use the Linux subsystems on Windows 10, but some work has to be done using a Windows system. The moverules.sh script should best be ported to powershell.

Sure. It’s the unerlying principle that is important. If I work out a Windows method one day, I will add to your other thread.

@job,
Always good to see someone who knows better than me what I was trying to do… You have completely missed the point of the original post, but that’s ok.

@johnjore I don’t think it matters what you were responding to, it was the response that I was speaking about. Did I miss something?

I think the best thing to take away from ALL of this is that the community may be your best resource to start with and when that is exhausted, possibly a GitHub issue is in order.

Sorry for late joining this thread but came across it whilst searching for startup and general reliability issues.

I feel that is the most important aspect for OH to concentrate on at the moment.

Thankfully there are all sorts of people in the world and I suspect @pensionado as myself don’t like to trouble core developers and maintainers when we expect to be able to fix something ourselves or worse they are very unpredictable and not easily reproducible problems. On the other hand there are all too many forum posts from people that expect you to more or less write the Things, Items and Rules for them and you think this person can’t of even read the first page of documentation.

If I was a paying customer of OH Ltd then I would be banging on the door demanding support and fixes but as an end user consumer of OH opensource I don’t feel I have much right to demand anything and when I see posts about users running big instances without issue (indeed claims seen again in this very thread) I go back to it must be my fault therefore I’ll keep plugging away at it.

So yesterday I deployed the ‘remove rules at startup’ workaround based on a variant from the post of @job and it’s improvement in respect that my startup was much cleaner and faster and I’m thinking things may be better until I got back from going out for 3-4 hours and find some rules aren’t firing again.

Interesting when I look at ESH #1896 and consider if I were running OH Ltd and that was on the bug tracker system I could only give it a severity of critical/must fix. Appreciate it’s not a simple fix and quite involved but it’s been open since July 2016 and is somewhat the original posters point as @mstormi has acknowledged. I’d guess a workaround like @job has done could likely have been done in the core of release 2.0, 2.1 or 2.2 that would be better than what appears to be nothing and likely contributes to the underlying feeling of instability as it is clearly an issue for many and likely many more that don’t realise it.

I didn’t use OH 1.8, only been involved a year or less, but I recommended OH to a friend about 5 months ago but in all honesty now I would find it hard to recommend if any one asked me. I can’t get my system to run for more than a few days without a restart required. My rules code has become excessively defensive, everything is ‘if starting up return;’ protected, re-entrant locks etc

It is difficult to have everybody happy and the complexities of these systems means there will always be problems but I do have sympathy with the OPs post as I’ve been feeling his pain. Sure he could have done things different ways and it’ll just be a matter of opinion as to whether they would be better or not but if you look at it as feedback the community has lost a user due to the reliability issues he experienced.

Best I go raise a new post on my very difficult to reproduce, track and fix random rules stop running issue which hopefully wont consume to much of other peoples valuable time.

One things for sure we all want OH to be the best it can.

1 Like

FYI, that ‘UI lag’ bug I referenced is fixed, GUI now is usable while rules are being processed.
Now that lagginess is also and still surfacing on rule execution. But now as it’s for essentially the same technical reason as in the UI, I guess we won’t need to wait long for this get fixed, too, @henning seems to be working on it.
This is to state developers DO listen and fix issues IF you enable them to by tracking down and documenting the circumstances under which such a problem shows up. Now THAT, YOU as a user are still expected to do, you can’t expect the developers to do it. Yeah I know it’s sometimes very hard to identify a problem when you don’t manage to reliably reproduce the problem state. But that’s how it is, and that is by no means easier if you’re a developer.
There’s apparently also (new) discussions on how to approach ESH #1896, but it’s obviously not as simple there.

Agreed

Almost finished by moving away from openhab, but today I had to restart for a small change and again an error occurred during startup, which required manual intervention:

2018-08-16 14:25:15.890 [INFO ] [ipse.smarthome.model.script.SysStart] - System started: event
2018-08-16 14:25:16.237 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Delay startup rules': 'plusMinutes' is not a member of 'org.joda.time.DateTime'; line 18, column 15, length 18

This is output of the way I try to prevent startup problems, now it doesn’t even recognize well documented functions of classes. Forcing this again by a refresh of the file that contained this rule it worked:

2018-08-16 14:39:38.831 [INFO ] [ipse.smarthome.model.script.SysStart] - System started: event
2018-08-16 14:42:38.846 [INFO ] [ipse.smarthome.model.script.SysStart] - Triggering delayed system start

Now the 3 minute delay I programmed with the plusMinutes worked.

So much reliability and resilience.

@pensionado I had never been a fan of OH rules language Xtext/Xtend. It maybe a toy project to write a new language but its implementation (the virtual machine) is very complicated and life consuming task. There is no wonder you faced issues. I did too, it was very painful. I moved away from rules and did implement things in other languages like plain Java, Bash, Perl. OH2 is smooth in my experience, if you stick to Java only.
The thing I am trying to tell you is ‘I moved away from Xtend rules not openhab’. I gather you may have a lot of intellectual property already invested in rules and it must be a frustration to know they no longer work as they used to in OH1.8.
It had always been my wish to integrate an already proven JVM scripting language like Scala, Groovy and non-JVM scripting languages like shell, Perl and Python. People should be able to write bindings in just few lines of shell scripts for example. Of course the performance penalties have to be analyzed. But those penalties are sometimes worth compared to human cost associated with writing/maintaining a too much verbose Java code or trying to get Xtend/Xtext to work reliably.

I advise you to rethink your decision and stick around. This is a global project and global community. Things will get fixed sooner or later.

Now that’s a programming error of yours that possibly has been in there some time.
OH does not change code or config all by itself for sure, neither does it suddenly start accepting code that it did not before (unless you changed OH). It can be hard to understand at times, but that doesn’t entitle you to blame it for things you caused yourself.