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 
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. 
Should read more thoroughly. Sorry, didn’t mean to copy. 
If only 1 out of 4 starts is successful, you could have easily raised an issue about “Unreliable startup”. 
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.
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