Rule engine: Set color: Set color by numerical value

[josh]

The spaces shouldn’t matter, but the quotes do. They should be straight quotes, not curly quotes:

• " = good
• “ = bad

And it looks like you have a rogue quote after the hue value. So it should look more like:

{"hue":240,"saturation":100}

[Techno_Vol]

This didn’t work for me. Any thoughts? Thanks!

[josh]

What did the Rule Logs show?

[Techno_Vol]

[Chris_C]

What DTH are you using in smartthings and what do the logs there say?

[josh]

Hi @Techno_Vol – I just noticed you’re part of our Next Gen Samsung SmartThings beta. You might try sending the hue value in the range of 0-100. This is one of those oddities that we handle automatically for you when you use the color picker – the SmartThings COLOR_MAP range for hue is 0-100, so you have to scale the value to match that. 240 is roughly 67 (240/360 * 100 = 66.66)

[Techno_Vol]

Thanks @josh, I’ll give that a try.

[Techno_Vol]

@Chris_C Osram Lightify RGBW A19/BR30 US version (HA) DTH rev 01/19/2018
by gkl_sf

[Techno_Vol]

@josh That worked for Hue and Saturation, thanks! Can Luminance be set??

[josh]

If you mean the brightness level, you can include a level attribute in the COLOR_MAP:

{"hue":67,"saturation":100,"level":100}

[Techno_Vol]

Thanks @josh What I’m trying to get is a darker blue.

From this:

To this:

[Nezmo]

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.

[josh]

@Nezmo

But now I see I can’t use setColor with the randomly generated color name I have.

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.

[Nezmo]

@josh

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?

[josh]

@Nezmo

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?

[Nezmo]

@josh

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:

Rules / Variables based on Date or Calendar

Absolutely Josh. Actually, what I’m looking for here for my Christmas rule I could also use elsewhere. It’s just this Christmas one is what is bothering me the most right now as it’s my most complex. The date range as a condition is the biggest item. Then I want to be able to code that at certain times on certain days but only when the date range is true do something. Similarly, I want to trigger x mins before sunset, again only within a date range, do something else. Being able to set mu…

Here’s the SharpTools Rule (WIP).

Log snippit:

The DTH in use is ZigBee RGBW Bulb.

[josh]

@Nezmo

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.

[Nezmo]

@josh

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

Thanks Josh. I’ll have a go with that workaround a little later tonight.

[Nezmo]

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.

[josh]

Can you share a screenshot of the full rule so I can better understand the context? Feel free to PM me if you prefer.