Removal of the OH 1.x Compatibility Layer

Ok, it seems really many poeple like to do this. For me it isn’t really a server, but when I think server I think of min 8 drive bays and so on. So a small server would be a NUC for me. And that’s really small to me…

IIRC it was mentioned the compatibility-layer is in the end an OH1-Core which is running inside OH2. So if the compat-layer isn’t there in OH3 wouldn’t it consume less RAM (of course it depends of the bindings used and so on, but you know what I mean?)
And besides this may be when OH3 is ready there is a PI3++ or PI4 with a little more RAM than today. I don’t know if it is really a problem to run OH1 on the PI, too when time has come. But as said, I am not really a PI-expert.

Yeah it‘s not a server in the classic term of servers.
As Tobi said, it‘s a smart home server or better defined a openHAB server. In terms of software not hardware.
Many users or techies are using RasPis for their smart home installations.
There‘s better hardware for sure, indeed a RasPi is a good compromise for this purpose (openHAB).

A RasPi 4 wont be released before 2020 :wink:

Of course the pi is a kind of server here. It’s just for me no really a server. But by definition it is serving services and is a server and is quite powerful for its size, thinking of what power servers of my definition had 20 years ago!
Ok, but OH3 isn’t coming before 2020, either. Is it? :slight_smile:

I believe openHABian supports Pine64 out of the box. But if not, the manual install of openHABian will work on any Debian based distro. I’ve used openHABian on an Armbian running on a BananaPi without problem.

It depends on what else you have running on your RPi. From what has been described, the OH 1.x Compatibility Layer is almost a separate copy of OH 1.8 running on your OH 2 Karaf. Remove that, perhaps it frees up enough to run it as a separate application instead of as a bundle inside the one Karaf.

To raise a more philosophical question, what is the responsibility of any software project to provide backwards compatibility? You have extreme cases like Microsoft Windows where one can almost run just about any software created for Windows in the last 20 years still. Then you have phones like Android and iPhone. On a lark I tried to get my old Moto Droid (the one with the slide out keyboard) to run. Nothing worked.

Losing backward compatibility does come at a cost in loss of users for sure, perhaps loss of developers too. But maintaining backward compatibility comes at a cost to and I’m hearing from the developers that they are no longer willing to pay that cost.

It’s not ideal, but I can’t think of a better compromise than what is proposed, running multiple instances of OH and federating to retain support for the bindings that no one has been willing to migrate to the new architecture (for what ever reasons).

But it will have more RAM. :slight_smile: And I wouldn’t expect OH 3.0 to be released too much before 2020 either. The timing might work out nicely.

And to directly address CalDav, there has been work in David’s PaperUI-NG study to bring more CalDav capabilities into OH proper which might be suitable for replacing this binding. The devil is in the details of course.

This really sounds great and would resolve some problems for me! Would you give me a hint where I could find more details on that? Thanks :blush:

The UI-study of @David_Graeff you can find here.

1 Like

@nibblerrick Would you have a hint in which point within the 192 contributions in that discussion? :slight_smile:

I would have to skim through the thread again. But I think you can do this on your own. The other information in that thread is quite interesting, too!

2 Likes

Ok, but let us be more specific on what is affected. For my OH installation I just checked all used bindings and found out that I am using actively 9 1.x bindings which then would be left behind:

1.14.0.201901260356 │ openHAB Mail Action
1.14.0.201901260356 │ openHAB CalDav Binding
1.14.0.201901260356 │ openHAB CalDav Calendar
1.14.0.201901260356 │ openHAB Expire Binding
1.14.0.201901260356 │ openHAB FritzboxTr064 Binding
1.14.0.201901260356 │ openHAB NetworkHealth Binding
1.14.0.201901260356 │ openHAB Serial Binding
1.14.0.201901260356 │ openHAB SNMP Binding
1.14.0.201901260356 │ openHAB JDBC SQL Persistence bundle

Compared to that only 7 2.x bindings:

2.5.0.201901280820 │ AVM FRITZ! Binding
2.5.0.201901280820 │ D-Link Smart Home Binding
2.5.0.201901280820 │ NTP Binding
2.5.0.201901280820 │ SomfyTahoma Binding
2.5.0.201901280820 │ Tankerkoenig Binding
2.5.0.201901280820 │ ZWave Binding
2.5.0.201901280820 │ Exec Binding

I am aware of the anouncement that there will be probably replacements for actions and persistence bundles but even then still it would be 7:7. So a loss of 50% of functionality when expressed in number of affected bindings.

I only see 2 bindings left in your case : CalDav + FritzboxTr064 (if we indeed can port all persistence services). All others have an OH2 variant.

  • Actions would not be left behind. There is already an approach identified to move them to 2.x
  • OH 3 is likely getting native support for scheduling
  • Expire, to quote Kai, should have been implemented in the core in the first place and not been a binding
  • I believe the is some sort of 2.x binding for Fritz but let’s say it doesn’t do what you need
  • There is a 2.x replacement for NetworkHealth
  • Persistence bindings will not be left behind. There is already an issue open I think to move them to 2.x.

So you are really only talking about 3 OH 1.x bindings: FritzboxTr064, Serial, and SNMP. And if the scheduler doesn’t do what you need then 5 with the two CalDav bindings.

Are there 2.x versions of Serial and SNMP in the works? Only 1.x versions appear in the OH Docs right now.

Are you sure?
Network Health Binding: I am running OH on Windows and there the Network Health Binding unfortunately is the only workable solution (as the newer Network binding will always tell you all devices are online even if they are not).
SNMP: I cannot find any 2.x version
Expire: I cannot find any 2.x version
Serial: Semms to be needed for Z-Wave(?) and 3rd party bluetooth binding from marketplace(?)

I believe that bug has been fixed. If not, it is a bug that will be fixed I’m sure long before OH 3 is released.

Not the serial binding. If I understand correctly OH 2 has a serial communication service that all bindings that need to talk to serial devices can use instead of having every binding implement their own. That service is not the same as the Serial 1.x binding.

The 2.x binding doesn‘t offer what the 1.x TR064 binding can do, it‘s only for the smart home part of AVM.
The TR064 binding is to get informations from a FritzBox or change some things like Wifi or Call Deflection.

1 Like

And have you tried to convince the new binding maintainer to incorporate the features that you need? :slight_smile:

I was waiting for that fix since OH 2.1, and after 1.5 years of waiting I gave up and switched back to 1.x NetworkHealth. But I will try again right now to check.

No.
I‘m currently not at home and only have my phone with me.
I‘m going to do so when i‘m back home.

Just checked it, everything is reported to be online, the bug is still there. So I also doubt that the bug will be fixed long before OH3 as it has not been fixed for years now.

What Java version are your running because the last comment in the issue indicates the problem was a JDK bug and it has been fixed in Java 1.8 Build 138.

Did you look at the thing status or at the online channel? If the online channel reports a thing as online if it is not, please open an issue at openhab2-addons repository. I‘ll have a look then.

1 Like