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.
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.
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.
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.
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.
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.