We need your help on testing!

Setup, Configuration and Use 1.x Compatibility
81

That fixed it @watou, InsteonPLM with a PLM works :slightly_smiling:

What needs to change with the binding so this doesn’t need be ran from the prompt?

82

Regarding the netatmo binding, I noticed a minor bug. When I start openHAB2, I got this error:

15:47:12.895 [INFO ] [ding.netatmo.internal.NetatmoBinding] - The following Netatmo measurements are not yet configured:
        xx:xx:xx:xx:xx:xx#Temperature (Indoor)
        xx:xx:xx:xx:xx:xx#Noise (Indoor)
        xx:xx:xx:xx:xx:xx#CO2 (Indoor)
        xx:xx:xx:xx:xx:xx#Humidity (Indoor)
        xx:xx:xx:xx:xx:xx#Pressure (Indoor)
        xx:xx:xx:xx:xx:xx#yy:yy:yy:yy:yy:yy#Temperature (Module extérieur)
        xx:xx:xx:xx:xx:xx#yy:yy:yy:yy:yy:yy#Humidity (Module extérieur)

When comes the next refresh cycle (5 minutes later), everything is then OK.

As a result, you have first values only 5 minutes after starting openHAB2.

I have not checked if the behaviour is the same in openHAB 1.8.

83

Could you create a PR similar to this one, but that depends on the openhab-transport-serial feature? That way the binding can be installed from the Paper UI, and installs dependent features at the same time.

Separately, the aspect of the InsteonPLM binding that depends on the org.apache.http bundle will still fail, so I’m assuming you tested a different aspect of the binding?

84

@watou, I’ve already did that. https://github.com/openhab/openhab/commit/2cd8362a26555f21d0c742fa04311fd5d131b7d4#diff-9a92cb6081222067edd1cc1e2ada4c76.

I manually copied a snapshot build if insteonplm to the addon’s directory, along with the config file. I assume that’s why things weren’t plumbed correctly?

Yes, I used a PLM via a USB (serial) port vs the hub that uses http. So as long as somebody uses either a USB or serial PLM, it should work.

85

Yeah, a distro defining the dependent features is needed for the dependent features to be installed via Paper UI. So make a PR like you did for netatmo and I will review and merge.

86

It was done awhile ago by @Kai :

What is missing is the ability for OH2 to detect OH1 addons in the /addons directory and install the oh1 compatibility layer. Otherwise, this will continually come up.

87

I think an issue against one of the other repos would help, unless it’s already documented somewhere that manually installing dependent features is required if you drop an addon JAR in the addons directory.

88

@kai, which repo is the correct place to create an issue for this?

Rob

89

In the future, users could develop and put personal 2.x bindings in the addons subdirectory. So the compatibility layer must not be installed because a jar is present in this directory.

90

It is documented here. We might also add a note to the README file within the addons folder - feel free to create an according PR for https://github.com/openhab/openhab-distro/blob/master/distributions/distribution-resources/src/main/resources/addons/README.

91

Btw, @watou and @Lolodomo, you are doing an amazing job on getting 1.x add-ons working again - THANKS!

92

@Kai, OH2 should be smart enough to detect a OH1 binding and make sure this step has been completed:

Install the 1.x compatibility layer by running feature:install openhab-runtime-compat1x in the openHAB console

Not everybody reads the documentation :slight_smile: especially with how simple it was to do this with OH1.

93

I agree with you. Even me who knows this constraint, I sometimes forget to do it. It should be done automatically, if technically possible.

94

I doubt that it is. Anyhow, we will soon have all that is working included as installable features, so you won’t need the addon folder anymore, only for rare exceptional cases.
The only thing I could imagine is to introduce another package besides “standard”, e.g. something like “oh1compat”. But this again could be misleading since people might think that you cannot use any 1.x add-ons on the “standard” package.

95

@ranielsen, would you do that?

You and your crew are doing brilliant work, so thank you, too!

96

Note that I have tested only 6 1.x bindings and 5 2.0 bindings.
I remember you wrote we have 160 1.x bindings. That would mean my own tests only cover around 4% of all 1.x bindings. Very low in fact.

Remains to be tested by myself (1.x bindings): MQTTitude, rrd4j, RFXCOM (waiting for a fix in the 2.0 binding) and my powermax binding.

97

MQTT and weather 1.x bindings correctly packaged and working well in OH2 snapshot 111.

1 Like
98

Unfortunately the netatmo binding is broken in this last snapshot. I will open an issue. I get a JSON parsing error.
Issue opened: https://github.com/openhab/openhab/issues/3937

99

I probably missed the PR but the snapshot 111 fixed my issue with Astro 2.0 and incorrect date format for display of astro dates in UI. Thank you.

I will try again RFXCOM 2.0 and Freebox 2.0 in case there was a general fix for display of items in UI.

100

Updated status with OH2 snapshot #111.

Features OK, considering my personal (and so partial) usage:

  • Astro 2.0
  • NTP 2.0
  • Freebox 1.9
  • MQTT 1.9 + MQTT io transport 1.9
  • Weather 1.9
  • MiOS action 1.9 (with patch not yet included in snapshot 111)
  • HTTP action
  • Logging action

Features KO (not working at all):

  • Netatmo 1.9 (was OK in snapshot 106)

Features working but with bugs:

  • RFXCOM 2.0 (not yet tested with snapshot 111)
  • Freebox 2.0 (not yet tested with snapshot 111)
  • Hue 2.0 (not yet tested with snapshot 111)
  • MiOS 1.9 (fix not yet included in snapshot 111)