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.
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.
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.
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.