Removal of the OH 1.x Compatibility Layer

Development
163

If you have separated the business logic and openHAB interface, which is always recommended anyway, there is not much to do actually. You need a Factory class and a few ThingHandler classes, depending on how much you want to follow the Thing approach. You could in theory just add one single Thing with all the configuration that your OH 1.x binding used and therefore one ThingHandler class.

The problem with other OH 1 bindings is that their code base is old and they do not use new library versions and best practice dependencies (like gson instead of jackson). If you have a relatively new codebase, you do not suffer those issues.

1 Like
164

Is there sample code and documentation on how to do the minimal conversion, that might help get some of the more complex bindings migrated such as insteonplm. It does appear to have the openHAB interface separated from the business logic (openhab1-addons/bundles/binding/org.openhab.binding.insteonplm/src/main/java/org/openhab/binding/insteonplm at main · openhab/openhab1-addons · GitHub).

1 Like
165

No there is no such thing. A blog post with a walk-through would be probably be the right format.

2 Likes
166

Thank you, @David_Graeff and @ranielsen .

When I have some time I will study the openHAB developer guide, and if as you say the migration is simple, I will try to rewrite the binding to be compatible with the 2.x model.

What I don’t know how long it will take me to do it. Lately I don’t have any free time.

Greetings.

1 Like
167

Hi
it would be cool to have such walk-through.

I would be very much interested in the migration of the LCN binding.

Tim

168

See Tutorial: Migrating OH 1 addon to OH 2: preparing (1/x)

It’s a work in progress but already very useful.

2 Likes