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?
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.
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,
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.
@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.
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.
