Developing a persistence addon (not a binding)

Hi everyone!
First of all, I searched but couldn’t find anything on this topic, I am very sorry if I missed anything :slight_smile:
For my bachelor thesis, I am developing a data market platform that allows people to publish their sensor data and allow interested groups such as researchers to get access to statistics generated through this data.
Therefore, I want to develop an OpenHAB addon, that allows OpenHAB users to publish their data to our platform.

I already read the guide for developing a binding, however, it seems to me that this is not what I want to create. What I want to create is actually a persistence add-on, that sends data out of openhab rather than collect data and make it available within OpenHAB (which is what bindings seem to do).

Now for bindings there is a lot of information on how to create these, but that doesn’t seem to exist for persistence add-ons. Can anyone point me in the right direction where I could find some kind of documentation to get started? Am I wrong in assuming that my addon would be a persistence addon?

Thank you so much in advance,
Lasse

I think a Persistence add-on is probably the right choice. I don’t think you will find much documentation on it though. You will probably need to look at an example to show you how to do it. I’d look at the mapdb addon as it will probably be the simplest example.

The persistence add-ons are currently hosted on the Eclipse Smarthome repo.

I thought that they were all over here, in the OH1 repo.

Like MapDB.

I could be wrong. I thought they ended up at ESH. I didn’t look them up though.

Most persistence implementations are still in OH1, but I would suggest to implement against the OH2 / ESH API if implementing something new :wink: .

@ssalonen has been working] on transitioning dynamodb this way for a while. He’s been looking for more information on how the process should go…

I wrote a sample database implementation for the H2 database for OH2 at the same time that I implemented the OH2 persistence API, but the database was never merged. It should still be kicking around in the PR list though (in the ESH repo) if anyone wanted to take a look.

1 Like

Thanks for this tip @chris !

There’s PR 2081 based on your original PR, it seems. A lot of useful discussion, especially around the UNDEF and NULL. Seems like the general consensus is that UNDEF should be persisted but not NULL. I believe this is something different from openHAB1 persistence addons (also mentioned here when I originally contributed DynamoDB persistence for openHAB1).

It’s a shame that there’s no reference implementation nor docs regarding this topic :frowning: Even the H2 PR is somehow incomplete/WIP, and there’s no UI support for configuration (see my problems with DynamoDB, linked above).

Well, I guess we will get there eventually…

Best,
Sami

My original PR was meant to be a relatively simple reference implementation of the API, but it got picked up by others, the discussion expanded, and it never got merged…

1 Like

Thank you all for your responses! I guess I will start looking at other implementations of persistence add-ons then !

From what I have found out so far, I think I only need to create a class that implements the Storage interface, is that right? Then OpenHAB will magically call the put method whenever some sensor value (or other stuff) changed.

However, I am starting to think that a persistence Add-On is NOT the thing that I want. I want to give people the opportunity to publish some of their data to my service, however, if I understand correctly, it is only possible to configure one persistence service. I don’t want to store all the users data to allow them to query it, I want to export some of the data and that’s it!

What kind of add-on would that be, third-party-integration? I am getting kind of lost here…

IMHO opion OH knows the DEFAULT persistence, which can be set and will be used if the persistence service is not stated. If a special persistence service is stated, it will be used.
There is a .persist file for every persitence service installed.

To give a wide-spread example, a lot of user do use a persitence service to store data for long term usage (rrd4j, influx, mysql …) AND do use mapdb to store the last update of each item for a “RestoreOnStartUp” strategy. In other words, the use of more then one persitence service is quite normal!

1 Like

That is incorrect. I even wrote a design pattern on this. Design Pattern: Group Based Persistence

The items that get persisted are defined in the .persist file. They can choose on an item by item basis what to persist. And it has possible to have a persistence survive that is write only without query. See the MQTT persistence add on.

Ok in that case, I can implement my addon as a persistence addon without sabotaging the users :slight_smile:
Now, I still have several questions:

  1. It looks like one way for me to implement this addon right now is to implement the Storage Interface (like org.eclipse.smarthome.storage.mapdb does it). Is that correct? I find it really hard to figure out what belongs where. The MQTT persistence add-on that @rlkoshak mentioned implements PersistenceService, but that seems to be the OH1 way of doing it? If I check the PaperUI configuration page, under persistence it says something about org.eclipse.smarthome.persistence, and then I can enter which persistence service to use. However, I can not find any packages with such a prefix, only org.openhab.persistence or org.eclipse.smarthome.storage. Which one is it using?

  2. Is there any nice way of getting an environment with which I can experiment? When I run OpenHAB from eclipse all I get is the UI filled with weird placeholders (like “dnfzt Binding”). I would love to have some binding that produces information that will be persisted, so I can see what the information looks like that will be passed to the persistence addon, is there any easy way of doing this? Also, I found a file called rrd4j.persist, which contains a line
    // let's only store temperature values in rrd
    Temperature*, Weather_Chart* : strategy = everyMinute, restoreOnStartup
    This seems to cause rrd4j to only persist temperature readings, which is a functionality that I would also like for my persistence add-on, however, I don’t understand how that works, since Items as described here don’t seem to have a special temperature type.

  3. Is there any developer documentation that I am missing? I find it kind of hard to figure out where to start on my own, and I don’t want to bother you guys too much. From the code that I have read so far, I am assuming that if I implement this storage interface, OpenHAB will automatically call the put/delete method when an Item changes, with some key (the items name?) and the item as a value?

Sorry for having so many questions and thank you for being patient with me :slight_smile:

Cheers,
Lasse

Sadly I cannot help with hardly any of the questions except for the .persist part. The Temperature* part means all members of the Temperature group.

The more I dig into this the more confused I get. So far I could only find persistence Add-Ons in two places:

  1. org.openhab.persistence (listed under “other projects” after the installation of the IDE)
  2. org.eclipse.smarthome.storage (listed under “Runtime”)

The org.eclipse.smarthome.storage namespace seems to have only 2 add-ons, json and mapdb. These seem to be executed by default. When running OpenHAB from the IDE, I can not install any other addons, as all I can see in the paper ui are randomly generated names for (apparently nonexistent) persistence services, e.g. “AFeHo Persistence”.

How can I use an actual persistence add-on when running OpenHAB from the IDE? Should I implement my persistence service by implementing PersistenceService or StorageService? If I implement it as a persistence Service, what do I need to do to make it OH2 compatible? Some of those seem to be compatible to OH2 (like mqtt) since they are listed here, while some others aren’t. @chris talked about implementing against the ESH API, I guess that means implementing StorageService like org.eclipse.smarthome.storage.mapdb does would be the correct way, is that right?