I have to respectfully disagree. Almost every Home Automation platform for the last 20 years has had “scenes”, and that includes Zwave, Hue, Apple Home, Home Assistant, Control4, Lutron and many more.
To say they are just rules without if statements is like saying a bicycle is just a tricycle without an extra wheel. Not necessarily untrue, but it doesn’t mean the definition of tricycle is superfluous.
Scene is an industry term used pretty much the same way by everybody. (even SmartThings). It is a way of changing the state of multiple devices. One important and significant difference between scenes and automations on most platforms is that scenes do not have sequencing where automations almost always offer that.
Sometimes this matters a lot, sometimes it doesn’t matter at all, but it is a real difference.
In terms of architecture, on almost all platforms scenes can be initiated with a single service call. Automations typically require one for each step.
It’s a distinction that has been useful in the Home Automation industry for 20 years.
I agree that the new name is confusing, but I think there is a useful distinction between scenes and routines or we wouldn’t see them offered separately on so many different Home Automation platforms.
Where are you seeing them? If I pick a device that’s involved in one of my Smart lighting rules and then check the “In Use By” section, the Smart lighting rule is not listed…
I wasn’t intending to suggest getting rid of them, though I concede it is hard to read it any other way. I think that they are essential. I also think the way they are now presented in the client apps is a great improvement as it makes it clear that, in SmartThings, they are basically Routines without an ‘if’. There may be other subtleties but they clearly don’t feel that typical app users need to know about them. The term ‘manually run routines’ might be technically dubious but it might be considered an improvement over ‘scenes’ for its target audience.
What I was intending to suggest is that the simultaneous presentation of Scenes as developer grade tools alongside the Rules API is a nonsense and needs to stop. The only reason they are even relevant is that the Rules API doesn’t have an action to execute another Rule, only specifically a Scene. Implement such and the Rules API becomes immediately more powerful and indeed so do scenes (using the term generically) as they can then be built on the Rules API directly and so won’t be dependent on the absurdity of the exclusive manual use of a UI in a mobile app.
Find it useful to see when in the default “Logic View”, a deleted device is shown as Unnamed Device. Now that can quickly be corrected copying the id from the Devices menu.
That can be quite useful. I’ve been doing essentially the same thing for five years now with the Rules API (but only a year and half with Routines and Recipes - still kicking myself it took so long). I’ve always found an even more useful thing is actually to be informed when a ‘missing’ device is being used in rules (of all types) and apps. I say ‘missing’ because these days you can’t tell if a device is deleted or if you just don’t have access to it.
It is also handy to know if a Routine was created from a preset (created from the device pages) and to a lesser extent a template (created via the discover page). I don’t know if the AWA flags that.
It is possible to detect if there are rules out there that are owned by apps. That’s useful to know. You can’t read them or even know which app owns them (as far as I know) but you can find out their name and what devices they are using.
Hi, @TapioX
Sorry for the delay, we created a feature request last week about this. Remember the implementation of this kind of request depends on the team’s workload and approval.
Can you provide more details about this request, please?
Do you mean to sort them by default? I see that if we click on “Source”, it gets sorted by that value.
this is cool, nice to see something beyond the CLI. I had created a bunch of Rules in the CLI and just stumbled on this, easy to make an edit when i had a switch fail and needed to replace it within a rule.
Question: why some rules able to control the Enabled\Disabled and some are not?
is this, simple rules created in the phone app vs more complex rules added through the CLI?
so true. if a rule is using a device that is offline (maybe it’s broke, like in my case) and needed to replace the switch, it would be a big time saver to see which devices are offline, etc.
maybe even alias of the device name, instead of the GUID
