Maybe add a setting that allows for auto checking of updates (not installing!). Would like to see if there is an update available on the main settings page or title bar/messages if possible. Just one or 2 less clicks I have to do but no biggie!
Speaking of convenience it might also be good to have at least the local link next to the dashboard name on the apps main page as well. Again one less click and it only really matters when managing multiple dashboards - would have been kinda handy during this Halloween season while setting up my HE inspired trickery..
In the top right corner I get an orange icon that appears when there is an "alert" of any kind...include firmware updates. It's obvious on my desktop but only shows in landscape on my phone.
So I have another suggestion - this one is for the Mode Manager app.. I want to have multiple custom away modes like away & away@night etc. I can set these through RM but seems like Mode Manager should be able to handle this.. Ideally all the away modes would be considered as "away" for purposes of monitoring etc.
Extending the idea further - for the modes themselves maybe instead of just "Name" have a mode property like "type" that you could set to predefined system types like "away"/"home"/"alert" OR simply just a boolean "away" - which would be set on the Location configuration page.. Other apps like MM would then be able to know that a given mode was either an "away" mode or not for selection/testing purposes..
Of course this may be overcomplicating things.. which is a dev trap I frequently fall into.
You can make up all of the modes you want, and both RM and Mode Manager can deal with them for you. The only baked in aspect of modes anywhere in the system is the special property of Away in Mode Manager. That is, it is ignored for time-of-day setting of mode, and returning from it can cause time-of-day to apply to the return mode.
People tried to go down this path that you are describing in ST a few years ago, in the context of a security app. It lead to a huge mess, as it completely overloaded and conflated different concepts onto a basically simple thing: mode is just a list of names that you interpret how you want to. Not my place to be a preacher about this, but experience suggests that simple is better when it comes to modes.
Are you conflating location mode with HSM status? I'm not saying you are, but the intent of location mode is so vague (on both this and a certain other platform) that it's hard to tell from a description. From what Bruce says above, I'd say this is intentional--mode is best seen as a way to restrict automations from running ("only in certain mode(s)" is a default restriction available to all apps), and people can implement modes with whatever meaning they want that makes it useful for them: home or away, day/night, etc.
Personally, I use modes primarily to "fork" most of my lighting automations (probably my favorite use of Hubitat) into different paths depending on time of day. Thus, my modes are named Morning, Day, Evening, and Night (maybe should have called this "Sleep"). They change automatically, mostly with the help of Mode Manager, based on sunrise/sunset times, my sleep/wake times, and manually as needed. They do not figure into my use of HSM at all.
It sounds like you can do what you want by just creating a virtual "Away" switch to complement your mode selection. Many apps will allow you to use a "only if switch X is on/off"-type restriction, then keep using location mode in a way that might be similar to what I'm doing. You can automate the changing of this virtual switch based on whatever is available to Hubitat, e.g., HSM status or whatever presence devices you might be using (or you could use this to automate HSM status). This avoids needing to create separate modes like Home-Night, Away-Night, etc., which is the only other option I can think of since location mode can only be set to a single value (not only would adding all these modes be counter to Bruce's advice above, it would also be difficult to switch between them--say you're in Away-Day but come back home; you'll have to make sure it knows to revert to Home-Day or whatever, and do this for each mode you have).
If your "away" concerns are always tied to HSM, some automations may also let you restrict based on HSM status, so you might not even need to do either of these things. However, apps that allow restrictions based on HSM status are much less common. The virtual switch was a workaround I saw some people use on ST, and it may be useful to you as well. I don't bother, since again I mostly use mode for lights, and if I'm "away," I probably still want them to turn on if it thinks someone's there (they shouldn't be ).
So in thinking about this further I may have indeed conflated the two (mode/HSM Status) with respect to Mode Manager..
In ST I used modes as a running global variable status. I had several modes - home, home@night, away, away@night, hold & alert. I then had the monitoring, routines and various rules that reacted in different ways based on these. Seemed a nice clean, logical way to do things without additional virtual devices etc.
).
