Graphing integration options for Hubitat Hub

Hubitat Easy Dashboards with Graph tiles

These are pretty easy to setup. You simply create a dashboard using Easy Dashboards and add the appropriate tile. Once the tile is created you select the tile type to be graph and what measurement you want to include. This will display a graph for that metric.

Pro’s

  • Extremely easy to implement since it uses the Easy Dashboards and built in tiles
  • Built into the hub firmware and is continuing to get minor improvements.
  • Runs completely on Hub

Con’s

  • Very simplistic with no advanced functions.
  • Only displays a line graph or bars.
  • Only uses metrics stored on hub which tend to be limited

Use Case
This is a reasonable solution if you just want something to show current metrics. This will likely create a basic picture of how the hub is running in a recent interval but will not provide general trends of what is going on over significant time. The limitation of only showing based on stored event history an be very limiting. That said this can be a decent place to start.

Webcore with Hubigraphs add-on

I am aware of the solution and it has a fallowing. If you use Hubigraphs before this is a good option for you.

Pro’s

  • Completely local to hub graphing solution
  • Graphs work with built in dashboards
  • If you already have Webcore, you are already part of the way there
  • Good Community support.

Con’s

  • Long term storage on hub in hub storage.
  • Takes up hub resources when graphing or event tracking
  • This was effectively a port of Hubigraphs that was not getting active updates.
  • Takes a bit of fiddling to figure out how to get them to display what you want

Use Case
Honestly i need help with this. This is not a solution i have used. Without hands on experience, i would expect if you already use Webcore this could be a good option.

ConstantGraph

ConstantGraph appears to be a free/paid solution that is cloud based that a user would sign up with for a curated solution to display various metrics from the Hub. The free tier seems to be very similar to Watchtower except for the use of event data vs 5 min intervals for the lowest precision of records.

Pro's
Free and paid solutions which means very easy maintance.
Currated dashboards which are nice, predefined, and functional

Cons
Cloud Dependent.
Potentially additonal cost if you want more data then what the free plan provides

Use Case
This could be good for the user that wants to get the graphing function off the Hub, and is satisfied with something similar to Watchtower.

Watchtower

Watchtower is a fully local graphing solution that canl provide a good overview of the device statistics. Though it runs on the hub Watchtower implements downsampling. This means it takes steps to limit the number of records and size of the stored data by keeping representational data for given intervals.

Pro’s

  • Completely local to the hub
  • Performs downsampling to reduce storage and cpu used when accessing older data
  • Has Long term storage that can be used to show trends over a long period of time.
  • Creates its own dashboards for the metrics with some very interesting configuration options.
  • Actively being developed by the Community developer

Con’s

  • Because it uses intervals to poll data and does downsampling the accuracy of the data should be considered rounded for the interval the data is being displayed for.
  • Keeps data locally on hub which means it is using local IO, CPU, and Memory to operate.
  • Maximum accuracy is 5 min polling. Will not provide more accurate information.
  • Because downsampling is used this is primarily for displaying numerical metrics. May not be optimal for State metrics, but does have the ability to support them.

Use Case
This is a very good flexible solution for those that want an all local solution that you can set and forget. The automated downsampling in many ways is a fantastic option many other solutions are missing and really helps keep the size of the retained data down.The lack of accuracy is only an issue when you find a use case that needs it and as such this solution will meet most users needs easily

Grafana, Influxdb, Stack

The use of Grafana and Influxdb is by far the most powerful, robust, and flexible option. At the same time it is easily the most complex. It requires you to either upload your data to the cloud, or run an always on host in your home to collect the events from the hub as they occur. A smart app called InfluxDB Logger is uses in most cases to upload event data to the Influxdb database. The latest version of Influxdb v3 allows MQTT to be used to upload events into the DB. Once the events are in the database, Grafana is an enterprise level graphing, monitoring, and analytics tool used to take the raw metrics and create visual representation of your hubs events.

Pro’s

  • Influxdb is a purpose built Time Series database, and as such is extremely performant
  • Most robust graphing and alert solution with Grafana with it’s various panel options
  • Completely removes hub from picture so more advanced graphing functions can be performed
  • Because you are running this on external hardware, storage and IO concerns are no longer an issue
  • A good variety of prebuilt dashboards exist already
  • Because you can set this up on fast storage can keep full accuracy data for much longer then if the data resided on the hub.
  • Grafana is smart enough to request data in appropriate intervals to only retrieve data it needs so downsampling isn’t necessary.

Con’s

  • Requires always on computer, or uploading your data to the cloud.
  • Because this is a robust solution your setup will like require decent amount of resources
  • You still need to be aware of the resources needed to run on those external systems
  • Downsampling data is not automatic and you will need to manage how it is done.
  • To manage storage usage you may need to setup retention limitations
  • IT investment for managing always on gear if you run it locally at home
  • Dashboards require you to know how to query the database which may not be straight forward. Starting dashboards from scratch may not be easy.

Use Case
Simply put this is a great option if you already run a home lab or want the most accurate database possible while not being worried about a little upkeep. In general once setup this solution will just run with little concern. Then when you want the most complete data possible Grafana provides an extremely dynamic tool to display any metrics you want. Having this off the hub you can res assured it won’t impact anything running on the hub, and grafana can be made available anywhere.

I wanted to start a thread to discuss the various options for Graphing with Hubitat. I can personally think of 4 that i have either tested somewhat or read about so i started with the above post of information. If you can think of more options, pro’s, con's for each one let let me know and I will update the list above. The idea here is to simply inform folks. If i am wrong or need to elaborate on something above please let me know so i can update it.

8 Likes

Reserved incase needed

Yet another option, and one that I use.
http://YourHubIPAddress/hub/advanced/freeOSMemoryHistory
Select all, Copy. Then use a spreadsheet (I use Numbers on Mac) to paste in the data. I then have a graph pointing to that data. Results look like this:

Pros:
Nothing running on hub that is not already running - nothing is else using the memory except the OS and Java.

Cons:
Can only graph Free OS, 5m CPU avg, Total Java, Free Java, Direct Java (I am only graphing Free OS here.)
Not continuous - must delete old data in spreadsheet, refresh webpage of the data, Copy all, Paste back into spreadsheet.
You cannot change the frequency of reporting - it is fixed to 5 minutes.
Reboot resets data.

Reason I am using it is I wanted to document a "virgin" hubs memory decline but try to ensure there are the minimum of other variables. I also have Z-Wave, Zigbee and Matter disabled.

Personally I am using both Watchtower and a locally operated InfluxDB and Grafana.
Grafana is for the more complicated graphing needed and Watchtower for the simple graphing tasks.
My main concern is with InfluxDB logger app that seems to consume a lot of my hubs’ resources.
I would be interested to know what are you guys doing to make the logger app less hungry for resources?

@amithalp

InfluxDB Loggers impact is directly related to how much you want it to track. It is pretty lean as it is. It is just the more you have happening on the hub he more activity it is going to have to process. Influxdb Logger has two way activities happen. It is either triggered by events, or by Polling intervals. If you want to minimize the load from Influxdb Logger turn off polling, and limit the devices setup to only be the ones you want to track.

That said You have to remember that the hub load shown in app stats is good but not exactly 100% accurate. It can track what the app is doing but doesn't fully show back end procesess or correctly account for wait states. For instance a wait state when the hub has posted records to Influxdb will have some wait time while the packets are being transmitted, then processed remotely, and then waiting for a return response. That time doesn't stop the CPU from handeling other activity, but will show in the App Stats as consumed time. So if you transmit packets to the cloud and the cloud is being slow it can artifically elevate what you percieve as load on the hub.

In a healthy environment i have never seen influxdb logg cause a load issue. I have only seen that happen when my Influxdb Database was down for a extended period of time. And the reality of that is that @dennypage has code that should minimize that. I have on occasion made few changes to config values that reduced his guardrails effectiveness

I really do like what i have seen from watchtower. I think it is a great optioon for allot of folks. If i had the option to put hubitat on a MiniPC an dictate the underlying storage myself i would probably run Watchtower actually. The automatic downsampling is very appealing,

After 5+ years of collecting data for InfluxDB i have a ton of records some of which are back from my Smartthings days. My InfluxDBv3 database has 91.5 million records in it. I am trying to look at ways to clean it up and it isn't a simple undertaking.

One thing i have been pondering though around this question is if the MQTT items added recently for both Hubiat and Influxdb can help reduce load. It seems promising, but it comes with the tradeoff of upgrading to Influxdb v3. In my testing the Appstats shows a total system busy of 3.6% with Influxdb Logger using 37.2% of that while MQTT Exporter is 0.6%. I think the MQTT method transfers the the load from Hubitat which is doing very light weight mqtt messages to the Influxdb3 host that is parsing and formating the mqtt messages to LP data and then posting to the influxdb database.

@slate though this is a option, i don't really consider it as part of this discussion though. It requires a fair amount of manual intervention everytime you want to do the graphs and as you pointed out is limited in what it can display. All of the other options listed above are complete tools that capture, store, and provide a presentation layer that other then maybe some initial setup don't require interaction with it later. So perhaps i should post that at the top of this thread as a criteria to be on it. The solution performs the storage, maintenance, and presentation of the graphs without user interaction after initial setup.

2 Likes

I'm an active WebCoRE Hubigraphs user. They meet my needs perfectly, a graphic representation of current activity that I want to observe. No need for "very" long term historical data.

1 Like

What would you say are the pros and cons of webcore with Hubigraphs

Built-in app. No external hardware or services to setup and manage. Graphs work perfectly with Hubitat dashboards. I've not used any other weCoRE capabilities.
Cons, not unexpected but it takes a bit of fiddling to figure out how to get them to display what you want. Great support here on the community.