Running ESH/OH2 parallel to OH1.x

[kgoderis]

I just wanted to start a new thread on how to migrate from a OH1.x environment to a OH2 ESH-backed environment, given that (1) there will be a compatibility binding available in OH2 to support OH1 bindings on the one hand and (2) the path to migration of each binding will be long and depending on community effort.

I see some possible scenarios here:

1. Run ESH/OH2 next to OH1.x on the same host (possible? possible from OSGi and java VM point of view?), and have those 2 interact via
   a. OSGi bus
   b. MQTT
   c. ....?
2. Pray the Gods to be merciful to Kai and have OH1.x compat. lib in place without too many hiccups
3. Same as 1. but without interaction, loosing thus some functionality, and having to operate 2 GUI's to control things
4. ... ?

[kaikreuzer]

I think there is not the one answer and everybody is free to choose one of the options that is best for him.
Although I hope that around 80% of the bindings should work through the compatibility layer, some will have problems. So it depends on which bindings people use whether option 2 is possible or not.
Furthermore, the configuraiton and rules will require small changes, so it is a migration that users have to do manually. This should not be too much effort, but still.

I plan to release an openHAB 2.0 alpha together with openHAB 1.6 - based on this version I would then like to ask the community to start testing the new runtime and the compat layer.

Am 02.10.2014 um 11:55 schrieb kgoderis notifications@github.com:

I just wanted to start a new thread on how to migrate from a OH1.x environment to a OH2 ESH-backed environment, given that (1) there will be a compatibility binding available in OH2 to support OH1 bindings on the one hand and (2) the path to migration of each binding will be long and depending on community effort.

I see some possible scenarios here:

Run ESH/OH2 next to OH1.x on the same host (possible? possible from OSGi and java VM point of view?), and have those 2 interact via
a. OSGi bus
b. MQTT
c. ....?

Pray the Gods to be merciful to Kai and have OH1.x compat. lib in place without too many hiccups

Same as 1. but without interaction, loosing thus some functionality, and having to operate 2 GUI's to control things

... ?

—
Reply to this email directly or view it on GitHub.

[kgoderis]

You could also install a guideline in which new bindings have to 2.0-based, thereby freezing the 1.x branches. Anyways, 3 bindings done at my side, of which 2 complex ones. Migration goes swift to say the least, so if we make a few other base bindings like http or serial available, then based on these base bindings migration can go even faster....