Unfortunately also the Tinkerforge binding does not work in OH2 Beta 1, issue created.
With the last OH2 snapshot (#89), I was able to test the Mios binding and it simply does not work but without any errors logged. I created a specific topic for that: [Fixed] Mios binding 1.8 not working in openHAB2
I tested the Freebox 1.8 binding in OH2 snapshot #89 and I encountered a similar problem that with the Mios binding, that is the binding seems to start correctly with no erros but items are never set.
22:24:52.017 [DEBUG] [org.openhab.binding.freebox ] - BundleEvent STARTING - org.openhab.binding.freebox
22:24:52.025 [DEBUG] [ng.freebox.internal.FreeboxActivator] - Freebox binding has been started.
22:24:52.029 [DEBUG] [org.openhab.binding.freebox ] - BundleEvent STARTED - org.openhab.binding.freebox
22:24:52.182 [DEBUG] [org.openhab.binding.freebox ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.freebox, component.name=org.openhab.binding.freebox.binding, component.id=156, service.id=265, service.bundleid=159, service.scope=bundle} - org.openhab.binding.freebox
22:24:52.199 [DEBUG] [ding.freebox.internal.FreeboxBinding] - Appname : openHAB Freebox Binding
22:24:52.203 [DEBUG] [ding.freebox.internal.FreeboxBinding] - AppVersion : 1.8
22:24:52.207 [DEBUG] [ding.freebox.internal.FreeboxBinding] - DeviceName : openhab2srv
22:24:52.215 [DEBUG] [ding.freebox.internal.FreeboxBinding] - AppID :org.openhab.binding.freebox
22:24:52.231 [DEBUG] [org.openhab.binding.freebox ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.freebox.FreeboxBindingProvider}={component.name=org.openhab.binding.freebox.genericbindingprovider, component.id=157, service.id=264, service.bundleid=159, service.scope=bundle} - org.openhab.binding.freebox
22:24:52.834 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'ntp:ntp:local' has been updated.
22:24:52.847 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
22:24:52.945 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
22:24:54.110 [INFO ] [.openhab.core.internal.CoreActivator] - openHAB runtime has been started (v2.0.0, build 201601150204).
22:24:55.676 [DEBUG] [ding.freebox.internal.FreeboxBinding] - Apptoken valide : ...
22:24:57.061 [INFO ] [ding.freebox.internal.FreeboxBinding] - Freebox binding properly configured
22:24:57.062 [INFO ] [b.core.service.AbstractActiveService] - Freebox Refresh Service has been started
I am suspecting a general compatibility problem.
Maybe the refresh service of the bindings is never run ?
Ok, at least a good news 
It looks like the Freebox binding 2.0 is working mostly.
Some of the data retrieved by the binding (and correctly set in the items) are not displayed in my sitemap. It concerns all my string items. For example, this one:
String Freebox_cs_ipv4 "ipV4 [%s]" (GFreebox)
Could it be related to this issue: https://github.com/eclipse/smarthome/issues/871 ?
I will do more in depth testing of this binding later. As I previously explained, unfortunately some of the features implemented in the 1.8 version are missing in the 2.0 version.
Yes, it seems so.
Let me give you a quick update:
The Karaf-based runtime now uses the Apache Felix (instead of Eclipse Equinox) implementation of the OSGi Declarative Services and ConfigurationAdmin specs. In theory, this should not make any difference, it practice it seems it does.
In general, the Felix implementations are said to be cleaner, more modern and better maintained, so they should not be a bad choice. Most problems that are currently coming up are actually due to the fact that our existing codebase is not clean and has some bugs - which nobody ever noticed because Equinox let that pass.
For one such issue, we have now decided to not clean up the bundles, but rather activate a compatibility flag (a kind of “dirty mode” - this is about the messages regarding missing import-packages that you have seen: Enable boot delegation for backward compatibility · Issue #85 · openhab/openhab-distro · GitHub
Another problem with many add-ons seems to be the component activation (if the services should be available at start, this needs to be declared).
The ZWave 1.9 binding has just been fixed this way: Z-Wave: Added logging and set immediate="true" for activebinding by cdjackson · Pull Request #3837 · openhab/openhab1-addons · GitHub
The KNX 1.9 binding as well: made the KNX binding work by activating all components at bundle startup by kaikreuzer · Pull Request #3839 · openhab/openhab1-addons · GitHub
So I am confident that others will need the same simple fix.
You can get a clue, if you run
scr:list
and check if all components of your binding are activated - I have seen many situations where this is not the case.
I expected that I could manually activate it through
scr:activate <component name>
but somehow this does not have any effect for me. But in any case: adding immediate="true"to your components should not harm and there is a good chance that it will make it work on openHAB 2 - have a try and report back, please!
@Kai: ok I will try but unfortunately probably not during the coming days…
openhab> scr:list | grep mios
25 | ACTIVE | org.openhab.binding.mios.activebinding
26 | ACTIVE | org.openhab.binding.mios.genericbindingprovider
openhab> scr:list | grep freebox
31 | | org.openhab.binding.freebox.binding
32 | ACTIVE | org.openhab.binding.freebox.genericbindingprovider
openhab> bundle:list
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
-------------------------------------------------------------------------------------------------
10 | Active | 80 | 2.22.1 | jersey-min
11 | Active | 80 | 2.3.0.201506221200 | JAX-RS Gson Provider
12 | Active | 80 | 5.3.0.201512270850 | OSGi JAX-RS Connector
13 | Active | 80 | 2.3.1 | Gson
14 | Active | 80 | 10.0.1.v201203051515 | Guava: Google Core Libraries for Java 1.5
15 | Active | 80 | 3.0.0.v201312141243 | Google Guice (No AOP)
21 | Active | 80 | 3.2.0.v201101311130 | ANTLR Runtime
22 | Active | 80 | 1.6.0 | Commons Codec
23 | Active | 80 | 3.2.1 | Commons Collections
24 | Active | 80 | 1.1 | Commons Exec
25 | Active | 80 | 2.2.0 | Commons IO
26 | Active | 80 | 2.6 | Commons Lang
27 | Active | 80 | 3.2.0 | Commons Net
51 | Active | 80 | 4.0.3 | Apache Karaf :: Wrapper :: Core
52 | Active | 80 | 3.1.0.7 | Apache ServiceMix :: Bundles :: commons-httpclient
54 | Active | 80 | 2.10.1.v20150123-0348 | EMF Common
55 | Active | 80 | 2.10.2.v20150123-0348 | EMF Ecore
56 | Active | 80 | 2.10.2.v20150123-0348 | EMF XML/XMI Persistence
57 | Starting | 80 | 3.7.0.v20150402-1709 | Common Eclipse Runtime
58 | Starting | 80 | 3.6.0.v20150318-1503 | Extension Registry Support
84 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Config Core
85 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Configuration Discovery
86 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Config Dispatcher
87 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Config XML
88 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core
89 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome AutoUpdate Binding
90 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core Binding XML
91 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core ID
92 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core Persistence
93 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Scheduler Service
94 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core Thing
95 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core Thing XML
96 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Transformation Service
97 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Console
98 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Console for OSGi runtime Karaf
99 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Monitor
100 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Multimedia I/O Bundle
101 | Starting | 80 | 0.8.0.201601082233 | Eclipse SmartHome Net I/O Bundle
102 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome REST Interface Bundle
103 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Core REST API
104 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Sitemap REST API
105 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome SSE REST API
106 | Active | 85 | 0.8.0.201601082233 | Eclipse SmartHome Model Core
107 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Item Model
108 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Item Model Runtime
109 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Persistence Model
110 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Persistence Runtime
111 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Rule Model
112 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Rule Runtime
113 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Script
114 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Script Runtime
115 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Sitemap Model
116 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Sitemap Runtime
117 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Thing Model
118 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Thing Model Runtime
119 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome MapDB Storage Service
120 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome UI
121 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome UI Icons
122 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Classic IconSet
123 | Active | 80 | 2.6.2.v201407030533 | Xtend Runtime Library
124 | Active | 80 | 2.6.2.v201407030533 | Xtext
125 | Active | 80 | 2.6.2.v201407030533 | Xtext Common Types
126 | Active | 80 | 2.6.2.v201407030533 | Xtext Utility
127 | Active | 80 | 2.6.2.v201407030533 | Xbase Model
128 | Active | 80 | 2.6.2.v201407030533 | Xbase Runtime Library
130 | Active | 80 | 5.0.1.v201404251740 | ASM
131 | Active | 90 | 2.0.0.201601150204 | openHAB Core
132 | Active | 80 | 2.0.0.201601150204 | openHAB Karaf Integration
138 | Active | 80 | 1.1.0.201512270850 | Swagger Provider
139 | Active | 80 | 1.5.5.sp1 | swagger-all
140 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Basic UI, Fragments: 144
141 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome WebApp UI
142 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome Paper UI, Fragments: 148
143 | Active | 80 | 2.0.0.201601150204 | openHAB REST Documentation
144 | Resolved | 80 | 2.0.0.201601150204 | openHAB Basic UI Fragment, Hosts: 140
145 | Active | 80 | 2.0.0.201601150204 | openHAB Classic UI Fragment
146 | Active | 80 | 2.0.0.201601150204 | openHAB Dashboard UI
147 | Active | 80 | 2.0.0.201601150204 | openHAB Classic Iconset
148 | Resolved | 80 | 2.0.0.201601150204 | openHAB Paper UI Theme Fragment, Hosts: 142
151 | Active | 80 | 2.0.0.201601150204 | openHAB 1.x Compatibility Layer
153 | Active | 80 | 4.2.3 | Apache HttpClient OSGi bundle
154 | Active | 80 | 4.2.3 | Apache HttpCore OSGi bundle
155 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome hue Binding
156 | Active | 80 | 0.8.0.201601082233 | Eclipse SmartHome UPnP Transport Bundle
157 | Active | 80 | 2.0.0 | JUPnP Library
158 | Active | 80 | 0.8.0.201601082233 | ntp Binding
163 | Active | 80 | 1.8.0 | openHAB MiOS Binding
164 | Active | 80 | 1.8.0 | openHAB Freebox Binding
So for the Freebox binding 1.x, that seems to be a very similar case to ZWave and KNX.
For the Mios binding, the two components are active, so it could be again something else.
PS: is it normal that few bundles are only in state “Starting” like “Eclipse SmartHome Net I/O Bundle” ?
Right, but this binding has never been reported to be working (also not on alpha2), so there can indeed be other problems that need to be analyzed.
PS: is it normal that few bundles are only in state “Starting” like “Eclipse SmartHome Net I/O Bundle” ?
Good question, will need to have a look into that…
@Kai: what do you think about my problem with string items and the Freebox binding 2.0 (just 4 messages before this one) ? Do you want I create an issue ? Or is it the same issue as the one you created ?
This sounds likely, yes.
Changing immediate=true fixed Netatmo, created a PR with the fix: https://github.com/openhab/openhab/pull/3853
Good to know for Netatmo binding. I will surely test myself.
I think I read somewhere that something changed for the certificate management in OH2 and that certificates have to be put in a particular directory ?
Can we have an explanation what we have to do now ?
Thanks
Any news for the weather binding ?
For my very basic usage of the HTTP binding, that is a call to sendHttpGetRequest in a rule, this binding seems to work well in a recent snapshot of openHAB2.
Nevertheless I opened an issue because few errors are logged: https://github.com/openhab/openhab-distro/issues/101
I didn’t do anything different than OH 1.X for certificates. If there’s a way to not have to install the StartCom certs, I’m all ears.
I am not sure if this topic is relevant or not: SSL with OpenHAB2
My feeling would be that there is now a specific keystore for openHAB and so we don’t have to update the JVM keystore. But I am not sure at all.
FWIW, Ecobee and Nest bindings work with no issues on Build #95, installed via Paper UI from online distro. Nice work, @kai and everyone!
1 Like
With the latest OH2 snapshot build #99 (22.01.16) the Tinkerforge binding is working as expected.
Thanks for fixing, issue updated.
Updated status with OH2 snapshot #102:
- NTP 2.0 binding: now OK (config parameter is saved)
- Astro 2.0 binding: now displays dates in UI but still not with my requested format
- RFXCOM 2.0 binding (only used for Oregon sensors): almost OK. I have only a problem with temperatures (format conversion error)
- Freebox 2.0 binding: almost OK. I have only a problem with display of string channels (maybe dates too)
- Hue 2.0 binding: almost OK. Switch ON/OFF and brightness slider not working well
- Mios 1.9 binding: almost OK. I have a problem to control dimming lights
- HTTP action : OK
- Weather 1.9 binding (with Wunderground provider): KO
That would be absolutely cool if smarthome issue #871 could be fixed. My feeling is that it could be the source of several of my current issues.
I realized that I am using the HTTP action not the HTTP binding.