[SOLVED] Trouble sending Colorpicker value as HSB via MQTT to SmartThings

[Curtis]

Hi All,

I’ve tried to get my head around this for the past week and have been all over the forum, read the OH demo rules and searched Google but cannot seem to solve my issue.

MQTT works fine and I can send the default values from the color picker but that of course does not send the correct colours as my lights are expecting an RSB value rather than RGB.

Below is my obviously incorrect code as there is no color conversion or anything else. I’ve only just started to learn rules, well and code for that matter!

.items

String Steps { mqtt=">[broker:smartthings/Decks/color:state:*:default],
				     <[broker:smartthings/Decks/color:state:*:default]"}

.rules

rule "Step lights"
when
	Item Steps received update
then
	Steps.postUpdate
end

.sitemap

Colorpicker item=Steps   label="Step Lights"

If someone could point me in the correct direction that would be brilliant thanks.

[kay (Kay Puffer)]

Hey Curtis,

I am currently at the same issue but the following Tutorial helped me quite a bit: Neopixels/RGB LED example

[Curtis]

Thanks very much for taking the time to help out.

@Kees_van_Gelder

The colorpicker sends an HSB (Hue, Saturation, Brightness) code

This is one of the things that confuses me as what I want to do should be done automatically. I want the HSB and it is the value that the Colorpicker sends. It’s also in the format I need it ie (xx,xx,xx). I wonder if it is something to do with the decimal places…

At the moment my colours change but don’t match the picker and when I move towards the right of the screen the lights go a dim white. So confused.

[Curtis]

I understand the issue and it is my fault but I still don’t understand the solution.

My lights are controlled using HSL not HSB!!

[Kees_van_Gelder]

I dont think it is possible (or at least not easy) to convert HSB to HSL in OpenHab. If I may ask what LED do you have that it reacts to HSL?

[Kees_van_Gelder]

I am happy it helped you

[Curtis]

You know what, the more reading I do the more difficult this becomes. It appears it is not my lights that are the issue but what I’m trying to do them.

The lights are connected to SmartThings and I’m trying to use the MQTT bridge to connect them to openHAB.

After much research it appears that SmartThings uses an odd method to interpret colours. It’s defiantly not RGB I know that much but I’ve seen some people say its HSL and others HSB but both of those have a Hue value up to 360 but SmartThings is 0-100. I wonder if the range has just been compressed to get that figure but I’m struggling to get my head around it. (article i read on ST forum https://community.smartthings.com/t/getting-philips-hue-values/2602/23)

[Curtis]

I’ve just ran a test and it appears that the hue value has been compressed to fit within a 0-100 range. I just divided the a hue value by 3.6 and entered the number in my MQTT client and the colour is what it should be.

Creating a rule that takes the Colorpicker “hue value” and divides it by 3.6 is over my head though.

[rlkoshak (Rich Koshak)]

Design Pattern: Proxy Item

Please see Design Pattern: What is a Design Pattern and How Do I Use Them for information on what a DP is and how to use them. Problem Statement Often one faces one or more of the following situations: the need to perform additional logic before sending a command to a device the need to send a command to multiple devices based on a single event the need to do something different based on the state of one or more other Items the channel to update the state of an Item and the channel to send c…

[Curtis]

Thanks very much, I’ll give that a good read!

Apologies for posting on two threads. I believed this issue had ended and started a separate conversation but it appears they where part of the same problem.

[Kees_van_Gelder]

You shld definitely read Rich’ link regarding programming. But separate from the I tried to find out what the exact colorformat of Smartthings is, some sources suggest it is ‘hue’, ‘saturation’, ‘color’ which does not really make sense to me.
If you change the hue value by dividing it by 3.5 does that just give you the right color or do you then have right color, saturation and luminosity/brightness?

[Udo_Hartmann]

As I had to read about the difference between HSB and HSL …

HSL, HSB and HSV color: differences and conversion - codeitdown

[Curtis]

@Kees_van_Gelder from what I can tell “hue” & “saturation” make up the “color” value and the L refers to a “power level” value rather than “color lightness”. It appears that people refer to the colour as HSL which is incorrect as the L does not stand for “lightness” at all. From what I can tell colour is still in HSB and the B is a power level value which would make sense as that would control the brightness of the lights. I hope that makes some sense… my head hurt just writing this!

This is going to make my rule a bit more complicated too as I need to post to two MQTT topics “color” and “level”. So I have to grab the Colorpicker values convert the the H add it to S and post to “color” and then grab the B and post that to the “level” topic.

FYI

These are the values that can be changed using the ST API

This is the code from the ST App

    "colorControl": [
        name: "Color Control",
        capability: "capability.colorControl",
        attributes: [
            "hue",
            "saturation",
            "color"
        ],
        action: "actionColor"
    ],

    "levels": [
        name: "Switch Level",
        capability: "capability.switchLevel",
        attributes: [
            "level"
        ],
        action: "actionLevel"
    ],

    "relaySwitch": [
        name: "Relay Switch",
        capability: "capability.relaySwitch",
        attributes: [
            "switch"
        ],
        action: "actionOnOff"
    ],

def actionColor(device, attribute, value) {
    switch (attribute) {
        case "hue":
            device.setHue(value as float)
        break
        case "saturation":
            device.setSaturation(value as float)
        break
        case "color":
            def values = value.split(',')
            def colormap = ["hue": values[0] as float, "saturation": values[1] as float]
            device.setColor(colormap)
        break
    }
}

So I’m going to try and create a rule that does the following:

[Kees_van_Gelder]

I knew there was a good reason I stayed away from HSL, though I have a routine that makes RGB out of it (but you need the reverse)
The code you showed is actually what got me durprised earlier as in 'hue, saturation, color, but I guess they make the color out of hue and saturation.
Anyway, I dont think I can be of any further help, but should you fid a solution I’d be happy to hear it just in case/for future use
Good luck

[Kees_van_Gelder]

Interesting. My impression was that HSB and HSV indeed are basically the same (as they say) and HSL and HSI are the same too (HSI is not mentioned)

[Curtis]

Absolutely, knowing the problem is a good start, I “just” need to figure out how to write the rule now and will post the solution here when I get my head around it.

Going to start by taking a Lynda course on Java 8 as I have 0 coding experience so feel that would be a good start.

Cheers everyone.

[Kees_van_Gelder]

good luck

[Curtis]

Hi All,

I’ve spent the last couple of days beginning to learn Java and Xtend and I’m struggling a bit. I’m simply trying to split out my HSB into separate variables so I can do what is mentioned above.

From my limited 2 days experience I think it is a parsing issue as I’m dealing with a Decimal but I’m using an Integer. To be honest I’m lost. If someone could just nudge me in the right direction that would be great as I keep going round in circles.

Here is my rule:

rule HSBtoST
when
    Item Deck_HSB changed
then
    var hsbValue = Deck_HSB.state.toString
    logInfo("HSB", "HSB State " +hsbValue)
    
    val numsSplit = hsbValue.split(",")
    
    val int first = Integer::parseInt(numsSplit.get(0)) 
    val int second = Integer::parseInt(numsSplit.get(1))
    val int third = Integer::parseInt(numsSplit.get(2))
    
    logInfo("HSB", "H " + first + "S " + second + "B " + third)
end```

[rlkoshak (Rich Koshak)]

And the error in the openhab.log?

Are you using ESH Designer? One nice thing it has, especially when you are first learning, is <ctrl><space> to offer valid ways to complete the statement you’ve started typing. So if you typed Deck_HSB.<ctrl><space> it will give you all the methods available on State.

So I’m going to split this into two parts. First how to figure out what is wrong with the code you have, the other a better way to do it.

First, whenever you have such problems logging is your friend. Log each numSplit.get before you try to parse it. when you do log it, wrap it in quotes so you can see if there is any white space or other non-parsable characters which would prevent parseInt from successfully parsing the values.

I think the hue part is always an integer so I don’t think the problem is because of a decimal point. But if there is a decimal point you can’t use Integer, you have to use Float.

As an aside, since you know that numSplit.get(0) represents the hue, it is far better to name that variable “hue” rather than “first” which really is not very informative. It is much easier for you, future you, and others to understand code when you use meaningful variable names.

And now for the better way.

On the other thread where you brought up parts of this issue, back when we thought you needed to convert the HSB to HSL I posted the following code:

    val hsbHue = (MyColorItem.state as HSBType).hue.floatValue
    val hsbSat = (MyColorItem.state as HSBType).saturation.floatValue
    val hsbBrt = (MyColorItem.state as HSBType).brightness.floatValue

    val hue = hsbHue
    val sat = hsbSat * hsbBrt/( (if((2-hsbSat)*hsbBrt < 1) hsbHue else 2-hsbHue) )
    val lightness = hsbBrt / 2.0

As you can see, you don’t need to parse the .state.toString at all. You can get at the raw primitive value for each directly.

By default, when you call .state you get back a generic State object. But you know because you read the docs that a ColorItem carries an HSBType which is a subclass of State. So you can cast that generic State object to an HSBType which gives you more methods to access the data stored in the State.

To discover what those methods are you need to visit the ESH Javadocs, look at the code itself, or you can do what I do and use ESH Designer and just type <ctrl><space>. Soon the VSCode plugin will support this I think too.

I applaud your willingness to learn how to do this stuff and that you are not just asking us to do it for you. But don’t spin your wheels too long on your own. We are happy to help!

[Curtis]

@rlkoshak

And the error in the openhab.log?

2017-10-27 09:04:15.568 [ERROR] 
[.script.engine.ScriptExecutionThread] - 
Rule 'HSBtoST': For input string: "105.076142"

@rlkoshak

Are you using ESH Designer?

Yes, I’m using it but not quite got to the stage where I can begin to write things correctly in the first place

@rlkoshak

Log each numSplit.get before you try to parse it.

I did try this after I posted and noticed that my problem happened before the parsing section.

2017-10-27 10:44:14.425 [INFO ] 
[g.eclipse.smarthome.model.script.HSB]
- HSB Split [Ljava.lang.String;@12dea75

@rlkoshak

when you do log it, wrap it in quotes so you can see if there is any white space or other non-parsable characters which would prevent parseInt from successfully parsing the values.

I’m not 100% sure I understand what you mean here, well I understand what you are saying but not how to implement.

@rlkoshak

As you can see, you don’t need to parse the .state.toString at all. You can get at the raw primitive value for each directly.

By default, when you call .state you get back a generic State object. But you know because you read the docs that a ColorItem carries an HSBType which is a subclass of State. So you can cast that generic State object to an HSBType which gives you more methods to access the data stored in the State.

Oh I see now. I was a bit confused with the HSBType, I incorrectly assumed it was only useful for converting to HSB to RGB. I think I am beginning to understand now.

I’ve just tried again but for some reason I’m still not getting a result.

rule HSBtoST
when
	Item Deck_HSB changed
then
	val hsbHue = (Deck_HSB.state as HSBType).hue.floatValue
    val hsbSat = (Deck_HSB.state as HSBType).saturation.floatValue
    val hsbBrt = (Deck_HSB.state as HSBType).brightness.floatValue
	
	logInfo("HSB", "H " + hsbHue + "S " + hsbSat + "B " + hsbBrt)
end

2017-10-27 16:43:06.400 [ERROR] [.script.engine.ScriptExecutionThread] - Rule 'HS2': org.eclipse.smarthome.core.library.types.HSBType

@rlkoshak

I applaud your willingness to learn how to do this stuff and that you are not just asking us to do it for you. But don’t spin your wheels too long on your own. We are happy to help!

Thanks, I really want to understand how to use openHAB fully so am very willing. I do love this forum as it is very helpful due to people like yourself but I also like to try and figure things out for myself as however painful, it is a good way to learn… well until I start going round in circles and pulling my hair out