I am wanting to be able to change the mode manually. I understand there are two basic approaches: 1. using a routine to set the mode, and 2. creating a virtual device. I’ve been reading about the Alexa Helper and that sounds a lot like how I want to go about it. However, I don’t have an Echo, and no plans to add one. Nonetheless, I started following the steps described on this page: FAQ: Adding Mode Control Switches (all platforms) . I created 4 momentary switches and created a new room to put them in. Then the next step listed goes into the Alexa Helper, and the more I investigated that, the more I became uncertain if that is really what I should do given that I don’t have an Echo. I guess my question is: Is there a different set of steps for this if Echo integration is not what I’m after? I just want to be able to go to the new room, and press the momentary switch to change the mode as desired.
Thanks much for any pointers!
Sorry, I just sent it back to the same topic you were already in.
To be honest, I don’t know exactly how Alexa helper works right now. It’s become more and more complicated overtime.
But there’s a different smart app you can use that will just assign a mode change to a switch and then you’re all set. Hang on a minute and I’ll find that link.
OK, I have added post 18 to the change mode FAQ and it will explain how to do this without using Alexa helper.
Thanks for the response. I’m not sure that I’m completely following. I did attempt to use the “Switch Changes Mode” app with the momentary button tiles that I had already set up as described before. It did not appear to work from what I could see. However, I tried it again, this time using Simulated Switches with the “Switch Changes Mode” app instead of the momentary buttons, and that did change the mode. So while it seems to work with the simulated switches, that does not seem ideal to me, for this reason: Once I set up the second simulated switch, I could turn on the first simulated switch to change the mode. Then I could click the second switch to change the mode again. But now looking at the state of the switches, they are both on, which is confusing to see, since only one mode can be active at a time. So I think for this purpose, the momentary buttons seem to be a better fit for what this is trying to accomplish. I will entertain any other options, but if necessary, I will proceed with the Alexa Helper since that would allow the use of the momentary buttons. Am I missing anything?
I tried it, and it did work with the momentary switch, but weirdly the change didn’t show until I close the app and re-opened it. Not sure what that’s about.
In any case, if you want to use a binary switch, that can also work.
After you have it set up so that the mode change is tied to the switch, you will need to set up one More smart lighting automation so that the virtual switch always turns itself off after one minute. That way it will be ready to use again the next time.
You can use the power allowance feature in smart lighting to do this.
Choose smart lighting, and then a new automation.
Select the virtual switch as the “light” that you want to control.
Say that you want to turn it off.
For the trigger condition, choose “power allowance” from the multiple-choice list, and then set the amount of time to one minute.
Save that, and every time the switch is turned on, it will automatically turn itself off after one minute.
Turning the switch off will not do anything to the mode if you haven’t set it up to do that.
Or, if you’re feeling ready for a whole new world of automation, give CoRE a try.
You can assign a mode to each momentary button easily. You could even have one button to rotate between several modes.
And for true automation, set your modes to automatically change depending on a combination of sensor inputs and switch states.
CoRE installation guide and a link to the CoRE wiki in post one of the following thread:
Once you have CoRE installed, if you need help setting up a new piston (that’s what CoRE calls each rule), post on here or in the CoRE peer assistance thread:
You were right, JDRoberts, it was working, I just wasn’t seeing it reflected in the UI, but testing confirms it. So thanks for the help with that. The CoRE stuff sounds interesting too. I may tackle that as well if I start feeling ambitious.
One last question, is there anywhere else in the Android app to see what the currently active mode is, other than the “Home” screen? I added a new mode named HomeVacay for days like today where we’re home but it’s not a normal school/work day. On my phone it shows “Mode is: Hom…” so it’s not easy to distinguish between Home and HomeVacay on the “Home” screen.
Viewing the current mode does indeed suck!!
A good way to check the mode would be to use CoRE.
You could have a momentary button or routine that when pressed triggers an on-screen notification (or SMS) telling you the current mode.
Personally I hate modes (they just confuse my wife). Instead, I use physical buttons and routines to trigger scenes when required.
Let’s say I have 4 modes. If I were to use CoRE for this, would I create 4 pistons, 1 for each mode? Or is it possible and/or better to have a single piston that can handle all 4 cases?
Secondly, is it possible to add an indicator to the “Right Now” tab on the Dashboard that just always shows what the current mode is?
For getting a notification of the current mode the following piston works well.
This example uses both SMS and Push Notification but you just need to choose one or the other.
It uses the CoRE system variable $locationMode (case sensitive)
In regards to having the current mode displayed on the ‘right now’ tab, it would need a custom virtual device, it’s certainly possible but is beyond my limited coding abilities… Maybe someone will see this thread and take up the challenge?
Edit: I’m not 100% sure but I think the ‘right now’ tab is reserved for sensors. It should still be possible but may have to say something like ‘Mode (Home) is active’ (or inactive) and have a different line for each mode.
I can think of a simple way to achieve this using multiple virtual motion devices + CoRE and I’ll write some guidance later (need to give the little one a bath and then we’re going out for a Carvery dinner… Yum!!)
Right… I have a working method for displaying mode state in the ‘right now’ tab.
You need to create a virtual device for each mode you have (so in your case 4). These devices should be given the ‘type’ “Simulated Motion Sensor”. I named mine as follows:
- Mode (Away)
- Mode (Home)
- Mode (Automatic)
- Mode (Paused)
Here is the snag - To get these 4 virtual devices to show up in the ‘right now’ tab they need to be included in the SHM Security settings. I don’t use SHM ‘Armed Stay’ mode so I added them there.
If you use both Away & Stay modes of SHM this method won’t work for you as it will trigger false alarms.
Now, to make these 4nr virtual devices work together I used CoRE.
The example below will turn the relevant virtual device to ‘active’ when the mode changes to the matching state + it will turn the other 3 virtual devices to ‘inactive’.
For example, if mode changes to away, the ‘Mode (Away)’ device will change to ‘active’ and the other 3 devices will change to ‘inactive’.
As an added bonus, the following CoRE piston also allows you to change the mode via the ‘things’ page by clicking on the virtual device tile you want.
End result in the ‘right now’ tab looks like this (current mode = ‘Paused’):
Note - You need ‘expert mode’ enabled in CoRE to be able to put the ‘when true’ actions within each group of triggers.