InfluxDB Logger Support

@dennypage,

Because I had two occasions with this recently I updated the InfluxDB Logger to include some notification functionality. I have created a pull request to add my edits into the main repo.

@dennypage not sure how you wanted issues report (or if you will see the github issue I posted)? Found an issue with the Power Source definition and posted it on github: Power Sources dropdown does not populate · Issue #62 · HubitatCommunity/InfluxDB-Logger · GitHub

Also might I suggest a little more info in the first post, like where to find it on GitHub and a mention about installing it from HPM?

1 Like

Any tips on migrating from influxdb1.x to influxdb2.x?

I just spun up a new VM with influx 2, is it a matter of just creating a database on it and changing the post url in the app to post to it instead?

Basically, yes, but the login method is different so you will want to make an API token in Influx as well.

Or, Influx has upgrade / migration docs which if done correctly you will keep your data and it will create legacy DBRP mappings so any existing integrations will work with the same credentials.

If you want to start from scratch on a new database this post has a bunch of instructions for setting up InfluxDB Logger: Using HE with with InfluxDB, Grafana, with InfluxDB Logger

1 Like

Thanks. I'm gonna check that post out in a few.

I just tried making my first database as I was used to in v1, and holy cow they changed everything. I wasn't using any authentication before with any of my stuff. :slight_smile:

Just FYI if you have any existing dashboards tied to Influx v1, you will need to create a DBRP mapping and point your existing datasource in Grafana to it so they keep working. The new v2.x Flux language is totally different for the queries in the dashboards.

Here is a little bit of info on it, Influxdb2 and HE integration - #9 by jtp10181 . At a minimum you only need the v1 DBRP and not the v1 Auth, since Grafana supports using a token to authenticate for InfluxQL by adding a manual authorization header. Here is the guide from Influx, giving you a link right to the key piece which is the token authentication: Use Grafana with InfluxDB OSS | InfluxDB OSS 2.7 Documentation

May be best if you have any questions to post over on the Guides post and we can chime in there.

Think there's really much reason to migrate? My main reason was, I'm spinning up a new VM and starting fresh because I'm having some issues with my existing setup. Plus it's running on an out dated version of ubuntu.

I figured now was the time to migrate, but the more looking I do the more I see folks talking about influx v2 nearing it's end of life with v3 coming out.

Thinking maybe I just hold off..

I am not sure what the upgrade to v3 is going to look like. I suspect they will keep building upon the Flux query language and the structure of the 2.x release, so hopefully it will be a fairly easy upgrade. I did a little searching but could not find much for details, just marketing type info.

Also with 2.x / Flux you can use my prebuilt dashboards that are being tested right now: Ready-to-Use Grafana Dashboards! - Beta Test / Feedback

Flux is going away in 3.x from what I've gathered. A lot of folks aren't happy.

I didn't realize I'd have to update my dashboards to go from 1 to 2. I might just stick with the old until I can't anymore. :frowning:

Nothing set in stone, but it sounds like they want to push to a more SQL like query language.

:person_facepalming: :person_facepalming: :person_facepalming: :person_facepalming: :person_facepalming:
Influx v1 (InfluxQL) already WAS very similar to SQL.... then they changed it to Flux.
Sounds like they regret that decision and are switching to native SQL now, what a :poop: :cloud_with_lightning_and_rain: this is going to be. Good thing is I already know SQL very well.

You don't have to, you can also setup a DBRP mapping in Influx and then set that up as a InfluxQL data source in Grafana, which allows you to use the v1 query language on the v2 database.

3 Likes

That was the general train of thought.. I was asking elsewhere about it and was told, why bother upgrading now lol

Agreed. I am sticking with my InfluxDB 1.x instance. No reason to upgrade IMHO. I run it as an add-on on my Home Assistant Yellow system, along with Grafana and Node-RED. HAOS makes running these containers trivial. I really don't use HA for much, except as a way to integrate a few devices with Hubitat that currently are not supported. The add-ons are a great feature.

1 Like

Yeah, I'll be sticking with v2.x

You probably have a fair amount of time to not worry about it. As of right now it looks like V3 is only for a very select use case. There is no OSS version and their cloud option isn't there either. One thing I would point out though is that there is a decent chance you will need to go to 2 to get to v3 so that may be something to think about. That or just start from scratch.

Also I would point out as @jtp10181 has pointed out there is no need to worry about rewriting stuff for flux(V2). I upgraded my database earlier this year because of concerns since the older software hasn't received any updates in so long. If you use default configurations the upgrade is pretty straight forward. Then you just need to create the DBRP connection which is essentially one curl command to the server. You do need a few db values that are quickly obtained from the GUI that actually works in v2. Then you just create the Data source connection in InfluxDB.

I have it documented in this thread here, but I was directed to whole process by @jtp10181

Using HE with with InfluxDB, Grafana, with InfluxDB Logger - :bellhop_bell: Get Help / Integrations - Hubitat

It really isn't bad.

3 Likes

Hey folks, I've just had an oddity on one of my hubs which boiled down to something with InfluxDB Logger v2. Wanted to mention it in case it's of relevance to anybody else.

I have two hubs, both logging to the same InfluxDB. I upgraded "Hub 2" to 3.2.1 and then forgot to upgrade "Hub 1" which remained on 3.2.0. Wake up today to find "Hub 1" completely locked up, Zigbee network offline, severe load, yada, yada. Huge event queue for InfluxDB Logger.

I'm in the process of redoing stuff on my HE boxes anyway, so I didn't care. I just deleted InfluxDB Logger on both hubs, rebooted and the problem is gone. But should this have happened? Was it anything to do with the mismatched versions? When I rebuild things later should I avoid logging two hubs to the same InfluxDB (that would seem weird)?

Ta!

It is extreamly unlikely it is related to InfluxDB Logger. The most recent change was just about fixing a capability typo. All that would have done was enable devices that didn't previously work.

The only time I have seen a issue triggered by InfluxDB Logger is when I was testing the apps data protections when DB adds are failing. As the data protection adds more and more records it will gradually grow the DB. That will eventually cause other problems. But that as you can see that is more of a result of other failures.

The only way I can see a problem with two hubs is if you are using the advanced attribute features and the drivers for the devices involved include incompatible data for same named attributes. That isn't exactly a problem though with InfluxDB Logger, but the devices drivers involved.

3 Likes

I get a message in my logs for the app:

[app:528](http://REDACTED/logs?tab=past&deviceId=663#)2023-10-13 12:14:14.857 AM[error](http://REDACTED/logs?tab=past&deviceId=663#)java.lang.NullPointerException: Cannot invoke method getDisplayName() on null object on line 367 (method updated)

Nothing to worry about? Is it breaking logging?

I would guess you deleted a device which you had selected in the app, and now it is looking for it.

Possibly opening and closing the dropdown that the device was selected in and then saving will clear it out of the list the app has stored.

1 Like

Version 3.3.0 has just been released.

This version adds support for publishing Hub Variables to InfluxDB. The following types are supported:

  • Number
  • Decimal
  • String
  • Boolean

Publishing of DateTime variables is not supported.

In addition, this version supports recording the outstanding InfluxDB queue size (length) in a global variable following each post. This allows the outstanding queue size to be used in other applications such as Rule Machine. An example use case, using a variable named "InfluxDB Hub Information queue", is show below.

4 Likes

@jshimota

I know I asked you for a step by step eons ago; here's a belated thank you. I finally got some time to set everything up on my synology. The detailed process was a great help.

3 Likes