Added this note to the first post, do you think it's clear enough?
NOTE FOR NEW USERS: When you go to create the virtual device for this, the driver will be in the User Devices section of the drop down. This is after all of the built-in drivers.
3 Likes
Yes, I understand this message now.
However, a couple of months ago I did not know that I had to add as a device to use this driver until I read this in another thread.
Or maybe:
NOTE FOR NEW USERS: Install driver via HPM, then create a virtual device.
Add Device -> Virtual -> add device name and select "Hub Information" under Type* and save.
What is showing in the html attribute (suspect you may be missing the template file - https://raw.githubusercontent.com/thebearmay/hubitat/main/hubInfoTemplate.res needs to be copied to the Settings | File Manager if it's missing)
Looks like it was a momentary issue. You should be okay, but if it keeps occurring let me know.
1 Like
Added this note to the first post, do you think it's clear enough?
NOTE FOR NEW USERS: When you go to create the virtual device for this, the driver will be in the User Devices section of the drop down. This is after all of the built-in drivers.
Yes thanks, I think that's enough of a hint that I would have persevered! I only eventually got around to trying the Virtual Device option because it didn't initially occur to me that my actual HE C-7 would be treated as a virtual device for the purposes of the driver connection. (I started out looking for Hubitat in the list of device vendors.) That bit of counterintuition might be a useful detail to emphasize... 
I changed it a little based on @iEnam's suggestions to:
NOTE FOR NEW USERS: After installing the code into the Drivers Code section via HPM (recommended) or the import method, go to the Devices tab and:
Add Device -> Virtual -> add device name and select "Hub Information" under Type and save.*
(The driver will be in the User Devices section of the drop down. This is after all of the built-in drivers.)
3 Likes
I updated to 2.7.21, and am still seeing the initialization errors at boot:
dev:662023-01-03 22:25:02.785 warn getFreeMem httpResp = 200 but returned invalid data, will retry next cycle
dev:662023-01-03 22:25:02.726 warn getDb httpResp = 200 but returned invalid data, will retry next cycle
dev:662023-01-03 22:25:02.702 error Attribute value for ntpServer exceeds 1024, current size = 9314, truncating to 1024...
dev:662023-01-03 22:25:02.700 warn getEvtDays httpResp = 200 but returned invalid data, will retry next cycle
dev:662023-01-03 22:25:02.682 warn getStateDays httpResp = 200 but returned invalid data, will retry next cycle
dev:662023-01-03 22:25:02.682 warn getTemp httpResp = 200 but returned invalid data, will retry next cycle
dev:662023-01-03 22:25:00.328 trace Hub Information Driver 2.7.21 initialized
They’re not hurting anything just an indication that the hub was still initiallizing when the poll fired. I removed the immediate poll at startup a while back as long as one was scheduled in the future, I may look at coding a reschedule of any poll attempt in the first 3 minutes.
2 Likes
Following along here to discussions nearly 2 years ago.
Is node-red and the maker api still the best way to get cpu load, memory, etc into influx for graphing?
I'd rather not have to spin up another docker container just for this, but if it's the only way...
I already have a instance of influx and grafana, and use influxdb logger to log other attributes. But it looks like the only way to get it to log hub info is to allow access to all attributes which unchecks all the other devices I'm logging. A second instance of the app doesn't work.
[EDIT] I got this working in webcore. I'll share the piston here once I've got it where I want it..
if you insert
input "actuators", "capability.actuator", title: "Actuators", multiple: true, required: false //**tbm
at line 100 of the Influx Logger does it solve your problem?
1 Like
I may be barking up the wrong tree, but is there any chance we can have further breakdown for polling of states that don't change frequently from the polling interval. When I look at my device stats my hubinfo() Device is using by far the most resources of any device. Overall, it isn't killing the hub, but it doesn't make sense that it alone is over 50% more cpu time then the next highest device and then the next highest one following that is probably 10% of the hub info device.
What do you have in mind? Might be able to work in an addtional polling interval with a little analysis on which would benefit from it.
Just get an ecobee thermostat or iotawatt, you'll forget about this driver real quick.
Thinking about it some more, I already have 2 polling cycles running (normal and updates), with a little work, I could add an additional polling cycle and change the boolean option for each set to a selection of which polling cycle to use, and let the hub owner customize their experience….
1 Like
So I wanted to get some stats from the hub info driver into influx/grafana but felt all the node-red stuff was a little overkill for the task.
I managed to get it done thru webcore. Here's the piston and a early screenshot of the dashboard. It took a little figuring out how to use the attributes. Turns out they need to be stored as variables. You could probably use this to log any sort of stats that isn't supported by the influxdb logger app.
2 Likes
I think that's a good idea, I have a bunch of stuff turned off to reduce the polling load since it doesn't really change. Really for the 5 min poll I just want the CPU, Mem and DB info. Looks like there is maybe a few other things some people may want frequently updated. All the other extras personally I would kick out to every 6-12 hours or something.
2 Likes
For me it feels like the stuff that changes the most is temp, CPU, memory and DB Size. Stuff like Internet IP, Zigbee Channel, etc, can run much less frequently. Platform updates and perhaps a couple of others probably sit in that in-between spot....
I do have a Ecobee thermostat and I think the level of CPU for it is also a bit high. My concern is if i am not using all the extra work it is doing then that cpu consumption may be for nothing or at least not giving me return on my gear. My responsibilities in in my RL job have been largely system reliability and performance management. A large part of that is controlling the type of work you have running so it isn't spikey and more consistent resource usage. I have no way to know for sure but i suspect allot of stuff is spikey loads on Hubitat and then when i see single jobs like Hub Info and Ecobeee suites that runs off polling at given intervals and has high cpu load it is a bit of a trigger for me. But like i said earlier it isn't like i am 100% sure since i can't see the low level stuff.
@thebearmy
I think @jtp10181 and @sburke781 got it right. I would think a short regular interval or those things that we know for sure are going to change frequently. So CPU, Memory, DB Size, hub temperature. These probably need to default to the current 5 min as they do update fairly frequently
Then there are things that should probably only be done on hub restart only. Like the Zwave and Zigbee data, firmware Version information, Hub restart information, Hub location, Hub name, hub model, Time zone data.
Last there probably should be a long poll interval group for things that do not update frequently, but you may still want to be notified. I would see this being checking for Firmware updates, Event max numbers, maybe the Uptime info,
Then you probably need a way to trigger the polling action just in case a user makes a change and wants to see it immediately
I would also look for a way to update things that can be subscribed to that way if possible. The two i see that do that are those related to HSM.
The last thing I see is you include attributes/states that are redundant. Would it be possible to reduce them so we only have lets say 1 state value for the current firmware, 1 for the relevant temp and scale a given user uses. In some places you have epoch time values and formated time values.
This is just me spit balling, but the whole point of it is to poll frequently only the things that change frequently. and not the the things that don't. Things that only really change on reboot should be retrieved at reboot time. Then things that can change but infrequently should be a longer customizable polling interval. Then lastly things like HSM state that are event based should have their updates received via an event instead of polling.
Also @thebearmay thanks for even considering looking into this. Your stuff is fantastic and I totally believe for all this does the cpu usage isn't unreasonable.
1 Like
