[RELEASE] Hub Information Driver

Woo hoo! This is great! An educational sample template you could post (adding it to the documentation in the first post in this topic) would be the template that gives the same output as the default (no template) output. (Or at least as close as you can get to the default output.)

Nice idea ! for a good while I've been taking a couple of community apps and 'modding' them so they layout correctly in my dashboard (I'm a huge fan of Android Dashboard which I run on a Portrait monitor in my dev workstation - I use Bluestacks as an emulator under win10/11). Each time the app or driver gets an update, I need to go back and repeat the work...

The concept of pushing through a template could alleviate many things - I hope others take your idea and run with it too! Off the top of my head notification tile, gametime and open weathermaps might gain big benefits!

1 Like

Hi all,
Would you be so kind to suggest me under what number should not drop down the freeMemory please? I'd like to create a webcore piston to notify me when freeMemory is on critical number.
Thanks in Advance

Free memory lower limit varies by device and app load, but most should be good to at least 250K if running

Thanks for the info

1 Like

There are many, many threads on this (I had the same question myself a while back, answered many, many different ways). Enter “free memory” in the search function to see a variety of suggestions and rationale for each. However, this is an answer I once got directly from the Hubitat staff:


May 20

The free memory metric in better reflects the state of affairs, but it is different from pre-2.3.1 and even different from early 2.3.1 public releases.

This also means that the "reboot hub when free memory goes below 250" approach is no longer applicable. You can let it run all the way until the "low memory" alert pops up at 80m.”

That having been said, I used to have mine set up at 250K per @thebearmay (he has been a virtual firehose of great information and help to me), but lowered it to 175K since I am on (the latest firmware) and 175K gives me about 30 days between automatic reboots via RM5.1 without any noticeable slow downs in my specific use case. Of course, YMMV depending upon your set up.

Edit: link to quote:


Had to answer conservatively, I'm away from home at the moment and couldn't check where I have my alerts set at currently. I know 250 is safe, and believe I may have lowered mine to 200 on the production hub and maybe as low as 150 on my development hub (no critical devices or rules). Part of the determination on where you set it has to take in the rate of loss and the frequency of your checking.


Completely understandable. Notice that despite HE saying that you could just let it go to 80K, I still have mine set up to trigger at 175K. For a while, I had it set to 125K but I was fine with going about 30 days between auto-reboots at 175K so I also played it more conservatively. BTW, again, thanks for all the help, suggestions and apps you have provided me over the last two years!


Unless I'm doing something that impacts it heavy, many times my development hub will go from one HE update to the next update between reboots, so they really have tightened it up.


Thanks for your suggestion.

The actual data displayed is dependent on the options selected, but this should be close to what most people are using.

<tr><td>Version</td><td><%hubModel%> / <%firmwareVersionString%></td></tr>
<tr><td>IP Addr</td><td><%localIP%> / <%publicIP%></td></tr>
<tr><td>Free Mem</td><td><%freeMemory%></td></tr>
<tr><td>CPU Load/Load%</td><td><%cpu5Min%> / <%cpuPct%></td></tr>
<tr><td>DB Size</td><td><%dbSize%></td></tr>
<tr><td>Last Restart</td><td><%lastHubRestartFormatted%></td></tr>
<tr><td>ZB Channel</td><td><%zigbeeChannel%></td></tr>
<tr><td>ZW Radio/SDK</td><td><%zwaveVersion%> / <%zwaveSDKVersion%></td></tr>

Yay! Thank you for that. That creates the possibility to rewrite formatAttrib() to construct that HTML template string to pass to altHtml() that does all the lookup and layout work. No need to duplicate the lookup and formatting code in both places.

That thought had occurred to me as well. To implement I'll need to install the template from the driver at first run or when the HTML attribute gets enabled. Very doable, and I have the code in a couple of other concept drivers, just need to move it over. That might be the impetus to move from 2.6.x to a 2.7.0 release.

1 Like

v2.7.0 is out. Some minor code cleanup, but the major change is that the html attribute is always done using a template file stored on the hub. By default this will be hubInfoTemplate.res, but you have the option of using another file (or modifying the default one). If you turn on the Enable HTML attribute preference and the template file information is empty or the template doesn't exist on the hub, the driver will download the default template to the hub.

The default template uses HTML table elements to format the output, but, keeping in mind that you are limited to 1024 characters, you may use whatever HTML you wish. Attributes are inserted by delimiting them with <% %> , i.e. <%cpuPct%>. In addition to the 51 driver attributes, <%@date%> and <%@version%> are also available (current date and current driver version respectively).

A small app to help you generate templates is also at


I updated to the latest version. Turned off html attribute creation. Turned it back on to get the file on the hub. I don't have the file on the hub. I don't have an html attribute and am seeing these errors in the log. Anyone have any ideas? Thanks

Fix is up now.... v2.7.1 Missed one of the hub security changes when moving my beta code to release

THANK YOU! This is a great driver. So much information.

1 Like

Still no go but seeing different log errors now. Thanks

typo ge instead of get... give me a sec.

Edit: Do a HPM Repair and you should be good.


I don't use HPM but will do an import. That's how I update most things.


1 Like

Download the Hubitat app