Well the issue here is that not all your devices on cloud are within the same network so that doesn’t count as locally discovered devices.
Yes
If the devices are discovered then it will save you a ton of time on setup e.g. “configuring all discovered devices at once if possible” however your hub is empty of devices you will need to configure them manually ← at least filling device connection info.
Got it, thank you. I thought the cloudAPI would bypass the VLAN requirement and that was the source of my trouble!
I started the manual configuration and eventually got all the devices entered.
There was an odd bug? with a couple of switches, where they initially refused to connect and be registered. After querying the device, it returned with an error, but the entry form “Device Name” had a different name than the one I had originally typed. I eventually figured out that if I submitted immediately without changing anything, the entry would be accepted.
If I tried changing anything on the entry form the first time it returned with the error, such as the name back to what I wanted, it would never be accepted and I would have to exit out to restart the process.
Regardless, thank you so much again for maintaining this fork!
This isn’t a bug, This is a feature I added before to automatically help/fix input mistakes for users with devices on different subnets or so. Basically, if you enter the device ID correctly, the rest of the fields will be filled automatically from the cloud list, except for IP and Protocol version
That’s very cool and a great demo. Wish I had known about it as it may have saved me some time! Is it in the tutorial documentation?
@umu_ugg
I’ve got an oddball device with a seemingly undocumented DPID of 101. From the Tuya API explorer:
{
"code": "m0",
"custom_name": "",
"dp_id": 101,
"time": 1733103333231,
"type": "string",
"value": "00000301ff06ff0000ffff0000ff0000ffff0000ffff00ff"
},
It’s a string of Christmas lights (specifically “Brizled/Brizlabs Smart RGB String Lights”). This particular endpoint encodes the lighting pattern of the lights, where when work_mode is scene, the pattern, color selections, speed, and direction (forward/reverse) are all encoded into the value. It’s all pretty straightforward, I’m just not sure how I would go about adding all that into integration. I could open an issue in Github and we could hash it out there?
Nope, If were in docs then it would goes under TIPS which it not an existed category atm.
You could add it as custom scenes, configure -> reconfigure an existing device -> choose your light on the Light entity configuration step in “custom scenes” box add your scenes e.g.
00000301ff06ff0000ffff0000ff0000ffff0000ffff00ff: Name of the scene
000e0d0000000000000000c80000: Night
and so on, this way it will replace the default scenes by the one you inserted.
Has anyone had any luck with RF Remote transmitters? I have a couple of IR+RF remote controllers added to my LocalTuya integration, and I have successfully learned and use IR commands - but RF commands don’t seem to get “learned” correctly. I can learn them in the Tuya app, but that doesn’t help me use them in LocalTuya.
Is there any way to see what commands (if any) are being received by the Home Assistant “Learn Command” action?
I have had the same experience. I have two different Tuya branded IR/RF transmitters. IR learns and sends correctly, RF won’t learn. There was (or maybe still is) a branch with slightly different RF learn code, makes no difference tho. I sent my logs to the dev and he said he still couldn’t figure it out, and I guess he doesn’t have one of those devices to test himself. I’d love to make my RF devices local and no longer have to use the Tuya scenes hack. These are my only remaining Tuya devices where I still have to use the built-in Tuya integration.