Thanks @josh What I’m trying to get is a darker blue.
From this:
To this:
Oh my. I just finally figured out how to generate random color names (red, green, etc) and how to create a rule that loops until an end condition is met. But now I see I can’t use setColor with the randomly generated color name I have.
Still noodling over all this but so far not sure how to get from A to B on this.
That depends on your device handler / driver.
Some devices do accept a named color, but it’s not required as part of the standard which is why we send over the hue/saturation by default (since that is required as part of the COLOR_MAP standard).
If your device does accept a named color, you can flip the Advanced toggle on and customize the data type and value that gets sent across in the command.
Right. In webCoRe I send a name and it works. I’ve tried sending the color name as text in SharpTools and the command executes according to the logs but it doesn’t actually register on the SmartThings side. Perhaps WC does some stuff in the background?
UPDATE:
I thought I was sending the color name as a string but maybe not. Each time I go to edit the action it looks like it has changed back to { }. Is this just a UI ‘error’ or is this because my color name is actually a context variable? Is it possible that the context variable is null when the rule has not triggered yet and thus the rule engine editor is not seeing a valid string value to save?
Can you share a screenshot of what you did in webCoRE and what you are trying to do in SharpTools?
What type of device handler or driver are you using for the devices in question?
Josh, it’s the second image in this post:
Here’s the SharpTools Rule (WIP).
Log snippit:
The DTH in use is ZigBee RGBW Bulb.
WebCoRE appears have some sort of named color translation layer as it looks like the stock Zigbee RGBW Bulb DTH does not accept named colors.
From a quick bit of digging, it appears to be part of the SmartThings Groovy Color Utilities but literally the only reference I can find to it is in WebCoRE. I’ve asked my SmartThings contacts if they have and documentation on it. 
As a workaround, you could get your random color in the COLOR_MAP format that SmartThings devices expect:
{'hue': 0, 'saturation': 100}
You should be able to pass that directly to the setColor method. Alternatively, if you’re only varying the hue, you could randomize just the numerical hues that you need and then only inject that as part of the setColor command:
Send Command: setColor({'hue': $yourColor, 'saturation': 100})
Edit: One thing to keep in mind is SmartThings has a weird format for the hue value. In color theory, hue is 0-360, but in the SmartThings commands you have to translate that to 0-100.
1 Like
Thanks Josh. I’ll have a go with that workaround a little later tonight.
Okay Josh, I’m sorry but I need more help.
How exactly should I be forming the argument in the HTTP Action? As JSON, a string? And exactly in what syntax?
I have tried both above with:
{'hue': $context.response.data.result, 'saturation': 100, 'level': 50}
and
{'hue': {$context.response.data.result}, 'saturation': 100, 'level': 50}
From what I can tell I’m not getting the actual result sent, rather the literal $context.response.data.result.
Can you share a screenshot of the full rule so I can better understand the context? Feel free to PM me if you prefer.
PM’ing you now. Thank you.
For anyone else who finds this in the future and was curious how this would work…
I’m using the ‘string’ data type (Aa) and then formatted it like a JSON string:
When your cursor is in the input for editing, you’ll notice the expressions (for the variable reference) are wrapped in double squigglys. And when you’re tabbed out of the input field, they should show as parsed expression fields with the small grey pill button style shown in the above screenshot. And make sure to use straight double quotes " for the quotes.
1 Like
Yep, thanks Josh. Working like a charm for me now.
1 Like
I am now trying to get a similar rule setup to generate random colors for a Z-Wave RGBW Controller (Fibaro). I am using a custom driver.
I cannot seem to get it to work like I have for Zigbee devices I did before. When I try to send a string (formatted as a JSON formatted argument):
{"hue": {{$context.response.data.result}}, "saturation": 100, "level": 50}
I get the following in the logs:
In another test I submitted the argument as a JSON (versus string) without the random number context variable and it works.
However, in the JSON I can’t seem to format the context variable correctly. Is it even possible?
To summarize:
- Driver does not appear to accept the string (formatted as JSON) argument.
- I cannot get context variable in to a JSON argument.
This is the section of the rule throwing the error:
For clarity, here’s my test rule. The top action fails, the lower action works. And I can’t find a way to have the context variable in the latter.
Update: The JSON Editor now supports inline expressions!
The JSON data format currently does not support inserting a variable. If your original screenshot showing the logs was for JSON argument, then it makes sense that it showed the raw {{$context.response.data.result}} string as it is not currently translated. I can look into what it would take to support that, but it’s not something I’ll be able to get to immediately.
In the follow-up reply that showed a string argument that has a variable in it, that should be handled fine from the SharpTools side of things and your SharpTools logs should show the context variable being parsed and injected as expected. From what I understand, the driver doesn’t seem to handle that format though?
Have you tested the exact same format that worked as a JSON argument type {} (from the second part of the second screenshot) as a string Aa to verify that the driver isn’t handling the JSON data formatted as a string?
Have you watched the driver logs to see how it is handling the arguments that are being passed to it? Considering the string format of an object has worked for other device types, I suspected that maybe the SmartThings API was inherently handling the parsing of these requests, but it’s possible that the parsing is something they coded into specific drivers. In which case, I wonder if Mariano would entertain parsing a string formatted JSON object. I think the first step here is identifying what the driver is actually seeing though.
Thanks for your feedback Josh.
In the first example I showed that was using a string argument.
I am getting the failure message when sending the argument as a string.
For the test rule I show above here’s the log for the first action using a string argument containing the context variable (this one fails):
Here’s the log for the second action using a JSON argument (this works):
If I submit the argument as a string WITHOUT the context variable it also fails:
I’ll have to work on this. I don’t currently know how to get driver logs. I guess I’m going to have to learn the CLI properly.
Thanks for the clarification. You could also just try floating the question to Mariano. He might know off the top of his head why it would work with one driver but not another.
I suspected the SmartThings REST API was handling the parsing, but it’s possible they were doing it within all the drivers that I’ve tested with so far. Without knowing why the JSON as a String format is failing with his driver (eg. no logs), I don’t have a lot of insight as to why it doesn’t work with his driver. It’s certainly possible that it was a per-driver thing with the parsing and maybe Mariano would be open to adding that to his driver.
Otherwise, I will take a look at what it would take to add the context variable parsing to the JSON argument format, I just won’t be able to get to it right away.
1 Like
Will do. I’ll bring it up to him over on the ST community and I’ll follow-up here with anything I learn.
Thank you.
1 Like