var HSBType blau = new HSBType(new DecimalType(240),new PercentType(50),new PercentType(100))
This works for me too, but I would want to know what those Parameters of this HSBType constructor stand for?
H = Hue:
The color of the light to display represented as the number of degrees around a color wheel that lays out the colors in rainbow order. So red is 0/360, green is 120, and blue is 240. As you move between two points you start to mix the two colors. For example, magenta is a mix of blue and red so you will find it around 300, half way between blue and red.
S = Saturation
How pale or rich the color appears. For a gray color use a saturation of 0. For the richest version of the chosen H use 100. Think of S as the amount of H injected into the base gray color to show.
B = Brightness // how bright the light is
How bright the light is. If B is 0 the light is off. If B is 100 the light is on all the way.
So an HSB of 240, 50, 100 means the color blue at half saturation with the light fully on.
Thank you Rich,
Ah all right, that makes sense.
But I’m curious what happens to the HSBType instances we’re creating?
Are those saved on the pi’s heap and how long are they saved?
If those rules trigger over and over again, isn’t the heap crowded with many objects after some time?
and makes it a difference storing a instance in a global variable and sending the variable value to a thing/item or is it equal to just send a new object?
For example
gLight.sendCommand(new HSBType(new DecimalType(360),new PercentType(100),new PercentType(100)))
or
var blau = new HSBType(parameter, parameter, parameter)
gLight.sendCommand(blau)
Won’t affect me now, but I start to get into Rules more and I’m implementing more and more things into my OH system and it feels like I should start with good Performance design patterns as early as possible.
And I have one Problem with the HSBType brightness parameter.
If this parameter is 100, the Yeelight only shines with about 50% of it’s power.
But I assume this is a mistake of my Mi Home binding rather then the xbase rule right?
Yes
That is getting deep into the 's internals. Assuming it works like Java, upon which the Rules run, once nothing is pointed at the object it becomes eligible for garbage collection. I’m not sure if garbage collection is scheduled periodically or it waits until it needs to run.
In this case the object is only pointed to by the Item so it will remain for some time after the Item is set to a new state.
If you are really worried about performance, declare the hsb as a global val, but this would really be too about the cost of creating a new object every time the rule runs (I.e. cpu), not memory.
Over all, I tenoned against worrying about these things at all until you know you have as problem. Roles do not typically run often enough or do enough for this sort of thing to matter.
They only thing to watch it for is to avoid long running rules. So avoid long Thread::sleeps, while loops, etc inside a rule. You only get 5 threads meaning only 5 roles can run at a time. When you run out no new tools can run until running ones exit which can cause latency or cause your rules to stop.