Must I replicate Mode Manager's time of day rules in Rule Manager?

Can someone clue me in if I'm overlooking something here?

Based on the examples give in mode manager, I've setup basic Day, Evening, Night modes based on time of day. My intent was to change the scenes activated upon entry for softer lights at night. This works pretty well. There's also Away mode, which is set as a modes to ignore time changes. So when you're away, it won't change.

Likewise, I have then setup HSM to track Modes:

  • Arm Away when mode Away
  • Arm Night when Night
  • Disarm modes: Day, Evening

Again, this works pretty well on its face. So how to this relate to Rule Manager? This seems to be unidirectional without Rule Manager. You can set HSM based on Mode, but not vice versa. Not necessarily a problem, but...

When an event happens to disarm HSM, it seems the only way to keep HSM/Mode in sync is to change the Mode, which will be observed by HSM. Test this with rules and it works fine. However... in testing it would appear you have to replicate all the time of day changes into Rule Manager.

I created a Rule which triggers on the disarm event with an action to set the Mode to Day. This caused HSM to disarm, which was great. However, if it was Evening when this happened the mode never set to Evening... it seems the time changes are one-time events and not "anytime between these points". The only answer I've found so far is to replicate the time-of-day adjustments from Mode Manager into the disarm rule.

Am I missing anything which could make this better?

Yes. Mode is a state that is accessible by all apps in the hub. You will now be able to select the condition of what the mode is in a rule. So, let's say you have a button controller rule and you want pressing that button to trigger a different scene depending on mode. You will select the action "Activate Scene per Mode" and all of your modes will be displayed for you to select a scene for each of them (yes you can repeat you don't have to have a different one for each).

Mode is a global function throughout the system. You don't have to set it up again in another app.

Just some additional info for you, a video was produced which may help you.
Here's the latest one.

Sorry, I am missing what you are saying. Let me explain an example timeline and maybe you can help?

  1. I leave home. Mode shifts to Away because of a trigger.
  2. Evening comes, but Mode does not shift to Evening because it's in Away (as configured)
  3. I return home and Disarm HSM in the Evening time window.

How do I get the mode to be Evening, after leaving Away? If I set to Day, it will remain in Day mode all Evening. Likewise, if I set to Evening and it's in daytime it will stay in Evening the rest of the day.

In mode manager. If you have the time of day set in Mode Manager, when you return from away, either by presence or by switch, it will pick the correct mode for you.

That video takes a person through setting up the config I described above. I had already set that up, as described in the opening query. Nothing in that video deals with how to ensure you return to the time-appropriate mode after leaving Away.

There is an option:

image

Enabling that will use your time of day settings to set the mode based on what time you return from Away.

I have an external trigger for returning from away--disarm via keypad. Hubitat's presence stuff doesn't work for us, and even if it did mobile presence is subject to random fluctuations. We don't want a single switch to control disarm-- we want a pin to be used.

I realized as I was responding I could probably used keycode to trigger a virtual device, but that seems to be padding around the problem. Is there a more direct way to trigger Mode Manager to assign the right time of day mode?

I just thought I would post it in case you had not seen it.
Personally I don't use it as I used a rule in the early days and just kept using a rule opposed to Mode Manager.
Here is my rule for modes which works and is relatively basic as I like to keep things simple.

BTW, the repeat every hour is a belt and braces in case the rule doesn't get evaluated for whatever reason. It just ensures it is in the right mode every hour. Hasn't been needed yet though. (I think).

It only supports button devices. A single button to disable the alarm without confirmation of who did it is not acceptable for us. We want keypad-based unlock.

If you want to use Mode Manager, you can return from away via a button or a switch or presence. Any of those can also be virtual devices.

HOWEVER....you are going to run into a bit of a problem here.....

You said earlier that you have HSM set up to follow Mode. Now you are saying that you want HSM to drive a change in Mode? That's going to cause some circular problems between HSM and Mode manager.

You can have HSM being disarmed trigger a VIRTUAL SWITCH that isn't accessible from a dashboard or anywhere else. Problem solved.

Yeah, I was thinking that a generalized Rule instead of Mode Manager might be required. But I was hoping there would be a more direct option.

@bravenel or @chuck.schwer is there any chance that Return from Away could be made an Action available in Rule Manager? That would solve this problem for me, and avoid the need to create a separate time ruleset.

Alternately, could we have an HSM disarm action be one of the triggers? Either way would work very cleanly, and not require users to create virtual devices to relay state.

Just use a virtual button. Or a virtual switch. Problem solved.

I was doing that first, but I realized HSM tracks Mode Manager so now I have the keypad unlock change the Mode, and HSM immediately adjusts. So it's only one direction.

Yes, a separate virtual device is a workaround. Before I went that route I wanted to make sure I wasn't overlooking a more direct option. At one point I have something like 60 virtual devices for tracking state like that, and I've managed it whittle it down to just half a dozen or so.

From a features perspective for Hubitat, "create a virtual device to do this" rules out 98% of the users (the 2% number came from someone in Hubitat). I feel like creating a virtual device is our (developers/hackers) ad-hoc step to work around something that hasn't been sufficiently integrated. And sometimes I find we hacked around it, but Hubitat did the right thing and integrated it well and we can get rid of the hacks. So this is me trying to make sure I didn't overlook a better integration.

That said, thank you @Ryan780 for confirming the workaround for me. Not trying to give you static, I do appreciate your insight.

So you removed the Keypad from HSM? Recreating all the functionality you lose by doing that will involve writing a lot of rules.

60 down to 12? That is quite a dramatic difference. I will say, the switch capability is the way that a lot of devices are exposed to outside influence in Hubitat. Unless you want to write your own apps, then you are stuck using what is available.

That's the route that I took. I didn't like Mode Manager or Thermostat Scheduler so I wrote my own that combined the two and directs HSM. It is all EXTREMELY custom and would make no sense at all to anybody else, but it works EXACTLY how I want it to. But that level of customization is only possible if you learn how to code your own apps in Groovy. It's not really that hard. I'm not a coder by any formal training, just self taught. I have a feeling that you'll end up in the same boat. Sick of settling for what you can do and want it exactly how you want it. :slight_smile:

Totally valid for people who want to hack a lot on it. I could easily do the same, but...

Pulling from my professional side, I work in FOSS communities where sharing our work with others has led to overall improvements in quality and usability for others. So I see tremendous value in making stuff that I need, but ensuring it's high enough quality and general purpose to get it in front of others who might catch my failures and/or contribute their own features to it. So this mindset leaves me with more interest in creating general purpose things others can and will use, and less interest in bespoke efforts I'm stuck maintaining on my own.

Obviously tremendously YMMV, and everyone makes their own choices about their efforts and interest.

No, sorry. Confused this I did. :wink: I just added a rule that an unlock action changed Mode back to Day.

Also we have several different types of keypads (including lock keypads) and HSM doesn't track all of them.

Keypads are keypads and locks are locks. I would not use those two interchangeably.

Speaking of which, is there a way my driver could (if enabled by the user in Preferences) do Mode Return from Away via direct action / not force the user to setup a virtual device?

This would be intended for those who want to control alarm state from their Abode, so that if they disable the Abode alarm it would reflect that in Mode/HSM. It would be great if the user could enable this without having to create a virtual device and a Rule.

Yes, your driver could expose and of the three capabilities we have already discussed: switch, button or presence. That is the only way to tell Mode Manager to "return from home". But if you are writing a custom driver, that is how you would do it. That is a limitation of Mode Manager. But there is no requirement that you use Mode Manager to manage your mode.

You're writing a custom driver you plan on releasing? For what type of device?