Automatons and scenes with location changes

[scottashell (Scott Shell)]

I’m having a heck of a time trying to recreate some routines in the classic app that will transition from one mode to another.

It seems that whenever I select a mode in an automaton I am no longer able to select a scene that will change into a new mode.

As a simple example if I create a scene that simply changes the mode to sleeping.

Then create an automaton that looks for no motion on sensors for a period of time, during a certain time window, and in certain modes.

Whenever I try to add a scene that includes any sort of loc.mode change it isn’t an option.

Is anyone else experiencing a similar behavior and might know what I am doing wrong or what I can/should do to make it work?

[JDRoberts]

You can’t do that in the new app at this time. Which, obviously, is frustrating.

You’re supposed to be able to do it by setting the mode in a scene, but so far that isn’t working.

See the discussion in the announcement thread for the migration:

Get ready to make the switch!

Routines in the Classic app allow you to have the same variable, but with a different value, as both the trigger and the result in an automation. Hugely useful. “if location.mode is Home and Michael arrives, change the location.mode to Guest” ‘If Switch 1 is on and it’s 6 pm, turn Switch 1 off.” Last I checked, this was not possible in the new V3 app. Has this changed?

[Automated_House (Jimmy)]

As JD said, it isn’t currently possible due to UI limitations with the app. However, if you let the migration utility move the routine for you, it should be created as you have it in Classic.

[orangebucket (Graham)]

@scottashell

Is anyone else experiencing a similar behavior and might know what I am doing wrong or what I can/should do to make it work?

Have you tried adding a scene that doesn’t include a mode change, saving the automation, and then adding the mode change to the scene?

[scottashell (Scott Shell)]

@JDRoberts

You can’t do that in the new app at this time. Which, obviously, is frustrating.

You’re supposed to be able to do it by setting the mode in a scene, but so far that isn’t working.

See the discussion in the announcement thread for the migration:

I figured that was the case and saw others (myself included) pointing it out but didn’t seem to get a clear answer so figured I would start another thread in the schedules and automatons folder to see if we could get definitive confirmation that it doesn’t work.

[scottashell (Scott Shell)]

@orangebucket

@scottashell

Is anyone else experiencing a similar behavior and might know what I am doing wrong or what I can/should do to make it work?

Have you tried adding a scene that doesn’t include a mode change, saving the automation, and then adding the mode change to the scene?

Alas, the app is “smart” enough to know that a scene is being used an automaton that is changing the location mode and doesn’t allow location modes to be added in the scene. I’m a problem solver by nature so I always try different approaches to problems.

[scottashell (Scott Shell)]

@Automated_House

As JD said, it isn’t currently possible due to UI limitations with the app. However, if you let the migration utility move the routine for you, it should be created as you have it in Classic.

I don’t like waiting… I’d rather have things in place before it’s necessary so I’m not scrambling to figure it out when I’m forced to do it.

[JDRoberts]

@scottashell

@orangebucket

@scottashell

Is anyone else experiencing a similar behavior and might know what I am doing wrong or what I can/should do to make it work?

Have you tried adding a scene that doesn’t include a mode change, saving the automation, and then adding the mode change to the scene?

Alas, the app is “smart” enough to know that a scene is being used an automaton that is changing the location mode and doesn’t allow location modes to be added in the scene. I’m a problem solver by nature so I always try different approaches to problems.

Some people have said if they create the automation with a “placeholder” scene that doesn’t reference the location.mode, save the automation, then edit the scene to add the mode it works. But that feels scary-fragile to me. Who knows which direction it will change? Not something I’d deploy in a production environment.

[orangebucket (Graham)]

@JDRoberts

Some people have said if they create the automation with a “placeholder” scene that doesn’t reference the location.mode, save the automation, then edit the scene to add the mode it works.

Yes, that is exactly what I meant. It does work.

I don’t do it myself because of the fragility of it as a solution. Creating and editing automations is a miserable experience at the best of times without making it harder.

[Automated_House (Jimmy)]

That doesn’t work any more. When you edit the scene, the scene knows what automations it’s used in and what conditions those automations have.

[orangebucket (Graham)]

@Automated_House

That doesn’t work any more. When you edit the scene, the scene knows what automations it’s used in and what conditions those automations have.

I have an automation that use location mode as a condition and runs a scene. I just opened the scene, which knows it is used by said automation, added an action to set the location mode, and saved it.

So unless there is a January release of the app that hasn’t made it to me, it still works.

[Automated_House (Jimmy)]

I stand corrected! Not sure what i was thinking of You can indeed create a “shell” scene, setup your automation with mode as a condition, and then come back to the scene and add a mode change.

[JDRoberts]

My concern is that you’re not using a different feature as a workaround. You’re using something that might well be seen by the engineering staff as a bug, so it could be “fixed“ at any time without notice or notification. And it might even be “fixed“ in such a way as to make the existing automation stop operating.

I’m not saying that would happen, but it definitely could: they’ve done it before.

[Automated_House (Jimmy)]

definitely. This may only be a temporary work around until they “fix” it. Ideally, they hear the need for this type of restriction to be removed and this is wasted typing

[orangebucket (Graham)]

@JDRoberts

You’re using something that might well be seen by the engineering staff as a bug,

I think it should be considered as a bug. The automation and scene editors have to sing from the same hymn sheet.

May be there should be a clear differentiation between restrictions and trigger conditions and actions should only be allowed to also be restrictions. That kills the infinite loop but keeps some useful functionality.