It’s not possible to change the polling interval, no. But hopefully soon we will switch to use a persistent connection (and asyncio implementation of the underlying library) which removes the need for polling and gives us push updates instead.
Hi,
thanks for the reply.
If I remember, when I tried to use nodered to monitor the sockets, the change of status and attributes took place in real time, I don’t know if this had already been mentioned.
I’ve never used nodered, so I have no idea how that works. Does nodered have an implementation for the local tuya protocol? This component uses polling (opening and closing the connection at every poll) at least. But will be changed soon as mentioned earlier.
Hello,
I don’t use NodeRed either, I used it to try to monitor Teckin sockets, before the arrival of @rospogrigio in this topic, because localtuya was not compatible with my sockets!
I bring you the link with the information they had provided me to configure NodeRed, I don’t know if it can be good as a starting point:
However, localtuya already works perfectly well.
Mine was just curiosity 
Trying to setup tuyalocal and I did until I wanna add the plug to the list.
I got tuya local to search the device and got the id/key inputed on integrations. However I got error
Logger: custom_components.localtuya.config_flow
Source: custom_components/localtuya/pytuya/__init__.py:224
Integration: LocalTuya (documentation)
First occurred: 6:13:02 PM (1 occurrences)
Last logged: 6:13:02 PM
Unexpected exception
Traceback (most recent call last):
File "/config/custom_components/localtuya/config_flow.py", line 235, in async_step_basic_info
self.dps_strings = await validate_input(self.hass, user_input)
File "/config/custom_components/localtuya/config_flow.py", line 171, in validate_input
detected_dps = await hass.async_add_executor_job(
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 271, in detect_available_dps
data = self.status()
File "/config/custom_components/localtuya/pytuya/__init__.py", line 244, in status
return self.exchange(STATUS)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 239, in exchange
return self.exchange(command, dps)
File "/config/custom_components/localtuya/pytuya/__init__.py", line 224, in exchange
data = s.recv(1024)
socket.timeout: timed out
Help
Hi Carlo, Hi @postlund,
I tried to integrate a Tuya light bulb with the following code, but it can’t manage the status:
localtuya:
- host: 192.168.x.x
device_id: myID
local_key: myKey
friendly_name: LampadarioStudioLocalTuya
protocol_version: “3.3”
entities:- platform: light
friendly_name: LampadarioStudioLocalTuya
id: 4
- platform: light
This error reported:
Logger: custom_components.localtuya.common
Source: custom_components / localtuya / common.py: 255
Integration: LocalTuya integration (documentation)
First appearance: 6:08:15 PM (30 occurrences)
Last access: 18:13:11
The light.lampadariostudiolocaltuya entity requires an unknown DPS index 4
The light.lampadariostudiolocaltuya entity requires an unknown DPS index 3
This error is generated when I try to turn the light on or off through the button in the home assistant:
Logger: custom_components.localtuya.common
Source: custom_components/localtuya/common.py:157
Integration: LocalTuya integration (documentation)
First occurred: 18:10:23 (6 occurrences)
Last logged: 18:15:09
Failed to set status of device 192.168.x.x
PS:
Can the friendly_name be invented for the custom component local tuya (LampadarioStudioLocalTuya) or does it have to refer to the device name on the tuya app (Lampadario Studio)?
You are probably using the wrong DP. Try adding via config flow (Integrations) as it will provide a list of all DPS and their value. You should find one with a boolean value (True/False). When adding via config flow you can always edit via Options for the integration, so you don’t have to remove and add again. Changes made via options are reflected immediately.
I’m not sure what you mean regarding friendly name? You can specify anything you want, but we don’t have access to any of the names you have in the app as that is stored in the cloud (which we don’t talk to).
Thank you!
I made the configuration via flow and the ID reported as true was 20.
I entered that value and now the bulb can be managed via localtuya! Yeah 
The other values that have been reported are the following:
20 (value: True)
21 (value: white)
22 (value: 460)
23 (value: 293)
24 (value: 000000000320)
25 (value: 000e0d0000000000000000c80000)
26 (value: 0)
Is it not possible to set the brightness via the slider and manage the colors of the RGB bulbs?
Cool 
Brightess and color temperature are supported, provided you find which DPS to use. RGB is not supported yet but being worked on to some extent. Neither I nor @rospogrigio own any light bulbs, so the light platform is not very well tested. There might be bugs.
Edit: I would suspect that 22 and 23 are brightness and color temperature, but I’m not sure which is which.
How do I add other IDs to the bulb inserted via flow?
I’m available as a beta tester for bulbs
1 Like
Ah, the PR adding those fields have not been merged. I will rebase and try to have it ready for merging. After that you will be able to pick DP for brightness and color temperature in the config flow.
From yaml, it could be configured like this:
host: 192.168.x.x
device_id: myID
local_key: myKey
friendly_name: LampadarioStudioLocalTuya
protocol_version: “3.3”
entities:
- platform: light
friendly_name: LampadarioStudioLocalTuya
id: 20
- platform: light
friendly_name: LampadarioStudioLocalTuya
id: 22
- platform: light
friendly_name: LampadarioStudioLocalTuya
id: 23That would mean that you add three different lights (within the same physical device), all with the same same. It will work like this:
host: 192.168.x.x
device_id: myID
local_key: myKey
friendly_name: LampadarioStudioLocalTuya
protocol_version: “3.3”
entities:
- platform: light
friendly_name: LampadarioStudioLocalTuya
id: 20
brightness: 22
color_temp: 23
This PR adds support for brightness and color temp, if you are up for testing that:
Niceeee work…mine simple 2 gang switch works and is stable
I have to edit the common.py, light.py and en.json files and then insert in the .yaml file
brightness: 22
color_temp: 23
In some way you need to do that, yes. You can use whichever way you feel comfortable with, but make sure all changes are copied over so you don’t end up in some intermediary state.
Hi,
I installed the localtuya-homeassistant-light_dps version and I can confirm that the slider for the light intensity and the color temperature work! Great
In my case I can’t reach the maximum brightness of the bulb and the minimum level slider stays a little higher and can’t turn off the bulb.
I had the same problem with TuyaCustom. You can see how they solved the problem in this post, I don’t know if the same change can be made in the localtuya light.py: https://github.com/ollo69/ha_tuya_custom/issues/6#issuecomment-653592857
I tried to set 100% of the brightness and 52% of the color temperature from the smartlife app. This is the result obtained in Home Assistant:
brightness: 255
color_temp: -75
friendly_name: LampadarioStudioLocalTuya
supported_features: 3
brightness: 1000
color_temp: 95
tuya_device_id: mydeviceID
friendly_name: Lampadario Studio
supported_features: 19
Practically the brightness scale of my bulb reaches 1000 instead the range in LocalTuya is 25 - 255
Another problem, if I command the light bulb from the smartlife app, it conflicts with HA and the light bulb in localtuya is no longer manageable and is “unavailable” and you have to restart Home Assistant.
Thanks
Great, then then we know that it works at least! Once @rospogrigiohas reviewed we can merge that part. But we will have to take a look at brightness. I’m not entirely sure how it’s supposed to work, but the thread you posted might help. I’ll have a look at some point unless someone beats me to it.
All tuya hardware has a “physical” limit of one TCP connection. In practice this means, only one app can talk to any device at any given time. At this point we open and close the connection every time we do something (fetch status or update a DP). With the upcoming changes, we will keep a persistent connection at all times, to leverage instant updates for instants. This means that you will have to pick: either use this integration with Home Assistant or the app. But you will not be able to use both.
A clarification is in place: you can use the all, but not when you are on the same network as your devices. That’s when the app uses the same access point that we do, which only supports one connection at the time.