I am using openHAB 2 with influxdb (1.10.0) for persistence.
Now I am searching for a possibility to add Tags to influxdb.
So is there some kind of beforeSave-event available for influxdb?
Or can I intercept the persistence event somehow?
Cheers,
Chris
No. Persistence in OH is written to support a vast array of databases from Time Series (e.g. InfluxDB), SQL (e.g. MariaDB), Document (e.g. Mongo), and embedded (e.g. rrd4j, mapdb). As such it provides a minimum API that supports the lowest common denominator across all these types of databases. A feature like tagging that is only supported by one or two DBs will not be supported.
I think your best way forward is to either come up with an approach that lets you do what you are trying to do without tagging or implement saving values directly to InfluxDB in Rules through its REST API.
Hi @rlkoshak, thanks for your fast reply.
I definitely understand your explanation regarding the lowest common denominator. That’s why I asked, if there is some kind of interception available - independent from the technology used beneath.
Do you know of any possibility to override/fork/whatsoever the persistence layer in oder to archive my goals?
Your other mentioned approach… rules… can I interfere the saving-mechanism by defining some rules? From my understanding right now, rules are only able to trigger some actions, rather than changing them. But maybe I am confused in this topic.
If I POST data to the Item endpoint… the persistence layer takes care of the data. From what I know right now, I can not alter/change/adjust these data accordingly.
And, yes, I need tags to be stored aside the time-series data.
The tags, indeed, are somehow static. This means, depending on the ID of the Item, Tag x has to be stored into influxdb.
By using rules I mean that you can implement calls directly into InfluxDB to store the data in some other database space using InfluxDB’s REST APIs and the sendHTTP* actions.
You can look into forking the persistence layer but you will end up touching so many parts of OH to make it work end to end I really think you will find it too big of a job.
Another alternative might be to write something external to OH that uses MQTT and the MQTT Event Bus to receive all the updates and commands on all the Items and then poopulate your database from there.
The key here though is that this will be duplicated data. You will need to store everything you need separately from the data Persistence stores (which may mean you will want to turn on Persistence entirely if you no longer need to use it).
Thanks for your detailed explanation, it makes things clearer to me.
So, as assumed, forking would not be a good strategy (like mostly always).
I will have a look into OpenHAB’s MQ support. For now it seems promising, though this will have kind of a huge impact. Since, in conclusion, the persistence layer should be disabled completely due to redundant data. What means, that there won’t be any way around it to reinvent the persistence logic, unfortunately.
This is bad news. The use of “tags” with influxdb is very interesting. I was looking forward to this feature. Also, the current version does not follow the recommendations of the influxdb team (https://docs.influxdata.com/influxdb/v1.3/concepts/schema_and_data_layout/)
I recommend filing an issue if that is the case. But be aware that adding the ability to use tags through the Persistence API is unlikely. Like I said above, the API has to support the lowest common denominator database capability. There is no way to support every unique feature available on all the different supported databases.
But like I said, if you need to store this information in different ways for analysis or what have you outside of OH, you have at least two options I mentioned above.
Hi,
Though I understand your point in general, but when talking about a time series database the options for tags is not some kind of minor feature, actually it is the feature.
I just had a look into the sources of the influxdb persistence. The persistence layer is quite simple and straight forward. From my analysis there should be just a basic extension in the store()-method: If the given Item has tags, these tags should be added accordingly. If the Item has none, nothing changes.
What exactly do you mean by touching so many parts of OH?
OpenHab’s Item does already have a native support for tags as it looks…
And storing records as documents is THE feature of Mongo DB. That doesn’t change the fact that OH does and much provide a unified interface for all these types of databases.
But tags are already used for Hue Emulation and integration with Alexa and other third-party services like that. Should someone implement tags in this way you end up having to choose between tags in the DB or being able to control it from Alexa or HomeKit.
Like I said, tags already have a function in OH so to properly implement this one would need to implement a new API which would touch the core persistence layer, Items syntax and parsing, and potentially require updates to all the other persistence plugins. Just reusing tags for this would break what tags are already used for.
Well, now you are comparing features with databases. If OH would support MongoDB it indeed would have to support documents since it’s the nature of the database. But I understand already that it always comes back to your very first statement which conclusion I have to accept, unfortunately.
OK, got your point. Though this is still an option for our use case, since we are not relying on any 3rd-party (consumer) services and are using OH just to retrieve and persist data from knx devices - so no habpanel, paperui whatsoever.
Yeah, well, this is for sure not what I want 
Thanks for clearing things up!
It seems to me like it would pretty simple to extend the influxdb persistence plugin with the ability to send all of an items groups and tags as influxdb tag values without messing with the rest of the persistence framework. The only challenge is that a single tag can’t have mulitple values, but since all we care about is if the tag or group exists for an item you could just abuse the API a bit and send each of them as tag_blah=true and group_blah=true I guess.
It would be extremely useful to have at least partial access to group and tag data when building influxdb queries, since you could query all items where group_battery=true (for instance) for a graph instead of depending only on the item names.
For reference: InfluxDB 2.0 with tags