If I use the and card ‘main modus is’ and then ‘actual modus is’ I get all defined submodes as selectable not only the one defined for that main mode.
If I have defined submodes with the same name for different main modes it’s dificult to decide to select the right one.
Possible solution is a flow card like ‘main mode is … and aub mode is …’ where the sub mode is filtered by the main mode.
Use case:
I have sub modes ‘Guest in the house’ and ‘Guest gone’ for the main modes ‘away’ and ‘holiday’. They are triggert by a switch if our neighbor looks after our home if we are away and different settings are active depending witch main mode is active.
Ok, I could name the sub modes different, but with a lot of sub modes it’s still not perfect.
I’ve put version 3.3.11 into test, and it includes a new ‘and’ card where the main mode is… and the sub-mode [is…], with a filter for the sub-modes belonging to that main mode. And apparently, there was also a bug with the new lighting settings: if a schedule was set to turn off after a certain time, the light wouldn’t actually turn off
I can change that card to: Main mode [is / is not] [Holiday] and sub-mode [is / is not] [Guest in the house]. That way, you won’t need to use Homey’s option to invert the card either.
Updated the main mode/submode condition card. You can now specify “is” or “is not” for both the main mode and submode. The THEN card for setting a mode has also been improved, with a clearer, properly ordered list of main modes and their corresponding submodes.
Jist FYI @Erikje, feel absolutly free to adjust your app how you (or users) would like. It looks like an amazing app!
Im thinking about exploring your app myself, although, home/away/asleep for me is a separate option to vacation (all 3 modus could be true while vacation is also true, meaning, wake up is later, or lighting goes different etc).
But my point, i hardly doubt our apps will conflict with each other: the DC app (or AVDs) is an extremly customisable app, but nog logic behind it, and that will never be my intention (other then through templates). So AVDs will not overlap with the intention of your app.
And i hardly doubt that your app will ever have the ability to customise devices the way AVD does, else it will loose its purpose: a relative easy configured device which uses extreme customisable automation.
If anything, i wished our apps could potentially work together: your automation with my customisable AVDs, mean, that cpuld be a dream come true tbh
