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:
... I know ... sorry you asked right?
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:
... I know ... sorry you asked right?
Just going to leave these here.
Oh and I have at least 1yr of data, so can adjust the ranges to anything I want.
We should have a Grafana dashboard sharing thread like the Node-Red Flow sharing thread. Those are some nice Dashboards
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.
This is an example of a Dashboard for my Dev Hub that uses InfluxDB Cloud.
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.
That information is far too valuable to be buried in the middle of this thread.
Please put this in it's own thread, with the title "Setting up cloud influxdb". Then edit this post to point to that thread.
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.
Hi
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.
Many thanks
Simon
ConstantGraph Founder
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.
@mavrrick58 Wouldn't MakerAPI fall into this role? (Except Maker is NOT read only).
The user would just create a Maker instance for ConstantGraph and select the devices they want it to access. The user can supply an URL to post events to. ConstantGraph would just need to setup an endpoint to accept the posted events. Also, ConstantGraph could poll MakerAPI for status updates for specific (or all) devices.
A specialized app may cut down on some noise so only relevant events are posted, but I think MakerAPI could easily work. I have two separate Maker apps setup on my main hub with nearly all devices posting events to Node-Red and HA, have not seen any performance issues from it.
I suppose Maker API could be used, It could be setup to post the events to a URL and then they could just use the Cloud API's for each device once they are discovered. But the setup process could be attrocious. and unintuiative.
Honestly they probably need something like InfluxDB Logger, or something that talks directly to the Cloud API as a integration app like Actiontiles, or Google.
Its not really that difficult, can be easily explained with 2 screenshots.
But yes, a dedicated app could be easier and more efficient with hub resources.
Whilst it sounds like a simple integration could be achieved using the MakerAPI, it seems the best option would to create an App as there are a number of edge cases that should be handled.
Is there an App Store where such an app could be published and shared with other users? Can someone share a link, if there is? Or would users have to cut and paste the code?
Would anyone like to create a basic App? By basic I mean somewhere to enter the ConstantGraph API key and a call to the ConstantGraph API either through polling or on a change event.
I'm not yet allowed to share links on this forum but the link to the ConstantGraph API reference is above somewhere. I would recommend starting with the simple data request.
Let me know if you need any help with the API requests.
The basic subscription to ConstantGraph is free and higher subscriptions only require a donation of your choice. However I'll give a free upgrade to anyone who wants to have a go at creating an App.
Out of interest, how do Apps handle separation of UI and logic code? Is there an HTML or JavaScript front-end to the Groovy backend?
I also see a lot of nervousness in the discussion above about hub resources. This is familiar to me with the Ezlo integration which used Lua Apps on a very low spec box - we put a lot of effort into ensuring the apps was not too demanding but was also slick and easy to use.
Many thanks for your interest.
You can simply link it in github or put it in Hubitat Package Manager (talk to @csteele or setting that up)
Join this group and you can post links and pics Hub owners - Hubitat
There isn't a dedicated App Store. There isa smart app called Hubitat Package Manager or HPM for short. That package manager allows a developer to publish code to a repository like Github and then HPM will check it periodically for updates. It also has a search function to help users fine apss. Though it isn't a default app installed on all hubs it is one of the must have apps for pretty much everyone. I would suggest just doing a search for HPM on the forums to learn more about it. @csteele is the current maintainer.
I think you should look at the community code for InfluxDB Logger i mentioned above. It sounds similar to what you need except it is obvsiously written for INfluxDB API's so that would likely need to be modified. InfluxDB uses LDP formating for the data import so if you could support that it would make it allot easier. It sends events based on a timer and quantity queued and is event driven. It also includes a function to send updates based on a polling interval if needed.
The UI in Groovy code is part of the overall Smartapp. There are define sections for UI vs Logic code . The UI can use HTML code in it.
Resources are someting many of the communty struggle with as many of us tend to have somewhat complex setups. The more we ask of the Hubitat Hub and it's cpu, ram the easier it is to consume it. To often though something works it has been found the method may not be the best on a small box like this with limited resources. Unlike a given device or one rule that has limited impact a event collection tool that can potentially be connected to a hundred + devices and using TCP to act on every event from those devices can get a bit unruley. It is a bit of the nature of what it is. So it just needs to be very effecient. I know when the app i mentioned earlier InfluxDB Logger was ported from Smartthings to Hubitat some performance issues were found. They are much better now and the current folks taking care of that have done a great job. It is just clear this is kind of app we really need to be careful with.
I think one of the chanllenges you may have as well with this is most users don't realize they want graphing until they want it. When they do they have been either using one of two solutions already. Either Webcore with the Hubigraphs integrations, or a INfluxDB with either native graphing or Grafana.
What would your solution bring that might persuade someone to move to your solution, or use it instead of those options?
I think that is a big question to answer for someone to take on the role of developing the solution