hi @KurtSanders, I looks like the message is formed as it should, i.e. I can't see anything wrong from the log messages that you posted. But I think you are correct that the problem is the protocol version. Unfortunately, I haven't seen any option for my devices to update to 3.4, hence it is very difficult for me to test and do updates to the drivers. I will give it a go though and see if I can dig a bit to also support 3.4.
Thanks @holand.ivar ,
The driver does not change the on/off state of the bulb, but appears to connect to it and have some sort of dialogue. So you are right, probably something in the new protocol (hate it when they are not backward compatible..).
If you need me to send any debug logs or authorize you on the cloud for this device, let me know.
I can control the RGB light from the tinytuya python apps so I know I have the correct settings.
Again, thank you for assistance.
Thank you.
For now, I discovered that I can use custom commands to set 21 to "colour" and 24 to a saved string, and then turn it on (aka 20 becomes true) so it might not be necessary to store 25.
I've also been trying to implement the HSL/RGB part of the driver, but I'm an amateur with groovy at best. 24 turns out to be HSL with the L in the range of 0-1000. I've managed to alter the driver to extract HSL from a response into attributes, but I can't reverse that to generate an appropriate string and command in the driver, e.g. enter "HSL" values in the device and click the button. I hope I'm making sense.
I was also trying use the Scenes. If that is something that you can implement, That would be awesome. If you need anything from me, please let me know. I'm trying to learn how to tinker with existing drivers and apps.
Finally, I was temporarily also using an app (BPTWorld's Lighting Effects) to randomize the colors. It was somehow working, but the error logs would fill with something along the lines of "command was not understood". Any ideas how it could have actually worked with the current driver?
None of this is urgent. Everything that you might be able to do is very appreciated.
(Edited on July 15, 2024 to update #3, first bullet point)
Based on my reverse enginnering today, you can ignore the request regarding parameter 25. It's for scenes, and is not a string that contains all the settings in one.
My request then changes to fixing the HSL buttons on the device page.
I'm going to summarize what I know. You probably already know all of this. From #3 to the end, is for scenes, which could be simply stored and set, or better yet, if they could be stored in the driver itself and chosen by it's name? i'm including all of the details for anyone who wants to tweak their own custom scene.
- if 21 is white, then 22 is the level from 10 (1%) to 1000 (100%) as a number.
- If 21 is colour, then 24 is the color in hex. first 4 digits is Hue (0-360), 2nd 4 digits is Saturation (0-1000), and Level/Brightness (1-1000) as a string
- If 21 is scene, then 25 is the definition of that scene, all in hex as a string.
- The first 2 digits is the array entry of the built-in scene starting with 00. Custom Scenes start with c9.
- Next 4 digits - speed of the transition from 0000 being the slowest to 6464 being the fastest. It actually looks like 00-64 (decimal 0-100) twice.
- next 2 digits - 00 (static), 01 (flashing), 02 (breathing) - the transition between the colors of the scene
- the color -if the color is white, then 12 0s followed by 8 digits for the shade of white? I'm not convinced this is absolutely correct. If it's a color, then 12 digits of the color followed by 8 0s.
- continue repeating for each additional color with 4 digit speed, 2 digits for the transition, and then 12+8 digits for the color.
Here are some examples of the built in scenes. I've added spaces to separate things.
Good night - 00 0e0d 00 000000000000 00c803e8
Reading - 01 0e0d 00 000000000000 03e803e8
Working - 02 0e0d 00 000000000000 03e803e8
Leisure - 03 0e0d 00 000000000000 01f403e8
Grassland - 04 4646 02 007803e803e8 00000000 4646 02 007803e8000a 00000000
Dazzling (flash between red, green, blue) - 06 4646 01 000003e803e8 00000000 4646 01 007803e803e8 00000000 4646 01 00f003e803e8 00000000
Holi - 25 4646 01 011303e803e8 00000000 4646 02 000003e803e8 00000000 4646 02 003d03e803e8 00000000 4646 01 0154032003e8 00000000 4646 01 0140032003e8 00000000 4646 01 001e02ee03e8 00000000 (this one has different transitions between colors!)
Christmas - 22 5a5a 01 00f003e803e8 00000000 5a5a 01 003d03e803e8 00000000 4646 01 000003e803e8 00000000 5a5a 01 00ae03e803e8 00000000 5a5a 01 011303e803e8 00000000 4646 01 007803e803e8 00000000 (this one has different transition speeds)
I created my own scene.
Static, lavender - c9 6464 00 00f5021803e8 00000000
edited it to some shade of white: c9 6464 00 000000000000 022503e8
Flashing between some shade of white and red: c9 6464 01 000000000000 022503e8 6464 01 016003e803e8 00000000
Flashing between some shade of white, and red, and blue: c9 6464 01 000000000000 022503e8 6464 01 016003e803e8 00000000 6464 01 00ee03e803e8 00000000
Breathing between some shade of white, and red, and blue: c9 6464 02 000000000000 022503e8 6464 02 016003e803e8 00000000 6464 02 00ee03e803e8 00000000
Same breathing but with the speed reduced: c9 1c1c 02 000000000000 022503e8 1c1c 02 016003e803e8 00000000 1c1c 02 00ee03e803e8 00000000
Same breathing with reduced speed with red, blue, and THEN a shade of white: c9 1c1c 02 016003e803e8 00000000 1c1c 02 00ee03e803e8 00000000 1c1c 02 000000000000 02ad03e8
I have added support for protocol 3.4 as an experimental option in the drivers. They are pushed to github. If you test them please let me know how it goes, as I said I have no devices to test it on that uses 3.4 or can be updated to 3.4.
1 Like
hi @neerav.modi,
I have updated the driver to support both HSV and HSL color mode, you will find a drop down menu in the device settings to configure this now:
Actually HSV/HSL seems to be causing a lot of confusion. Just look at Hubitat, when setting the color map you get the impression that Hubitat is dealing with a HSL color map:
however Hubitat gives you a color which corresponds to a HSV value (i.e. not HSL). I have notified Hubitat about this and they have updated their documentation:
Next you have the actual bulb implementation itself. The tuya protocol specifies that the bulb must follow the HSV model (see 24 here: Generic Light Bulb Template-Tuya IoT Development Platform-Tuya Developer). However the tuya bulb I have definitively follows the HSL mode... So we are not the only ones confused by this.
Anyway as I said, I have now added a setting so that this can be configured per device. So then it is just to experiment and see what produces the best color.
I will look into scenes now 
If you look at the latest driver it should now have support for scenes. Thanks for this input. Please test and let me know what you think.
More updates had to be made to support protocol version 3.4.
Latest update to the drivers has protocol v3.4 support. The generated output has been validated against tinytuya output. The untested feature is data reception, as I do not own a 3.4 device. If anyone can suggest a 3.4 version device that would be very helpful for continuing the support.
See here for updated drivers:
1 Like
Nice! Scenes work awesomely. I've generated a list of the pre-built scenes from the Smart Life app below.
HSL/HSV: That's a nice setting. Neither looks right for most colors, but it's so much better than before. I plan on tweaking to achieve the right color and saving in a rule or variables.
Set Hue, Set Saturation don't appear to do anything.
Preset Level and Set Level both change the brightness of white. I would figure that Set Level would effect the L/V of HSL/HSV, but instead it switches from "colour" to "white" mode.
lightEffects = [
0 : "000e0d0000000000000000c803e8", // Good night
1 : "010e0d0000000000000003e803e8", // Reading
2 : "020e0d0000000000000003e803e8", // Working
3 : "030e0d0000000000000001f403e8", // Leisure
4 : "04464602007803e803e800000000464602007803e8000a00000000", // Grassland
5 : "05464601000003e803e800000000464601007803e803e80000000046460100f003e803e800000000464601003d03e803e80000000046460100ae03e803e800000000464601011303e803e800000000", Colorful
6 : "06464601000003e803e800000000464601007803e803e80000000046460100f003e803e800000000", // Dazzling (flash between red, green, blue)
7 : "07464602000003e803e800000000464602007803e803e80000000046460200f003e803e800000000464602003d03e803e80000000046460200ae03e803e800000000464602011303e803e800000000", // Gorgeous
8 : "08000000001e0320012c00000000", // Night Light
20 : "1446460200ae03e803e80000000046460200b4012c03e80000000046460200b4003203e800000000", // Blue Sky
21 : "1532320200f003e800640000000032320200f003e803e800000000464602012703e802ee00000000555502000003e803e800000000464602001302ee03e8000000004646020032025803e800000000323202005a038403e800000000", // Sunrise
22 : "16323202005a0384006400000000323202005a038403e8000000004646020032025803e800000000505002001e02ee03e800000000323202000003e803e800000000", // Sunset Glow
23 : "1746460200f003e803e80000000046460200dc02bc03e800000000", // Ocean
24 : "184646020028032003e800000000464602001e038403e8000000004646020014038403e800000000", // Sunflower
25 : "19464601007803e803e800000000464602006e0320025800000000464602005a038403e800000000", // Forest
26 : "1a464602000a038403e800000000464602000003e803e800000000", // Kung Fu
27 : "1b464603001803e803e800000000", // Candlelight
28 : "1c4646020104032003e800000000464602011802bc03e800000000464602011303e803e800000000", // Dream
29 : "1d646401000003e803e80000000064640100f003e803e800000000646402007803e803e800000000646402003d03e803e800000000", // Mediterranean ??
30 : "1e323201015e01f403e800000000323202003201f403e80000000032320200a001f403e800000000", // French St??
31 : "1f46460100dc02bc03e800000000464602006e03200258000000004646020014038403e800000000464601012703e802ee0000000046460100000384028a00000000", // American ??
32 : "20646401003d03e803e800000000646401007803e803e8000000005a5a01011303e803e8000000005a5a0100ae03e803e800000000646401003201f403e800000000646401000003e803e800000000", // Birthday
33 : "21323202015e01f403e800000000323202011303e803e800000000", //Wedding ??
34 : "225a5a0100f003e803e8000000005a5a01003d03e803e800000000464601000003e803e8000000005a5a0100ae03e803e8000000005a5a01011303e803e800000000464601007803e803e800000000", // Christmas
35 : "23505002000003e803e80000000046460200f003e803e800000000", //Independence ??
36 : "24464602000003e803e800000000464602003d03e803e800000000464602011303e803e80000000046460200f003e803e800000000464602007803e803e800000000", // Diwali
37 : "25464601011303e803e800000000464602000003e803e800000000464602003d03e803e8000000004646010154032003e8000000004646010140032003e800000000464601001e02ee03e800000000", // Holi
38 : "265a5a020014006403e800000000464602000003e803e800000000", // Victory Day
39 : "275a5a020014006403e800000000464602000003e803e800000000323202015e01f403e800000000464602011303e803e800000000", // Easter
40 : "28464601011303e803e800000000464601001e03e803e800000000", // Halloween
41 : "2946460200000000000003e803e846460200000", // Soft
42 : "2a23230100000000000003e803e823230100000000000000c803e8", //Dynamic
(No guarantees that I didn't miss a comma or quotation mark! :-D)
2 Likes
For forum search purposes, I use the Local tuya RGBW Bulb Driver for XMCosy+ outdoor landscape lights and it works brilliantly.
This is just something that the other light drivers do, but I wonder if I could do something like detecting what mode the light is in and do either adjust the native brightness (affects the "white LED" only), or adjust the level/value in "color" mode. I haven't seen any other driver do this, but this is definitively an interesting feature. Thanks for the suggestion.
Just a heads-up, the 3.4 implementation in the driver is not working... I did miss the point that 3.4 protocol requires negotiation of a session key to operate. I am in the process of updating the driver to support this though. I have all the messages needed. But I do not have any devices that support 3.4 so testing the implementation is somewhat a pain, and I am currently relying on other users input and tinytuya python library to verify the inputs and outputs.
If someone have a tip for a device that has confirmed 3.4 protocol support I would very much like to know, that way the development would be much easier.
1 Like
Local tuya protocol version 3.4 is now fully supported in the drivers and tested (on a RGBW light bulb). Head over to my github repo and make sure to update with the latest version. This version also has a lot of stability improvements to the driver, also for the 3.1 and 3.3 version of the protocol. I have also included @neerav.modi 's scene suggestions. And a big thank you to @KurtSanders for support by sharing your debug log output.
TIP: Upon first connection to 3.4 devices I have seen issues where you I had to power on and off the bulb if you I had used tinytuya to communicate with the device previously.
3 Likes
Another update from me. I have added a feature in the driver to keep the communication channel with the device open, i.e. it reconnects when the socket is closed. This means the driver can be used with switched and for devices that are controlled outside HE, e.g. from Smart Life.
Keeping the socket open means that you get instant updates if the status of the device change outside HE without polling for status.
The feature is enables in the preferences, and it is default on:
This is awesome, works so well, Thank you for all the hard work and contributions to the community. I much prefer to have local control of all these devices. Hopefully soon I will be able to retire my Home Assistant!
1 Like
I've moved beyond testing and updated all my lights to this driver. THANK YOU!
One more thing: is it possible to get this on HPM?
1 Like
I was not aware of the HPM possibility, I will definitively look into that. Thanks for the hint
1 Like
I just setup and tried to use this driver, pulled the keys, but the driver won't accept it. IE I paste in FO4:l6$gE{+JHA, and it changes it to F$gE{+JHA in the device local key field, and then when I try to hit an endpoint, I get this:
[dev:4113](https://10.54.25.35/logs?tab=past&deviceId=4113#)2024-03-21 11:23:55.551 AM[error](https://10.54.25.35/logs?tab=past&deviceId=4113#)java.security.InvalidKeyException: Invalid AES key length: 9 bytes on line 1064 (method off)
And will I need a seperate driver for each type of device I have? I'm very confused at this point...vs the cloud driver that sucks, but works, when Tuya's api isn't breaking...
Thank you!
I've added my 25 lights, they are in groups, so I've tried Motion and Mode Lighting, and lights in groups turn on randomly in the group, some come on, some don't, some go off, some don't.
I also tried in Room lighting, but as I've had issues with in the past, it doesn't even turn anything but a switch on reliably 
hi michaelahess,
First of all I think IE is doing something strange with the data entry, looks like it is removing what it thinks is a time string "04:16" from the entry for some unknown reason. Can you try with Chrome or Edge, I do not see the same issue with this key on my end.
That being said, something is strange with the key you posted, the key must be 16 characters long exactly. What the driver does is that it interpret the text string as 16 bytes = 128 bits which is the AES key that is used to communicate with the light bulb.
You should not need several drivers to control several bulbs, however I did see some issues that I fixed the latest version back in February. Can you make sure you have the latest version and test again?
