We need your help on testing!

All,

I have tried my very best to fix the most critical issues in openHAB 2 and its compatibility layer.
There is already a good list of 1.x addons being successfully tested with the openHAB 2 runtime (see https://github.com/openhab/openhab2/blob/master/docs/sources/addons.md#compatible-1x-add-ons).
Nonetheless, considering that we have by now more than 160 1.x addons, this is still a too small number.
I would therefore like to encourage you to also test all other addons on the latest openHAB 2 runtime snapshot (available at https://openhab.ci.cloudbees.com/job/openHAB2/).
See https://github.com/openhab/openhab2/blob/master/docs/sources/installation/compatibilitylayer.md#how-to-use-openhab-1x-add-ons on how to do this.

The most obvious candidates to do these test are of course the original authors of the addons - so please step forward!

If you have tested an addon successfully, it would be great if you could create a PR like https://github.com/openhab/openhab2/pull/282/files for it.

The goal for me is that openHAB 1.8 should be the last release which comes with its own runtime and designer - after this, openHAB 2 should be stable enough as a replacement for all users. Having compatibility with all existing addons is therefore vitally important, so I count on you!

I have also talked to Thomas that any new contribution of an addon has to be tested against openHAB 2 in order to be accepted to be merged - I have also documented this requirement at https://github.com/openhab/openhab/wiki/How-To-Contribute#a-note-on-openhab-2-compatibility.

Please let me know if you have any questions. If not, I am very much looking forward to many positive PRs about compatible addons!

Cheers,
Kai

6 Likes

Kai

I however think that some bindings will not be migrated or will need a new lead to maintain it

For example, plugwise I wrote but I do not use it anymore. I have little interest to maintain it

Maybe we need a table with binding name, author, new lead required, new lead name,
?

K

1 Like

I think for the moment we can deal with such questions, if bindings reportedly stopped working and nobody can be found who fixes it. For openHAB 2, there is already the concept of maintainers: https://github.com/openhab/openhab2/blob/master/project-orga/MAINTAINERS.md

Would I be correct if I said that you don’t want other areas tested at this time. For example I find that some of the Paper UI is not following the expected behaviour in terms of saving settings and dismissing the settings dialogs for Things. But I understand it is described as a prototype and not necessarily an intended final design at this stage.

You are right that the Paper UI is indeed still under development and thus I do not ask for any direct feedback on this. If you come across obvious bugs in it, feel free to report them to https://github.com/openhab/smarthome.paperui/issues.

My request for help on testing is primarily for ensuring the backward compatibility of the runtime 2.0, so that features that people are using with openHAB 1.8 continue to work once they move over to 2.0.

Dear Kai,

I’m stuck with setting up OH2 with 1.x bindings.
Following the instructions on https://github.com/openhab/openhab2/blob/master/docs/sources/installation/compatibilitylayer.md#how-to-use-openhab-1x-add-ons
I copied all old 1.x bindings which I am now using in my productive environment to
/Users/dirk/openhab2-master/git/openhab2/distribution/openhabhome/addons/
and the openhab.cfg to
/Users/dirk/openhab2-master/git/openhab2/distribution/openhabhome/conf/services/openhab.cfg ,
I added the -Dgnu.io.rxtx.SerialPorts=/dev/tty.usbserial-A50285BI to the Run Configurations in Eclipse.
and for sure I restarted the runtime (several times).
But none of the bindings/ components is being recognized. Also the log displays nothing helpful.

What is ${openhab.home}? Is it like “/Users/dirk/openhab2-master/git/openhab2/distribution/openhabhome” in my case?

Did I miss something?

I am running OH2 on Mac OS 10.10.5 with Java 1.8 using FS20, FHT, S300TH components with CUL over USB (/dev/tty.usbserial-A50285BI)

Thanks in advance
Cheers
Dirk

Hi Dirk,

the section “How to use openHAB 1.x Add-ons” is about using the binary distribution and not about setting it up within the IDE. For using it in the IDE (to be able to debug etc.), see the steps described at “How to solve problems with a certain add-on?”
This screencast shows a similar process, merely with Eclipse SmartHome instead of openHAB 1 bundles.

Hope this helps!
Kai

Hi,
I only wanted to customize my new DBMS Persistence Service for OH2, but I am already advised on the 2nd paragraph to stumble Choosing a namespace. :wink:

Where to make the bundle for OH2 / ESH available?

  1. As OH2 compatible OH1 Bundle
  2. In the Namespace org.openhab
  3. In the namespace org.eclipse.smarthome

Option 1 should already be fulfilled remains to be tested as you describe above.
Option 2 and 3 have consequences.

DBMS could replace the existing JDBC-based services like MySql, H2 (and my reclusive [PostgreSQL] (https://github.com/openhab/openhab/pull/2805)) in the medium term and make redundant. At least to avoid redundancy code was the [Motivation] (https://github.com/openhab/openhab/pull/2805) to start DBMS.

From the perspective of the main developers, is there an interest to integrate more deeply this generic Bundle? Respectively, does it fit at all the architecture/concepts?

I can not and will not judge this. OH2 / ESH is too new for me.

Thanks
Helmut

Hi Helmut,

The question is whether there is at all a need to port the persistence service to OH2. So far, there hasn’t been any changes in the persistence APIs (besides the namespace change), this is something that might come in the future. For the moment, it should be perfectly fine to use the 1.x DBMS bundle on OH2 with the compat layer. The benefit of this is that there is no code duplication, i.e. you can continue to maintain the code at 1.x and it will be available directly for both OH versions.

Regards,
Kai

Hi Kai,
that simple, that’s perfect.

Thank You
Helmut

I can confirm that the following OH1.8.x bindings work in OH2 for me:

org.openhab.binding.astro-1.8.0
org.openhab.binding.networkhealth-1.8.0
org.openhab.binding.wol-1.8.0
org.openhab.binding.xbmc-1.8.0

I have been using these by ‘just’ copying over my OH1 openhab.cfg file.

While there is a v2 version of the Astro binding available, it doesn’t support events, unfortunately, which is why I had to revert to using the OH1 version. Having said that, it does work without issues.

I have not yet been able to pull requests for these, as my time is limited. If I get a chance to set up the new development environment, I’ll try to submit the PRs.

Hi @avdleeuw, Thanks a lot for testing!
I have added the bindings to openHAB 2, no need for you to create a PR anymore: https://github.com/openhab/openhab2/commit/1592ee5fb44cf76775530a099f4e42bd6576740e

With regards to old vs. new Astro binding: You are right, it would be nice to also be able to use the old one. With the current packaging, it is not easily possible to include both, but for the upcoming new Karaf-based distribution, I have already included it.

Best regards,
Kai

Hi Kai,
I did some tests of Satel binding recently and in general it works well. However there are some minor issues with items that are added after connection to the alarm system has been established. In most cases this is not an issue, but for items that change very rarely it is. I am working currently on a solution and after that I will add Satel binding to the list.

1 Like

Dear all,

at least in my case AVM Fritzbox bindings are not working at all. Maybe I miss something in the way of setup. But OH2 doesn’t seem to “search” for them (I have two 7390 boxes installed). I checked with the new addon provided with Alpha2 package and as well imported the addon from 1.7 addon package.

fritzaha:fritzbox.host=192.168.223.254
fritzaha:fritzbox.port=80
fritzaha:fritzbox.protocol=http

For the primary box as in openhab.cfg

Regards,
Stefan

FYI: I have created a separate topic, so that this thread is not polluted.

@avdleeuw Mind that the Astro 1.8 binding relies on Timer threads, these are removed in the 2.0 binding. Just for our information, can you telnet into your OH2 runtime and issue a “t | grep Timer” command and provide an indication of how many Timer threads you have in your runtime?

Tx
Karel

@kgoderis Please use the “Reply as linked Topic” feature for such discussions, so that this thread does not get off-topic - thanks!

Pretty much a newbie here, some coding experience. Played around with OH1 for a couple of days, decided my time would be better spent on OH2. Got my OH2 IDE all setup. All my devices are Insteon and Z-Wave, only been working with the Insteon so far. With the IDE, I imported the 1.x Insteon PLM add-on, got it working with the Classic UI. I see it’s already listed as tested, so here is the question: What has to happen to make it 2.0? Is that something I can help with?

Nothing has to happen really. A 1.x binding is absolutely fine to use with the new 2.x runtime and these bindings will be further maintained and supported. There is no need at all to port them to the new 2.0 binding APIs. This can happen at a later stage for bindings, where discovery is very helpful and devices can be easily formally described. Therefore testing the 1.x binding as you did is all I am asking for right now!

Cheers,
Kai