All bindings in the official distribution are automatically upgraded with each new openHAB version. The only exception was when we moved from OH2 to OH3, we lost the bindings relying on outdated OH1 architecture. When moving from OH3 to OH4, no binding with OH2 architecture was lost and they were all rebuilt with the last core framework.
So maybe you are talking about unofficial bindings. We can do nothing for that.
That being said, it does not mean that each binding in the official distribution is hardly maintained. We are relying on free contributions for that.
No, if you are talking about legacy bindings, they have been openHAB 1.x Bindings, running in openHAB 2.x with the „legacy-layer“.
Plain 2.x Bindings have been migrated to the next major versions.
You may be right. That is beyond my expertise as I only started to use OH at v2.2. From a user perspective it appears as though they 2.x bindings and are listed as such Add-ons | openHAB
You can see for both of these bindings a logo “v1” at top right. They were v1 bindings based on the initial architecture of bindings.
Old v1 bindings were abandoned when moving from OH2 to OH3 because relying on an outdated OH architecture. Between last release of OH1 and first release of OH3, it happens several years, and noone was interested to provide a new version of these bindings compatible with OH2 and further versions of OH.
Starting with OH2, this should not happen anymore, this is one point we take care.
OH4 even introduced mechanisms for an automatic upgrade of things when a binding is enhanced.
Thanks. I see the Panasonic TV binding is marked v1, but I don’t see it for the ISY. Nevertheless, that helps explain what happened. Interestingly both bindings were updated “unofficially” to run with 3.x and actually they run with 4.x with few issues if they are configured manually. I don’t think it would take much work to get them “official”. I have been looking at trying this myself, but my Java skills are not that strong. Anyway thanks for the clarifications.
Unfortunately, I think both both developers have moved on, so unless a new developer picks them up I think we are stuck here. I will try my hand clean them up, but I’m not very optimistic as my JAVA skill set isn’t very strong.
FWIW
For legacy support there’s always the option to run an oldish OH 2.X or 3.X and use the remote binding. So no need to move when it used to work before you updated, just a matter of adapting your setup.
I wouldn’t understand why lack of support for legacy hardware would be a reason to move anyway.
Even though the ISY binding is designated 3.0.1, it works fine with any OH3.x release.
For PanasonicTV the link is
I believe both of these are latest/last updates. @J-N-K worked on the PanasonicTV for a while but decided to no longer develop new bindings. Nevertheless, what he developed before stopping work, is quite good and I have tried it with OH4.x with a manual configuration (text file for thing) and it works with no issues that I found.
The ISY binding will also work with 4.1 using a manual configuration things, but the Insteon Thermostat has an issue that causes bridge to flag between ONLINE and OFFLINE, otherwise if I remove the Thermostat Thing my other 50+ devices work fine.
This is why I believe that it would not take too much work from a JAVA programmer to migrate them to 4.x. However, I also understand everyone has a life outside of OH and these things take time away.
@mstormi In principle I completely agree with what you are saying. In fact it is exactly what I am doing. However my OH system is large, with extensive automation and many hundreds of man-hours invested. For a user with a smaller and perhaps less complex installation it may seem attractive to just move everything to a single installation/platform. Everyone’s use case is a little different. I have considered moving to another platform, but I like OH and I have not found anything better to justify the pain involved with moving. So for now I am happy with federating OH3.x docker with OH4.x docker as everything runs quite well. It is a very viable solution for my use case, until/unless the legacy bindings are updated.
@John_Siemon : for your information, there was an official proposal for a migration of the panasonictv binding. I guess this is the binding you were expecting.
It was reviewed in January 2022 but the contributor finally did not continue.
There are a lot of very good bindings which are no official bindings (like ESPhome, Daikin Onecta, Viessmann…). Even some of them are also not on the marketplace. Wouldn’t it make sense to make those bindings official in order to not loose support in the future? The question is also who takes care that a binding gets official or not?
Only the author/contributor can by creating a PR (pull request). After the review and merge by the addon-maintainers, the binding will be part of the official distribution.
It just takes some time to review all PRs…
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
60
Just to throw my hat in the ring…
I’ve tried OpenRemote V2 and found it hard to configure, V3 just never got out of the starting gate for me. (Required a powerful machine or complex installation)
I tried installing HomeAssistant many years ago and that was a complete non starter, I either couldn’t get it to install or couldn’t get my head around how it worked
openHAB V2 was easy enough to install and I found text based configuration a bit of a mountain to climb, but my head adapted to it well.
V3, migration at first, then a complete re-write of Item led to a lovely stable environment that does everything my wife and I need.
(Simple basicUI in Android app and voice control)
The Velbus official gateway computer now runs a version of HomeAssistant, that I’m encouraged to learn and sell.
After a long “on-boarding” and video creation session with a Velbus HQ tech, I understand why a low tech user / installer might like it, but for my mind, I just can’t understand how the components work together or how to arrange the UX to something I like.
Now I’m getting approached by the team at Trigrr to partner with them and “sell their solution”
My conclusion is…
(Like with all hardware)
No one platform / system is appropriate for every situation.
when i started many years ago with home automation I looked into HA and OH
My impression, at that time, was that OH was much mature compared to HA.
For that reason I started with OH. OH had a steep learning curve for me.
At the moment it is running OH3.4 in a Linux container (LXC) on a Proxmox 8.1 server
175 things, 632 items
one big rule file of 3000 lines…
no comercial bridges (like HUE etc)
heavy usage of mqtt (zigbee2mqtt and zwave ui)
many bash / python scripts that interact with OH
Things that can be automated in the house are controlled by OH.
OH is very very stable, this is very important to keep the relation with my wife at the current level.
Once in a while OH container crashes with a oom (out of memory) error.
The reason of this oom error is still in progress …
However in such a situation OH recovers within a few minutes without manual intervention.
So for me there is no reason to leave OH.
a verry happy OH user …
anton van der leun
