Send string command to Color Item results in differnt colors

  • Platform information:
    • Hardware: Raspberry Pi 4 Model B Rev 1.1
    • OS: Raspbian GNU/Linux 10
    • Java Runtime Environment: OpenJDK Runtime Environment (Zulu 8.50.0.259-CA-linux_aarch32hf) (build 1.8.0_272-b17)
    • openHAB version: openHAB 2.5.10-1 (Release Build)

Hi guys,

I am a little bit confused with the Color item behavior of my Philips Hue White & Color Ambiance E27 LED lamps.

I have quite a number of rules that are controlling my lamps and I didn’t want to deal with all the code required to control a HSBType. Therefore, I decided to create some virtual String items that hold the final state definition of my scenarios. I have defined them as

Group Lichtfarben "Farben" <colorlight> (Einstellungen)
String cHueSzeneHell "Hell" <colorlight> (Lichtfarben,RestoreOnStartup)
String cHueSzeneNormal "Normal" <colorlight> (Lichtfarben,RestoreOnStartup)
String cHueSzeneGedimmt "Gedimmt" <colorlight> (Lichtfarben,RestoreOnStartup)
String cHueSzeneEntspannung "Entspannung" <colorlight> (Lichtfarben,RestoreOnStartup)
String cHueSzeneNachtlicht "Nachtlicht" <colorlight> (Lichtfarben,RestoreOnStartup)
String cHueSzeneWeihnachtslicht "Weihnachtslicht" <colorlight> (Lichtfarben,RestoreOnStartup)

and they are initialized during system startup:

rule "Farben definieren"
when
  System started
then
  cHueSzeneHell.postUpdate("49,36,100")
  cHueSzeneNormal.postUpdate("49,36,80")
  cHueSzeneGedimmt.postUpdate("44,72,30")
  cHueSzeneEntspannung.postUpdate("44,72,70")
  cHueSzeneNachtlicht.postUpdate("44,72,1")
  cHueSzeneWeihnachtslicht.postUpdate("44,72,60")
end

When I now want to update a lamp I simple send a command with the state of the corresponding virtual configuration item as:

rule "Flur_Licht_Standard"
when
  Channel "homematic:HmIP-WRC6:xxx:yyy:1#BUTTON" triggered "SHORT_PRESSED"
then
  Flur_Treppenlicht.sendCommand(cHueSzeneNormal.state.toString)
end

This worked well for quite some time now, but all of a sudden, the light does no longer match my expectation. I debugged the situation and found out, that the final color that is set by sending the String via the HUE Binding to the lamp is in fact depending on the previous color set on the lamp!

In the logs I see that the values that are set and send to the HUE bridge are always the same! But they get interpreted differently: If I set an arbitrary color via the HUE app on my smartphone the result of the command execution is different than that, if I set an arbitrary whiteness value via the HUE app.

Is this a known behavior? I thought that setting a HSB value on the Openhab side should always result in the same state of the lamp, but this does not seem to be true. What am I doing wrong? Would the actual use of a HSBType within the command avoid that behavior?

Thanks.

As you are sending the command to the Flur_Treppenlicht item, is that the item that controls the color channel of the hue bulb or is it a group item that then contains items for the various channels? I would suspect you need to send the command directly to the color channel.

I believe the issue you are experiencing maybe caused by the way the bulbs work in terms of setting color vs color temperature as the bulbs typically get turned on in one mode.

1 Like

Sending a command to a Group Item just results in the same command being passed to all Group members. This should be visible in your events.log.
However … it can give unexpected effects with some bindings because it’s rapid-fire, making a mini flood of multiple commands.

Oh sorry, I forgot to add the item configuration for those:

Group:Color Flur_Treppenlicht "Treppenlicht" <colorlight> (Flur)
Color Flur_Treppenlicht_EG_unten "Treppenlicht (unten, links)" <colorlight> (Flur_Treppenlicht,LichterAnwesenheit,RestoreOnStartup) {channel="hue:0210:001788404d8c:29:color"}
Color Flur_Treppenlicht_EG_oben "Treppenlicht (unten, rechts)" <colorlight> (Flur_Treppenlicht,LichterAnwesenheit,RestoreOnStartup) {channel="hue:0210:001788404d8c:31:color"}
Color Flur_Treppenlicht_DG_unten "Treppenlicht (oben, links)" <colorlight> (Flur_Treppenlicht,LichterAnwesenheit,RestoreOnStartup) {channel="hue:0210:001788404d8c:32:color"}
Color Flur_Treppenlicht_DG_oben "Treppenlicht (oben, rechts)" <colorlight> (Flur_Treppenlicht,LichterAnwesenheit,RestoreOnStartup) {channel="hue:0210:001788404d8c:30:color"}

In fact it is not the item itself but a Color group, but the behavior is the same if I send it on the item’s color channel individually. So no difference on the OpenHab side.

Do I need to set both channels (color and color_temperature) accordingly to get the same result every time? I thought that the HSB definition contains all information needed to set a color properly.

According to your items it should work as expected - you shouldn’t need to set both color and color_temperature.

What does the event.log show?

The event log shows the correct values (as far as I can see). First change of light color:

2021-01-07 16:58:48.441 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht' received command 44,72,70
2021-01-07 16:58:48.446 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_EG_unten' received command 44,72,70
2021-01-07 16:58:48.460 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_EG_oben' received command 44,72,70
2021-01-07 16:58:48.476 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_DG_unten' received command 44,72,70
2021-01-07 16:58:48.496 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_DG_oben' received command 44,72,70
2021-01-07 16:58:48.514 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_EG_unten predicted to become 44,72,70
2021-01-07 16:58:48.572 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_EG_oben predicted to become 44,72,70
2021-01-07 16:58:48.610 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_DG_unten predicted to become 44,72,70
2021-01-07 16:58:48.649 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_DG_oben predicted to become 44,72,70
2021-01-07 16:58:48.684 [GroupItemStateChangedEvent] - Flur_Treppenlicht changed from 44,72,70 to UNDEF through Flur_Treppenlicht_EG_unten
2021-01-07 16:58:48.688 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_EG_unten changed from 44,72,30 to 44,72,70
2021-01-07 16:58:48.692 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_EG_oben changed from 44,72,30 to 44,72,70
2021-01-07 16:58:48.696 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_DG_unten changed from 44,72,30 to 44,72,70
2021-01-07 16:58:48.700 [GroupItemStateChangedEvent] - Flur_Treppenlicht changed from UNDEF to 44,72,70 through Flur_Treppenlicht_DG_oben
2021-01-07 16:58:48.702 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_DG_oben changed from 44,72,30 to 44,72,70

And another change:

2021-01-07 17:00:54.068 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht' received command 44,72,30
2021-01-07 17:00:54.073 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_EG_unten' received command 44,72,30
2021-01-07 17:00:54.090 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_EG_oben' received command 44,72,30
2021-01-07 17:00:54.105 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_DG_unten' received command 44,72,30
2021-01-07 17:00:54.120 [ome.event.ItemCommandEvent] - Item 'Flur_Treppenlicht_DG_oben' received command 44,72,30
2021-01-07 17:00:54.141 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_EG_unten predicted to become 44,72,30
2021-01-07 17:00:54.176 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_EG_oben predicted to become 44,72,30
2021-01-07 17:00:54.207 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_DG_unten predicted to become 44,72,30
2021-01-07 17:00:54.244 [nt.ItemStatePredictedEvent] - Flur_Treppenlicht_DG_oben predicted to become 44,72,30
2021-01-07 17:00:54.275 [GroupItemStateChangedEvent] - Flur_Treppenlicht changed from 44,72,30 to UNDEF through Flur_Treppenlicht_EG_unten
2021-01-07 17:00:54.277 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_EG_unten changed from 44,72,70 to 44,72,30
2021-01-07 17:00:54.279 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_EG_oben changed from 44,72,70 to 44,72,30
2021-01-07 17:00:54.281 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_DG_unten changed from 44,72,70 to 44,72,30
2021-01-07 17:00:54.283 [GroupItemStateChangedEvent] - Flur_Treppenlicht changed from UNDEF to 44,72,30 through Flur_Treppenlicht_DG_oben
2021-01-07 17:00:54.285 [vent.ItemStateChangedEvent] - Flur_Treppenlicht_DG_oben changed from 44,72,70 to 44,72,30

You can see that I have changed the lights twice. Both are getting set correctly through OpenHab, but the HUE bulbs turn into a green light instead of the warm white, which all the other bulbs in the house are getting set to, when I send this command to those.

I don’t see anything wrong in the event.log you posted, so am a bit mystified. I even sent the color value directly to one of my HUE bulbs and saw that it does produce a ‘Warm White’ (note: I’m using OH3 but shouldn’t matter for this).

Steps to reproduce my issue:

  1. Send the Command (44,72,70) to the bulb => Warm White
  2. Go to HUE App and modify the color of the bulb with the color picker circle to any color
  3. Wait approx. 30 seconds until OH has received/recognized the new color from the HUE bridge
  4. Resend the Command (44,72,70) to the bulb => Green color
  5. Go to HUE App and modify the color of the bulb with the color temperture widget to any color
  6. Wait approx. 30 seconds until OH has received/recognized the new color from the HUE bridge
  7. Resend the Command (44,72,70) to the bulb => Warm white

That happens to all of my HUE bulbs and this brings me back to my initial question: Is this behavior “expected” or do I have to send another command first, such that the HUE bulb recognizes the command as HSB color?

I just tried your steps on a bulb here and believe I experienced the same issue (a greenish hue). Note, I tested using OH3 and by sending the commands to the bulbs color channel directly from the console. I guess this might be an issue with the HUE bulbs.

Yes, I think the bulbs are getting kind of confused if one mixes up color and color temperature values. If I first send a color temperature of 100% and then send the color, everything works great, regardless to the steps above.

I wonder if the binding could be modify in such a way, that the values send to the bulb contain all four values of the RGBW range. I havent digged into the bindings code yet, I first wanted to verify if the behavior is a bug with my configuration or if it is common behavior. So thanks for verifying that. :slight_smile:

So I walked through the source code and I think the corresponding method is the following:

The lightState is asked for its color mode in line 75 and based on that, the corresponding transformation is applied. For some reason, OpenHab does not seem to be updated if the color mode is “changed” outside of OpenHab… I am not yet sure about that statement, I have to debug into the opposite communication direction to verify this hypothesis… but it would perfectly explain the experienced behavior.

After spending some time reading over the StateUpdate class and the ColorMode enumeration, I stumbled upon that there are THREE color modes defined:

  • XY: CIE color space coordinates
  • HS: Hue and saturation
  • CT: color temperature in mirek

The line I mentioned before only handles XY as a special case, but does not differentiate between HS and CT. So, if I change the “color mode” of the bulb in the HUE app, it will lead to the unexpected behavior that I have.

So, I think we should open a bug ticket here for the binding. What do you guys think?

I think it would be fair to open an bug report.

Ok, I just found out that I was (unfortunately) walking through the openhab version 1 archived github repo… :unamused:

But, the lines of code did not change ever since then:

So, still the same issue.

Workaround to that solution: Make sure that you use the same color mode (best use HSB) for all of your bulbs. Set it in the HUE app and do not change it there. :slight_smile:

Then all bulbs will work as expected.

Created a bug ticket at: