What schema do you use to feed event attributes to InfluxDB ? Are they all fields?
Here is how I build the payload in NR
msgFields is the values
I pass the unit and type as tags.
Reminds me I was going to fix the timestamp to be the exact one from the event, although this wont be far off.
I read a lot of docs trying to figure out the "proper" way to do this and was thoroughly confused so this may not be the best way but it seems to work.
var msgInflux = { payload: [],topic:"influx-event" };
msgInflux.payload = [
{
measurement: msgPl.name,
fields: msgFields,
tags: {
deviceId: msgPl.deviceId,
displayName: msgPl.displayName,
unit: msgPl.unit,
type: msgPl.type
},
timestamp: new Date()
}
];
1 Like
Thanks!
Off-topic but I'm still learning InfluxDB/Grafana and having trouble setting things up so that tags don't end up breaking up my measurements into multiple tables... Any good reading material you can recommend?
Nothing in particular, if you are using flux for the query you may need a group command in there. I have no idea how I figured out my queries, lots of searching around and trying different things.
You can also setup a v1 connection then you can use the old style selectors for the queries, but it has some limitations.
2 Likes
Thanks for your work on this. I am looking to get into the logging and visualization game and it seems that this app, InfluxDB & Grafana is the go-to for most people so I figured I would start here. I am using Docker on a Synology NAS as my host and got an InfluxDB 2.6.1 image and a Grafana 9.3.6 image up and running.
Based on the discussion here it would seem that you guys are working on the best path forward still so I am wondering if I should just hold on a bit or try to get what you have so far working?
Being new to this side of it and not having (at least that I could see) documentation about the different settings and what they do is a challenge in picking what I should configure. IDE level, Polling, Write timing, Queue size, System Monitoring, are there defaults I should start with and then tweak from there? What is the impact or what is lost based on what is selected?
If the answer is, just hang on since it is in process, I am ok with that as well.
No need to wait. It's been used by several of us for years.
My recommendations for getting started:
- Leave the logging level at the default (info) for now. Change to warn after you are comfortable with the behavior.
- Set Soft-Polling to 0 (disabled)
- Set write to db to 1 minute
- Leave Queue Size Limit at the default (50)
- Turn off everything in System Monitoring
- Don't use Get Access To All Attributes
- Leave Only log events when the value changes at default (off)
Enjoy!
2 Likes
Is there any prospect of being able to enable soft polling for specific devices? I turned soft-polling off, and it has instantly created an issue for my use-case;
In Grafana I have a graph that tracks lounge temperature, outside temperature (via OWM), and the Heating set-point (via Nest/Google SDM). The challenge is, with the set-point changing so infrequently I often 'lose' that line on the graph - soft polling ensures there is always a value, hence creating a nice continuous line for me on the graph.
I've switched soft polling back on for now (10 mins), but it would be great to enable it just for 'difficult' devices, if that's possible! 
Thanks for the hard work you folk have put into updating and optimising this 
I have been dabbeling with a way to do that, just haven't quit managed to find the best way yet.
So I am working on it. The problem is making something that is backword compatible with what everything already out there.
That said you can install 2 instances of Influxdb logger. One to work with everything you want polled and one for all the stuff you don't.
2 Likes
I want to change the behavior of soft polling so that it only creates an artificial event if the device hasn’t already sent an event. This will make soft polling far less onerous. Probably rename the option to something more appropriate as well.
The configuration of the logger is already large and complex, so I don’t see soft poll as something that you would toggle on/off for each device subscription in the configuration. Unwieldy to say the least.
The good news, as @mavrrick58 points out, you can now have multiple instances and this is definitely the best way to approach the problem. Now and in the future.
1 Like
A few points/feedback:
The current version on HPM has the default as on. Not sure the interaction between soft polling and this setting.
This issue was the reason for soft polling to begin with. IMO this is a database/query issue. Bringing states forward from before the query date/time should be possible. (There is a similar issue in financial balance sheet reporting that reporting systems addressed long ago.)
I'd call it something like "Create periodic database records independent of a device event" and make it clear it's for slowly changing measures like temperature, humidity, battery percentages.
IMO you should not worry about backward compatibility. I don't think the Influx database is going to be reset. Re-setting up the Hubitat app shouldn't take more than a few minutes.
I think that's fine. I think that also makes parent/child apps more appealing/useful. I'd suggest putting database config in the parent to avoid double configurations.
1 Like
That is easy to say now with no users complaining. The problem is that week or two after the update is pushed with a bunch of folks realizing they don't have data because they have to reconfigure their app instance. Personally I agree this app has been really stagnant for a while. It is just recently we have had a huge push of revisions. but for the most part the app hasn't seen changes for years.
That said I have something you might be interested in once I clean it up.
DB config is one of several reasons that might lead to creating a new instance (log to different bucket or endpoint). Parent app should crystallize as few parameters as possible IMO - unless they can be overridden somehow in the child app.
I get it. It's possible to note breaking changes in the HPM update process. I know few people read them. I'm the kind of person who has re-created Rule Machine rules along the way. I think the long run cost of being stale is higher/a bigger risk than the cost of re-creating configurations.
Sure. 1 parent app per Influx database. The reason to put DB config in parent is if polling devices are required to be separated from non-polling ones. Cloning config/child apps would be OK too, but I'm not sure how easy that would be to do.
My bad. I had the sense reversed in my head. Leave it at the default value (true).
I worry a great deal about backward compatibility. People update packages with the expectation that what worked previously will continue to work. I believe that this is a reasonable expectation, and I will honor it if at all possible.
1 Like
So I have a question and I would really like a good real-world answer.
How important is it really to have the ability on our Hubitat hub to output to multiple InfluxDB Servers? Not well we should have the option if we want it, but really does anyone have a real word reason for this?
Yes, I have used multiple servers in the past (from multiple hubs in case you are going to ask).
I expect to do so again in the future. Two reasons: 1) To isolate data in databases based on use case and retention requirement; 2) I like to run "side by side" for major upgrades such as InfluxDB 1->2.
Agreed, and actually you can join multiple queries in Grafana, and if you edit the raw query instead of using the point and click designer thing I think you can ignore the time constraints of the current view. It might just be possible to look back a few extra days and join in the last record. I might have to try it out and see if is possible. I wont be something for a novice though.
2 Likes
Apparently open since 2016. There are some example queries in this issue and some of the linked related issues. As you said, not sure how easy for novices to implement without good examples.
