search

eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
861 stars 784 forks source link

ClassCastException in HandlerFactories #2521

Closed kaikreuzer closed 7 years ago

kaikreuzer commented 7 years ago

There are reports from a number of bindings about ClassCastExceptions, when trying to instantiate a handler for a bridge - the Thing framework seems to hand in a Thing (and not a Bridge) instance in that case. Before the Thing refactoring, this code was working, so it seems that this must be some bug in the framework, not in the bindings. See a log here:

Caused by: java.lang.ClassCastException: org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to org.eclipse.smarthome.core.thing.Bridge
at org.openhab.binding.homematic.handler.HomematicThingHandlerFactory.createHandler(HomematicThingHandlerFactory.java:50)[204:org.openhab.binding.homematic:2.0.0.201611212345]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:98)[104:org.eclipse.smarthome.core.thing:0.9.0.201611191809]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:586)[104:org.eclipse.smarthome.core.thing:0.9.0.201611191809]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:1)[104:org.eclipse.smarthome.core.thing:0.9.0.201611191809]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:177)[97:org.eclipse.smarthome.core:0.9.0.201611191809]
... 4 more

More infos also at https://github.com/openhab/openhab2-addons/issues/1462

sjsf commented 7 years ago

Just to be clear: in this case the binding is perfectly right to assume it's a Bridge:

if (THING_TYPE_BRIDGE.equals(thing.getThingTypeUID())) {
    return new HomematicBridgeHandler((Bridge) thing, typeGenerator);
} // ...
sjsf commented 7 years ago

I'm trying to reproduce this issue with latest smarthome/master and openhab2-addons/master. However, I always correctly get a Bridge instance.

@re-vo-lution can you give me any hints on how to reproduce it? How was the wrong "Bridge" created - via a .thing file or in the PaperUI? And if the latter, was it existing already in the database before you applied the update or did you newly create it afterwards?

re-vo-lution commented 7 years ago

I will explane my way. I created the system by using the openhabian-image and updated the system with apt-get update and apt-get upgrade actuall OH2 build. i have used the files in /etc/openhab2/ from my backup(all files like rules, items..., but without things). I installed the homematic binding with paperUI and get this error in the logfile.

re-vo-lution commented 7 years ago

addintional info: some user tell that the innogy binding works with OH2 build 477 to 577, but for example with 602 and in my cose with 609 its not working.

sjsf commented 7 years ago

With innogy binding you mean the one that is displayed as "RWE SmartHome Binding", right? Is it exactly the same error? Otherwise I'd say let's not mix up different stuff in this issue.

However, if it is the same, then this would a good hint - I'm just not aware that there is a native openHAB2 binding for RWE/innogy, so we'd need to look at the compatibility layer...

re-vo-lution commented 7 years ago

@sjka : No, i mean the new innogy-binding in apha status from Olliver Kuhl. I showed the rror message from this binding here: https://github.com/openhab/openhab2-addons/issues/1462

This is not exact the same error, but its also about the bridge handler and this error haves some other people, you can show here:

http://www.innogy-smarthome-forum.com/thread-openhab-2-innogy-smarthome-binding-alpha?page=12

But i get the error for the homematic-binding with an installed innogy-binding and without a installed innogy-binding.

How can i help? Maybee some more log-data with logging in Debug-Modus or something like that?

BR Rene

sjsf commented 7 years ago

Oh, I see, thanks. From that I can tell that the innogy problem is completely unrelated - this is something that needs to be fixed in the binding itself (i.e. "handlers" of a Bridge need to implement the BridgeHandler interface, not the ThingHandler interface).

So let's focus on your Homematic issue here. I'm still struggling to understand where this "Thing" instance (which actually should have been a "Bridge" instance) is coming from. So if you could enable debug logging for org.eclipse.smarthome. and org.openhab.binding.homematic. that would be awesome. If you don't want to publish the logs here you can send them to me directly also, just let me know.

re-vo-lution commented 7 years ago

i activate the logging in karaf with these both lines and hope this was correct. log:set DEBUG org.org.eclipse.smarthome. log:set DEBUG org.openhab.binding.homematic.

Then i uninstall the binding and installed it again. For the new installe here its the logging:

2016-11-23 16:15:19.455 [DEBUG] [org.openhab.binding.homematic ] - BundleEvent INSTALLED - org.openhab.binding.homematic 2016-11-23 16:15:19.728 [DEBUG] [org.openhab.binding.homematic ] - BundleEvent RESOLVED - org.openhab.binding.homematic 2016-11-23 16:15:19.756 [DEBUG] [org.openhab.binding.homematic ] - BundleEvent STARTING - org.openhab.binding.homematic 2016-11-23 16:15:19.759 [DEBUG] [org.openhab.binding.homematic ] - BundleEvent STARTED - org.openhab.binding.homematic 2016-11-23 16:15:19.844 [DEBUG] [org.openhab.binding.homematic ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.type.ChannelTypeProvider,

org.openhab.binding.homematic.type.HomematicChannelTypeProvider}={component.name=org.openhab.binding.homematic.type.HomematicChannelTypeProviderImpl, component.id=189, service.id=317,

service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic 2016-11-23 16:15:19.859 [DEBUG] [org.openhab.binding.homematic ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingTypeProvider,

org.openhab.binding.homematic.type.HomematicThingTypeProvider}={component.name=org.openhab.binding.homematic.type.HomematicThingTypeProviderImpl, component.id=190, service.id=318,

service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic 2016-11-23 16:15:19.879 [DEBUG] [org.openhab.binding.homematic ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.ConfigDescriptionProvider,

org.openhab.binding.homematic.type.HomematicConfigDescriptionProvider}={component.name=org.openhab.binding.homematic.type.HomematicConfigDescriptionProviderImpl, component.id=192,

service.id=319, service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic 2016-11-23 16:15:19.889 [DEBUG] [org.openhab.binding.homematic ] - ServiceEvent REGISTERED - {org.openhab.binding.homematic.type.HomematicTypeGenerator}=

{component.name=org.openhab.binding.homematic.type.HomematicTypeGenerator, component.id=191, service.id=320, service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic 2016-11-23 16:15:19.911 [DEBUG] [org.openhab.binding.homematic ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}=

{component.name=org.openhab.binding.homematic.handler.HomematicThingHandlerFactory, component.id=193, service.id=321, service.bundleid=203, service.scope=bundle} -

org.openhab.binding.homematic 2016-11-23 16:15:19.946 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling thing handler factory

'org.openhab.binding.homematic.handler.HomematicThingHandlerFactory@85537': java.lang.ClassCastException: org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to

org.eclipse.smarthome.core.thing.Bridge java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to org.eclipse.smarthome.core.thing.Bridge at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_111] at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_111] at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:186) at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:79) at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:63) at org.eclipse.smarthome.core.thing.internal.ThingManager.doRegisterHandler(ThingManager.java:582) at org.eclipse.smarthome.core.thing.internal.ThingManager.registerHandler(ThingManager.java:561) at org.eclipse.smarthome.core.thing.internal.ThingManager.addThingHandlerFactory(ThingManager.java:1024) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_111] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_111] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_111] at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_111] at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.helper.BindMethod.invoke(BindMethod.java:41)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1660)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.DependencyManager.invokeBindMethod(DependencyManager.java:1636)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeBindMethod(SingleComponentManager.java:370)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.addedService(DependencyManager.java:319)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.addedService(DependencyManager.java:295)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1215)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1136)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:945)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:881)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1167)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:120)[34:org.apache.felix.scr:2.0.2] at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)[34:org.apache.felix.scr:2.0.2] at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)[34:org.apache.felix.scr:2.0.2] at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482)[org.osgi.core-6.0.0.jar:] at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415)[org.osgi.core-6.0.0.jar:] at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)[org.osgi.core-6.0.0.jar:] at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)[org.osgi.core-6.0.0.jar:] at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:902)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:165)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:75)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:67)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:102)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.container.Module.publishEvent(Module.java:466)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.container.Module.start(Module.java:457)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1199)[9:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:840)[9:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_111] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_111] at java.lang.Thread.run(Thread.java:745)[:1.8.0_111] Caused by: java.lang.ClassCastException: org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to org.eclipse.smarthome.core.thing.Bridge at org.openhab.binding.homematic.handler.HomematicThingHandlerFactory.createHandler(HomematicThingHandlerFactory.java:50)[203:org.openhab.binding.homematic:2.0.0.201611222318] at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:98)[104:org.eclipse.smarthome.core.thing:0.9.0.201611191809] at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:586)[104:org.eclipse.smarthome.core.thing:0.9.0.201611191809] at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:1)[104:org.eclipse.smarthome.core.thing:0.9.0.201611191809] at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:177)[97:org.eclipse.smarthome.core:0.9.0.201611191809] ... 4 more 2016-11-23 16:15:19.982 [DEBUG] [org.openhab.binding.homematic ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.UpnpDiscoveryParticipant}=

{component.name=org.eclipse.smarthome.binding.homematic.discovery.bridge, component.id=194, service.id=322, service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic

hakan42 commented 7 years ago

Just for the record: This happens during the netatmo binding initialization too:

Caused by: java.lang.ClassCastException: org.eclipse.smarthome.core.thing.internal.ThingImpl cannot be cast to org.eclipse.smarthome.core.thing.Bridge
        at org.openhab.binding.netatmo.internal.NetatmoHandlerFactory.createHandler(NetatmoHandlerFactory.java:53)[196:org.openhab.binding.netatmo:2.0.0.201611181914]
        at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:98)[103:org.eclipse.smarthome.core.thing:0.9.0.201611191809]
        at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:586)[103:org.eclipse.smarthome.core.thing:0.9.0.201611191809]
        at org.eclipse.smarthome.core.thing.internal.ThingManager$7.call(ThingManager.java:1)[103:org.eclipse.smarthome.core.thing:0.9.0.201611191809]
        at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:177)[96:org.eclipse.smarthome.core:0.9.0.201611191809]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111]
kaikreuzer commented 7 years ago

@hakan42 Is this with things coming from the mapdb database that was created with an earlier version? Or can you reproduce this by starting from an empty db and adding a thing in the latest snapshot?

hakan42 commented 7 years ago

I am pretty sure that it was with a clean mapdb as I wanted to test the initialization of hue.

I will check with tonight's build and an empty mapdb again and report.

re-vo-lution commented 7 years ago

With the build 610 the homematic-binding works at my installation. But the bridge was not automatically added to the inbox, i must add it manually. After i set the CCU IP-Adress that the things of homematic are automatically added to inbox.

hakan42 commented 7 years ago

@kaikreuzer With build 610, the ClassCastException still occurs in the netatmo binding. I have started with a completely fresh installation, empty mapdb directory, empty cache and tmp directories.

sjsf commented 7 years ago

Okay, I just downloaded openHAB2 610, fresh database, empty config, fresh everything. I installed the netatmo binding, added a new "Netatmo API" thing (which is the bridge) via the PaperUI, entered some bogus as the credentials and all went fine:

openhab> smarthome:things
netatmo:netatmoapi:ba4a941b (Type=Bridge, Status=ONLINE, Label=Netatmo API, Bridge=null)

somehow we are still looking at the wrong place... Our main focus should not be the bindings, but the question who or what created these wrong bridges. What did you do differently?

sjsf commented 7 years ago

PS: [Off-Topic]: Of course I raised https://github.com/openhab/openhab2-addons/issues/1472 for the bridge being ONLINE instead of OFFLINE (Configuration Error), but that's a different story...

hakan42 commented 7 years ago

The only difference that comes to mind is that I have my netatmo binding in a netatmo.things file:

netatmo:netatmoapi:home
[
    clientId = "my-clientid-at-netatmo",
    clientSecret = "my-secret-at-netatmo",
    username = "my-user-name-at-netatmo",
    password = "my-password-at-netatmo",
    readStation=true,
    readThermostat=false
]

with the values in the netatmo.things file being placeholders of course 😄

Apart from that, I have cleaned everything and started with 610. I will try later today to disable the things file and create the bridge via the Paper UI.

sjsf commented 7 years ago

This seems to be highly relevant. I notice that in your things file the "Bridge" keyword is missing - which is okay if it gets inferred from the ThingType. But for this, the binding has to be loaded first. So adding the "Bridge" keyword in front definitely should fix your problem. And I will check if maybe the loading order (things file vs. binding) causes this bug.

sjsf commented 7 years ago

Yep, that's definitely it:

May happen with ANY binding if you leave out the "Bridge" keyword in your .things files. I'm now looking into fixing it.

Btw: @kaikreuzer how optional is the "Bridge" keyword? I couldn't find any clue in the docu that it is, and also the bindings include it in their examples for bridge definitions.

kaikreuzer commented 7 years ago

Well, the documentation is indeed not clear on that. It says "The first keyword defines whether the entry is a bridge or a thing" and "It is possible to skip the Thing keyword", which reads as "you can skip the 'first' keyword and simply start with the UID".

Do you have any explanation, why it worked in the past? Was that merely a lucky coincidence?

hakan42 commented 7 years ago

So adding the "Bridge" keyword in front definitely should fix your problem. And I will check if maybe the loading order (things file vs. binding) causes this bug.

Yes, adding "Bridge" to the things file does fix the problem. Confirmed fix 😄

sjsf commented 7 years ago

that's good to have your confirmation, thanks! So we now have an official workaround. We all can use our smart homes again while I'm hunting the root-cause.

Do you have any explanation, why it worked in the past?

not yet. Just looks like really unfortunate timing: The ThingHandlerFactory is registered already while the ThingTypeRegistry is not yet aware of the ThingTypes (i.e. xml processing still in progress), so the GenericThingProvider tries its best. Which as we know is not enough. However, just adding some debug logging for better analysis already fixed it 😩 So maybe the Brigde/ThingHandler refactoring optimized it in a way that it now does not always work anymore by coincidence. Otherwise it's definitely unrelated, as far a I can see.