compat1x: Support for "org.openhab.core.items.ItemRegistry"

[dkreutzer]

Hi,

I am playing around with openhab2 since a few days and I must say that I really like that approach!
But I am struggling with a few things (configuration stuff is not very verbose if something is not setup well - of course this is also due to the OSGI stack and the given laziness of configuration/ service-injections)

Now back to my "problem". I am going to replace my own "homemade" solution and require some sort of charting (e.g. temperature/humidity in a certain period)

For opanhab2 I am using RRD4J. As far as I understood is the charting of RRD4J not supported, so I am going to use the default charting instead. And - finally ;-) - here is my problem:

Invoking the chartservlet gives me an:

java.lang.IllegalStateException: RRD file does not contain RRA: MAX archive
    at org.rrd4j.core.RrdDb.findMatchingArchive(Unknown Source)
    at org.rrd4j.core.RrdDb.fetchData(Unknown Source)
    at org.rrd4j.core.FetchRequest.fetchData(Unknown Source)
    at org.openhab.persistence.rrd4j.internal.RRD4jService.query(RRD4jService.java:198)
    at org.openhab.core.persistence.internal.QueryablePersistenceServiceDelegate.query(QueryablePersistenceServiceDelegate.java:57)
    at org.eclipse.smarthome.ui.internal.chart.DefaultChartProvider.addItem(DefaultChartProvider.java:251)
    at org.eclipse.smarthome.ui.internal.chart.DefaultChartProvider.createChart(DefaultChartProvider.java:171)
    at org.eclipse.smarthome.ui.internal.chart.ChartServlet.doGet(ChartServlet.java:171)

Looking into the code this shows that org.openhab.core.items.ItemRegistryis not being injected into the RRD4JService, which leads the the MAX consolidation function.

In the rrd4j.xmlof the plugin you see that it requires

  <reference bind="setItemRegistry" cardinality="0..1" interface="org.openhab.core.items.ItemRegistry" name="ItemRegistry" policy="dynamic" unbind="unsetItemRegistry"/>

And - finally - that is not (yet - hopefully) supported by the compat1x API.
Is there any roadmap for this? Or is maybe someone already working on it?

Thanks and keep it up!
Daniel

[kaikreuzer]

Hi Daniel,

Thanks for analyzing this! I indeed overlooked the dependency of the rrd4j service on the item registry so far.
Usually, addons are not supposed to make use of the item registry directly - that's why I did not implement it in the compat layer. So would actually prefer a solution that changes the 1.x rrd4j implementation to get rid off this dependency. We would need to get hold of the item type in some other way... But if this all looks too complicated and other addons require the registry as well, I might also reconsider the support of it in the compat layer.

[dkreutzer]

Hi Kai,

thanks for the fast reply. As far as I understood RRD4J will be the default persistence for openhab2, so a direct implementation of the 2.x API might be the most sufficient way. What do you think? Is that somehow on the roadmap?

On the other hand I agree that compat APIs in general should be comprehensive or - at least - unambiguous (I mean it should be transparent what they support and what not).

Looking into the code of the RRD4jService it will not be easy to get a proper solution (beside just having a workaround for my problem - which could be to look into the RrdDb and its Archives for the available ConsolFun. Unfortunately the Itemis already there, before the FilterCriterion is been build. But since only the name of it is used as handle it is lost.

So maybe there could be the chance to inject it directly in the org.openhab.core.persistence.internal.PersistenceServiceFactory, there is the item registry available and the information about the required injection is available via the bundle context. I need to dig more into this OSGi stuff - maybe my thoughts are to silly, since this sort of injection is basically the job of equinox and not yours and supporting the item registry in the compact layer might be a much easier task.

So for me I found some workarounds now and I could apply them to my local sources, but all of them do not look clean and universal enough to help the community. If you have a proposal - just let me now and I could look for it if I have time.

Daniel

[kaikreuzer]

Hi Daniel,

As far as I understood RRD4J will be the default persistence for openhab2, so a direct implementation of the 2.x API might be the most sufficient way. What do you think? Is that somehow on the roadmap?

I am not sure yet. Within ESH we have completely re-done the binding and the rule APIs, all towards making them nicely accessible towards UIs (other than the Designer). I could imagine that we might want to do the same with the persistence one day - so as long as it has not changed compared to openHAB 1, I feel that supporting the existing persistence services through the compat layer is just fine - no need to maintain two different versions that work exactly the same way.

On the other hand I agree that compat APIs in general should be comprehensiv

I just had a discussion about the MIOS binding, which makes heavy use of the ItemRegistry (with good arguments). As there are other bindings as well, I think I relax my requirements here a bit and will look into supporting the ItemRegistry within the compat layer. This will then also be the simplest solution for rrd4j :-)

Best regards,
Kai

Am 01.03.2015 um 23:13 schrieb Daniel Kreutzer notifications@github.com:

Hi Kai,

thanks for the fast reply. As far as I understood RRD4J will be the default persistence for openhab2, so a direct implementation of the 2.x API might be the most sufficient way. What do you think? Is that somehow on the roadmap?

On the other hand I agree that compat APIs in general should be comprehensive or - at least - unambiguous (I mean it should be transparent what they support and what not).

Looking into the code of the RRD4jService it will not be easy to get a proper solution (beside just having a workaround for my problem - which could be to look into the RrdDb and its Archives for the available ConsolFun. Unfortunately the Itemis already there, before the FilterCriterion is been build. But since only the name of it is used as handle it is lost.

So maybe there could be the chance to inject it directly in the org.openhab.core.persistence.internal.PersistenceServiceFactory, there is the item registry available and the information about the required injection is available via the bundle context. I need to dig more into this OSGi stuff - maybe my thoughts are to silly, since this sort of injection is basically the job of equinox and not yours and supporting the item registry in the compact layer might be a much easier task.

So for me I found some workarounds now and I could apply them to my local sources, but all of them do not look clean and universal enough to help the community. If you have a proposal - just let me now and I could look for it if I have time.

Daniel

—
Reply to this email directly or view it on GitHub #146 (comment).

[dkreutzer]

Hi Kai,

that sounds good! For now I just migrated my local version to the openhab2 API, so that it works for me until the extended compat1x API is available. As a side effect the RRD4JChartProvider is working now as well.

Best regards,
Daniel

[xsnrg]

Daniel, I am in the same place with the RRD file does not contain RRA: MAX archive error. Care to share your manual patch?

[dkreutzer]

@xsnrg: here you go (https://github.com/dkreutzer/openhab2-bindings.git)
@kaikreuzer: Kai, I hope that's ok for you. I am going to remove it after the compat1x API is ready to support the missing features. But for now I though it might help others like xsnrg to have a workaround and to keep working with openhab2 instead of falling back to 1.x.
I am currently also thinking of having some sort of configuration to influence the archive building regarding data life cycle. But maybe that is also already planned on your side.

[xsnrg]

@dkreutzer Thanks!

[kgoderis]

+1

On 12 Mar 2015, at 02:26, xsnrg notifications@github.com wrote:

@dkreutzer https://github.com/dkreutzer Thanks!

—
Reply to this email directly or view it on GitHub #146 (comment).

[kaikreuzer]

Ok, I have implemented this part for the compat layer and successfully tested rrd4j persistence and charting with it.
Please note that you will need a 1.7.0-SNAPSHOT of the rrd4j bundle that includes openhab/openhab1-addons#2300 (once this is merged).