It is important to understand the design of Hubigraphs in order to grasp both the advantages and the limitations of Hubigraphs.
Hubigraphs is designed to work on a dashboard. As such, when you load (or refresh) a dashboard, the "tile" queries the database for all events covering the graph's time period. This can be thousands of events (depending on your device). To be clear, it can take 20-30 seconds for the initial loading. That is the bad news.
Hubigraphs does not add any loading to the Hubitat Hub. Once a dashboard is loaded, the graphs update using the same endpoint as the dashboard. Therefore, all updates from that point forward DO NOT add any load to Hubitat, it is all on the device that is displaying the dashboard.
Hubigraphs uses Google Charts Therefore, all the limitations, advantages and ease/difficulty of use is inherited from Google Charts. In the alpha build, I tried to incorporate as many options as possible (axes, labels, titles, etc). Some people have asked for features that to be blunt would require designing and implementing my own graphing API.
Hubigraphs was designed to work without external devices. I enjoy playing around with Grafana, Influxdb, and other technologies, but it has required too much maintenance and configuration. I designed Hubigraphs only within the confines of Hubitat (user apps, dashboard, etc). I have no plans to support other platforms (SharpTools, and other third party dashboards at this time). Do I care if you "steal" my code, modify it, and add native support for those platforms? Not at all (see my FAQ).
"Your idea is stupid and slow and I don't like it" - Don't use the app
"Your app is crashing my Hub. I submitted a support ticket" - Don't do that, the fine folks at hubitat do not maintain the app. This software is given free of charge with no support.
"The latest update broke the app, FIX IT". I do this for fun, please don't make it un-fun.
"I have a great idea for a feature". Go ahead and post it, I might get around to it...
"You ignored my great idea". See #2
"I hate you for getting my hopes up, your app is awful/buggy/stupid". Ok
"Please fix your app, it's broken". All cards on the table, I built this app for my wife. I will continue to support and provide updates as long as she uses it.
"I stole your code and made it soooo much better" Thanks. Please post it so I can start using it.
"You are awfully sarcastic, I don't like you". I have teenagers.
"You stole the "Hubi" name, your app doesn't deserve it." My daughter came up with it. If the hubitat owners object, I will change it.
"Your latest fix made things worse." I already covered this and See #9
Enjoy. Please take a look and tell me what you think.
This has a two part answer. One parameter is the refresh rate. This updates the webpage automatically (but only uses the data stored in the app). This makes the dashboard update correctly periodically.
Second, data is INITIALLY loaded when the app is installed or updated. This can take 10-15 seconds. Then the app subscribes to proper events and the data is updated real-time. If you were to refresh the webpage one second later, the new data would be there. I used this design to drastically reduce loading on the hub...I.e 10-15 seconds every 5 minutes....
This does exploit a weakness with the app; non-periodic updates will cause the graph to look old (if no new events have been received in a while). I only use it right now with my weather station that updates every five minutes. So, the short answer is that the data updates when an event occurs.
Got it, thank you.
I'd like to use this for a power meter, but they can be super noisy as I found out with my related Initial State Graphing Port, and I'd rather rate the reporting v.s preventing the device from reporting in close to real-time.
I'm not sure happy with Initialstate and their costing, so this is sounding awesome.
Right now I just use my port for monitoring Humidity changes and history.
Thanks for another very useful app/driver. Not sure what to say about it other than I love the ground work. Played with it for far too long last night/this morning and I'm exhausted as a result.
Couple of questions. Answer at your leisure, or don't!?
Your FAQ is awesome, but I have to admit to being confused if you want to hear anything from anyone about it other than its great.
How many graphs can realistically be used at once before the expected hub performance hit is over the top?
Are you able to keep the child apps in a list you can edit later? Sorry if I missed something (other than it's Alpha). It was a one shot deal for me. Build all in a single session, only clicking the back arrow on the browsers, or gather up all the links and then deploy later, but no future edits. Once I click done on the parent app, all I have are the links. The parent app doesn't show up int the list of apps, and the children obviously aren't there to go back into for edits.
Since the parent and child app doesn't show up after closing the parent app, the only way to delete one, is to delete all by removing the code for parent app, so I can then remove the code for the child app to kill OAuth (at least that's the only way I could figure out on my own). Did you have a different experience than me?
Had some fun and I love how easy it was. Unfortunately I had to remove it because all my "learning" attempts piled up and having about 8 of them getting updates at once brought my secondary hub where it was installed, to its knees. In fairness that hub is already burdened by two HEMs updating at 1 and 5 second intervals respectively. But that's where I would need the app/driver to live, so not sure if there's a good compromise in my case. At some point, I will have to play with it on my third hub that doesn't have anything going on.
Anyway, here's what I was able to easily come up with, before I brought everything to a halt with my learning mistakes. Couldn't get edits to stick, so this isn't exactly how I wanted it, but it looks so nice. Really appreciate your efforts.
@SmartHomePrimer thanks for the feedback. My FAQ was very much tongue-in-cheek and I would love any good/bad feedback. I was just feeling snarky when I wrote up the Instructions. I intended to delete it, but everyone has been having so much fun with it....
In any case, I’m a little confused by the loading issues. Once the initial install is done, there should not be a huge load unless you update it. The rest of the time, it triggers on an event, adds the event to the list and then cleans up events that are too old, in testing it took less than a second.
The parent/child app issue: could you describe it more? See below; this is what I see:
I absolutely get that parent/child view. And as long as I open each child, and only navigate back to the parent using the browser back button, I get that view and can setup multiple. But if I click that Done button on the parent, the link remains viable (as long as OAuth isn't changed of course), but the Parent app isn't shown in the list of installed apps. So to create another child, I have to start from the beginning, as if I was installing the parent/children from the beginning.
Great work! I have been wanting to do something with graphs in Hubitat without having to install graphana, influx, etc. and this is perfect. Works great so far and can't wait to see what you do with it in the future. Thanks for sharing!
Edit: I noticed that the html virtual device doesn't show up on the "Choose Devices" list on the dashboard app settings screen. I try to avoid using the "Use all your devices" toggle as it slows down my dashboards with my 200+ devices. In order to get it to show up in the list I added "capability "Actuator"" to your html driver and now it shows up and works just fine. Just an FYI for anyone else who may have this issue.
This is an awesome idea! I was working on a project I was calling "HubiChart" that I wasn't targeting for Dashboard integration immediately (just a way to view device history; was going to try to figure that out later if people asked) and was using chart.js instead of Google Charts--bascially a way for me to finally get rid of Home Assistant, which I was keeping around more or less only to (ab)use its simple built-in history graphs/charts. My problem is understanding the chart.js API. I might just give up and start using yours instead.
OK. This issue first is resolved for me. I was testing this at 4am, plus I forgot to click Done on the parent, before beginning to build the children. That's pretty basic stuff, but I'm sure it's going to trip up other users too. Maybe there's no way around the need to do that. I think @Cobra puts a note in his apps to click Done on the parent before creating the children, if I recall correctly.
In regard to performance, this just isn't going to work on my secondary hub that has my HEMs on it. They're very chatty devices as it is, but I'm making that worse with updating one of them every second, and the other every 5 seconds. A few other apps and devices seem to be fine, but the addition of this app seems to be too much for it. I set up a new child with updates every minute and it causes the HE Web Interface to become unresponsive. I had to reboot via the diagnostic tool, but that only gets me back to an unresponsive Web Interface if I open the child app to view or edit. Seems to be significantly worse than last night. Maybe it's something to do with how busy my electrical is right now versus 4AM in the morning.
I'll try this on my third hub and see if it's better for me.