Offtopic:
I know we two already had this discussion…
For a normal user of openHAB it‘s not so normal to register at an developer platform to create an issue when he already mentioned an issue/bug in the community.
I know it‘s an endless discussion 
This has been discussed before?
This was my concern here, too.
I think it wil get easier that people are willing to register at github and file issues over time, but it is really unknown terrain for the average user. And therefore this case where an issue is open and the user has made it so far isn’t obvious what he should do.
Besides @J-N-K hint it was an oh1-issue where there were complaints about an oh2-issue. That’s a valid point of course…
I could have sworn I was in the 1 addons repo. I must have hit a 1 by mistake. My bad.
Unfortunately then we can’t support such “normal users.” It’s really as simple as that. It’s an open source project. And I, as someone who is not using the binding or not seeing the same problem, am not in a position to file an issue myself.
It’s a limitation of open source I guess.
If you want to report an Issue to Microsoft, you need to register there as well. Same for Adobe etc. There is no real difference to commercial offerings. And github is really easy to use, especially if someone made it to the register screen for this forum at some point as well.
It’s the very first posting (last lines)
No, not mandatory. It’s also possible that you have to communicate with the microsoft partner and he tries to reach microsoft and gets only the wrong department and after one week someone of the right department calls back and wants to investigate. And that for an ERP-Solution.
Yes, sorry OT but just happened last week…
Are there pinned posts in this forum where it’s explained that a user should file an issue at github in such cases? I don’t have an overview atm, but if that’s not the case, may be something to consider? Just spontanious idea…
edit: would it be something which could be added to this thread?
That‘s fine but then i don‘t understand why you (not you as a person but pointing to the „we“ you used) would like to make things easier for new users.
Why does the user needs to report the issue in GitHub?
Why can‘t he just report the issue here in the community as a central point of communication for users.
The GitHub part still takes place by the maintainer.
I can‘t see how the project wants to gets new users with shiny UIs and easy onboarding but still requires them to register another account at a developer platform to report an bug.
Yes i know, no one get‘s payed for support and there‘s not helpdesk.
Atleast there should be a discussion take place how this will be handled in the future.
Not really.
Just call the hotline and get help.
Keep in mind, we‘re talking about the user perspective and not the business perspective.
You can‘t compare open source to paid products, because all the other time it‘s discussed that oH is free to use and therefore has no helpdesk.
I’m not talking about getting help. I’m talking about reporting bugs. If you are part of the microsoft developer thingy to report problems in windows, you do need an account. Of course. The consumer hotline will not do that for you. They will be more like… “Oh it doesn’t work for you… please restart your computer.”
1 Like
In some threads, e.g. new bindings, the maintainer has made the thread to discuss the new binding ideas and when users which weren’t at github had issues the maintainer had filed the issues. I think there’s not one way for this topic how it should be handled. May be there could be a mixed approach in the future.
Enough OT, may be it’s the best to discuss this in a seperate thread when the main OH3-directions are done.
User perspective… 
First you talked about issue now about bugs.
An issue will be reported to the hotline and needs to be clarified as a bug.
How should a USER know if it‘s an issue or an bug?
I haven’t thought about this aspect. I always assumed that the binding documentation clarifies what the binding is capable of. And if that is not working, it is a bug. But an average Joe might not differentiate enough.
For my bindings I usually ask the users to create a bug report on Github. I don’t expect them to know of the platform. But I also tell them that I will probably forget about it without a report.
Do I understand correctly :
you are saying that the bug reported in 1.x
Is working in 1.x (with the correct java)
and is not working in 2.x (with the same java version.)
From my perspective…I think it’s OK to not offer full backwards compatibility…but what makes users leave is not providing backwards capability
We need to be able to continue to operate the items and devices we own…with the new iterations of OH.
I will use the example of the OH1 EXPIRE binding…if you want to not support it in version OH3.0 - I’m ok with it (just typing this scares the Sh*T out of me) but provide me that same capability in the UI…why does it have to be a binding? Maybe it doesn’t have to be a black or white issue but some level of grey in between.
Let’s face it…it’s a hell of a lot easier for me to switch HA software that supports my tech than it is to pull out all of my devices that are no longer supported with a code/version change and replace them with ones that are.
I love my OH installation - and would prefer not to look for other solutions…but if my house no longer operates the way my family is used to…I will have no other option…staying on old code is not a viable option for me.
2 Likes
That sounds like a good idea. Though that thread is already lengthy and posters get annoyed when we ask them to read it.
Usually, when a user has a problem and they post it to this forum, we will attempt to solve their problem or if it is a bug, narrow down what part of OH the bug resides. Then we will ask them to go file an Issue, often proving a link on where to go.
I would prefer that the users follow this approach really because I don’t think that “normal users” as Michael put it, have the knowledge necessary all the time to know to go post an issue all on their own or know which repo it should be filed in.
But at the same time, when asked by someone here to go file an Issue, I do expect them to do so. As someone who is not experiencing the problem myself and maybe not even using that binding, I’m not the right person to file the issue. If additional information is required like debug logs and the like I won’t be able to provide it.
Because the only way the developers who will fix the bug know there is a bug is by there being an issue on GitHub.
As Jan said, it is unreasonable to expect the developers to read every posting trolling for potential issues.
Not all Issues are actual bugs but instead miss-configurations or miss-understandings. That’s what the forum is for. But to repeat myself, when the helpers determine that the issue is indeed a bug, we need the user to file the issue because the helpers are not in a position to help the developers figure out the source of the bug.
Honestly, if this is too much to ask of a user, then that user is a net drain on the project over all. Open Source development is a community effort. We ALL must pitch in and do our part to make the project succeed. As a user of the project, you can do your part by filing issues when you find a bug.
It’s not hard. We can help you with the process if you run into trouble or can’t figure something out.
If you can find ANY open source project that works differently I’d be very interested to see it. They may not have you go to GitHub but they will require you to file an issue
This. ^^
The forum is for asking for help. Sometimes on the forum we may determine that you have found a bug. If we do, we need you to do your part as a member of the community and file the issue. If that is too much then I’m sorry to say that you are a net drain on the community.
In this context issue == bug.
We will never recommend you file an issue over a problem. And as I’ve said several times in this one reply, we don’t expect users to just know when to file an issue. But when the helpers on the forum ask them to, we expect them to do it.
The documentation is almost never adequate. Honestly, the folks like me and vincent and dim and all the rest are the first line of triage. We end up being the ones that walk the users through some diagnostic steps that will help us to determine if the problem is configuration, indeterminate, or really a bug in a binding or the core. If it’s determined to be a bug, we will ask the user to file an issue.
That’s why we wrote that “Help us Help You” posting. We spend a huge amount of time playing 20 questions and reading through logs and such to try to diagnose problems. 80% of the time we find it’s a configuration problem. The rest we send to file issues where we assume the devs pick up the 20 questions and hopefully find a fix.
In this particular case, Jan asked vossivossi to file an issue. I went and looked and found the wrong already opened issue confusing matters. But the fact remains, the user knew to go file a bug because we asked him to. We don’t expect any more of users than that. We don’t expect them to know to go file an issue on their own. We do expect them to ask for help if something doesn’t work and file an issue if they are asked to.
So it would seem. The problem must not be in the JDK on Network Binding.
Expire is really not the focus of the conversation because it never should have been a binding in the first place. It should have always been part of the core. And I suspect that what Expire does will become a part of the core in OH 3. At least I’ll continue to squeak about it until it is.
We do have an approach to provide continued support for OH 1.x bindings. But realize that OH 1.x bindings ARE old code. If you need to keep using OH 1.x bindings, then staying on old code is your only viable option.
3 Likes
It’s my only viable option if I want to stay with OH. And this is what I fear how a lot of users may feel.
Take away the compatibility…don’t take away the features…I know this statement is simplistic but it’s the basis of most user’s fears. Is updating the binding the only way to keep these features in OH?
It may be…
my point is, with a few exceptions, if you are running 1.x binding, you are already running old code. Continuing to support the old code on an OH 1 or 2 instance and federating with OH 3 only reveals the situation we are already in. It doesn’t change it.
I’ve said it before and I’ll say it again. Only one person has maintained the compatible layer all these 5 years and he is done. We can force him to work on something he doesn’t want to. No one is stepping up to maintain it.
What would you have the project do? At least we have a way that the OH 1 bindings can still work and interoperate.
Will we lose users? Yes. but it’s not like we have a choice.
I hate to see any user go, but at the end of the day, but if OH no longer sure your needs with the support the devs are willing to give then perhaps OH isn’t going to work for you.
The devs do what they can. If it’s not good enough then so be it. We will continue on doing the best we can and should you decide to come back we will welcome your return.
I think I might be one of the “quiet bystanders” here as was @KidSquid, I am now getting to the point to chime in. A decision to eliminate OH 1 binding compatibility for OH 3 will force people to stay back if they rely on OH 1 bindings to run their hardware (e.g. Insteon). In my case, if I move to OH 3, 90% of my home will stay in the dark (literally) when it comes to automation. Anybody in that situation will stay back, and eventually, over time will migrate to other alternatives. I would imagine that the loss of that user base (a lot of seasoned users over the years) will hurt the overall project because they loose their voice.
The net effect of staying back will also eliminate the chance of getting an adaptation of the old bindings to the new OH 3 concept, since new users will not sign on when they see that their technology is not supported, and old users only hear “…well, the binding is not supported by the original developer any more…”.
4 Likes
There is an mqtt bridging software existing.
2 Likes
I totally agree. If we would expect the developers (I do hope plural is still valid) to read all posts in here, shen should they do the needed work on the code?
My personal reasoning for answering on this forum is to give the developers a break! I hope their “de-motivation” can be kept at a minimum that way.
5 Likes
This “staying on old cold is not viable” - I don’t know. As said, you are on old code already. It sounds like “you have to refresh this binding, because I say so”. I know it mustn’t be meant like that but I see a little danger discussions heat up with those demands.
No want really wants to leave users behind, I think.
On the one hand core maintainers can spend their time to provide a compat-layer for bindings where the maintainers don’t want to “upgrade” them to a newer binding-version or they can evolve the core.
I think it’s not easy but may be for really heavy used bindings (yes, hard to measure that) there should be a way to refresh them to not loose the userbase and make all of them unhappy. But to maintain a compat-layer which only 1 or 2 persons can maintain at all for some bindings which are just abandoned and a handfull of users out there using them is not the way to go, from my limited perspective.
1 Like