Apex Charts is another example of something that could likely be used on HE:
I have never got around to playing with it myself.
1 Like
Using something like either of those libraries for point in time data sounds pretty simple. How are you graphing trends over time? That requires storing data over time. That’s why many of us have resulted to hubigraphs, webcore or other external logging/graphing solutions.
Or am I missing something?
2 Likes
Did a similar proof of concept a while ago with Hub-a-Dashery using Chart JS and Gridstack JS. So yeah, the presentation part is not a problem.
Like @chowell said, the problem is with storing data over time. We need some sort of RRD database, either provided by Hubitat or built by someone smarter than me 
3 Likes
All bets on Hubitat then!
2 Likes
My bets will be on someone else who posted above... 
In HE we are missing the very simple time graphs available in SmartThings - like this one :
Aggregating the hourly and daily data for a 24-hour period and a 31-day period will not be so much data to store; - probably, the HE file system is enough (as already done in HubiGraph and WebCoRE LTS ) ?
4 Likes
The current setting options for device event retention could make it problematic to provide a consistent view over defined periods, unless the data was kept separate to the current events for each device. I.e. you can say keep X number of events, which could span any number of days or weeks. Not to say this can't be overcome in various ways, just something that would need to be considered for a built-in, predictable option.
1 Like
Probably this is what I meant. Save an average value for each hour - this is 24 values to be stored for the last 24 hours period. On the new day - store an average value for the previous day.
24 + 31 = 55 values (and timestamps) that need to be stored. That's all - there is no need for fancy zoomings of the past periods. The SmartThings simple history graphs are very handy, and that's all I need to look at to see how my thermostat behaved today and in the past month.
3 Likes
Would have to think on how this would be best implemented a little, but not a difficult add in concept. You’re basically talking about storing a set number of timestamped values updated at a regular polling interval - easy stuff. If you store it as one file per device it’s an easier design from the storage and retrieval standpoint, but not impossible to do as a multi-device.
2 Likes
Or below.... 
2 Likes
These Java Scripts are black magic for me 
I have only (some) embedded systems development background, a time ago...
1 Like
For a single device and a single metric (e.g. temperature), I was thinking about storing a fixed number of datapoints, similar to what whisper does; something along the following lines:
- 5 min accuracy = 12 points per hour -> keep data for 3 days (72 hours) = 864 points
- 1 hour accuracy = 24 points per day -> keep data for 1 month (31 days) = 744 points
- 1 day accuracy = 31 points per month -> keep data for 3 years (60 months) = 1095 points
- 1 month accuracy = 12 points per year -> keep data for 10 years (120 months) = 120 points
Note: I did not spent a lot of time thinking about the numbers above, we need to find the right balance between usefulness and size.
This way, the "database" size for one metric will not increase with time, we just lose precision the further we go back in time. We need a mechanism to continuously crunch/roll-up data with higher accuracy into data with lower accuracy.
C-8 Pro is a "beast", so we should not have problems with the required processing power/RAM. Storage wise, we already have some Groovy functions to create/edit/remove files in the File Manager.
We also need an efficient way to extract the metrics from the database, using REST/JSON endpoints. I believe JSON is not a very space-efficient way to store data
2 Likes
In my case, my plc stores 439 values in one year:
house energy
year : 12 measures
month : 31 measures
week : 7 measures
hourly : 24 measures
total : 74 measures
e-car energy
year : 12 measures
month : 31 measures
week : 7 measures
total : 50 measures
geothermy energy :
year : 12 measures
month : 31 measures
week : 7 measures
instant 12 measures
total : 62 measures
Temperatures
year (min/max) : 24 measures
month (min/max ) : 62 measures
week (main/max) : 14 measures
day (min/max) 48 measures
Total : 148 measures
Water
month : 31 measures
week : 7 measures
hour : 24 measures
total : 62 measures
French drain
year : 12 measures
month : 31 measures
total : 43 measures
Grand Total : 439 measures in one year. For now, all data are harvested (and stored) by my PLC and the most important data are sent to my C5 through node-red. The full graphs are generated by my PLC and sent to the web as an html page.
the generated html file and the .js files :
https://www.dropbox.com/scl/fi/1td40ltkgz6hke2p2tz6w/hubitest.zip?rlkey=bg976w3k03ji8n51to7zis2cj&st=kmyvt3cx&dl=0
3 Likes
First of all:
439 datapoints per year is the bare minimum and is enough to render data as bar charts, like you did. For line charts, I was thinking to have ~500 datapoints per view (3 days/1 month/3 years) to make it look "good" on PC screens. But then again, you might be right as your charts are awesome
1 Like
@dandanache, et al
First iteration of the code. One device - multiple attributes permitted, number of points retained and reporting interval are configurable :
https://raw.githubusercontent.com/thebearmay/hubitat/main/apps/devAttIterSto.groovy
App allows for multiple copies and renaming of the app, produces a CSV file stored in the hub local file system.
5 Likes
How much do I win?
2 Likes
Thank you. A long time ago I worked in industrial chemistry and in those days you had to do a lot with a little. To give you some context, the PLC (Semaphore Tbox lite with a 32b processor that must run at around 200 Mhz) that analyzes various parameters in my house, and that generates my html pages, is a power monster with 320 kb of ram (chronologies: 64 kb and 256 kb sampling tables) and 48 kb for my programs (Ladder/Basic) : @Bravenel will certainly appreciate
So I've learned to be thrifty and pragmatic.
My html page is therefore a synthesis of what I consider important. I don't need to have temperature measurements "by the second", as long as I know the instantaneous temperature and the min/max for the day (week, month, year).
The information from my drain allows me (and node-red transfer and some Hubitat rules) to see if my pumps are working as expected, and my water consumption (instantaneous, for the day, week, month and year) allows me to see if everything is working (again) as expected and to automatically cut off the water (sedna valve) in case of problems.
The rest (electricity consumption) is just statistics to see if my house is " purring " as usual.
I save my html every month and every year (12 html pages per year). For statistic purposes.
But if I could cut out the middleman and generate my graphs directly from Hubitat, I'd be even happier. That said, Hubigraph regularly helps me to understand all these parameters.
Better than my embedded ActiveX (...) page generated by my PLC.
5 Likes
This is an awesome first iteration! Love how fast and easy you make it look 
CSV is awesome for data storage.
But man... the UI... looks like it was made by an engineer Lots of bits and bolts:
What I would love to see (here come requirements, we're all experts at this ):
-
One app instance for all devices/attributes. Something along these lines:
I would also remove the reporting interval (besides the number of datapoints), and use some predefined values. As a user, I only care about what attributes I want to have graphs for.
-
Automatic CSV file naming, based on device id and probably accuracy (day, month, year).
-
I see that the app stores the attribute values in the app state. Can't we just collect the attributes'
currentValuewhen updating the file? -
Automatic crunch / roll-up aggregations with lesser and lesser accuracy. Don't really know how we aggregate attribute values like
motion:active,switch:off, etc. This is fun!
Again, great work... as always!
4 Likes
- I suck at UI
but could build a parent app over this to provide a unified experience. - I could generate it easy enough, but by allowing you to name it you could restart the data collection without over writing the previous data.
- Design decision that allows me to poll the values at file creation and then use subscriptions to keep the current value updated - should keep the impact to the hub to a minimum.
- Max/Min/Avg for numeric values are actually on my drawing board just didn't have the time to implement in my self imposed deadline yesterday.
4 Likes
Check out my SmartStart Manager app I think that design might work here also. I have a list view page similar to the mock up from @dandanache and when you click the name on the left side it goes to the edit page for that one entry. Edit page could be the UI that @thebearmay already built.
Screenshots at bottom of the second post: [APP] SmartStart Manager for Z-Wave (Long Range support) - #2 by jtp10181
3 Likes
I'm going to start a new thread for this app so that the graph library discussion can also continue.
Edit:
6 Likes
