Mode Manger with Guest Mode or Virtual switch for Guest Status?

🧰 Built-In Apps and Drivers Built-in Apps
#1

I have a need for some automations to behave differently than usual when/if there are guests staying overnight.
Per the thread: Guest mode options for setting this up include via Mode Manager and via a Virtual Switch. I'm trying to assess the pros and cons of using one or the other, and am posting to get insight from those far more experienced than me.

  1. I don't use mode manager now as I just don't see any need for it.
  • I have no grouping of automations that happens at the same time. Using either set times or sunrise/sunset with various +/- offsets in rule machine and room lighting serves my household needs well.
  • I have one "Night" trigger that occurs at a different time every day, and is triggered by turning a particular switch off. This is the only thing that has more than one automation associated with it, but again, it works fine with the trigger turning off that switch. Making turning off that switch trigger Night mode, and then Night mode triggering various automations seems to add one more variable that seems to me is more complex...
    = This leads me to believe I could use Mode Manager and set modes of Guest and No Guests. What I am unclear on is whether the modes in Mode Manager are tied into the HSM modes. I may want to use HSM in the future and don't want to do something now that would create extra work then.

  1. I don't yet have a dedicated physical display for dashboard interaction. So I'm reliant on my computer or my phone to log onto a HE dashboard and press a button, or programming a switch I already have as a 2x or 3x press to trigger the "virtual switch." Am I properly understanding how virtual switches work?
    Is it possible to set up an Inovelli switch to glow a different color, as a visual confirmation, at a 3x press to turn on the Guest virtual switch?
    Is there a pro/con to using one or the other in terms of dashboards and/or writing automations?

  2. Other ideas?

  • I am strongly opposed to adding battery operated devices.
  • The only effective sensor I can fathom for this is an mmwave sensor in each room that would detect the presence of sleeping people. The only switch in each guest sleeping room is a single switch for a dumb ceiling fan/light combo, so I don't think an appropriate switch is even in the works yet. It would be possible to ceiling mount a sensor and power it from the attic, but I cannot find any availability yet for one that would not show the usb cable coming out of the side, and would require the hole in ceiling only be large enough for the USB cable. Thus at present I think setting Guest Mode or Guest Status will involve some sort of manual operation.
#2

If you don’t use mode manager already and have no other pressing need for other modes, then it might be simpler to use a virtual switch to restrict your automations from triggering.

If you anticipate using additional modes to trigger or restrict other automations in the future, then it might make more sense to get started with mode manager now.

Nope. Think of HSM as having different alarm arming states. Totally unrelated to modes unless you configure HSM to arm/disarm when the hub changes to certain modes.

#3

If only conceptually, a switch makes more sense to me in that it is an on or off state, i.e. You have guests or you don't, whereas modes can cover a range of states. That is of course assuming you don't want to have some variations for different guests, that would lend itself more to modes.

Plenty of apps offer some use of a switch to enable or disable their features, whereas modes is less common for toggling rules in this way.

1 Like
#4

I use Rule Machine for managing modes. It's taken me ages to perfect, but now everything is great. Modes change automatically based on who's home and who's not, using geolocation and ZigBee presence sensors. Entry codes work great for setting modes for guests and housekeepers.

1 Like
#5

I've decided to use a virtual switch for this. In trying to implement it, I've got some questions:

I set up the virtual switch in devices so it exists. I did not see any options for additional definition in devices.

Then, in Rule Machine, I added a rule whose trigger is a triple click up on an unrelated Inovelli Switch, and the resulting action is to turn on the Virtual Switch. This also works fine.

Q1: Is a separate rule needed to turn off the Virtual Switch or is there some way to define both the on (triple click up) and the off (triple click down) in the same rule? If so what is the best method (ie how??), and is there any disadvantage to combining on and off into one rule?

Ideally, whenever this virtual switch is on, I'd like the LED color on that same Inovelli switch to change the to blue. I could include this LED color change in the rule, but then the LED color change would be tied to the triple click trigger, and I'd like the color to change even when the Virtual Switch is turned on and off digitally (via Hubitat dashboard or device page).

Q2: Is the recommended practice to make the LED color a separate rule triggered by the the switch status, or is there some way to combine both the LED color and the physical on/off option into one rule? If so, is there any disadvantage to doing this?

#6

I would make separate rules for the the thing that controls the switch and the things that happen when the switch is changed.

You can easily combine the ON/OFF functions into a single rule very easily. Sorry, I can't easily connect to my home network at the moment so I can't screenshot an example for you just now, but, its pretty easy.

Trigger: Innovelli up 3x, Innovelli down 3x. (use both states as triggers, then either will start this rule)

Then for Actions, use:

  • [IF] innovelli up3x [THEN]
  • ON: virtual switch
  • [ELSE-IF] innovelli down3x [THEN]
  • OFF: virtual switch

That should be the first rule.

Then, you could also make a single rule for the actions of the switch state being changed in the same format:

Trigger: virtual switch (changed)

Actions:

  • [IF] virtual switch ON [THEN]:
  • Set your lights blue
  • [ELSE]
  • Set your lights white (or whatever)
2 Likes
#7

I have the same question. I think technically you could write it as:

Trigger: Triple Up
Action: Turn on virtual switch
Wait: Triple Down
Action: Turn off virtual switch

But, I’m somewhat confused about the “Wait”. I don’t know if that means it’s constantly polling for the event on your switch, which in my mind, is going to be worse than just creating 2 separate rules.

I would probably make a separate rule called like “Mode LED indicator” just for the LED incase you want it to be based on a different mode. For example, I know a lot of people here use red to indicate that they’re in “Away” or “Night” mode and their alarm is armed. So, I guess (at least for my uses), I’d also add to the first rule to change to “Guest” mode and create a rule for the LED that changes colors based on my system Mode.

#8

I used to think like this and started reading that using events is better than conditions if you can. This probably shows that’s not always the case!

#9

In my view, the issue with this method is that as soon as you tap the switch 3x up to turn the virtual switch ON, now the rule is running in the background continuously in a wait state until you hit the down 3x command. On the other hand, using the conditional action, it will execute the appropriate action and then simply end.

Also, should something happen to cancel the wait state AFTER the switch had turned on, (like the rule exits or the hub reboots), now there is no discrete way to turn the virtual switch off now. Down 3x will not trigger anything because the rule is not actively waiting. With a conditional rule, you avoid this potential issue.

I am sure there are other ways as well. I am a pretty big fan of conditions though.

#10

@a.mcdear

I totally agree for this. But, this was the post that made me think I had to start thinking differently lol. A few comments down, I believe one of the staff (?) said it was better to use events rather than conditions when you can.

#11

I could be wrong, but I believe this thread you've linked is referring to something different entirely. This thread from 2020 was a question about two different types of waits: Wait for Condition vs. Wait for Event.

"Wait for Condition" I am pretty sure has been deprecated and/or renamed to "Wait for Expression"

This is not the same thing as a conditional action. I think this is why it was changed from "Condition" to "Expression", to avoid exactly this type of confusion with other things that were already called "conditions"

#12

I’m pretty sure it’s talking about changing a rule like this:

Trigger: Generator sensor CHANGED

IF (~ Generator sensor inactive(T) [TRUE]) THEN
    Cancel Delayed Actions
    inactive() on Generator virtual sensor
ELSE
    Delay 0:00:10 (cancelable)
    IF (~ Generator sensor active(F) [FALSE]) THEN
	active() on Generator virtual sensor
    END-IF
END-IF

To a rule like this instead. Ignore the IF…THEN, he was getting false positives with his vibration sensor from squirrels.

Trigger: Generator sensor ACTIVE

Delay 0:00:10
IF (~ Generator sensor active(F) [FALSE]) THEN
    active() on Generator virtual sensor
    Wait for condition: ~ Generator sensor inactive TRUE
    inactive() on Generator virtual sensor
END-IF

According to the video, the reason it works is because the “Wait” is a subscription that gets stored in the database and is essentially free. I should have watched the video again because it answered my question on whether it was constantly polling/running in the background and the answer is “No.”.

1 Like
#13

The conversation may have moved on, and this may not be the most useful input at this stage... but hey, I'll have a go :slight_smile:

To use a different example... And I'm not suggesting this is in some way "best-practice", but my approach...

I can have different "Mode Change" triggers that transition me into certain modes, they could be Samsung Button presses, virtual button presses, changes in presence, etc. I then have different actions I want to take when the "Mode Changes to X". So I have some RM rules, Button Controller Apps, etc that are used to define how I trigger a mode transition. I then have, typically RM Rules, for what to do when the "Mode Becomes X".

I guess what I'm getting at is, in my case, I may have multiple methods to move into a mode such as Night, defined in separate Apps / Rules, but then have a single spot where I define what to do when I the mode changes to Night. I may add new rules that trigger the transition to Night, but my list of Actions to perform when I make that transition does not need to change.

This is likely stepping more into my day-job and not relevant for many situations, including yours, but may be useful for some people who want options for triggers, but centralise their response to something like a mode change, or even the change in the state of a virtual switch.

2 Likes
#14

This is exactly my thoughts on Mode usage and what I’m trying to do. While I am super eager to write some rules already, I feel as though, I need to just step back and organize my main infrastructure. I feel as though setting up my Modes properly falls under that category. It’s almost like setting up solid Reference Data in a software system. What else would you consider part of the “infrastructure”?

#15

This is exactly how I do it too.

#16

I started with a flowchart and moved on to a composition notebook. The flowchart helped me come up with all of my various modes that I wanted, all the various things that happen when those modes, and when to use variables or virtual switches for keeping track of state info.

Then I started building my rules. I started this years ago, and essentially it's all in RM 5.1 now. It's still a work in progress, I am always tweaking things here or there as the days go, but essentially I have replicated all the capabilities of Mode Manager and HSM (I was in way too deep when I discovered those apps later in my Hubitat journey)

Now I literally have a whole binder filled with notes, handwritten rules, flowcharts, hub variables, etc so that hopefully if something happened to me, maybe my wife has a chance of understanding how everything works.

2 Likes
#17

Thank you for all the responses!

Re modes vs virtual switch
I decided to go with a virtual switch because even though I don't currently use modes for anything else, if I used it to toggle guest status, it would preclude using it for anything else later, and a virtual switch will work fine.

Re how I write the rules for the virtual switch
Working backwards:
I totally agree with @sburke781 & @a.mcdear in having a single spot to define what to do. In my case, I have a rule triggered by a certain switch going off (which can happen at various times) that starts a sequence of events. It is essentially a "Night Mode" and if I ever have a need for modes, I will add switching to night mode to the sequence.
It is this rule that will include the "What to do" when the Guest Switch is on. Specifically it will prevent certain things that normally turn off from turning off when the Guest Switch is on. Similarly, other rules that execute at any time (ie turn light in Guest hallway off if no motion for 15 mins) will also be suspended at all times day/night when Virtual Guest switch is on.

That leaves me with my original two questions:
Q1: is there some way to define both the on (triple click up) and the off (triple click down) of the virtual switch in the same rule?s
@a.mcdear gave me a clear way to combine the On and Off into one rule.
Problem #1: It does not work. I can turn the Virtual switch ON physically but it will not turn off physically. Below is my rule (masked part is all the exact same; masked for personally ID'ing info)
image
I can confirm the Inovelli switch is getting the up & down commands. Last physical command at Inovelli switch was the down command
image
but virtual switch still thinks it is on...
image
The triple down click (Button 3 held) that is supposed to turn it off actually calls for it to go on:

image
image1665Ă—70 11.3 KB

What am I doing wrong?

Q2: is there some way to combine both the LED color and the physical on/off option into one rule?
It appears the answer is no.
I can't simply add it to the above as in @a.mcdear's example because the trigger needs to be the status of the virtual switch rather than only physically turning on the virtual switch. I may turn the virtual switch on or off via the dashboard and in that case still need the LED color to change. So I added a separate rule, and that seems to work.

1 Like
#18

I don't have much to add, but is there are reason you're trying to set those paddle events up in RM? Button Controller is tailor-made for handling exactly this sort of thing and does it very well. I manage all 9 of my Blues's paddle actions in BC.

1 Like
#19

OK I think I know whats wrong with your rule. (I'm assuming based on your last comments that this is a paddle switch with 2 physical buttons) As far as I am aware, the HOLD function does not work on multi-tap commands. You can hold a button, but you can't tap once or twice and then hold.

Do you mean turn the LED on/off with the color change? As in

After re-reading your original question above again, I think I am misunderstanding, so let me see if I got it correct.

  • you want to use the "Guest-Overnight" virtual switch state being ON, essentially enables "guest mode", OFF disables guest mode.
  • You want to be able to easily see that "guest mode" is on, by having the LED on the switch turn blue whenever guest mode is enabled.
  • You want to be able to activate and deactivate the "Guest-Overnight" switch both with a physical button press or digitally and in either case you want the same result.

Am I missing anything? I'm not quite understanding your second question about the LED color and physical ON/OFF in one rule. Are you meaning you want to combine the triple-tap up and triple-tap down rule and with the LED color rule?

#20

OK I think I know whats wrong with your rule. (I'm assuming based on your last comments that this is a paddle switch with 2 physical buttons) As far as I am aware, the HOLD function does not work on multi-tap commands. You can hold a button, but you can't tap once or twice and then hold.

It is an Inovelli Switch, and I got the "Button Mapping" (Tap down 3x = Button 3 held, etc.) from the link below. The way I understand this is that if I triple tap up on the switch, it communicates that button 3 is held
:
[ORIGINAL LINK DELETED and replaced with corrected one below - same info]

  • you want to use the "Guest-Overnight" virtual switch state being ON, essentially enables "guest mode", OFF disables guest mode.
  • You want to be able to easily see that "guest mode" is on, by having the LED on the switch turn blue whenever guest mode is enabled.
  • You want to be able to activate and deactivate the "Guest-Overnight" switch both with a physical button press or digitally and in either case you want the same result.

Yes to all three and you are not missing anything.

Are you meaning you want to combine the triple-tap up and triple-tap down rule and with the LED color rule?

Yes, I was trying to do that, but I don't think it is possible. In my mind both are related as both are features of the virtual guest switch, but I think I have to get that out of my mind.

Thank you...

Download the Hubitat app