Curious, how are you finding additional endpoints to query?
I didn’t. I figured out that as Smart Lighting is an app plugin, not a SmartApp (despite where it gets listed), its Rules must be in the same place as the Routines are and it was just a matter of overriding the default filtering. As Routines and Rules have SMARTTHINGS in capitals as the creator I figured that might be significant and I couldn’t think of anything around that could be using the known possibility of RECIPE. Presumably there might be other recipe creators in the app in future, but that is a bridge to cross then.
Oh, and if anyone is wondering about Routines created by templates, those are just ordinary Routines with a bit more metadata saying which template was used.
Exposing the Smart Lighting rules yesterday has helped me with a couple of longer lasting questions, namely what is a ‘recipe’ and what is the ‘ARB’. Obviously I was well aware that a /recipes endpoint existed and ‘RB’ always seemed likely to stand for ‘Rule Builder’. I had a few thoughts about what the ‘A’ ought to stand for (disappointingly, it is ‘Advanced’).
My knowledge remains superficial, but having read a Smart Lighting rule it became trivial to then find its previous generation which I am going to call recipeVersionInstall as I don’t know what else to call it. That consists of a recipeVersion and its configuration data, with the recipeVersion being a combination of a template rule and configuration placeholders, and yes there is a recipe in there too, but there is no body to that.
Where does the ARB come in? Beats me, but it gets a credit in the rule and recipeVersionInstall metadata.
I don’t have any real point to make. I am just observing that none of what I could see looked engineered as a one-off solution and it seemed to have a more conventional flow to it compared to Routines.
@orangebucket Thanks for sharing this link
I also went through my own automations.
I have question about
"sequence": {
"then": "Parallel",
"else": "Parallel"
}
"sequence": {
"then": "Serial",
"else": "Serial"
}
What is the purpose of these sequence definition?
That particular form of sequence is associated with an if action. In that action you will also have a then and possibly an else that each contains an array of actions. The sequence determines whether those actions are executed one after the other in the order they are defined (serial) or all at the same time (parallel).
You will also find a sequence at the top level. So …
actions: [
...
],
sequence: {
"actions": "Serial"
}
That will allow you to make the same choice with the actions array.
1 Like
Sorry to be dense…what does the URL look like to get the Smart Lighting rules?
hmmmmm
I get them using:
https://client.smartthings.com/rules?creators=RECIPE
with an optional locationId={{locationId}} if you have multiple locations.
In theory that would get you any rules the client apps create from recipes, but Smart Lighting seems to be the only one out there at the moment.
1 Like
Yeah, well while I wouldn’t say this is a grey area, it could be a tad whiter.
Personally I think that given the relative lack of guidance material it is potentially game changing for those interested in working with Rules.
Many thanks…
If I may ask, what gave you the clue to use that syntax? ie using ?creators=. (I read your post re “recipe” above and that is pretty impressive deduction on its own)
It also helps if you end up deleting a load of devices (eg virtual ones) and then recreating…This helps to reconstitute the routines.
Was very annoying the first time when I realised I had no idea what routines I had!!!
I just thought creator looked interesting as a filter in the spirit of other API calls and I can’t be the only person in the world who would insist on it being pluralised if it could take more than one option.
I have had a rather successful week for finding things but I’ve been looking for some of this stuff for two or three years on and off. I’ve tried literally hundreds of what, with hindsight, are completely ridiculous things.
A key thing I’ve learned about the APIs is that they are inconsistent.
I’ve found: using the version number in the path and the accept header are not equivalent; the version number in the path can break things; any version number can break things; and sometimes a version in the accept header is required (even if it is 1). Sometimes query string filters are required, sometimes they are optional.
Very impressive You are clearly more persistent and patient than most
I think I will take a lesson from this 
Rules are perfectly happy with unknown device IDs in them. That’s why I prefer them. I can scan for unknown IDs and quickly fix them.
I understand why they mess with Scenes and Routines when devices are deleted. I just find it odd that they use the Rule as the ‘source’ in the way they do. The recipe approach just seems so much better.
2 Likes
That’s one recommendation for moving routines to rules. Any other advantage, like for example any function that’s not available in routines?
e.g. the EveryAction which I don’t know if exists in routines, but I haven’t seen it.
I am not aware of any function available in the public Rules API that isn’t available to Routines, indeed the opposite is the case. However the Routines are using the functionality to implement a fairly basic ‘if … then’ with limited and/or grouping. The Rules can do multiple serial/parallel actions, each of which can be a sleep action, a command, or a nested ‘if … then … else’ with arbitrary and/or/not grouping.
2 Likes
Sorry, I don’t really understand this. 
What do you mean by the ‘source’ and what is the recipe approach? I haven’t come across recipes other than in this thread, and I guess I have no idea what they are!!
This is speculative but is the guess I am comfortable with at the moment …
My best guess is that Smart Lighting is a collection of rule templates and that when you create an automation this happens:
- You are guided into selecting a particular rule template without realising it.
- You supply the configuration information required by that template.
- The rule is constructed from the template and submitted to the API.
When you want to update the automation you either change the configuration information or backtrack to a different rule template.
However with a Routine it is more like this:
- There is basically one flexible template that you are configuring.
- You supply the configuration information in a relatively free form fashion.
- The actual rule is constructed and submitted to the API.
When you want to edit it the rule is read back from the API and disassembled into something the Routine Creator understands. If the device is deleted or is out of spec this process can go wrong.
Something like that anyway.
2 Likes
Aha…interesting…Thanks for explaining
Today’s realisation about Rules (and their various friends) is that they are Installed Apps, just like the old Groovy Smart Lighting and webCoRE pistons (so I really shouldn’t have been at all surprised). They have the app type BEHAVIOR, which is not only painful for a Brit to type but is a familiar name from the past.
So when you write a Routine that checks temperature from the weather, there is an app out there subscribing to changes in temperature for a given geolocation from the Coordinate API service.