If you're feeling adventurous, you can try this experimental app
Look for the "Device Audit Report" feature in the "Devices" tab. There will be a device inventory table in the generated report.
I also added a tool for grabbing & exporting zigbee logs (Radio Capture).
HOLY SH*T. This is Gods work. Thank you! First ever actual HE power tool. amazing.
It's actually Claude Code's work 
, although quite a bit of time was invested in building up the necessary Markdown documentation, skills and memory scaffolding to guide its work.
It's nuts! (In a cool way) to see all the info that it's pulling together. Very interesting.
Are you going to create a release topic for this - seems like it deserves its own topic. (Claud will be so proud.) 
Nice work! This is great info!
Very impressive!
some might argue Claude (or any AI) is the new God. 
Can I already ask for a feature ? On the summary page:
Can you add a 'device by group' section much like the 'device by room'? I'm often trying to find orphans and missed devices and that would be nice!
Can we get this device inventory app broken off into new thread. I would love to keep this going, but separate it away from my ZB issue.
Interestingly, i was also working with Copilot to dig out some inventory info - but this app is way more powerful than what i was prepping. But again, i might also have some requests to add on ;0)
@hubitrep I had Copilot review your app for potential use in what I am trying to solve. It loves your (Claude's) work thus far, lol. But here's what "we" are thinking.
Hi — first off, thank you for putting this together. This is one of the most comprehensive and well-structured Hubitat utilities I’ve seen. The audit system in particular (using /device/fullJson with async batching) is extremely well thought out.
I’ve been digging into the code pretty deeply, specifically around the Device Usage Audit and extractAuditFields()—and wanted to run an idea by you to see if it aligns with your vision or if you’ve already thought about this.
I’m running a multi-hub (4 hub) setup using Hub Mesh, with devices distributed across hubs for radio load and range.
My goal is to build a true device inventory + lifecycle management view, specifically:
From what I can see, your audit pipeline already:
/device/fullJson/<id> for every devicedataJsonThat effectively solves the hardest part:
Getting reliable make/model/firmware at scale without scraping UI pages
Right now, the audit output is device-centric.
What I’m exploring is adding a second layer of aggregation, something like:
Group devices by:
manufacturer + model
For example:
Zooz | ZEN15
- 1.10 : 10 devices
- 1.12 : 8 devices
Flag models where:
firmware versions > 1
These become:
Because the app runs per hub, the current approach would be:
/api/audit/data from each hubThat works fine—but I wanted to ask:
Have you considered (or would you be open to) a lightweight aggregation layer or export enhancement to better support multi-hub environments?
Not necessarily pulling remote hubs directly (which would add complexity), but maybe:
hub name in audit outputThese are intentionally small and non-invasive:
Add device inventory fields to audit outputYou’re already extracting them—just ensuring they’re surfaced in allDevices:
Add optional aggregation in finalizeAudit()Something like:
byModelfirmwareDrift(keeping it optional if you want to preserve current behavior)
Add a clean export endpointFor example:
/api/audit/export
Returning:
This doesn’t change the app’s core purpose (diagnostics), but adds:
A device inventory + maintenance dimension
Which seems adjacent to what you’re already doing with:
Honestly, the biggest thing you’ve already nailed is:
Using
/device/fullJson+dataJsonas a structured extraction layer
That’s something a lot of people (myself included) hadn’t realized was viable at scale.
If this direction is interesting, I’d be happy to:
Either way — great work on this app, it’s incredibly well engineered.
Thanks for the kind words.
I asked my AI to consider your AI's (isn't this fun) request. Here is what they think, taking into account the guidelines I fed them
Thanks @DarellCraighead — this is a sharp request, and you're right that the /device/fullJson + dataJson layer is doing the heavy lifting, so the data's already there. Let me split your three asks, because they don't all land in the same place for me.
Surfacing manufacturer/model/firmware — good news, that one's already in there. As of v5.37.0 the device report has a 
Device hardware and firmware table with Manufacturer, Model, and Firmware columns (sortable, and filterable by name/manufacturer/model). If you're not seeing it, you're likely on an older build — grab the latest and it should be right there. So no work needed on that front; you're right that the extraction was the hard part and it's already surfaced, with a CSV export button to boot.
byModel / firmwareDrift aggregation and a flattened multi-hub export — I'm going to hold the line on these, and I want to be honest about why rather than just say "maybe later." Keeping devices on a consistent firmware across your hubs, and producing a flat device register, is inventory and lifecycle management — a genuinely useful job, but a different job from "is this hub healthy / what's wrong with it." I'm trying to keep this app a tight, single-hub diagnostic tool and not let it quietly grow into a device-management one. It already straddles that line in a couple of spots and I'd rather not widen the gap.
There's also a Hub-Mesh reality worth being explicit about, since you're running four hubs. Mesh itself only shares the devices you've explicitly linked between hubs — it won't hand one hub the full inventory of its peers, so the app can't simply read across the mesh and roll everything up. You can go the other way and call each hub's API remotely (that's the per-hub pattern below) — but doing that across hubs drags in hub security: a token, and login credentials wherever it's enabled, for every peer. That cross-hub auth-juggling is exactly the kind of thing I don't want a single-hub diagnostic tool to own; it's a job for a layer that sits above the hubs.
The good news: you don't need me to add anything to build the drift view you want. The OAuth API already exposes the per-device records, with mfr/model/firmware, as structured JSON:
POST /apps/api/<id>/api/audit/start (kick off a scan)
GET /apps/api/<id>/api/audit/status (poll until done)
GET /apps/api/<id>/api/audit/data (the per-device records)
Hit that on each of your four hubs (each runs its own instance + token), and the cross-hub byModel / firmwareDrift math lives in a thin aggregator you control — which is exactly where it belongs, because it can outlive and outgrow this app without bending it.
None of that is a knock on the idea — the per-device data is all exposed over the API, so assembling a cross-hub view from it is entirely possible. It's just a layer that sits above the individual hubs, separate from diagnosing any one of them, and I'd rather keep this app tight and single-purpose than fold that in.
One sliver of #2 I'd actually consider inside the app: a per-hub "this model is running mixed firmware on this hub" flag. That's a real diagnostic signal (two identical devices, one misbehaving, turns out they differ), as opposed to a cross-hub asset register. If that'd be useful to you, say the word.
What is a group for you? I'm not aware of any such first-class construct on the HE platform.
If you are thinking of Groups & Scenes, that would be out of scope for this app.
Looks like it's got its own topic now. Not sure about a "release topic" as this was really meant as an experiment, hopefully something along the lines of "the greatest app you'll never need". I doubt I will have much time to support it.
The main underlying objective was to concretely learn how to vibe-code something "at scale" (this app is huge by Hubitat community standards, over 4,600 lines of Groovy and 4,300 of HTML/js).
The motivation for this particular app stemmed from:
If the app turns out to be useful, great. If it inspires others, even better.
This is handy and meets my needs and minimizes the clicks I have to do to check other things similar to this. Thanks and kudos.
Is there going to be an option to exclude virtual devices for "total devices" or change the temp from celsius to farenheit?
understood! thanks for considering.
Thanks for the great app.
Is anyone considering having a symptom checklist for users to fill out when posting to the community and an items fixed checklist.
With multiple reports from this app, the symptoms and the items fixed, someone could build a diagnostics checker using AI that could help the users, with known issues, fix their issue without needing help from the forum. This could be a good learning experience for novice and intermediate level users.
I may have missed this in the discussion, is there an endpoint that I could use to run the app from a rule?
There is not. What output would you expect from that? The app is meant to be used sparingly, for diagnostics purposes when a problem is being experienced. I'm not sure it has a lot of predictive value at the moment.
I can't stress this enough, this app isn't free to run. It can really hammer the hub. The heaviest feature, device audit, is behind a button because of that. Also keep in mind that the app, being experimental, may surface a lot of false positives.
That being said, it is possible to schedule performance checkpoints and configuration snapshots. I suppose it would be easy to add a switch input to trigger those. It might also be possible to trigger the generation of a "full report" (saved to File Manager).
Was really thinking about the [quote="hubitrep, post:17, topic:164196"]
performance checkpoints and configuration snapshots
[/quote]. A schedule would be great for that.
After years in reliability engineering, I'm to collect failure mode and failure effect information based on the information in your app. Then giving users things to do to narrow down the problem. Perhaps the information the app gathers is enough....
The ability to schedule snapshots and checkpoints is there - look at the app settings in either the hub app or the from the html page. I just added the switches in case you prefer to trigger them from RM (can be set from hub app only).
That would also exclude most cloud/LAN devices I think, as their drivers are typically assigned to virtual devices.
Made it so it adapts to your hub setting, thanks for the flag.
Was looking at your code. Found the list of Integrations. Could you add B-Hyve, Sonoff and Yolink. I'd be happy to test them for you.
Can you be more specific about the outcome you are expecting?
The app does the identification algorithmically first: basically, any device that belongs to a parent app will be considered as part of an integration. The app only falls back on the integration table to set a connection type (cloud, lan direct or lan bridge). The table lookup is by string, which is brittle.
Yolink is surfaced, as well as others which are not in the table (e.g. Konnected).
