Would greatly appreciate it if some kind soul could help me understand a little bit better, I’m trying to get the hang of the syntax and all that but after reading forumposts for a couple of hours I can’t even tell a curly bracket from a square anymore.
Am I understanding correctly that you toggled the ‘Advanced’ switch on and added the color argument to the on() command?
Keep in mind that the commands need to match what your hub is reporting or your hub will likely reject the command. For setting the color of a device, you would typically use the setColor() command… or setHue() and setSaturation() individually.
@Nezmo is doing something similar. They’re using the new Expressions feature along with an expression similar to:
Every time the expression runs, this randomly picks one of those numbers which are each ‘hue’ values. The next step in the rule could be a setHue($myRandomHue) command.
That’s going to depend on the logic. If each of the conditions can be impacted by each other, then having them sequentially won’t work.
For example, if you have something that says:
IF light is off
THEN turn on
IF light is on
THEN turn off
It’s going to run each of those conditions in sequence if they are stacked on top of each other, so the first condition will turn the light on, then the next condition will run and since the light is on, it will turn it off.
Depending on what your conditions are, sometimes they can be stacked though – it just depends on what the conditions are and how they interact with each other.
Allright, what about loops?
I was thinking if I set up the light to switch color with a delay of a coupe of seconds in between but don’t want to build a flow that is a mile long. Would it be possible to end the flow by calling the same http request that starts it or is that something that can make things fly off the handle?
Please see the comment above… you can’t arbitrarily adjust the commands. You must send commands that the device expects to receive, so you should be able to use the color picker with the setColor() command, for example. You can’t just add a color argument to the on() command since the device doesn’t expect that.
Each device might behave slightly differently with how they handle a setLevel() or setColor() command while they are turned off. Many devices will automatically turn on and set the level/color, but some may not. So you can try just sending the setColor() command for example and see if that works.
You can find documentation on the Expressions feature here:
If setup properly, there’s no issue with an action at the end of a flow triggering the rule to start over again. For example, some people have logic where the last step is to flip a variable false then true again to simulate a loop. Usually this is combined with delays and/or conditions to make sure you don’t get stuck in an infinite loop running super fast. This is not something we ‘officially’ recommend/support, but it seems to be a popular community approach.
Allright, just to clarify, it’s not possible to do something kind of like this? Provided that the commands in the fields for the strings below would follow syntax correctly of course, with variables perhaps?
You must use arguments that the device expects and supports. You cannot arbitrarily add arguments to commands or the device won’t know how to handle them. When you sync devices over to SharpTools, it asks your smart home hub what commands it supports.
In general, those commands will match up with the capability definitions that SmartThings provides. In exceptional cases where a device needs a special command that isn’t supported by the stock capabilities, the manufacturer might develop a custom driver that defines a custom capability. This is not particularly common with normal devices like lights and basic sensors, but is more common with community developed drivers.
You can send multiple commands for a device in a row. Or in the case of the setColor() command, you generally can send the various attributes as part of the COLOR_MAP argument type that SmartThings supports:
Most color capable devices will support all three of the parameters, but some only support hue/saturation and separately want you to send a setLevel() command to adjust the level.
Glad to hear you are enjoying things.
I would add that if you are looking for a random number between 0 and 99, there’s an undocumented random(min, max) function that might work for you. In theory, you could drop the variables altogether and use inline expressions to get a random hue:
Yeah well obviously, it would be rather silly for instance to ask a lightbulb to turn the oven to 225°C, hence me qualifying the question with this.
The reason I’m asking for the clarification is because you wrote
I took that to mean that you cannot send the parameters for “color”(hue, saturation, level) with “on” since the device is not expecting that together with the on command and has to be set after. Of course i realize that i can’t just make stuff up and should expect to get rich if i send printMoney($1000) to my vacuum when we’re working within syntax.
However now with your latest post in mind I assume you were being specific about the need to break down the choice of color into hue and saturation rather than denying that my ask is possible.
Well damn, seems like i went and made things way overcomplicated, but I learned a bunch so it was well worth.
It does however leave me wondering what the purpose of an undocumented function is?
Seems like this is something @Nezmo also would find useful in regards to his basically identical flow.
Yes, I would recommend moving from the Labs endpoint to the built-in expressions feature. It should be more resilient, faster, and more flexible. All of the functions that were available in Labs, including the pickRandom() you’ve been using, plus a bunch more are available with expressions now.