Hi,
I mean ie as in example, I was doing this in Edge, and tried on Chrome as well. Will try firefox later today.
I was cut/pasting the key from the command line output, but I'll clear the cache file and give it another pull.
I'll update once I get a chance to do this, thank you!
Tried in various browsers on various computers, all give me the same, modifying this string
FO4:l6$gE{+JHA even here isn't showing it right... F < 0 4 : l 6 > $ g E { + J H A
to
F$gE{+JHA
HA! I was able to escape it:
F<O4:l6>$gE{+JHA "F & l t ; O 4 : l 6 > $ g E { + J H A"
Now it works!
Aha, now I understand, then it makes more sense. This is a protection to prevent HTML injection, & l t ; is indeed the HTML way of dealing with less than (<). I wonder if I can do something with the driver to overcome this issue. Thanks for pointing this out, and good that you found a workaround.
I think I have a fix for this issue in the latest updated driver, see: hubitatappndevice/Device/tuyaDevices/tuyaGenericBulbRGBW.groovy at master · ivarho/hubitatappndevice · GitHub
The fix seems to be to feed the escaped key back into the device settings.
// Update the setting in case < got replaced in the original input
device.updateSetting("localKey", [value: localKey.replaceAll('<', '<'), type: "text"])
@holand.ivar FYI, there is something wrong with the lights/driver when the Configure Bulb Mode device setting is set to HSV (native Hubitat). It must be set to HSL for the light to work properly.
Background: (from memory) My lights stopped working in Jan. Well, one or two lights worked but not consistently, the others did not. I troubleshot everything: the phone app worked, the device ID/IP/keys were correct, changes to through the app showed in the device page, but there was no way to control the light (on/off or any control button on the device page, nor any existing rules). I know there was a lot more done to troubleshoot, but nothing worked, and I gave up. Fast forward many months later, I decided for kicks to change the Bulb Mode setting from HSV to HSL on a "broken" light, and it suddenly started working again!
Changed the setting on all lights, and the driver is working perfectly again! Something broke it in the Dec 2023/Jan 2024 driver updates. I suspect it had to do with the scene settings being added. I had been testing the scenes on the light that was set to HSL and the color controls on the ones set to HSV.
I had this issue when first setting up this driver. But my solution was to remove and readd the light into my account as many as time needed until I got a key that worked in the driver! 
I've found a problem in the Send Custom Data to Device command. It breaks if the data is somewhere between 106 and 132 characters.
Try setting the endpoint 25 to:
25464601011303e803e800000000464602000003e803e800000000464602003d03e803e8000000004646010154032003e8000000004646010140032003e800000000
It won't work at 132 characters. Then try, after having removed one more 26 character color:
25464601011303e803e800000000464602000003e803e800000000464602003d03e803e8000000004646010154032003e800000000
It works and the responses are not garbled.
The same with Set Effect. Trying to set it to 37 does not work. But it seems to be more restrictive. 29 and 39 also do not work. However, 28 works.
Is there any way to increase the string length that the driver can handle?
Possible to make this work with LEDvance bulbs?
Hi Zack,
I am using it with a couple of ledvance bulbs. It works for me. There are some python tools out there that helps you extract the needed keys. It is a bit fiddly but I think I managed to do it using this guide: https://youtu.be/IzmA2VAhecA?si=SsJ6oDJU0Y0PKXUi
EDITTED 
short story to the ones who read the first post, I found I had more than one version of the driver and found that I selected the wrong one!
Now I am at this local key error:
dev:5752025-01-29 14:46:14.730
error
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 16 when decrypting with padded cipher on line 1498 (method DriverSelfTest)
I got the local key from tuya developer
HI HypeTaxx,
You have to make sure your key consists of exactly 16 characters. There has been some issues in the past where the key contained special characters that was eaten by the Hubitat interface. Do not post your key here, but do you see any obvious special characters? Previously "<" and ">" has been problematic, but these was fixed.
Ideally if you can just create a similar key that generates the same error and send to me by PM it would make it much easier for me to debug and fix.
BR
Ivar
Can someone help where to enter the local key? I am not seeing an input box for it. Pls advise
Locate the device under Devices in Hubitat and select the Preferences tab, then you should see this view, which should provide fields for Device IP, ID, and local key.
Thanks for the quick reply, i found the issue. I was using different driver 'Tuya Local RGBW Light'
I was forced to reset my XMCosy lights to connect to a new WiFi. When running the tinytuya scan locally, I get the following, which now includes an error. My tuya developer account is no longer active. The scan shows the same keys, ids, etc as before. I no longer have local control as before.
% python3 -m tinytuya wizard -nocolor
TinyTuya Setup Wizard [1.12.7]
Existing settings:
API Key=<redacted>
Secret=<redacted>
DeviceID=<redacted>
Region=us
Use existing credentials (Y/n): y
Error from Tuya server: Error from Tuya Cloud: Code 28841002: 'No permissions. Your subscription to cloud development plan has expired.'
Check DeviceID and Region
% Tuya % python3 -m tinytuya scan -nocolor
TinyTuya (Tuya device scanner) [1.12.7]
[Loaded devices.json - 6 devices]
Scanning on UDP ports 6666 and 6667 and 7000 for devices for 18 seconds...
Unknown v3.3 Device Product ID = keynremrcjf97twe [Valid Broadcast]:
Address = 192.168.xxx.xxx Device ID = <redacted> (len:22) Local Key = Version = 3.3 Type = default, MAC =
No Stats for 192.168.xxx.xxx: DEVICE KEY required to poll for status
Tree Product ID = keynremrcjf97twe [Valid Broadcast]:
Address = 192.168.xxx.xxx Device ID = <redacted> (len:22) Local Key = <redacted> Version = 3.3 Type = default, MAC = <redacted>
Access rejected by 192.168.xxx.xxx (check key): Unexpected Payload from Device: None
Path Lights Front Product ID = keynremrcjf97twe [Valid Broadcast]:
Address = 192.168.3.81 Device ID = <redacted>(len:22) Local Key = <redacted> Version = 3.3 Type = default, MAC = <redacted>
Access rejected by 192.168.xxx.xxx (check key): Unexpected Payload from Device: None
Path Lights Side Product ID = keynremrcjf97twe [Valid Broadcast]:
Address = 192.168.xxx.xxx Device ID = <redacted> (len:22) Local Key = <redacted> Version = 3.3 Type = default, MAC = <redacted>
Access rejected by 192.168.xxx.xxx (check key): Unexpected Payload from Device: None
Scan completed in 18.0342 seconds
Scan Complete! Found 4 devices.
Broadcasted: 4
Versions: 3.3: 4
Unknown Devices: 1
>> Saving device snapshot data to snapshot.json
And when doing a Status on the device page
Any ideas?
EDIT: Keeping the above in case others run into similar issues. Turns out that I have to renew my developers account, then run the wizard again, and then run the local scan for the updated keys.
Your "Edit:" was going to be my suggestion. I think you are correct in that you need to re-run the whole process if you change the network SSID. Without trying it myself I assume you had to re-pair the devices in the app itself. The keys you found when scanning initially after the re-pairing is actually stored locally on your PC (if i remember correctly), or tinytuya fetches the old information from tuya developer platform.
For security reasons it is a logical choice by Tuya to disable the current key if network changes, somewhat a pain for us, but logical from a security side.
Ideally one should have developed functions to pair the Tuya devices directly to Hubitat, however that requires some serious hacking, if it is at all possible without changing the firmware of the device itself.
So that basically means that I have just under 6 months to add any more Tuya networked devices to my hub and never to change SSID again. 
Tuya has made free renewal a one time thing. 
Since it's a password, yeah, I think it would be a lot of hacking if it could be done at all. I might have to see if I can sniff communications to see what is happening during the adding process.
Agreed.
GOOD NEWS! After going down the proverbial rabbit hole, I discovered that Tuya has moved the Device Management commands from IoT Core (paid with free trial) to Smart Home Basic Service, which doesn't expire. I also discovered that I was still using 1.12.x of tinytuya, and just updated to 1.16.1. Don't know if the newer version has updated the API commands. And looking at the code, I can't make heads or tails of the actual command to see if it's the old or new one.
My problem now is that my developer account is active, so I can't test if the updated tinytuya fixes the need for a developer account with IoT Core service.
Download the Hubitat app
