JoDehli / PyLoxone

Python Loxone binding
Apache License 2.0
164 stars 40 forks source link

Not possible to set brightness and color for a light from HA to Loxone #100

Closed johny-mnemonic closed 2 years ago

johny-mnemonic commented 2 years ago

I am not sure whether I am doing something wrong or whether there is a bug in HA or PyLoxone, but I am unable to set brighness and color of the light in Loxone from HA.

When I send just rgb_color i.e.:

service: light.turn_on
target:
  entity_id: light.led_kitchen
data:  
  rgb_color: [0,0,255]

It set's the color of the light correctly, but with 100% brightness. And when I try to add brightness to the service call:

service: light.turn_on
target:
  entity_id: light.led_kitchen
data:  
  rgb_color: [0,0,255]
  brightness: 153

It sets the brightness correctly in Loxone, but it switches the light to white color resetting any color it was set to. Looks like if PyLoxone expects that only white dimmable lights have brightness. I have a few of white dimmable lights controlled this way and everything works fine. This is my first RGB light that I am trying to integrate this way...

I noticed in Loxone live view, that the LightController is setting the color and brightness as a combination of both simply by mixing brightness into rgb color, so I tried to do the same in HA:

service: light.turn_on
target:
  entity_id: light.led_kitchen
data: 
  rgb_color:
  - '{{ (states.light.led_kitchen.attributes.rgb_color[0] * states.light.led_kitchen.attributes.brightness/255) | int }}'
  - '{{ (states.light.led_kitchen.attributes.rgb_color[1] * states.light.led_kitchen.attributes.brightness/255) | int }}'
  - '{{ (states.light.led_kitchen.attributes.rgb_color[2] * states.light.led_kitchen.attributes.brightness/255) | int }}'

Unfortunately that again sets the color correctly but with 100% brightness...

The motivation and other details: I have Loxone as primary system and HA used mainly to integrate things that doesn't work with Loxone. Now I have got the LED RGB strip which has it's own remote control which my kids love, so I can't dump it ;-)

I flashed the LED strip controller with ESPHome and with the help of a few automations I am able to control it from Loxone without any trouble. But I also want to get the state of the light strip back from HA to Loxone for when it is controlled by the remote control.

Could you please check it and advice what is the correct way to control brightness and color of RGB(W) lights through PyLoxone?

JoDehli commented 2 years ago

I have no lights so I never had this problem. Home assistant sents 2 events if you want to change the color and the brightness. So to fix this you must sent first the color and after this the brightness. This should do the trick. I did not test it because as I mentioned I have no lights. Hope this helps.

johny-mnemonic commented 2 years ago

That's unfortunately the first thing I tried and no luck. As I wrote, when you send just the rgb_color, it correctly sets the color and sets brightness to 100%. And then if you try to send any value for brightness, it resets the color to white (RGB 255,255,255) and sets the correct brightness.

I tried all the ways to set color and each of the works correctly, but once you try to set brightness in any way from HA, the color is gone. I tried them all, 'brightness', 'brightness_pct' and 'brightness_step_pct'. All reliably sets brightness, while dropping any color information...

My bet would be, that Loxone only accepts setting color together with brightness in single commnad, but I am just guessing here.

BTW: You can easily test lights without owning any lights at all. Just define lightcontroller output as rgb or dimmer and make that lightcontroller accessible to PyLoxone. You will get the light visible in both Loxone app and HA and you can try controlling it from HA and see what it does in Loxone app. No need to have anything physically connected. Basically all my lights that are incompatible with Loxone (like IKEA or Yeelight) are "integrated" this way. Just a definition in lightcontroller and that's it. For some I control the socket to which these are connected with that lightcontroller output, but that doesn't matter.

JoDehli commented 2 years ago

I know that I can test it but I do not need the lights. I spent hours to integrate and and tested it with virtual lights. In the past I had a lot of work that it works like now. I think they work as expected when you control it via ha. That was the goal in the fist place. If someone improves it without making major changes they can sent me a pull request. You can try openhab maybe they support this feature.

JoDehli commented 2 years ago

What you can also do if you are not happy with the way loxone is implemented you can make a web socket call thru my binding as explained in the read me.

For example if you want a rgb color thru one output of a light controller you can do it like this:

image

You can connect that with a button or a script. I think then you can do what you want.

JoDehli commented 2 years ago

And by the way if you want to simulate a plus command you can do it like this: image

JoDehli commented 2 years ago

And a temperature is set like this: image

johny-mnemonic commented 2 years ago

I know that I can test it but I do not need the lights. I spent hours to integrate and and tested it with virtual lights. In the past I had a lot of work that it works like now. I think they work as expected when you control it via ha. That was the goal in the fist place. If someone improves it without making major changes they can sent me a pull request. You can try openhab maybe they support this feature.

I know you spent a lot of your time developing something you are not even using yourself, just for us the users of PyLoxone and I am grateful for that. In case it sounded like I demand a fix I am deeply sorry, as that was not my intention. It just looked like you don't trust me that it is now broken (most probably due to a change in HA or Loxone), so I tried to provide few simple steps to reproduce this bug.

It is not about whether I am happy with the way it is implemented, it simply doesn't work now for colored lights (not possible to control the brightness). It works fine only for single color lights and simple switch lights.

In case you have no desire to fix or even verify this bug it's perfectly OK as it's your time, I just wanted to report a bug, that's all.

Thanks a lot for these hint's for direct websocket usage. That's a great workaround. I just made the HA -> Loxone control of RGB working thanks to it. Will try to check the code, whether it would be easy to fix, but I am more sysad than coder...

JoDehli commented 2 years ago

Can you try the master branch a last time. Maybe I found what was causing the problem. I also changed the on behaviour. It should now behave the same as in loxone.

johny-mnemonic commented 2 years ago

Thanks for your time, but unfortunately the behavior is still the same.

When I turn on the lightcontroller in HA it does the same thing as calling this:

service: loxone.event_websocket_command
data:
  uuid: 1071d041-014a-9e99-ffffd7846630eb23
  value: on

It activates the "more light" default scene ("Enables lightscene 9 (All on)" according to docs). So it's the same as if you send pulse to the O input of the lightcontroller. This looks like an obvious way to implement it so I am not surprised you did it this way. I wouldn't consider this as a bug per se. I just think it would make more sense to improve the behavior and activate the first light scene with plus command instead as that's what you usually want when you activate the light in the room. Instead of blasting all lights at full power.

Regarding the brightness of rgb lights.

service: loxone.event_websocket_command
data:
  uuid: 1071d041-014a-9e99-ffffd7846630eb23/AI3
  value: hsv(37,100,60)

Calling this, results in having the correct color and 60% brightness in Loxone. Precisely:

color_mode: hs
brightness: 153
hs_color:
  - 36.941
  - 100
rgb_color:
  - 255
  - 156
  - 0
xy_color:
  - 0.574
  - 0.406
color_temp: 0
uuid: 1071d041-014a-9e99-ffffd7846630eb23/AI3
room: ''
category: ''
device_typ: ColorPickerV2
platform: loxone

While calling this:

service: light.turn_on
target:
  entity_id: light.led_kitchen
data:  
  hs_color: [37,100]
  brightness_pct: 60

Results in white light with 60% brightness.

color_mode: color_temp
brightness: 153
color_temp: 153
hs_color:
  - 54.768
  - 1.6
rgb_color:
  - 255
  - 254
  - 250

Maybe it's interesting, that it changed the mode from hs to color_temp. On the other hand when you call just with the color:

service: light.turn_on
target:
  entity_id: light.led_kitchen
data:  
  hs_color: [37,100]

it sets the color correctly and it is still reported in hs mode. The only downside is, that it then always has 100% brightness.

Looks like even when you provide both information (hs_color and brightness) it doesn't combine them together to send correct hsv to Loxone, but it sends them in two steps. And sending the brightness alone seems to result in sending temp command instead of hsv to Loxone, which resets the color information... It seems like it first sends hsv(37,100,100) and then temp(60,6500), filling the "missing" values with the max value in both cases. At least when I send these using websocket I get the same result in Loxone as if I use the light.turn_on service in HA.

My workaround using websocket does exactly what would need to be done in the code:

service: loxone.event_websocket_command
data:
  uuid: 1071d041-014a-9e99-ffffd7846630eb23/AI3
  value: >
    {%- set hue = states.light.led_rgb_kitchen.attributes.hs_color[0] %}
    {%- set sat = states.light.led_rgb_kitchen.attributes.hs_color[1] %}
    {%- set br = states.light.led_rgb_kitchen.attributes.brightness/2.55 %}
    hsv({{ hue | round(2) | default(0)  }},{{ sat | round(2) | default(0) }},{{ br | round(2) | default(0) }})

It combines hs color information with brightness into single hsv call to Loxone.

JoDehli commented 2 years ago

Regarding the on command. I thought I changed it everywhere but I saw there are some more on commands. You can change it int light.py itself and see it works as accepted. For the replace the "on" with the "plus" in the light.py.

Regarding the brightness and color. I tried it on a RGB light itself. I think it was as subcontrol of a light controller. And I used the GUI for the service. The GUI allows the color or the temperature not both which makes sense for me. If you pass a temperature it switches to temperature mode. And on my testing it works perfect.

For me a colour to a light controller itself is difficult because a light controller can consist of RGB and normal lights which does not support RGB. I tried it only on subcontrols.

JoDehli commented 2 years ago

@johny-mnemonic I replaced now all on commands with the plus command. And now I can not turn on some of my test lights anymore. In Loxone the can also not switched by the plus sign. I can only switch them by choosing a scene. But in Home Assistant the scenes are only available when the light is already on. So when I leave the changes like this some users can not switch the lights anymore. Any succession why this happens? Why are the plus button on the loxone app and browser app are not working for this lights?

johny-mnemonic commented 2 years ago

Thanks for your time playing with this. I would say that in case there is any issue with using the plus command instead of on , then just don't spend more time with it. It is nothing major as you can easily workaround it without messing with websocket just by activating the scene you want. I just thought it would behave better this way... I wonder what kind of light can't be turned on by plus command as I have most of the lights configured like that in my house. I went through all my light blocks in Loxone config now and haven't found a single one that refused to turn on using the plus input. Maybe it behaves differently through websocket then when you connect a button to a plus input of the light block 🤷‍♂️. I can test that later.

Regarding the color temperature I thing this is misunderstanding. I am always working with subcontrols the same as you do and I never intentionally set color temperature from HA. The thing is, that when you send just a brightness change from HA to a rgb light (the subcontrol) it seems to be implemented the way that it sends the color temperature instead of sending color together with brightness (hsv). Which results in resetting the color information. As is clearly apparent from my previous post, when I used the light.turn_on service with color (either hs or rgb) and brightness it resulted in the light subcontrol changing it's mode from hs to color_temp. Which was totally unintentional and this is what I consider as the bug which prevents the brightness to work with RGB lights.

Did you try to send brightness to a RGB subcontrol? This is the only thing that doesn't work correctly for me. Everything else seems to work fine.

JoDehli commented 2 years ago

I changed every on command to plus and I leave it like this. Only one virtual test light is ignoring the plus command and does not switch anymore. But I did not look what is wrong or what is missing on this light.

Yes I did sent brightness only and brightness with color and it worked great. Can you sent me some pics and some config explanations that I can implement it like you did?

When I create the light controller I must decide what the light controller can do. For example if you have only switches on all light controller inputs I must disable the rgb and color elements. But the difficulty is that a light controller can consist of switches and rgb and dimmer etc....

Maybe you have an configuration which I have not implemented or implemented wrong.

johny-mnemonic commented 2 years ago

I have only 3 RGB lights and I discovered it on the least populated light controller: loxone_light_kitchen It has two switches and RGB light. The other two are more populated, one without any switch light at all. All dimmers and one RGB. And the second one has 3 dimmers, RGB and switch: loxone_light_bath2 All of them behaves consistently with what I described in previous posts though.

So you are saying, that when you send this from HA:

service: light.turn_on
target:
  entity_id: light.SUBCONTROL_ENTITY
data:
  hs_color: [0, 100]
  brightness:_pct 60

You are getting red light with 60% brightness in Loxone?

JoDehli commented 2 years ago

@johny-mnemonic I changed again the light behavior for the lights on the master branch. Can you try it on the sub-controls of your first lightcontroller in the previous post. The one with 2 switches and one rgb. There I tried it with brightness only, and brightness with temp and rgb color.

If this works I try the next one.

Note: I did not change anything on the main light controller. You should try only the "LED podlaha" light

johny-mnemonic commented 2 years ago

I am sorry, but it's still the same :-(

service: light.turn_on
target:
  entity_id: light.led_podlaha_kuchyn
data:
  #hs_color: [100,100]
  rgb_color: [0,100,0]
  #brightness_pct: 60

No matter whether I try with rgb_color or hs_color once I add brightness it changes mode from hs to color_temp which resets the color information...

JoDehli commented 2 years ago

Do you use the GUI? I tried it only with the gui.

The GUI converts the numbers to the right internal values.

JoDehli commented 2 years ago

Ok now I have tested everything and it works perfect on my system. I can set the brightness, color and temp on subcontrols. I removed the ability to change the brightness and color on the main light controller. It fits not in the loxone way of doing it. So now it behaves exactly like in Loxone.

I tried the following:

service: light.turn_on
data:
  rgb_color:
    - 255
    - 100
    - 100
  brightness_pct: 50
target:
  entity_id: light.rgb_5
service: light.turn_on
data:
  rgb_color:
    - 255
    - 100
    - 100
  brightness: 125
target:
  entity_id: light.rgb_5
service: light.turn_on
data:
  color_name: blue
  brightness_pct: 50
target:
  entity_id: light.rgb_5
service: light.turn_on
data:
  kelvin: 2200
target:
  entity_id: light.rgb_5
johny-mnemonic commented 2 years ago

Not sure why removing the controls from master entity helped, but now it works! 🎉 Looking at your changes I would have expected that the last changes for RGB light should have solved it, but it didn't...at least not for me.🤷‍♂️ Only now when you removed the master control it works.

Also I haven't tried it from GUI before you asked for it, but when I tried it yesterday, it behaved the same even from GUI. Once I selected any color, the brightness jumped to 100% and when I touched brightness it switched to white light. So at least we know this has consistent behavior in HA :-)

Now it works from GUI and all your service call examples works as well. Thank you!

JoDehli commented 2 years ago

@johny-mnemonic I removed it because the implementation was not really good. Maybe I can write it so that it behaves like it is expected. I think important is that the commands from the service calls are working. If they work users can write script and customize how they want it.

Maybe you noticed I added all sub controls to the devloper site under the attributes for the light controllers like in this example:

image

johny-mnemonic commented 2 years ago

I think important is that the commands from the service calls are working.

Exactly! And not just that. UI works fine as well. Thanks

I would say do not spend time on re-adding master entity controls. If there is something that could be useful, it would be the ability to have the effects available all the time, not just when the light controller is turned on. Users can easily workaround it now for example by defining button in the HA UI with the most used scene and placing it next to the light controller block, but would be nice to be able to activate any scene directly from the light controller block. I am not sure whether there is some limitation on HA or Loxone side that prevents this, though. So take this only as an idea for when you get bored and wanted to try to improve PyLoxone.

Maybe you noticed I added all sub controls to the devloper site under the attributes for the light controllers

I didn't 😉 But it's nice touch. Thank you! I missed it mainly because I usually go directly to the subcontrol I want to work with, but it is useful to have it all at one place.