@seime, out of curiosity: what would be required to make this an official binding?
My guess is: The will.
There are a lot of rules for an official add-on, development becomes very delayed, and new stuff must wait for the next OH release. It isnât âbetterâ for a binding to be official except that it gets better exposure. Also, as an official binding, all improvements are only available to those that upgrade OH to the latest version, as an âindependentâ add-on, improvements apply to all supported versions.
Another pro to being in the main distro: breaking changes to core are usually handled by the core team for your add-on when they make the change. It often means that a community addon doesnât work with new versions of openHAB until the maintainer puts in additional work. But yes, it can take a significant amount of effort to get new addons added to the main distro.
And while you list improvements applying to all supported versions as being a pro, it can also be a significant con as an add-on maintainer to try and support multiple versions. Things like Java version changes, changes to add-on.xml, etc. as well as aforementioned changes in core can make it quite complicated to build a single JAR that supports many openHAB versions. Case-in-point - when I make contributions to this add-on, I donât have a development environment that works with openHAB 4 because I donât want to keep old Java versions hanging around, so I actually have a âprivateâ branch in my own repo that changes the pom.xml to target current openHAB, and then once Iâm done I just cherry-pick it on top of @seimeâs master, and submit a PR from that.
Also, just because an add-on is in the main distro doesnât preclude also maintaining a community version of the add-on that you can use for whatever you want - perhaps only back-porting significant bug fixes, or back-porting most/all changes that happen in openhab-addons.
That said, I again emphasize that it can take a lot of work to get an addon into the main distro! Iâve made several small changes to this binding working towards things I know would need fixed in order to get it accepted, but Iâve yet to spend the time to really work through things, and start the big PR. There are a few areas that might be problematic that are non-trivial:
- The Noise encryption library is âvendoredâ in. Iâve not seen that with any other addons (though I havenât looked exhaustively), so I donât know if that would be acceptable upstream. I hope so, but worst case is it just gets published from a separate repo. I believe itâs just a fork of another library thatâs not maintained. This really wouldnât be that bad - Iâve dealt with external libraries that Iâm unable to publish to Maven Central before - I just published it to GitHub packages, and then distro ended up mirroring it into openHABâs JFrog repository.
- The way the binding interacts with the bluetooth binding is a bit odd. But the bluetooth binding itself is a bit odd, and could use some structural improvements. Iâm not sure Iâd want to spend extensive time changing anything in this binding until bluetooth binding changes are done.
- @seime has his own thread pool handling to address some of the deficiencies in how thread pools are handled in core. I doubt that would be acceptable for an addon in the distro. Ideally the deficiencies could be addressed in core first (whether that be just taking @seimeâs improvements, or addressing them in some other way). Itâs been discussed a bit in core, but hasnât really gone anywhere yet.
- There are probably lots of small things like logging guidelines that will take lots of back-and-forth when it gets code reviewed.
EDIT: oh yes, one other pro to being in distro: if the original author of an addon stops maintaining it or plain disappears, itâs much easier to have someone else take over as maintainer. Things can get murky and confusing if you have multiple forks of an addon available in the community.
I donât really see the âprosâ you see. I have two add-ons on the marketplace, and Iâve had no intention of making any of them official, because itâs hard to see what the upside would be. It should be said that both are relatively niche, if weâre talking about a large binding with many contributors, it might work better all in all to follow the official ârulesâ for coordination.
But, to me, itâs hard to get around the fact that I can fix a bug a day after itâs discovered, and have it available to all users back to OH 4.1.0 (which is my lower limit because thatâs where Java 17 started, and I havenât bothered figuring out how to do it with Java 11). If official, the fix would take weeks to months to reach the users, and it would require them to upgrade. Knowing that many, like myself, still run OH 4, I think this is a major point. It just becomes infinitely more useful.
I donât share your âfearâ of older Java versions, in fact, I still count Java 8 as the last âfullâ version of Java (after that, they abandoned Java as an application language and most focused on it being used for âweb servicesâ, without caring about what they broke for other use cases). I have Java 7, 8, 11, 17 and 21 installed, and I build using all of them. Eclipse mostly manages so that I donât even have to care about it, I just define what Java version each project should be built with. Java 7 is the exception because it requires extra command line options to enable TLS1.2.
When Eclipse builds OH for me, it builds using Java 11 (SAT), 17 and 21. I run my dev environment with latest core while I have my add-ons using Java 17 as active, open projects. I can edit any of them âliveâ while OH is running, and the bundles will be built and replaced dynamically. To me, this is no trouble at all, I donât even ânoticeâ that thereâs a difference except that I canât use Java 21 syntactic sugar in the add-ons (but since I think most of it is pointless anyway, thatâs not something I consider a problem).
I know that at any time some change can happen that makes it impossible to build across versions like this, but Iâm very happy as long as it works - and I think itâs important that when breaking changes are made, they are made for a good reason. If such a change was made, Iâm not sure if I would bother to maintain two versions, or if I would just maintain the âoldâ version. I certainly wouldnât maintain only the ânewâ.
My âvisionâ is that the marketplace should be made better (supporting versioning, dependencies etc.) so that more of the add-ons could live there, not the other way. The main reason for that is the very long wait times associated with having to follow the official release schedule, and the fact that you effectively force people to upgrade just to receive a fix.
The will to backport is very low, I suggested that the fix that broken the marketplace should be backported to 5.0.x, but even that was rejected. Which means that anybody running 5.0.x, or a version of OH 4 prior to 4.3.9 no longer have a working marketplace, and that all the add-ons that work fine with these versions are basically unavailable to the users unless they figure out how to install them manually.
To me, things should âmove the opposite wayâ for a more flexible and better experience 
Maybe the last 4 posts should be split into a separate thread by someone (@rlkoshak 
) but I find the discussion very interesting and would like to add these user aspects:
- The fact that core bindings are automatically installed after an OH-upgrade is a pro. Itâs not much work to reinstall marketplace bindings but something I regularly forget after upgrades.
- Regarding the risk that a marketplace binding might die when the author loses his interest (yes we had that point): Itâs sometimes hard to keep those bindings running. I would really hate to have to run an additional old OH-version or even a home assistant container just for one old binding as some users do it. There had been a discussion if it would be possible to enable OH to use HA bindings. That would imho be the best as it would free developers resources for OH progress instead of keeping bindings working. But probably hard to realize and introduces new problemsâŠ
- regarding quicker bug fixes of marketplace bindings: The point is true and my method is: If I need a certain bug fix or feature I switch to the latest version from the marketplace or use the jar from the developers repo (examples shelly or evcc). Otherwise I stay with the core version
Overall Iâm always happy when a binding makes it into core (Amazon echo, home connect) especially for the critical ones within my system as it feels more future proof to me.
If moved, include this post please.
Iâm not saying that things are ideal as they are now. There are a number of issues that Iâve worked on in the past that I was hoping to get implemented (I havenât worked at this for about a year now because I hit some obstacles that Iâm not quite sure how to overcome). Among those things were version handling of marketplace add-ons (upgrade/downgrade, automatic upgrade notification), dependency management so that one add-on can depend on others/require them to be installed, and crucially, inform the user what those add-ons are.
A part of this work was also to handle the upgrade mechanism. I know why marketplace add-ons usually disappears during upgrade. Itâs not the intended behavior, but the mechanism is so naive that it will usually fail. It tries once, during the first startup when everything else is in chaos, and if that fails, which is usually does, the add-on is just forgotten/dropped without further due. My plan was to change this so that it didnât delete the information that the add-on was there, tried again later, and that it was added to a list the user could reach in the UI where the user could manually select âtry to installâ or âremoveâ for those that couldnât be resolved manually.
It is with these changes, and others, I envisioned that ânon-officialâ add-ons could work well.
I donât think thereâs a significant difference between official and unofficial add-ons here, except that for minor updates like dependencies, those will probably be handled by others as a part of the official repo. But, when it comes to doing changes to the actual binding, we have quite a few examples of official bindings that suffer from this exact point. Iâve reported bugs or suggested fixes where the âauthorâ donât even bother to reply after weeks. Itâs clear that they have abandoned the whole thing, and that nothing will be addressed. Itâs not any easier for a developer that doesnât know the binding to âjump inâ and take control over an official than an unofficial binding. Itâs possible in both cases (add-ons are open-source after all, so anyone can fork and continue development), but it might require significant effort by the person that wants to âtake overâ.
Unofficial bindings have an advantage under some circumstances here, as they might be able to work fine for longer without being maintained. It depends on exactly what changes, but official add-ons are generally much more prone to breaking because of dependency updates (because they rely on OSGi features).
That might or might not be just a feeling, the actual âlongevityâ of an add-on depends on a number of factors, and Iâm not sure that the official/unofficial status is very high on that list.
I used to be a code owner for a binding, and have no desire to do it again. The nitpickiness of the add on maintainers was over the top.
You make it sounds like you had some particular issue(s). I have certainly met things that have annoyed me here too, but for the most part I find things reasonable. It will always be challenges when many different people, with different knowledge, habits and perhaps perception of what is âfashionableâ/right/wrong try to collaborate.
I havenât experienced any particular problems when it comes to nitpicking, but perhaps thatâs because Iâm pretty picky myself
But yes, the freedom to not have to follow some arbitrary âbest practicesâ with no or very little real value, can be a significant pro from a developerâs perspective. At the same time, some of these âbest practicesâ also lead to better quality code, and/or more consistent behavior with other parts of OH. So, there are two sides to this. Luckily, youâre still free to follow whatever best practices you deem worthy 
One reason that I donât want my add-ons being made official is spotless. I see that itâs very helpful to have a standard formatting that you can just run everything through so that code from everybody is formatted the same way. I donât have a problem with most of what spotless does, except the line wrapping. I find that completely hopeless, so much so that I consider some code almost unreadable after spotless has been applied. I normally split things vertically in some âlogicalâ way when they are too long to fit on one line. I try to keep âconceptsâ consistant, and if a method declaration is too long, I typially make it a âvertical layoutâ with one parameter on each line. Spotless wants none of that, and just jams everything together in a completely unorganized way. Itâs made me think that if I was every to make any of it official, I would have to maintain two versions - one that is properly formatted, and then whatever garbage spotless produces. It would make the maintenance burden much smaller, because the code would be instantly readable, instead of having to try to figure out what belongs to this call and what belongs to that.
I also canât stand using space for indentation, it just feels so âbackwardsâ when tabs are better in every way. Using spaces leads to some extra work at times, but overall Iâve learned to live with it. But, it means that I must have different IDEs for âOH codeâ and other code, because having to keep reconfiguring the IDEs depending on what code youâre working on is just not⊠viable.
These are just examples of what bothers me. Pretty much everybody will probably have something they dislike in one way or another, but thatâs part of the price one has to pay to be able to collaborate.
Yes, I know that you can use // to âfoolâ spotless, but I just donât bother because of the extra work putting all those //s all over the place, and the fact that itâs a way to circumvent the âstyleâ thatâs being imposed. As I see it, the line wrapping is a choice (spotless can be configured), so why should I circumvent it?
How about creating a PR to propose your changes?
Any changes to spotless now would mean reformatting the entire codebase - Iâm not sure if thatâs viable. I also assume that the current strategy has been chosen because there are those that think that âitâs the right wayâ.
We did that with Main UI.
I donât know â in my Java projects I am using spotless as well with Google Java Format, Iâm not really caring how my code is formatted, I just want it to be consistent.
Ok, itâs hypothetically viable then. I donât think itâs something Iâm ready to undertake though. As far as I know, spotless uses the Eclipse formatter âunder the hoodâ.
Iâve had some rounds with the Eclipse formatter in the past. Itâs generally capable, but falls short when it comes to line wrapping in my opinion. Itâs just too simplistic when it comes to line wrapping, you canât make the ârulesâ necessary to make it behave like I want it to. It is possible to make it much more permissive, you can make it accept what I consider âproperly vertically formatted codeâ, but not so much generate it. The result of tweaking spotless accordingly would thus probably mean âmore variation in vertical formattingâ. Would that really be welcomed?
What would be required to make this binding official? Nothing? 
It just requires openHAB project to recognize existence of third party addons beyond its own repositories.
The esp easy binding license is fairly permissive and it can be included in OH distro or addons KAR. Nothing holds addon maintainers to pull it in!
I think you missed the point
There are rules for how things are to be done, how it should be formatted etc., to be accepted as âofficialâ. In addition, all changes require approvals from maintainers.
The answer is therefor that crucially, the author must submit it as an official binding, the binding must adhere to all the rules that apply for an official add-on, and the submission must be approved by a maintainer. Thatâs it really.
I get the point, yet I am pointing how easy it is to get discussed addon included in OH distribution.
At the end of the day, âofficial addonâ is one which can be enabled by user. Whether check mark is required or not, OH already leave this decision to the end user.
Since users are accepting marketplace addons without âofficialâ badge, what really holds distro from shipping third party addons? Can anyone tell me this? After all, effort to do this is pretty much the same as for third party library.
A core binding gives users a much stronger sense of longâterm reliability. Even if the original developer or maintainer steps away, the binding is far less likely to be abandoned. It will continue to be maintained, updated, and supported across future openHAB releases.
An official binding is built every day against current openHAB core framework. No risk to run an outdated binding built with old dependencies.
It does not rely uniquely on one person but can benefit contributions from others and will be considered when something is changed in core framework that impacts it.
Being an official binding means also a kind of quality as code was reviewed by someone who knows well the OH binding concepts and good practices, what to not forget ⊠Believe me (or not), I have no example review process of new binding was useless and did not find bug.
That being said, it does mean an unofficial binding is necessarily of low quality, I would say it mainly depends on level in Java development and experience duration with openHAB development of his contributor. I would myself be confident only in few of them that already proved by their precedent contributions that they produce high quality.
Iâd say that this is a highly subjective belief rather than a fact. In either case, if the original developer steps away, somebody must pick up where he/she left to continue the development. This applies whether the binding is official or not.
It might be convenient to tell oneself that official bindings are well looked after, my experience is that this varies a lot, depending on the people behind them. Exactly as it is for non-official bindings. Broken, official bindings are sometimes included in the distribution for years after they stopped working, so thatâs really mostly a false sense of security. Iâve also found and fixed bugs that have been around for many years without anybody doing anything about it.
This is the same old thing that Iâve addressed so many times before: The âriskâ of running âoutdatedâ dependency is extremely overhyped. The vast majority of âsecurity flawsâ being found are irrelevant to most use cases, or arenât about security at all (DoS attacks, which most of them are about, are only relevant if you run a public web server). I guess people will just have to choose what to âbelieveâ on this point, I can recommend to anybody that isnât sure what to believe, to dig into a few example CVEs that âgets in their wayâ and force them to upgrade. Dig all the way until you really understand what âthe problem isâ, and then assess what âriskâ this constitutes for you. Iâve done so multiple times, and Iâve yet to find a single situation where it actually mattered for my use.
But, aside from that, this isnât how it works. Only if the binding brings its own dependencies, can an âoutdated bindingâ mean running âoutdated dependenciesâ. The typical binding JAR doesnât contain any dependencies, it only references them. That means, that the binding will use whatever version of the dependencies that your OH version uses. So, there is no âsecurity riskâ. This is by the way, the same reason that older bindings might break. If the dependency in your OH version has changed enough from the version of the dependency that was used when the binding was written, method signatures or types might have changes so that they can no longer work together. In this case, the binding wonât run at all. If it runs, it does so using the âcurrentâ dependencies provided by your OH installation, except in cases where a binding requires dependencies not provided by OH. In those cases, the dependency will either have additional JARs that must be put in the addons folder (which pretty much prevents them from being offered on the community marketplace) or use KAR files instead of JAR. So, for the most part, this entire point is moot.
Both official and non-official can be contributed to by others. I know there are non-official bindings where people contribute PRs. What is true is that only official bindings are usually taken into account when changes are made in core, but thatâs an âit either keeps working, or it breaksâ situation. The binding wonât just magically âbecome worseâ because of this. And if it breaks, the author can fix it in a day or two, without having to wait for a long release schedule.
Yes, as Iâve mentioned above, these âbest practicesâ are somewhat of a âquality assuranceâ, but not only. Many of the things being required arenât about âbest practicesâ, but about doing things âthe OH wayâ, or adhering to things like a particular syntax - which has no relevance for the user, only for developers.
But, the benefit you might get from the âbest practicesâ that are applied must be weighed against the huge benefit of the flexibility to have an independent release schedule. You can literally fix things in hours, which is more or less impossible for an official binding because of reviews and approvals, but foremost: Even if the fix is accepted quickly, it will take a long time to reach the user - it usually means waiting for the next OH version. To have the fix available in the next âcurrent versionâ (e.g. 5.1.5 at this time), an additional decision must be made, by maintainers, that the fix should be backported. And even then, weâre probably talking about weeks before it reaches the user, if the user is one of those that constantly update to the latest version. The rest of the users it wonât reach at all.
To me, the difference between the above, and making a fix available to all users, regardless of OH version, within hours, is fundamental and is such a huge âproâ that I canât really find words to express it.
I believe that, but I wouldnât credit the âbest practicesâ for most of this. The fact that somebody digs through the code one more time in itself is probably âthe most valuable partâ. I often find myself achieving âthe same effectâ without the involvement of others when I write tests. Itâs often not the tests themselves that are the most useful, but the fact that it forces me to go through the logic of everything once more. I often discover things that âare less than idealâ when I do that, and I consider this the main benefit of writing tests, even though it is mind-numbingly boring. So, Iâd say that getting somebody else to go through your code will almost always be a plus, regardless of whether itâs a part of the âmaking a binding official processâ or not.