ClassCastException in HandlerFactories #2521
Comments
|
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);
} // ... |
|
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? |
|
I will explane my way. |
|
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. |
|
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... |
|
@SJKA : No, i mean the new innogy-binding in apha status from Olliver Kuhl. I showed the rror message from this binding here: 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 |
|
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. |
|
i activate the logging in karaf with these both lines and hope this was correct. 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 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 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 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 {component.name=org.openhab.binding.homematic.type.HomematicTypeGenerator, component.id=191, service.id=320, service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic {component.name=org.openhab.binding.homematic.handler.HomematicThingHandlerFactory, component.id=193, service.id=321, service.bundleid=203, service.scope=bundle} - org.openhab.binding.homematic '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 {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 |
|
Just for the record: This happens during the netatmo binding initialization too: |
|
@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? |
|
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. |
|
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. |
|
@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. |
|
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: 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? |
|
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... |
|
The only difference that comes to mind is that I have my netatmo binding in a netatmo.things file: 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. |
|
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. |
|
Yep, that's definitely it:
May happen with ANY binding if you leave out the "Bridge" keyword in your .things files. 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. |
|
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? |
Yes, adding "Bridge" to the things file does fix the problem. Confirmed fix 😄 |
|
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.
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. |
…oaded Reusing the mechanism known from the ThingManager for Handler initialization, therefore factoring out the common code. fixes eclipse-archived#2521 Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
…oaded Reusing the mechanism known from the ThingManager for Handler initialization, therefore factoring out the common code. fixes eclipse-archived#2521 Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
…oaded (eclipse-archived#2615) Reusing the mechanism known from the ThingManager for Handler initialization, therefore factoring out the common code. fixes eclipse-archived#2521 Signed-off-by: Simon Kaufmann <simon.kfm@googlemail.com>
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:
More infos also at https://github.com/openhab/openhab2-addons/issues/1462
The text was updated successfully, but these errors were encountered: