Is there a way to view and use apps, integrations, and automations combined - as in prior to the separation in a recent “upgrade”? I find it a PITA to remember which one is which and go back and forth to the main menu to select. If not, there really needs to be a choice for the user!
http://<HubIpAddr>/installedapp/list
This just gave me the integrations not the combined list as was prior to the upgrade that broke it. I would like to have it the way it was in the app on my iPhone where all three - app, integration, and automations are combined. It would be nice to have it on the menu as a selection of Apps - Integrations - Automations - Combined.
So is there a workaround or do they just have to curse at it everytime I’m looking for something?
You do know that Search in any will tell you it's found in another, right?

Yes, I’m aware - still a PITA from what it was…
![]()
Yes, I read that a lot in the other topic...
Most of them will appear here, shortly, I predict.
![]()
I think this makes things easier for new users, at the cost of familiarity for early adopters. It's taken a bit, but now I like and accept the "new way." May as well adopt it.
I just want to know if I can reclassify apps? I want Hubithings to be in Integrations and not Apps.
You can by editing the source, BUT the developer doesn't have to make the change and the next update you do, will revert it.
Well then a suggestion I have @bobbyD is to allow users to easily categorize the apps. Maybe when I click the i for information over to the right and it opens that app's settings, there can be a section for settings that are independent from the app settings that the developer puts in. Maybe "User settings". This would also take care of @LGNEO's use case as well because he could just re-classify everything as an app.
Unfortunately the app definition can't be programmatically written or overwritten, so the code must be manually updated. As @csteele mentioned above, any new update that changes the definition will rewrite the menu definition too.
IMO- a feature should never be taken away. It can be added onto, but never taken away. Some thought should have been put into the “change”. It could have been put as a list where the parent would be the way it was, first child = app, second = integration and third = applications. That way you could have satisfied the need for change and still appeased the early adopters.
But that's exactly what happened. We added two new menu items. The Apps menu remained untouched.
Then can Zone Motion Controllers and Groups and Scenes be moved from Apps to Automations?
I wasn't going to get into the debate about features being removed... but I don't see how you can say the apps menu is untouched. It literally displays less things than it did before the update and there is no way to change that currently.
I like the idea of the categorization, but dislike not being able to categorize how I want.
It's the default, just like it's always been. There are now two additional menus and they have to be explicitly selected by the developer.
@bobbyD So what Hubitat is saying is; that’s the way the hierarchy said it’s going to be, don’t like it, move on. No user input needed.
What makes you think that? I addressed your point that "a feature should never be taken away" which we never do.
User input is always welcome, that sets Hubitat apart from others.
Do you mean something like this? The Apps Code page for each application would allow the user to select App, Automation, or Integration. This selection would take preference over the value in the code, so developer updates would not override the user's choice.
So what is the official Hubitat definition of what is an app, an integration, and an automation?
Per Claude AI -
“In Hubitat, these three terms have distinct meanings:
App
The broadest category. An “app” is any piece of software running on the Hubitat hub that adds functionality beyond the core platform. Both integrations and automations are technically apps under the hood — they’re all installed from the Apps section of the UI.
Integration
An app whose primary purpose is to connect Hubitat to an external system, service, or device ecosystem. It bridges Hubitat with something outside itself — like connecting to a cloud service, a third-party platform, or a protocol that needs a software layer. Examples: Google Home integration, Amazon Echo Skill, LIFX integration, Maker API. The result of an integration is usually new devices appearing in Hubitat, or Hubitat’s devices becoming visible to another system.
Automation
An app whose purpose is to do things based on logic, rules, triggers, schedules, or conditions — using devices already in Hubitat. It’s the “if this, then that” layer. Examples: Rule Machine, Simple Automation Rules, Motion Lighting, Notifications. No new devices are created; instead, existing devices are controlled or monitored.”
So, all that is listed is an APP. Using this logic, then integration, and automation is a subcategory of app and should be treated as such. Therefore, change the menu to App (with everything included) with subcategories of Integration and Automation.
All I’m saying is listen to the users since we all are Hubitat. Give us a choice…
out…
@LGNEO, Claude defines "Maker API" as in Integration, but Hubitat still sorts it as an App. Personally, I think Claude's got it right.
Count me as another vote for user selection of category, per @JDC's suggestion. I'm using at least one other App (for Yolink) that I would define as an integration, but which will (seemingly) not be updated by its author, and therefore will continue to be in the "wrong" place.