What you are constructing is similar to Dimmer Per Mode in RM, except you are allowing different levels for each device for each mode.
BTW, not to discourage you, but you can do the outcome of this with Scenes Per Mode. In fact, I'd really encourage you to keep going. Groovy is not hard to learn, and it can open up many cool things for you.
Also, notice the shorthand that Groovy allows:
input "Level$a$b, "number", title: "Level for mode $b"
Thank you. I am going on with Groovy. Because I've got a lot of stuff up my sleeves. And a lot I can do with other apps, but some things are either to much work to make (especially with RM) or demands such a combination of apps that I lose oversight of all rules. And there are some things I just can't do at all (get items from Google calendar is also on my to-do list)
BTW I like RM, but it can be a monster to work with.
Before RM, the only option for doing automations was to write your own in Groovy. So it's intent is to allow most automations to be constructed. It has a lot of power, and with that power can come complexity. And complexity is the bane of understanding and hence of things working as expected.
I like KISS.
And yes RM is very powerful. But the learning curve is pretty steep (no problem there) and the UI can be a bitch if you mess up your rule.
btw no disrespect for all the great work of course! I mean really, you (and the whole team) are really working hard to help everybody and to improve your product!
It's like you've read my mind (or the few posts I've made wishing for this exact thing). I'm really impressed with what you've managed to do with RM (and other apps) given the limitations of an app UI structure you more or less weren't responsible for creating, but I've always wondered what would be possible if Hubitat created its own.
Sounds a lot like you're trying to modify my app. I hope my code is readable to normal humans! If it's what you mentioned in the other thread, I'm almost thinking that what you want might be possible with just RM (it has a "capture" and "restore" feature for dimmers/switches, which you could use before and after changing lights for motion activity/inactivity). Not that there's anything wrong with learning Groovy--as Bruce said, it opens up a lot of possibilities.
Yes, I am rebuilding your app to overcome my difficult desires . But to be honest I have not looked at your code yet. I decided to start from scratch. Though I have looked at some code of Cobra and some others I came across while searching for answers. And I really don't mind learning Groovy actually. It sort of a trip down memory lane.
We have some tricks up our sleeve. But I have to say that addressing the RM UI is down on our list a bit. Our focus will be on new-to-HA users, and giving them a smoother path into this fun.
Ok, it's been a while since I got around to go on with Groovy. Though I'm still struggling with the whole array part (List, Collection, Map or whatever they wanna call it).
The solution Bruce gave was fine for making it work on the "input" of things. But on the "output" side it's a hell. So I end up with all kinds of variables called "LevelBulb_1In_the_evening": 90
How would one go through all the different variables names and use the values? It does not make any sense. Well from a Basic point of view maybe... Should we use GOTO line number X also? I thought this was 2019? Where we can use multi-dimensional array's? What make sense to me is having something like: settings["Bulb_1"]["In_the_evening"]["Level"][90]
Yeah, what you want to create is a data structure to store all of this in one place, a Map would be a good one to use, Maps are great, but you're going to have to study up to make good use of them.
Something like this maybe
I actually found out my problem might be somewhere else... I am trying to use this "actions" list in multiple pages... So I thought it would be a global thing. But it's not. How can I make it global within my app instance?