[FEATURE REQUEST] Global Enum Variables [a.k.a.] Parallel Modes

[mbishop]

There was a discussion several years ago, which started as "multiple Modes" and wound up with the conclusion that Mode is essentially a privileged global variable, and that anything you can do with a Mode, you can do with a variable, too. Since that time, Hubitat has made great strides in the usability of global variables on the hub. I absolutely do not want to discount the strides there! In fact, I want to build on them.

The scenario I'm trying to improve is essentially that some automations care about presence as well as time of day (interior lighting, for example) while some automations only care about time of day or illumination (exterior lighting, for example). Currently, the latter look directly at the illuminance value, but I'd rather have those thresholds centrally managed. If I set my porch lights to be on when it's "Dark", that automation doesn't trigger if no one is home, something I'd rather not advertise. (The alternative is to remove my Away mode and have everything that cares about presence look at an aggregate presence sensor instead. This is a possibility, and probably the direction I'll go next.)

To my mind, the main feature that Mode offers which a String variable doesn't is being essentially a dynamic enum -- you can't typo the string value, because you're selecting from a drop-down. You can rename a value of the enum without needing to update every app that touches it.

I've considered writing an app or driver to provide this feature, but the only device capability that allows for DYNAMIC_ENUM is LocationMode, and this thread suggests that there are no UI affordances for DYNAMIC_ENUM at this time, so it's still just a string. The only approach I've thought of -- and it's evil -- is to have an app that dynamically pushes driver code with a new "static" enum in the updated definition. That seems tricky to maintain, to say the least; I don't want to go there.

Would HE consider adding editable enums to the global variable types? If there's an easier way to build such an app, I'd be happy to write it if someone points the way.

[nh.schottfam]

An app can get all the available modes, and use that during it initialization

for (mode in location.modes){ ... }

[mbishop]

Sure, but that seems largely unrelated to my suggestion...? It can do that for Mode, but not for variables in general, because there's no enum type.

[nh.schottfam]

You can store in a global a json string if you wish.

[mbishop]

I'm still not seeing how that helps. Are you suggesting I could store the set of allowed values alongside the current value? If so, that only helps apps that know that convention. I'm asking for something that might result in a drop-down for RM et al.