Add support of RGB lights #120
Conversation
|
Hi @ultratoto14, Small note: Thanks again for developing this component. |
|
@SmartM-ui i need to force the color returned to white if i want the color picker to be updated. Using None only change the bulb icon. Can you check on your side ? |
I'll try it now, thanks! |
|
@ultratoto14 As soon as the color temperature slider is moved, the pointer returns to white :-) Can I ask you how I can configure, through the yaml and not the flow, the colors and the color temperature so I carry it back for all my bulbs and not just for the one I am trying? My current yaml is as follows: |
|
You can look in the README i updated it README |
Thanks |
|
@SmartM-ui do you have a list of the available dps for your bulb ? |
I have two models of light bulbs, on one I was able to configure it, on these others they are unavailable.
The bulb, via yaml and without color, was configured like this and worked:
|
|
ho provato così, ma risulta unavailable
|
|
This is the error reported when setting debug the log localtuya. @postlund , is it the same problem that had arisen in the past? Exception in _update_handler when dispatching 'localtuya_0xxxxxxxxxxx0': ({'1': False, '2': 'colour', '3': 181, '4': 83, '5': '5b2c00001dff5b', '6': '00ff0000000000', '7': 'ffff500100ff00', '8': 'ffff8003ff000000ff000000ff000000000000000000', '9': 'ffff5001ff0000', '10': 'ffff0505ff000000ff00ffff00ff00ff0000ff000000'},) Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 240, in _update_handler self.status_updated() File "/config/custom_components/localtuya/light.py", line 256, in status_updated hue, sat, value = [int(value, 16) for value in textwrap.wrap(color, 4)] ValueError: too many values to unpack (expected 3) |
|
For the one in snapshot, you should set the max brightness to 255. Usually when DPs starts at 1 => 255, when 20 => 1000. Also make sur no other integration/application is accessing the bulb. This bulbs only support one connection at a time. |
I don't think it depends on this, the problem arises when I try to manage the colors: (NOT WORK) (Same bulb works without color management) This is the error: Exception in _update_handler when dispatching 'localtuya_0xxx0': ({'1': False, '2': 'colour', '3': 181, '4': 83, '5': '301700001dff30', '6': '00ff0000000000', '7': 'ffff500100ff00', '8': 'ffff8003ff000000ff000000ff000000000000000000', '9': 'ffff5001ff0000', '10': 'ffff0505ff000000ff00ffff00ff00ff0000ff000000'},) Traceback (most recent call last): File "/config/custom_components/localtuya/common.py", line 240, in _update_handler self.status_updated() File "/config/custom_components/localtuya/light.py", line 256, in status_updated hue, sat, value = [int(value, 16) for value in textwrap.wrap(color, 4)] ValueError: too many values to unpack (expected 3) All the lamps that instead use these DPS work correctly: |
|
@SmartM-ui as mentioned, the one that is not working is using a 255 range and so another way of handling the color. id: 1
brightness: 3
color_temp: 4
color_mode: 2
color: 5
brightness_upper: 255 |
I was doing some tests, but the light bulb went haywire. I try to see if localkey has changed. |
|
@SmartM-ui just added a different way to detect color mode. Not linked to brightness setting anymore. But brightness and color_temp max value are linked. You can use tuya app to set color_temp/brightness to max/min and check the values of the corresponding DP using tuyadebug. |
custom_components/localtuya/light.py
Outdated
| ) | ||
| await self._device.set_dp(color, self._config.get(CONF_COLOR)) | ||
| if self._is_rgb_mode is None: | ||
| self._is_rgb_mode = len(self.dps_conf(CONF_COLOR)) > 12 |
There was a problem hiding this comment.
Am I understanding it right that _is_rgb_mode really represents if the bulb supports RGB or not and not current mode of the lamp (which I'm doing something similar for with white color)? It's a bit confusing to have two properties named the opposite of each other and not really representing the same thing. Can we consolidate into one variable?
There was a problem hiding this comment.
And it also seems strange to assign this variable here, would make more sense to set in status_updated in case the value change. I would however never expect it to do so, so it could possibly be assigned directly in the constructor.
There was a problem hiding this comment.
This one is representing the color coding, RGB_HSV if True, HSV4Bytes if False
There was a problem hiding this comment.
I set it originally in status_updated. It seems that it's not called when HA is restarted until something changed. If we have a bulb already On in white and just change color, the coding is not yet defined.
I may try to set it in the constructor but need to ensure data is already there. The problem with bulbs is that they can be powered off and not accessible when the constructor is called. In that case, we do not have the necessary data to update the value.
There was a problem hiding this comment.
Eventually, i extracted the check in a method without using variable.
custom_components/localtuya/light.py
Outdated
| if self._is_rgb_mode is None: | ||
| self._is_rgb_mode = len(self.dps_conf(CONF_COLOR)) > 12 | ||
|
|
||
| if self._is_rgb_mode: |
There was a problem hiding this comment.
Maybe we can extract this part to a method and re-use it in async_turn_on as well?
There was a problem hiding this comment.
Eventually, i extracted the check in a method without using variable.
Hi @ultratoto14 , Now the lamps that were previously unavailable also work, using the code: for these lamps the brightness slider did not reflect the true value of the bulb and I added, as proposed by you I noticed that the minimum of the localtuya slider corresponds to 3% of the SmartLife app slider and this sometimes creates some conflict if you use both apps. I tried to set: brightness_lower: 1 but this change makes the bulb unavailable when the brightness is turned down completely Do I try to update to the latest version released? |
|
Hi @SmartM-ui, thanks for testing, happy that it finally worked. We already know that some of the bulbs are not able to handle more than one connection at a time, meaning that even using HA and the tuya app at the same time is not possible. I mean, if we use the config flow way, i would recommend first to switch on the light, in white mode, with the brightness at 100%. As the config flow show the values of the DPs, it would be easy to read the value and set up the max brightness value. If your bulb supports two connections, you can also put localtuya/pytuya in debug mode logger:
default: error
logs:
#custom_components.localtuya: debug
custom_components.localtuya.pytuya: debug, and look for decrypted messages from your bulb. Change the values from the tuya app and read the ranges, adapt your configuration. Using this way i found that tuya app min value is 25 from one of my bulb and 10 for another one The best would be to have the config flow showing in real time the values of the DPs but it is far from what i can do. I don't know on which version you are testing, but after the afd938d commit, it's the same behavior, just refactoring. The color coding is deduced from the length of the color data point. Before that, it was based on the brightness range. |
@ultratoto14 I try to enter the code localtuya / pytuya in debug mode so as to discover the minimum and maximum level supported by the bulbs. Definitely 3 of my bulbs are set with 10/1000 level I think I have version 29f0af7, you solved the problem of the pointer in the color palette when switching from color to white. PS having manually saved the localtuya folder in the custom_components, version 2.0.1 is still installed in HACS and I still have this problem in the logs. Can I do something to fix or still need to fix the problem on the manifest.json? Logger: custom_components.hacs.repository.integration.rospogrigio.localtuya |
|
Hi @SmartM-ui, for the code, i just clone the repository, change the branch, create a symlink of the localtuya directory in the custom_component directory, and voila ! I do not use HACS for the moment, and then you can check on which version you are by just doing a git log command. |
|
Hey @ultratoto14 On this occasion I have installed your latest version (72272b4) and it works correctly. Good job! |
|
@postlund , @rospogrigio this is ready for review and merge if review is ok. |
|
I can review again later tonight 👍 Great job! |
|
@ultratoto14 Logger: custom_components.localtuya.pytuya Traceback (most recent call last): |
|
@SmartM-ui i didn't change the way the connection is used, i only interpreted the data and set the values. |
|
@SmartM-ui Heartbeats are sent every 20s to keep the connection alive. Would be great if you provided a complete log when this happens. |
|
@ultratoto14 The WIFI level, at least for a light bulb, is excellent, also because it is located in the same room as the router. @postlund I try to check the detailed log |
@postlund Here is the complete logs: or this: or this |
|
For me it's Ok |
|
Let's merge and take additional matters as new issues. |
This PR contains:
I didn't add an option to configure the color_temp upper value as for all the bulbs i have, they are always in sync with the brightness max values.
Configuration is explained in the README