Well I asked the question because I was hoping for someone with personal experience to speak for it.
Now that I have used InfluxDB and grafana for so long i really don't see it as hard to work with either. With the new version of InfluxDB logger I can setup a new environment with a free cloud account in probably 15 min. I do think the catch though is going from capturing the data to useable graphs. Whether it is Grafana, or the built in InfluxDB tools, creating the graphs is probably the most difficult. The nice thing though is it is also possible to create Templates and share them with other users.
I was really hoping for some good information as to how easy it was for creating graphs.
Setting up Influxdb and Grafana requires setting up a local system to run that. Constantgraph is a cloud solution that requires you to upload your data to them.
Not exactly true since early this year when Denny and I worked on updating the app to support SSL and InfluxDB2.0. You can use it with a free Cloud InfluxDB cloud account since that update.
I'm with you there @jtp10181. As a non-coder I could never bring this to bear myself; Influx/Grapfana is a non-starter for me as well. I've atleast encouraged CG to look at the HE Community, Maker API doc., et. al. As they say - you can lead a horse to water ... but can't make him drink. I guess I'll await any feedback from CG if they do decide to make an in-house effort to understand the HE platform. Maybe even the folks over at SharpTools could help co-develop a SuperTile based upon CG's data visualizer to drop onto a SharpTools dahboard - that would be sweet!
What is it you want to do. Allot of time one simple example is all it takes to get started or get exactly what you need. It can look intimidating, but once a few things are clear it is generally not to bad.
Visualizing data trends over time is an area of interest for my business.
These GitHub repositories I found initially sparked my interests in data collection-into-visualization:
There is a reason everyone at work goes to me for sexy charts
I need to fix mine to use some variables so they can be shared and dropped in easier. Right now you would probably have to edit every query to adjust. Especially since I am using node-red to get my data, which uses about the same format but I think one field is named different (displayName is something else I think?) that can cause an issue. I could try adapting the hub one since its the least charts, and PM you the code to try with InfluxLogger style data. I know one other person was able to get some of mine working as well but did not share the fixed dashboard back to me.
I would be up for it if you wanted me to try. I am generally pretty good at figuring that kind of stuff out. I actually just recently migrated my Hub Data into InfluxDB Logger from Node-Red. I have a Hubitat performance monitoring flow I was using to put that data into InfluxDB, About a month ago i moved as much of it as i could into InfluxDB Logger using the HubInfo Driver as the source device.
Grafana is allot more flexible then the graphing engine that is part of InfluxDB Cloud Free teir. I wonder if the built in engine when you load it locally has allot more options.
Speaking of threads - let's keep this germaine/on-topic; perhaps moving pure influxDB Grafana talk to ts own thread. I understand its a viable option for some.
Just sayin ...
Ok well getting back on topic. I see some problems with this being integrated based on there API's.
First, the only data that can be loaded is numerical. That would cause allot of additional translation for a bunch of devices. That would be additional cpu cycles to process. Then you would need a way to translate those data sets back to something relevant.
Then there is the need to setup every device before data is loaded. It looks like based on the API you would need to setup each device and various attributes before you could start to load data to it.
The solution appears to be based on a cloud service using MongoDB. Because of that there are additional complications to getting data to it.
In comparison, InfluxDB Logger litterly just waits for events to happen. When they do it formats them and queues them up to go at the scheduled interval or quantity. For this you would have to get the event. Then figure out the device number that is setup for that device, then format it into a map, convert that to json, then send it.
I suspect there is decent possibility for performance issues.
This doesn't even take into account the issue with limiting the data import to numerical values only. That is a big potential issue. I have a few things that simply wouldn't work in that setup.
That state is also based on the idea of a Smartapp loaded on the Hubitat Hub trying to handle it. If they worked with HE to create the integration between the Hubitat Cloud and their server then that might be a different situation. It would put work of the work likely on them while they would be a consumer of updates from the HE cloud. But then that would also mean there would probably be a financial arrangement to cover costs of providing that service to them.
I do think what they have for the data reduction and aggregation stuff is pretty click. It just won't be the simplest thing to get the data in.
I also saw on their site that it appears they have a data importer as well. I think there are community created ways to dump data to a flat file like a CSV and then you could use their xls importer to get the data in their system possibly.
I thought I'd drop into this forum since I was made aware of it. I'm excited to see discussion around an integration between Hubitat and ConstantGraph. I'm happy to modify the ConstantGraph APIs (within reason and ensuring backward compatibility where appropriate) to support a Hubitat integration.
For example, I noticed in the discussion above that the ConstantGraph APIs only support numerical data, whilst this is true, the APIs were created at a time when ConstantGraph could only process numerical data and this situation has now moved on; so updating the APIs to support string inputs (e.g. on / off etc.) should be reasonably straightforward.
I'm afraid I don't really understand the Hubitat architecture, but ConstantGraph can process events (as in, this value has changed) as well as status reports as would happing in polling every 10 minutes. The preference is for API calls to be event driven (as they retain more data) but this may not be practical in rapidly changing scenarios where a different approach is required (some customers have energy monitors that report every 5 seconds and this is is done through a combination of batching events and polling). Note that, ConstantGraph has a feature to disaggregate energy waveforms and identify the devices that are being used (despite then not being "smart"). E.g. a fridge has a different energy profile from an oven and the energy usage of each can be separated from a single Home Energy Monitor into separate energy "channels".
Does Hubitat have a scripting language which can receive events locally and pass them on to ConstantGraph? This would be a good option as the "App" could decide whether to batch events or poll as required. There would also need to be somewhere to enter the ConstantGraph API key and provide a UI to select which devices to send data for and report on the health/status of the integration. This is the way the Ezlo integration works.
Alternatively, does Hubitat have a cloud based API that can be called from ConstantGraph? If so, is it possible to create a (read-only) API key? All of the processing could then be handled on the ConstantGraph side. This is the way the SmartThings integration works.
HE allows you to write a app in Groovy so that would be the language you want to use for a smartapp. In Groovy you would have ways to format the data however you need it, and create a useful ui to setup anything you need to capture and transmit the data to you.
I know there is are cloud API's but i am not sure about how you would go about that. You may want to talk to HE staff to work on that together on the API side of it.
