MiOS Binding Compatibility validation with OH2

[mr.gu...@gmail.com]

I performed some initial/rudimentary checks of the MiOS Binding against OH2.

In OH1, I depend upon the following imports (originally from the XMPP Binding):

import org.codehaus.jackson.JsonParseException;
import org.codehaus.jackson.map.JsonMappingException;
import org.codehaus.jackson.map.ObjectMapper;

Under OH1, these are resolving in the OSGi container, but it might be happening as a side-effect of the org.openhab.io.rest stuff (see below).  

QUESTION: Should I be packaging these JARs with my [OH1] Binding, or should they be exposed by OH2 itself?

osgi> b 221
org.openhab.binding.mios_1.7.0.201502241621 [221]
  Id=221, Status=ACTIVE      Data Root=/usr/local/share/openhab/server/configuration/org.eclipse.osgi/bundles/221/data
  "Registered Services"
    {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.mios.MiosBindingProvider}={component.name=org.openhab.binding.mios.genericbindingprovider, component.id=90, service.id=166}
    {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService, org.openhab.binding.mios.MiosActionProvider}={event.topics=openhab/*, service.pid=org.openhab.mios, component.name=org.openhab.binding.mios.activebinding, component.id=89, service.id=167}

  Services in use:
    {org.openhab.core.transform.TransformationService}={openhab.transform=MAP, component.name=org.openhab.core.transform.processor.map, component.id=35, service.id=115}
    {org.openhab.core.items.ItemRegistry}={component.name=org.openhab.core.itemregistry, component.id=21, service.id=91}
    {org.openhab.core.events.EventPublisher}={component.name=org.openhab.core.events.eventpublisher, component.id=20, service.id=90}
    {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.mios.MiosBindingProvider}={component.name=org.openhab.binding.mios.genericbindingprovider, component.id=90, service.id=166}

  Exported packages
    org.openhab.binding.mios; version="0.0.0"[exported]

  Imported packages
    org.apache.commons.lang; version="2.6.0"<org.apache.commons.lang_2.6.0.v201205030909 [30]>
    org.codehaus.jackson; version="1.9.2"<org.openhab.io.rest.lib_1.7.0.201503251710 [199]>
    org.codehaus.jackson.map; version="1.9.2"<org.openhab.io.rest.lib_1.7.0.201503251710 [199]>
    org.openhab.core.binding; version="0.0.0"<org.openhab.core_1.7.0.201503251710 [187]>
    org.openhab.core.events; version="0.0.0"<org.openhab.core_1.7.0.201503251710 [187]>
    org.openhab.core.items; version="0.0.0"<org.openhab.core_1.7.0.201503251710 [187]>
    org.openhab.core.library.items; version="0.0.0"<org.openhab.core.library_1.7.0.201503251710 [189]>
    org.openhab.core.library.types; version="0.0.0"<org.openhab.core.library_1.7.0.201503251710 [189]>
    org.openhab.core.types; version="0.0.0"<org.openhab.core_1.7.0.201503251710 [187]>
    org.openhab.model.item.binding; version="0.0.0"<org.openhab.model.item_1.7.0.201503251710 [205]>
    org.osgi.framework; version="1.7.0"<org.eclipse.osgi_3.8.2.v20130124-134944 [0]>
    org.osgi.service.cm; version="1.4.0"<org.eclipse.osgi.services_3.3.100.v20120522-1822 [157]>
    org.osgi.service.component; version="1.2.0"<org.eclipse.osgi.services_3.3.100.v20120522-1822 [157]>
    org.osgi.service.event; version="1.3.0"<org.eclipse.osgi.services_3.3.100.v20120522-1822 [157]>
    org.openhab.core.transform; version="0.0.0"<org.openhab.core.transform_1.7.0.201503251710 [193]>
    org.openhab.core.transform.actions; version="0.0.0"<org.openhab.core.transform_1.7.0.201503251710 [193]>
    org.slf4j; version="1.7.2"<org.slf4j.api_1.7.2.v20121108-1250 [214]>

  No fragment bundles

  Named class space
    org.openhab.binding.mios; bundle-version="1.7.0.201502241621"[provided]

  No required bundles

[Mark]

Sorry, I got these from the XBMC Binding, not XMPP... 

[Kai Kreuzer]

Good question!

Is your question only about getting the 1.7 binding working on OH2 or about possibly migrating the binding code to OH2?

In general, we should try to keep the dependency tree small. OH2 includes GSON for JSON parsing, so the nicest way would be a refactoring to use this library instead - but then you might have a problem on the OH1 side as this does not contain GSON so far.

If it is only the jackson.core jar that is required, I also would not mind too much to add it to the runtime as it is only 210KB. I hope to add some proper dependency management in future that would allow to only install those libs if some addon asks for them, this would be even better.

So which way do you prefer?

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab2+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/f71304a1-aa98-4e3c-8b3d-98f8dd82b038%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark]

Hey Kai,

At this point I'm looking to run the MiOS Binding under openHAB 2.x, but in openHAB 1.x compatibility mode only.  I did a trial of this today in order to root out the initial set of issues that folks would run into.

Hence the library problem.  Given the log above, it looks like I'm dependent upon:

    org.codehaus.jackson; version="1.9.2"<org.openhab.io.rest.lib_1.7.0.201503251710 [199]>
    org.codehaus.jackson.map; version="1.9.2"<org.openhab.io.rest.lib_1.7.0.201503251710 [199]>

But I've not looked at the exact packaging of the two parts of Jackson I'm currently using.  I'm currently reconstructing my OH1.x Eclipse, since I managed to completely break it yesterday (it won't start)

I'll think about re-writing the MiOS Binding to OH2 standards later on, but it's a lot of work given the need to dynamically create the necessary [and user/deployment-specific] set of Thing definitions corresponding to each MiOS User's system - given it's a complete HA system in itself, with an infinite array of Things representable within that ecosystem.   

It makes my head hurt each time I think about it, so I've put that on serious hold ;)

[Kai Kreuzer]

Hi Mark,

To check whether all works nicely, just take the jackson jar file (e.g. from http://download.eclipse.org/tools/orbit/downloads/drops/R20150124073747/) and put it in the addons folder as well. If it works, I would add it to the runtime, so that it is available.

It makes my head hurt each time I think about it, so I've put that on serious hold ;)

Don’t worry - MiOS might not be a good candidate for an OH2 binding then, but this is why we have the compat layer - there should simply be no need to migrate existing bindings, if the concepts are not a good fit. So relax and keep maintaining the 1.x version :-)

Best regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/b0e5897d-52f7-4977-94ba-0d9716f4b605%40googlegroups.com.

[Mark]

It gets a little further once I include both Core and Mapper libs:

-rw-r-----@ 1 mark  admin  210307 Apr 13 13:29 org.codehaus.jackson.core_1.6.0.v20101005-0925.jar
-rw-r-----@ 1 mark  admin  558853 Apr 13 13:34 org.codehaus.jackson.mapper_1.6.0.v20101005-0925.jar

But I'll need to dig deeper since it's silently failing after that step.

Don’t worry - MiOS might not be a good candidate for an OH2 binding then, but this is why we have the compat layer - there should simply be no need to migrate existing bindings, if the concepts are not a good fit. So relax and keep maintaining the 1.x version :-)

The MiOS System entities are more like Things (from OH 2.x) than than they are Items (from OH 1.x) so there would be less impedance mis-match going with 2.x, but the need to acquire/provide the Typing information (not just names) up front is a little tricky in that world - at least not without having to hard-code, and then maintain, a lot of UPnP-like Service file knowledge.

[Mark]

Ok, so it is getting a lot further, now these two Jackson libraries are included.

The next hurdle is that, for some Item State changes I'm making, it's dumping out with the exception:

14:26:36.016 [ERROR] [b.m.internal.MiosUnitConnector:449  ] - Exception 'The state must not be null!' raised pushing property 'unit:house,device:313/service/urn:upnp-micasaverde-com:serviceId:Weather1/Alert.1.StartDate' value '' into openHABjava.lang.IllegalArgumentException: The state must not be null!
        at org.eclipse.smarthome.core.internal.events.EventPublisherImpl.postUpdate(EventPublisherImpl.java:123)
        at org.eclipse.smarthome.core.internal.events.EventPublisherImpl.postUpdate(EventPublisherImpl.java:179)
        at org.openhab.core.events.EventPublisherDelegate.postUpdate(EventPublisherDelegate.java:71)
        at org.openhab.binding.mios.internal.MiosBinding.internalPropertyUpdate(MiosBinding.java:486)
        at org.openhab.binding.mios.internal.MiosBinding.postPropertyUpdate(MiosBinding.java:412)
        at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.publish(MiosUnitConnector.java:447)
        at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.processDevices(MiosUnitConnector.java:570)
        at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.processResponse(MiosUnitConnector.java:681)
        at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.run(MiosUnitConnector.java:755)
        at java.lang.Thread.run(Thread.java:744)

In this particular case I am sending through a Non-Null value.  Specifically, I convert certain States to "UnDefType.UNDEF" prior to calling [OH1] EventPublisher.postUpdate().  This can happen in cases where the source-system has a representation for NULL, but the openHAB user has bound the Item to something like DateTime[Item].

In OH1 this works fine, but in OH2, it looks like these OH1 Types are being converted into OH2 Types and there's a mismatch*.

For this case, the code in the legacy postUpdate handler (EventHandlerDelegate.postUpdate) is using the OH2 TypeParser to turn [a String-version of] my OH1 State into the OH2 State.  Since the State I'm trying to set is UnDefType.UNDEF ("Uninitialized"), this is the value that's handed to the [OH2] TypeParser.   In turn, this method makes a series of [dynamic] valueOf() calls against the Item's AcceptedDataType list....   But in that list is UnDefType, and that class doesn't have a valueOf() method.

The ultimate result is that while I'm passing in a non-null value for newState, this conversion code is changing that to null... which subsequently fails in the calls into ESH's eventPublisher.publishUpdate()

Anyhow, for this model to work I think the ESH versions of the UnDefType need to have valueOf defined.  They probably should be defined in OH 1.x also, but it sounds like this issue hasn't been hit yet.

Either way, an assert should be defined here to catch the case where the inbound value is non-null, but the post-transformation value is null.  This will give folks an early warning if the issue arises again.

* There is a lot of scope for mismatch here, since the code is using the OH2 TypeParser on String values emitted from the OH1 Types.  If there's not a 100% match between these two worlds, then problems will occur.... but I'm probably stating the obvious.

[Kai Kreuzer]

Thanks for the analysis, Mark! This is indeed a bug and I have just created an issue for it (https://github.com/openhab/openhab2/issues/186) and will fix it soon!

Cheers,

Kai

Am 14.04.2015 um 02:05 schrieb Mark <mr.gu...@gmail.com>:

Ok, so it is getting a lot further, now these two Jackson libraries are included.

The next hurdle is that, for some Item State changes I'm making, it's dumping out with the exception:

14:26:36.016 [ERROR] [b.m.internal.MiosUnitConnector:449  ] - Exception 'The state must not be null!' raised pushing property 'unit:house,device:313/service/urn:upnp-micasaverde-com:serviceId:Weather1/Alert.1.StartDate' value '' intoopenHABjava.lang.IllegalArgumentException: The state must not be null! 

    {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService,org.openhab.binding.mios.MiosActionProvider}={event.topics=openhab/*, service.pid=org.openhab.mios, component.name=org.openhab.binding.mios.activebinding, component.id=89, service.id=167}

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab2/144de21c-750c-455e-a6cf-9276a01aa014%40googlegroups.com.