Updated InfluxDB binding with tags

Well, it wasn’t the weekend which brought time to try out your new addon-version, it was actually only happening right now.
Having just installed and configured my items, I want to confirm that everything works as expected, based on your documentation.
I am sending items into InfluxDB, they get mapped to measurements based on the group they belong to and have tags added, based on the per-item definitions.

@dominikkv: Thank you very much for making this possible! My InfluxDB set up is becoming way clearer and better usable through this.
If you don’t hear anything more from me, that means I am a happy user who did not find any problems with the add-on.
And all the best for 2020!

@dominikkv Will your version of the Persistence service work with InfluxDB 2.0?

No it doesn’t.
The protocol and drivers for 2.0 are different.
I started on a module with 2.0 APIs (look at this message).
But this is a very preliminary work that has been paused from the last months.
I’ve I get some guidance and support I will try to continue on it.

1 Like

@dominikkv: sadly your PR was closed by Kai Kreuzer. What does it actually mean? More work on your side to be done :(?

Also it would be cool, if one could enable “auto-tagging” based on the current timestamp. Means: putting a tag for the current month, year and maybe week number. Since otherwise it’s almost impossible to perform grouping with influxdb in Grafana. E.g. to graph the power consumption sum on a week, month or year basis.

You can group your data by time without tags.

I do it this way.

A new version of the addon has been integrated into master branch and will be available in OH 3.0.
It was originally a new addon for InfluxDB 2.0 but finally, it has been refactored and it’s a rewrite of the previous addon that supports both versions and incorporates @dominikkv work with tags.

2 Likes

That could be a starter, thanks! I was just reading about that there’s currently no way to group by month or year - only per days. So it’s always about the last n days and not about concrete and exact months. E.g. “show me the sum of consumption of january” (exactly 01.01.-31.01.) would be easier then to create graphs showing the totals over a year per month.

And that are great new @lujop, thanks :D!

while you wait for OH 3.0, you can directly send data to InfluxDB from OH instead of using persistence which allows you to put in any tags you want. Or course you can’t retrieve them from persistence then either, but if you normally look at the data through Grafana, this can work. Example here.

Can the new binding be tested/usef with openHAB 2.5 or is it only compatible with 3.0?

I am using OH 2.5.4 plus the JAR of the updated add-on (which was shared in this comment of this thread) and it works.

As far as I understand this PullRequest, the binding was massively rewritten to support both InfluxDB v1 and v2.

I don’t want to migrate to the older jar-Version and than migrate again once the new binding is released officially.

Hi, my contribution it’s only compatible with 3.0 because it uses new new openhab interfaces instead of eclipse smarthome ones.

It should be able to backport to 2.5 because it doesn’t use any feature only available for 3.0.
But some work to change packages and test it would be needed.

1 Like

i am updating openhabian from 2.4 to the current version incl. influx and grafana and now i am being asked to keep current version of influx or to install maintainers version. what should i do here ?

Configuration file '/etc/influxdb/influxdb.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D     : show the differences between the versions
  Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** influxdb.conf (Y/I/N/O/D/Z) [default=N] ?

Thanks

Here is your answer.

thanks :see_no_evil: