OH 1.x add-on assessment

Development Add-ons
31

Alex
Thanks for moving your question to the discussion thread
@5iver great poll, great research tool to find out how much these old bindings are being used. From my observations at this early time in the poll running, it seems most the bindings that have more then 1or 2 people using them already have a replacement in the works.

Alex, qualify ‘heavy use’ because I only saw a few that had more then 4 or 5 users and all of those have a replacement planned or in process of being created.
To me, one or two users doesn’t constitute ‘heavy use’

Perhaps but no one wants to do that. No one is stopping anyone who has java programming skills from doing so and so far no one has stepped forward.

32

Easier, perhaps but easier does not mean better. Some of the early design decisions hinder flexibility. Even of they were kept they would need to be ported to Java 11.

33

@Andrew_Rowe

Of course I meant “in heavy use”. That was Kai’s
statement above. Others have used the term afterwards.

What this exactly means, I don’t know.

Actually, all should be ported, but who should do the whole effort. Maybe you can find a volunteer who code the OH1 compatibility layer.

Think of those who have been using the old OH1 bindings for years. These users will not switch to OH3 until they have replaced their old devices. Many have paid huge sums of money. Should they buy everything new?

I do not think that the poll, as great as I find it, can tell the real number. Many do not participate in the survey or only occasionally appear in the forum. Are actually the download numbers determined?

34

ummm… I’m probably not the best person to ask this. I don’t believe it is worth the effort. (imho) Let em die a natural death. The poll results to me kind of bear this out already and early days.

I don’t really thiink this is a huge number of folks honestly. I was just chatting with a fella asking for help upgrading his 1.8 installation and his main rational was that the system had worked almost untouched for three years but new device were difficult to add to the system and he was ready to migrate.

And yes of course the survey isn’t totally representative of all users but it does give a pretty good idea of the slice of folks using this forum on a semi daily basis
Look Alex, I don’t want to argue, I just wanted to state my opinion, which is… let it go

35

I think the idea is that those v1 devices will be “crippled” running on OH2 with some linkage between OH2 & OH3. The developers want to minimize that impact though.

36

There are several OH1 bindings which are neither listed as legacy nor non-legacy, as they aren’t marked as compatible to OH2 (for example asterisk and vdr, both are sort of working by installing them manually).

So, these should also be addressed as there are some users which did not switch to OH2 yet, because of these incompatible bindings. :slight_smile:

1 Like
37

All addons in the openhab-addons1 repo, minus persistence and the ones marked as legacy, have been added to the poll. This includes the addons that are not included in the feature.xml and distro.

1 Like
38

Just wanted to add a link to a post Udo made in poll thread and comment on his post but did not want to clutter poll thread. Here is post

I believe at some point in the recent past (maybe earlier in this very thread) there was talk of baking in some time of usage tracking. I think the idea got dumped because of privacy issue

1 Like
39

This binding is also very complex due to the nature of the Insteon protocol that has been reversed engineered.

1 Like
40

I’m using the anel (hut) with lots of anel devices

41

Although a relative newcomer to OpenHAB (5 months) I have invested hundreds of hours and thousands of dollars in my OpenHAB installation. As a result, I am reading this thread as a stake holder with great interest and at times great concern. Having professionally managed a software development group in a past life I understand the difficulties of maintaining legacy code, even when it is critical to the enterprise. Being a user community of volunteers only further complicates matters. It is in no one’s interest to have only one, or even a few, people who understand and can maintain the code. When these few individuals have other priorities, progress on OpenHAB slows. This is to be expected as we all have lives away from OpenHAB.

From what I have read, not every post in this thread but more than 50%, it is a done deal that the 1.x compatibility layer will not be maintained going forward unless a new Maintainer steps forward, which is unlikely. Therefore, the question before the community is how do we move forward without totally stranding early adopters who are heavily invested and still using 1.x bindings. And let’s not forget as early adopters they helped to grow OpenHAB to what it is today.

If I may be so bold as relative new comer, allow me provide a somewhat different perspective of OpenHAB and what has attracted me to adopt and invest in this platform. For many this a hobby, but for others like me, our OpenHAB installation is an appliance just like a refrigerator or microwave oven. It runs my house. Just because Samsung or Bosch introduces a new model appliance with wiz-bang features doesn’t mean I have to run out tomorrow and buy it, especially if my current appliance remains functional for my needs. Likewise if I don’t need the new features of OpenHAB 3.0, no one is forcing me to change. As long as 2.x remains an available option I may be content to stay where I am. If I decide to get a new piece of hardware that is not supported in 2.x, then that is my choice and I will be faced with decision as to how best to move forward. Given my current investment in time and money, this will be critical juncture as to whether to stay with OpenHAB or move to another platform. To be brutally honest, if I wanted a bleeding edge, YAML/python based, unstable platform on which to build my implementation I would have chosen Home Assistant, not OpenHAB. I chose OpenHAB because it is a stable platform that has evolved steadily, but carefully, over years of development and that I can trust in my home, uses broadly accepted and used programming languages such as JavaScript, has a terrific and broadly based user community, and while the initial learning curve was steep it was manageable. It is hard for me to imagine anyone in the foreseeable future without a technical grounding being able to use any Open Source Solution to develop a true automation system. This is why the commercial systems, such as Crestron, can charge as much as they do. I’d love to be proven wrong, but I don’t see it. This stuff is complex and well beyond the average Alexa user.

So if the intent of OpenHAB 3 is to make it easier for developers to develop and maintain code, I am all for it. If the intent is to add bells and whistles, and the latest hardware du jour, to compete with Home Assistant, et al to attract new users, then I would be reluctant to follow that path. Sometimes being an astute follower, learning from the mistakes of others, can be more beneficial than being on the bleeding edge, especially if alienates or loses a chunk of the current user base.

I think Kai may have already declared this, but my vote is to maintain version 2.x in near term but add no new features. If 3.x bindings are backward compatible with 2.x (ie 2.x and 3.x bindings are interchangeable as seems to be the proposed development path since the solution for 1.x bindings in 3.0 is to convert them to 2.x bindings) then that would be great. The focus for 3.0 should be as the next generation platform with a modern, well documented and maintainable code base so that anyone with a little programming expertise can help maintain it going forward and no one individual is overburdened. This is realistically at least 12-18 months away as far as I can tell. Going forward for the foreseeable future, continue to make 2.4/2.5 available for dl for all platforms but marked as EOL with no active development or on-going maintenance. Nothing lasts forever, not even my refrigerator, so at some point we all have to make a decision whether to migrate or find another alternative that better meets our needs. For sure this will be easier for some than for others, depending upon the investment. Nonetheless at that point down the road we will have no option, but each of us will be better informed as 3.x will be mainstream and well implemented just as 2.x is today.

3 Likes
42

Yves
did you vote in poll?

43

My understanding is that the binding uses the OH API in a way that is not allowed in OH 2. So there never will be a replacement for that feature, at best not int the way that the weather binding does it. I could be remembering incorrectly though.

@BobA, @marcel_erkel, @5iver, it seems like it would makes sense to move everything after Removal of the OH 1.x Compatibility Layer - #161 to it’s own thread. It seems to have veered off to it’s topic and I frankly hate to see this long and contentious thread continue to pop up in everyone’s feeds.

44

Fine with me. Then this thread could also go back to the topic of the removal of the compatibility layer instead of which bindings it would concern which are two different things.

45

It uses webview, doesn’t it?

46

To display it on the sitemap, yes. But it exposes the Item states themselves in a way that isn’t allowed for OH 2 bindings, I believe.

1 Like
47
48

I use this one New binding addon for siemens Hvac controller OZW672.01 which is not in the lis

49

That binding was never merged into the OH baseline so is out of scope. Only those bindings that are officially part of the OH baseline (i.e. can be found through PaperUI, have a readme page in the docs, hosted in the openhab/openhab1-addons repo are in the list. And it appears to not have received an update in years. If no developers stuck around to get it merged into the baseline in the first place, I doubt there are any around to rewrite it as a 2.x version binding.

In that thread in March sihui posted

But that same post points to an external tool to make the integration possible.

1 Like
50

Rich, fair enough. It is a workaround accessing the BSB directly via this opensource community device. However I won’t go that route, after having spent over 500€ on an official Siemens webserver with official APIs I prefer that. I don’t have the necessary java skills to write or change an OH binding but I found out that it’s actually very easy to interact with the OZW672.01 in Node Red. So I’ll use node red as interface and transfer data to and from OH via Node Red.