Local tuya light bulb protocol version 3.3

Try using this:

I’m using this with wall plugs but seems to have support for multiple switches

1 Like

Worked it out!

Is it a know issue that the entity status update is slow?

I’m using this mostly for power monitoring so didn’t pay much attention to this.
For me almost the only problem is that I cut those sockets from Internet I can’t read values (like some initialization is missing).
This and slowness is probably more related to pytuya then localtuya-homeassistant.

Ive created this nodered plugin to work with tuyapi using protocol 3.3. Is very basic and is based on the tuyapi asynchronous example. I have only tested with 3.3 devices

1 Like

Hi Bob - could you resolve the “Data must be aligned to block boundary in ECB mode” problem? I also get it using your code, on linux. Switches successfully switch on and off using the 3.3 protocol, but status updates are slow and in the log the above error appears. I had raised the issue at https://github.com/clach04/python-tuya.

It’s now possible to flash again with https://github.com/kueblc/tuya-convert/tree/new-api and https://github.com/M4dmartig4n/tuya-convert.

Is there any local solution that supports color changing?

great job for the nodered plugin.

i was having the same issue and made the exact same step as you did (trying the api, doing manual dirty script then thunk about nodered or hass plugin).

i have 2 tuya dehumidifier and since they are brand “smart_life” the hass plugin wont work anymore (and i dont like going through this server maintain by god know who…to then use the tuya cloud)

this local api is awesome and work great.
i will give a shot for your nodered nodes but i will be using hass API instead of MQTT for sensor update & Co

great job, i will keep you in touch if it work, you may think about publishing it no ? it would save some people many hours of research i think :wink:

I haven’t done anything lately i have only one tuya device left (and is not in production). The other two i flash them with esphome. Since tuya convert released a method for bypassing the OTA restriction introduced a few months i don’t think i will publish, unless i acquire mode devices in the future and a new restriction is introduced

thanks for your reply,

i’m kinda scared about trying to flash them because I found the flasher https://github.com/ct-Open-Source/tuya-convert and the firmware i guess : https://github.com/arendst/Tasmota/wiki/Tuya-OTA but when i look into the compatibility list, i cant find my device and after some reading, i didnt find a revert to original firmware step …

You are talking about ESPhome but how did you know how the ESP inside is wire to control it ? Or am i missing something ?

my devices are deshumidifiers smart life.

anyway thanks for the work and your help :slight_smile:
depending on your reply i will try your nodered node or i might give it a try for flashing but only if i find a sure way to revert in case of trouble

I would start looking information at tasmota. I found the pin mappings for my device from tasmota and other Internet forums.
If the device is not esp then firmware flashing would not work.

The flashing process leaves the device with low size basic tasmota fw. From there you can upload a full size tasmota or esphome via web.

Hi, another user kinda new to HA so seeking a little guidance.

I have some Brilliant Downlights which are using API 3.3. I’m also controlling them via the cloud with voice assistants, not ready to flash them just yet but would still like to make use of localtuya in HA as well.

I’ve managed to get them working (I’m using this fork) by changing the index IDs to:

DPS_INDEX_ON         = '20'
DPS_INDEX_MODE       = '21'
DPS_INDEX_BRIGHTNESS = '22'
DPS_INDEX_COLOURTEMP = '23'
DPS_INDEX_COLOUR     = '26'

which these lights are using instead of 1-6.

The last problem I’m having is they seem use a brightness scale of 10 - 1000 instead of 25 - 255 and colour temp is set from 0 to 1000.

When I use the sliders of the component, I can only set a maximum brightness of 255 and a colour temp up to 255.

I’ve changed everything I could find relating to it in the scripts, so I’m guessing I’m left with HA storing these values in a scale of 0-255 and I will have to add some extra conversion in the scripts to scale them up to the 1000 range?

Am I on the right track?
Thanks

(Edit: Found this one which is already modified for the 1000 range)

@bamzero Hello.

What it looks like in your configuration.yaml

I have a dimmer, but it works just like a switch. Thanks.

Nothing special, just like the example

light:
  - platform: localtuya
    host: 10.0.0.1
    local_key: 1234567891234567
    device_id: 12345678912345671234
    name: tuya01

Sounds like you may have it as a switch: ?
If so try light: (if you are using a different component and it doesn’t work try either of the two I linked.)

I have several 1-, 2-, 3-channel switches, relays, and smart plugs (with a measurement of power consumption). I also have several dimmers, such as:

I also use this custom component. But in it, my dimmers only work as switches: ON and OFF. Without adjusting the brightness level.

And the author of this component wrote to me:

As a dimmer, this component does not know how to work - only as a switch.

Does this component work as a dimmer for you?

Hello.

I am try light:

light:
  - platform: localtuya
    host: 192.168.1.91
    local_key: 33054eabd5292214
    device_id: 83054170840d8e91adcb
    name: dimmer_01
    protocol_version: 3.1

use this custom component.

The dimmer appeared in the HA interface,

but it does not work. In logs:

Update for light.dimmer_01 fails
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 281, in async_update_ha_state
    await self.async_device_update()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 461, in async_device_update
    await self.hass.async_add_executor_job(self.update)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/localtuya/light.py", line 223, in update
    brightness = int(self._device.brightness())
  File "/config/custom_components/localtuya/light.py", line 140, in brightness
    return self._device.brightness()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 560, in brightness
    return self.status()[self.DPS][self.DPS_INDEX_BRIGHTNESS]
KeyError: '3'

What does this Error mean and what am I doing wrong? Thanks.

P.S. The dimmer has only state and brightness:

dpName: {}, dps: {1: true, 2: 255}

2 - is the brightness.

Normally 1 is on/off state, 2 is colourmode and 3 is brightness.

You will have to edit your init.py in pytuya for your DPS_INDEX values.

Try changing value for DPS_INDEX_BRIGHTNESS = ‘3’ to ‘2’
and DPS_INDEX_MODE = ‘2’ to ‘3’

(You may need to change the DPS_2_STATE values below it to match also)

Has anyone had anyone had luck getting RGB lights to work?
This repository link seems to attempt it but it is not working and it seems that the previous contributors are not maintaining it anymore.
I got the closest with the code from @Alfiegerner but have not be able to get it going. I’m not a coder so it might just be syntax or something.
I’m trying to avoid flashing my devices at this stage as I need to keep them in a working state until I get more devices.

what is the different between regular tuya and this one? Should I run both or just choose one?

localtuya means your HA is talking direct to the device (bulb etc).

WIth the normal integration:
Tuya HA --> talks to Tuya Cloud Server --> TuyaServers talk to Bulb

Local Tuya :
HA --> Bulb

so your automations are not dependant on cloud anymore