Unfortunately I haven’t been active developing my binding (nanoleaf) for quite some weeks but I would like to pick this up again and I do not want to break anything. Although I have been working with git for quite some time I still struggle with managing remote branches and the like (I am honest). As I don’t want to break anything and don’t want anyone to waste valuable time in fixing something that I did wrong, I’d rather ask a few questions and I would be very happy if someone could guide me.
The last development I did was on 2.5.x and I intend to maintain my binding for OH3 but I guess we still support OH2, don’t we?
-The remote origin is https://github.com/raepple/openhab2-addons.git
What I have done so far:
I locally switched to 2.5.x, fetched and pulled the git repo. Then I did a git reset --hard origin/2.5.x
I locally switched to master, fetched and pulled the git repo. Then I did a git reset --hard origin/master
Both branches tell me that I am uptodate now (but I don’t understand how this is related to the main repo or only my fork?)
So here are my questions as I hope someone can guide me a bit:
Do I have to sync this first with the main repo and if how would I do that?
Or should I proceed differently?
In general what is the best approach for me to continue the development without breaking something and in particular not screwing up the git history when later pushing something which would drive the community mad?
which are the branches I should work on to support OH2 / OH3? Do I have to maintain them separately?
Maybe this has been answered somewhere else but I couldn’t find anything so far.
You will want to sync so your fork matches the latest of what’s checked in to the upstream. Otherwise you’ll be developing against an old version of openHAB.
As for the rest, a maintainer will have to come along and answer. I would guess that the main branch is what you should code against and there would be a 2.5 branch for backporting changes, at least for awhile.
To give some backgroud. With openHAB 3 the openhab-addons repository was ‘reset’. Over time due to all jar libraries, the repository had grown quite big. So therefore the repository was reset. This means all history before that is not available anymore. The history can be found in the archived openhab2-addons repository. As a result of you have a fork before that reset it will show the whole openhab2-addons repository as diff.
If you have an existing local repository, and you still have it pointed to the location of openhab/openhab2-addons you need you need to change the git configuration to point to openhab/openhab-addons.
I have no specific advice what the bast approach here is,as it also depends on your experience. But to get a quick start if you don’t have changes in your own fork. Just fork the new repo (you possibly need to remove your current fork on GitHub) and do anew install locally. Where you can also install it with Java 11.
For development. All new development for openHAB 3 is on the main branch. And openHAB 2.5 is on the 2.5.xbranch. But in the 2.5.x branch in the ooenHAB repo only bug fixes are accepted and only if first a pullrequest for main is submitted.
I think I don’t have major issues that have to be backported at the moment (I am running the binding on 2.5 and it is running basically ok).
Hence, as you suggested I will go for a new fork based on OH 3 and leave 2.5 unless a major issue comes up. Thanks for pointing out java 11 (of course I heard that but I might had forgotten it).
Let’s see how it goes. Keep your fingers crossed for me.
Hey! Glad this is still getting worked on! Once you have everything squared away, do you have any plans to work on compatibility with the “shapes” panels? I just got the hexagon ones, and was bummed to find they aren’t compatible.
Interesting to hear that because I have the new Triangles and they work well with the binding. Unfortunately I don’t have hexagons and it is hard to purchase each of them to maintain the binding…
As soon as I start I may be able to look into it if you provide me details on what is going wrong with the shapes. In this case I would need detailed log information.
When I add my set as a thing, it only shows “Light Panels” or “Canvas” as options for the Nanoleaf device type. I think the hexagons are a different product called “Shapes”. They support touch controls similar to the squares, as well as some other features. I can get the whole array setup in openhab, and successfully do things like change the color, and power it on and off. However when I attempt to add the light panels, openhab doesn’t give me a colorpicker like when I added the whole array. I’ve please see the images below.
Unfortunately I’m pretty new to openHab and not quite sure where to look. Are you asking for the “Thing Type” of the controller? I also added a screenshot of the same section for one of the panels.
It is the modelId, which in your case is NL42 but currently I allow subpanels only for controller types NL29 - exactly what I expected. Unfortunately currently I see no other way of hardcoding all to be supported types.
@stefan.hoehn My general advice - if you want to avoid troubles in future try making your binding standalone. At least you won’t be a victim of “reset” action. Your repo will most likely stay compact for long time until you need to do above move.
It isn’t. So it’s only a solution if you intend to maintain a binding yourself and do all the general work to keep the binding up-to-date. If it’s only to not have to worry about a reset I would say it’s not very useful, because there have been far more changes over the last year that you would have to do yourself. So if you want to control development of binding in your ownn hands or want to commercialize a binding it makes sense.
Certainly if you very infrequently want to make changes to a binding in the openHAB repo and you worry about keeping your repo up-to-date locally. I would say to just do a new installation of eclipse, checkout a new branch and push that branch to GitHub to create a pull request from.
I think I’d rather stay on board with the rest of the gang and get all the benefits und support from people like you, Hilbrand.
Honestly the reset doesn’t worry me too much, anyway.
Same way as other bindings till now - using ie. eclipse marketplace. As far I know it still works.
I would not overestimate the work which is made on automatic basis. Past year/release when looking at code changes is mainly:
Replacement of org.eclipse.smarthome → org.openhab.core namespace
Rename of folders ESH-INF to OH-INF
Removal of SmartHome name from class names. Most relevant change in this area is move of SmartHomeUnits which become now Units clashing with Units class in tec-uom.
The other work which is not relevant for binding to work is:
Copyright year updates
Endless plays with @Nullable and @NonNullByDefault annotations
Formater / spotless fixes
Hard work which is core of your binding must be made by you anyway.
What you get by moving away:
No merge conflicts with stuff modified by others.
Independent branching which does not require thousands of files to be checked out.
Your binding build breaks by your fault only.
Fast CI/CD cycles (ie. using github actions Christian did)
Independent release cycle - you can flush your binding faster than schedule OH-addons release.
Freedom of IDE usage - no need to fight with Eclipse setup if you don’t know it.
Independence of long PR review queue.
Keep in mind that the “pros” side is mainly about your productivity. You can always decide if you want to contribute ready-to-use binding back to OH addons after having it solo.
The eclipse marketplace isn’t supported in openHAB 3. I made a proposal for a new marketplace, but haven’t got much time to complete my original proposed plan. Feel free to give your thoughts.
Regarding how to handle an add-on. I don’t think we should make it a contest what the best way is. There are pros and cons to both ways. If one has only limited time/interest to maintain an add-on I would recommend to have it included. Several bindings have been left behind because they where not included and the original author didn’t kept the binding up-to-date.
I think we shouldn’t make it a contest, but we shouldn’t be afraid saying what pros and cons are. Given that the only one way which gets promoted on this forum is one big repository holding hundreds of integrations I think its valid to discuss all options.
This attitude leads core maintainers to assumptions in most basic aspects such as documentation URI: Binding should be able to provide own documentation location · Issue #1401 · openhab/openhab-core · GitHub.
Think of it as a valid filter which allows users of these to show up and other maintainers to step in. It also trim down integrations which are not relevant. Kind of a vacuum for stale code where nobody have interest to move it forward.
