New Built In Mode Manager Questions

I'm trying to move mode management from the Mode Manager app to the new built-in Mode Manager and I have a question about how the triggers work.

Specifically I'm trying to wrap my head around "Mode Resets." It appears that this option is available only on "Away" mode. At least that's true for me.

Do I understand correctly that if the reset option is triggered, the Away mode will be turned off, and whatever shadow mode was current will be turned on?

I took my dog out for a walk. Away was triggered as I expected. But when we came home, although the logs show that Home mode was triggered, it appeared from the dashboard that it never actually turned on and HSM was still set to Armed. I had to manually change the mode to Home before I entered. But I wasn't using the reset option, and I wonder if that was the difference?

Note if I don't get this to work it's not a big deal. My existing combination of the Mode Manager app plus RM rules works very well. Just curious about how new stuff works.

1 Like

I was curious about that too -- I just use Home and Away for modes, so my setup is as vanilla as it gets...

Although that Away Reset is the exact same thing as what activtes Home, I decided to use the Reset too -- I guess it just felt like a reasonable belt-&-suspenders approach, though I don't know if it's really necessary or not.

I admittedly haven't tested not using the Reset -- I just haven't had motivation to try.

1 Like

I have 4 modes: Home, Evening, Asleep, Away. So I deal with things like is it Home because I woke up, or Home because I just arrived? And different things happen if it becomes Evening while I'm home vs Evening when I return. So I can see that the new built-in Mode Manager might make some things simpler if the reset works like I think it does.

I've done some testing today and it appears that the reset option on the Away mode does work the way I assumed.

Here's my simplified mode setup in the built-in Mode Manager:

  • Home: Switch-Day is on
  • Evening: Sunset -5 minutes
  • Asleep: Switch-Day is off
  • Away: Everyone leaves / Reset: Someone returns

I came and went multiple times during the day. Each time Mode changed to Away when I left, and back to Home when I returned.

I took my dog for a walk this afternoon. It was before sunset when we left and the mode was Home until Away was triggered. When we got back, it was after sunset and Mode became Evening.

So, yes, "Reset" changes the mode from Away to whatever the shadow mode is.

Probably I'm the last to figure this out. But I changed from the legacy Mode Manager to the new Mode Manager app when it came out with a pretty much straight-across move. Everything worked, so I never questioned how I had it set up. But this has certainly simplified my mode management.

1 Like

Nice - thanks for confirming!

1 Like

I’ll jump on this one too if you don’t mind, in the integrated mode manager how do you define the mode switch times if they occur at different times depending on day of the week e.g

I have day mode activate at 05.15 Mon to Fri and on Sat & Sunday this activates at 08.30

I couldn’t seem to get that working without creating seperate instances of “day” and then I would have to have both of those day modes in my room lighting rules :thinking:

No idea. In the Mode Manager app it would give you a new line to pick the days you didn't pick before. Maybe someone else knows. I wonder if this is a bug?

I unsolved my question, so maybe someone in the know will take a look. Or maybe you might want to start your own thread to give it more visibility.

Yeh I can’t work it out in the old app it looked like this

In the new integrated app in seems I have to make another mode of day to achieve the same, unless I’m missing something.

2 Likes

Yeah, I also made an effort to migrate to the integrated mode manager when I realised it had been released, but ran in to the same issue as you. I also use a couple of “earlier time of X or Y” and “later time of X or Y” and couldn’t see a way of replicating those either. I gave up my migration attempt and just figured that the new integrated mode manager must be the “basic rules” equivalent and if you need anything more complex, stick with the old mode manager. The migration attempt lead me to explore shadow mode more in the legacy mode manager and I have now doubled down on using that :joy:

2 Likes

Not a solution for within the built-in Mode Manager. But one thing to consider if you wanted to move over there. I'm retired and I don't keep a set schedule. I go to bed when I'm tired and wake up when I wake up. I use a switch — Switch-Day — as the trigger for Home and Asleep modes. In my case I tell Alexa or Siri to turn it on and off. But there's no reason that you couldn't have a RM rule set up to turn it on a different times for different days.

Of course this is way more complicated than just staying with the Mode Manager app. I'd probably choose to not make things more complicated.

1 Like

** disregard this is not the solution :pleading_face: my modes are very screwed up now**

I think I have it sorted, well at least it appears to be working as it should duplication of modes seems to be the way forward, there must be something in the background that recognises the second day is still day. (If that makes any sense).

The thing that caught me out was when I added an additional night I had to go back in to each instance or room lighting and re select night and the appropriate light configuration.

I’ll see how it pans out, but generally if there is a neater solution I’m all in (and I don’t like being beaten by tech)

Mode setup as it stands.

1 Like

TLDR; Duplicate modes don't appear to be an intended way to set up different days. Bad things happened when I created duplicate modes. There needs to be an update to prevent a user from creating modes with duplicate names.


I was thinking "modes with the same name must be the same thing". Looks like that's not the case. I had a mode named "Test". I created a second mode also named "Test" with different day/time triggers. I then tried to set up a rule in Rule Machine to using Test mode as the trigger. In Rule Machine, there are two entries with the same name:

I created two rules, one triggered by the first "test" mode listed, and one by the second. The rule just writes a log entry to say it was triggered.

When I went to the integrated mode manager and manually activated either "Test" mode, only the rule where I selected the second one fired. No matter which copy of "Test" I tried to activate, the rule I created where I had selected the first "Test" on the list would not trigger.

I switched the first rule to use the second trigger, and then both rules fired. So only the second instance of "Test" on the drop-down list was working. A rule based on the first instance of "Test" in that drop down would never fire.

To clarify, no matter which "Test" mode I tried to activate, the FIRST one that I created was the one that showed active. But that seemed to correspond to the SECOND one in the drop down list in Rule Machine.

When I click the button I circled in green, the active flag gets set on the other mode.

I couldn't find any way to activate the second Test mode. To make sure the bug isn't only with manual activation, I switched the second Test mode to activate at 12:02 PM. When that time arrived, the OTHER test mode activated. This screen shot was taken at 12:03.

In the logs, there are debug entries for app #1417 (Test mode setter) and app #1439 (Test mode setter).

I'm a bit surprised by this. I expected that the mode names were just a label and the real mode was an integer. The logs kind of confirm this by showing:

processing action for [mode:7, actionType:setModeUnlessAway, deviceIds:, description:Set mode to Test, index:0, type:then]

for one of the modes and

processing action for [mode:5, actionType:setModeUnlessAway, deviceIds:, description:Set mode to Test, index:0, type:then]

for the other one. But if the name were truly just a label, I would expect that I would have been able to get the 'active' flag to appear on either Test mode, and I would have expected I could trigger a rule based on either Test mode. Instead, it seems that despite one being shown as mode 5 and one as mode 7, they are interfering with each other due to the name/label being the same.

2 Likes

Correct, modes have both a name and an ID. An app can use either, with advantages and disadvantages to both. (Using the name means you can't rename the mode without having to reconfigure the app; using the ID means you can, among other concerns.) Each app may handle things differently, so behavior will not necessarily be the same on every app you try. I'd wager most built-in apps use the ID, so different modes with the same name are still different modes.

Whether it should let you do that or not, I don't know, but maybe not....I don't know what the behavior was in the old Settings page, other than that I don't remember this question coming up then.

1 Like

Well I’m at a loss then, is there no way to have the same mode trigger at different times dependant on days of the week - the above certainly explains why my lights aren’t working today :joy::joy:, back to the old version till some clarity comes on how this new one works.

2 Likes

I'll check it out. The built-in mode manager was intended as a "starter" with limited functionality, but this is a common enough scenario that it should handle gracefully.

7 Likes

I think the new built-in Mode Manager is much more intuitive which is great thing for new users. In addition to the above scenario, I have another request for you to consider (but I understand if it is just to unique to my requirements).

In the Mode Manager App. I have skip selected on my Sleep mode which is the only Mode I control with RM for both when it enters Sleep and when it returns to my normal time based modes. My setup could be really simplified if the new built-in Mode Manage supported creating a custom Mode that has the same attributes as the Away mode where you can specify a trigger both Set and Exit while tracking the correct Mode to return to if that makes sense. I realize this is a more advanced use case, but would work great for my needs and I imagine others would find creative uses that may simplify their setups also.

Thanks for considering this request and understand if you prefer to keep it simple as I certainly can continue maintaining my current complexity also.

1 Like