I would love to open a discussion about philosophy and how I've implemented some things. This is NOT that.
Modes in my mind are time periods. Heck, imo the name "Mode' is weird - the name 'Period' would be more apt, at least in my home world.
I also have 'state' and 'presence'. State, is 'Awake' or 'Sleeping'. Modes (or Periods for sake of this discussion) are not affected by State. Presence is 'Home' or 'Away'. There is a bit of weakness in the concept I use, since Sleeping sort of assumes 'Home' but let's let that dog lie for now.
When I attempted to implement Modes with Mode Manager a long time ago, I couldn't figure out how to use Modes with 2 states. I recall a user post about having 'Day - Sleeping' and 'Day - Awake' blah blah, but that was complex and didn't manage well.
Just for example, if I go to bed early, out of my normal 'sleeping' period, all my automations are still acting as if I'm awake. So having a 'sleeping' period, didn't work - I had to seperate that from modes. Now I have modes for each period of the day, and the flag, sleeping seperately handled with virtual switch.
My feature request - create Conditional modes. Then, the mode manager would be able to show me mode 'Day' but also carry a State. In the definition of the mode, you would (could) define multiple values for the new Mode, which would expand the flexibility of the Mode to reflect potential differences that reflect both the time Period as well as State (and even Presence).
While not the most well thought idea, I would love to go back to using Mode Manager. I stopped using it long ago so I could manage more robustly.
A missing ability for Mode manager is the ability to trigger a recheck. I could use modes AND rules to accomplish my needs, if I had a way to force mode manager to reset the Period after switching from Awake/Sleeping. For now, I have a complex rule simulating Modes.
Modes are nothing more than a convention to begin (and end) with. They have no intrinsic meaning beyond what you give them. They have 'global' reach, and basically are no more than a name. A Hub Variable has the same reach, and the same arbitrariness of interpretation. Mode Manager, as an app, simply imposes a particular interpretation on modes, primarily based on times but also on presence, switches or buttons. All of this is arbitrary, and its present use and interpretation derives from the way I thought they were useful for me, dating back to ST days. But, I have (and had) very simple needs, so modes are pretty simple. It's not surprising that modes are inadequate for other less simple use cases.
What you are describing would need a different Mode Manager app. Perhaps some enterprising user will write one to implement your needs.
Thank You @bravenel. Interesting info for sure. As a user, I see 'Mode Manager' and think thats what I'm supposed to do. It never occurred to me, as obvious as it is, that is just an app.
Mode Manager was originally pretty simple, until users started asking for more features (like switches and buttons, or other modes that act like Away). Even Away is arbitrary, although that one is more baked in to its meaning than any other mode.
I realized that myself! that was why I shied away from the discussion in the OP. Presence - home / away... is okay, but what about multiple bodies? etc etc. Even presence to a room... it goes down a slippery slope for sure.
But if you factor in 'build to your own needs' as you've suggested - it makes easy sense. Thanks for your help.
