Rule engine: Set color: Set color by numerical value

[josh]

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.

[Nezmo]

@josh

For anyone else who finds this in the future and was curious how this would work…

Yep, thanks Josh. Working like a charm for me now.

[Nezmo]

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:

1. Driver does not appear to accept the string (formatted as JSON) argument.
2. I cannot get context variable in to a JSON argument.

[josh]

Can you share a screenshot of the rule or PM @support the rule ID so we can take a closer look?

[Nezmo]

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.

[josh]

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.

[Nezmo]

Thanks for your feedback Josh.

@josh

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?

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):

@josh

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?

If I submit the argument as a string WITHOUT the context variable it also fails:

@josh

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.

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.

[josh]

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.

[Nezmo]

@josh

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.

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.

[Nezmo]

Latest update after working with Mariano.

It appears nothing makes it through the API with the argument sent as a string. Doesn’t make sense to me.

(EDGE Driver-Mc): Z-Wave Edge Drivers and others with FIBARO devices:

[Nezmo]

I guess at this point I’m lost.

(EDGE Driver-Mc): Z-Wave Edge Drivers and others with FIBARO devices:

I send a string/text in other cases and it works. But those that work are DTHs not drivers. Is that the issue here?

[josh]

Thanks for the update. I’ll look into it – in the meantime, could you call the setHue() command to change the color with your variable?

If the saturation of your bulbs also change, you could use the setSaturation() command as well.

[Nezmo]

@josh

in the meantime, could you call the setHue() command to change the color with your variable?

If the saturation of your bulbs also change, you could use the setSaturation() command as well.

I’ll give this a try today, thanks.

[Nezmo]

@josh

Thanks for the update. I’ll look into it – in the meantime, could you call the setHue() command to change the color with your variable?

If the saturation of your bulbs also change, you could use the setSaturation() command as well.

As expected, working fine when sending the numeric values.

[Michael_Beatty]

As I’m reading through this, am I understanding correctly that SmartThings isn’t parsing the setColor() parameters? I’m using the stock Zigbee RGBW Bulb DTH and passing the input argument {“hue”:83,“saturation”:100,“level”:7} and it isn’t working.

If I am understanding correctly, I should just sent those one at a time with setHue, setSaturation, and setLevel?

[josh]

Can you share a screenshot of your rule? Or at least the setColor() command?

[Michael_Beatty]

Sure

[josh]

Interesting. I’m also using the “Zigbee RGBW Bulb” DTH with a Sengled Multicolor bulb and that format works (though the device ignores the level parameter within the object).

I’d be curious if the issue persists once the device gets moved over to an Edge Driver. Kind of concerning that these devices haven’t been moved to Edge Drivers with only 26 days until the expected Groovy shutdown.

You could try using the advanced toggle and changing the argument type to a string and using the same format, but I suspect that may only work for Groovy devices and might stop working when the device cuts over to an Edge driver.

As you noted, the individual setHue() and setLevel() commands could be an option for you as well.

[josh]

@Michael_Beatty

As I’m reading through this, am I understanding correctly that SmartThings isn’t parsing the setColor() parameters?

Just to confirm, are you actually having an issue with those commands or you were just curious based on reading through the thread?

If you’re having issues, what do the rule logs say? I’m curious if the commands are going through successfully and they’re just being dropped or if there’s an error reported.

[Michael_Beatty]

@josh

(though the device ignores the level parameter within the object).

The hue and saturation values do match, but they were already that before the device turned on. It’s the level that I saw that didn’t change, so I just assumed all of it didn’t work. Looks like my behavior is the same as what you are seeing then.

@josh

concerning that these devices haven’t been moved to Edge Drivers with only 26 days until the expected Groovy shutdown.

My thoughts exactly, but I’ll keep my fingers crossed