This topic is for support of the community maintained InfluxDB Logger.
The InfluxDB Logger is available via HPM under the package name "InfluxDB-Logger", or it is available directly from Github.
Version 2.0.0 was introduced last week, which added InfluxDB 2.x support (thanks @mavrrick58!).
Version 2.1.0 was just pushed out. This release cleans up some leftover SmartThings and provides some performance improvement (lower CPU requirements).
6 Likes
Hi, I wanted to have multiple instances of the app to be able to set up different buckets but also so I could have some sensors with soft-polling off (see my PR). Turns out I think doing this is incompatible with the thread safety stuff, as I was seeing weird stuff like queue sizes not matching the number of calls to handleEvent() :
@Field static java.util.concurrent.ConcurrentLinkedQueue loggerQueue = new java.util.concurrent.ConcurrentLinkedQueue()
@Field static java.util.concurrent.Semaphore mutex = new java.util.concurrent.Semaphore(1)
I am new to Groovy and don't know much about Java but if I understand correctly those are class variables (shared across instances). Is there a reason why they can't be instance variables?
Would you mind adding the humiditySetpoint to the attributes to thermostats?
I've been running with it for years, and go back an manually re-ad it after each HPM update. I'm not familier enough with github to submit the change request.
This lets me graph indoor humidity and compare it to what my ecobee is calling for.
Line 313
From this:
state.deviceAttributes << [ devices: 'thermostats', attributes: ['temperature', 'heatingSetpoint', 'coolingSetpoint', 'thermostatSetpoint', 'thermostatMode', 'thermostatFanMode', 'thermostatOperatingState', 'thermostatSetpointMode', 'scheduledSetpoint', 'optimisation', 'windowFunction']]
To this:
state.deviceAttributes << [ devices: 'thermostats', attributes: ['temperature', 'heatingSetpoint', 'coolingSetpoint', 'thermostatSetpoint', 'thermostatMode', 'thermostatFanMode', 'thermostatOperatingState', 'thermostatSetpointMode', 'scheduledSetpoint', 'optimisation', 'windowFunction', 'humiditySetpoint']]
I searched the forums and found what looks like a decent solution, i.e. make the @Field static variables Map's so the queues and mutexes can be indexed by app id.
I pushed a new commit to the pull request. Will be testing over the weekend.
Hi all, a general request... when you do a PR, please make it as targeted as possible as It makes things so much easier to review and merge. Thanks!
1 Like
Are you sure this is causing a issue. I was running 3 different instances of the app the other day and they were all loading data into their respective locations fine. For a time I had 3 different instances loading data into a Influxdb1.8 version, a 2.6 version and then a InfluxDB Cloud version that was remote.
I will run some more tests. However I don't understand how it can work, other than luck, considering the queue is shared by all instances and the connection parameters are in app state.
That value attribute isn't part of the official capability. Then general rule for the app is that if the attribute is non standard you need to use option to "Get Access to All Attributes" as shown in the below image
That will make that non standard attribute avaliable. Just be care with what you select in that mode. As the data is sent as is it may cause problems with the InfluxDB Parser.
It doesn't seem to be causing any issues with my thermostats that don't populate that value and has been working fine for years.
That said; in that case what can we do with the app itself to run a second instance of it?
I have a lot of devices I log and would rather not have to go back thru and reselect everything.
I've tried a second instance for something else awhile back but it was a non starter.
I don't mean to sound ungrateful, appreciate you folks picking up and maintaining this code.
So I understand your point, but here is the thing. It is a completely custom attribute that isn't part of the published standards for that capability. From an app maintenance perspective it isn't a good habit to start including one off that are not documented. Ofcourse you can always update the app youself and run a non-standard version of it or make the change to using the option that will allow it to be sent.
You can install two versions of the app yourself, what were the problems you had previously that made it a non starter.
Never mind i see exactly what you are talking about. I reran my tests on my dev hub. It is quite obvious there..
1 Like
Yeah, only the first instance actually posts.
I tried awhile back to do it for something like this but ended up making a webcore piston to post my one off attributes to a separate influx database.
And I understand. I didn't realize it wasn't a standard attribute aside from ecobee thermostats.
I went ahead and pulled @hubitrep change into my dev hub and it does appear to work fine with creating a second instance.
I'm having second thoughts about my change TBH, although it appears to be working for me as well. Was about to withdraw until I can test more. Been re-reading some of the threads here on ... HE threads and it's quite the rabbit hole.
If you don't mind me asking why are you thinking about withdrawing it. Denny and I actually kind of brought up this idea as we were working on the Influxdb2.x integration. I think the root of your request to setup polling with different intervals for different devices is a good idea.
I am wondering if it would make sense to break out the polling part to it's own child app. That child app then just submits the HandleEvent action to the main app on the setup interval for desired devices.
InfluxDB likes larger chunks of data so it would be better to fill the queue and let InfluxDB Logger write it out in larger chunks when full or at the set intervals instead of having a bunch of independent jobs writing a few records at a time.
Another case for multiple instances is to break out your "custom" devices into a separate instance. So you can use the more simple menu system for most but have those odd devices in another instance.
I have also wondered why even poll at all? I have mine setup with MakerAPI > Node-Red > Influx which is only pushed events (same as what goes into the event log). The only issue I every really have is if the state of a device does not change for a long time it may fall off a graph because it has no events within the time period. The advantage I like here is I can also see how often a device is sending in events, and see if there are gaps where there should not be.
For the record, my setup sends every single event separate to Influx, I have no issues. But it is also being processed in Node-Red and not on the hub.
1 Like
You pretty much nailed it with this statement. It also means you can ensure you have data if you want to lets say look at graphs at the 2 min interval. If you don't have data they will likely be empty. Its benefit is questionable no doubt.
Not saying you can't do it, just saying documented best practice from InfluxDB is that they like 5k record chunks. We will never get there, but I was doing performance analysis as we were putting the code in for InfluxDB2.x and it is clear smaller chunks is not the way to go. It is a balance because you have to consider the overhead. Processing every single record as they come in will create the most overhead.
The reason is I don't fully understand what I'm doing 
The field static Map storing typed objects... I see funny stuff in my logs. Currently writing a basic app with just that mechanic to see if I can fully understand what is going on.
Yes, however I am realizing that the fundamental reason to have different instances might be to manage different DB connections. One of these two things - polling interval and DB connection - should allow multiple settings within one instance and my feeling is that it should be the polling.
Gears spinning...
1 Like
