Local tuya light bulb protocol version 3.3

Oh yeah, I’d recently changed that to see what happens. Anyway I still get some error, maybe a different one. Here’s what I get when I set the IP.

Boolean status of default property: false.
on
Connected to device!
Error! Error: Error from socket
    at Socket.client.on.err (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:323:30)
    at Socket.emit (events.js:197:13)
    at emitErrorNT (internal/streams/destroy.js:82:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
Disconnected from device.
Connected to device!
Error! Error: Error from socket
    at Socket.client.on.err (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:323:30)
    at Socket.emit (events.js:197:13)
    at emitErrorNT (internal/streams/destroy.js:82:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
Disconnected from device.
Connected to device!
Error! Error: Error from socket
    at Socket.client.on.err (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:323:30)
    at Socket.emit (events.js:197:13)
    at emitErrorNT (internal/streams/destroy.js:82:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
Disconnected from device.

That message points to the wrong protocol being used. Did you try setting it to 3.3?

Having changed to version 3.3, I get this:

Connected to device!
(node:82218) UnhandledPromiseRejectionWarning: Error: connection timed out
    at Socket.client.setTimeout (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:292:18)
    at Object.onceWrapper (events.js:285:13)
    at Socket.emit (events.js:197:13)
    at Socket._onTimeout (net.js:447:8)
    at listOnTimeout (timers.js:327:15)
    at processTimers (timers.js:271:5)
(node:82218) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:82218) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Disconnected from device.
Data from device: data format error
/Users/Mudi/Programming/MyCode/IOT/Home Assistant/syska.js:35
        console.log(`Boolean status of default property: ${data.dps['1']}.`);
                                                                   ^

TypeError: Cannot read property '1' of undefined
    at TuyaDevice.device.on.data (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/syska.js:35:68)
    at TuyaDevice.emit (events.js:197:13)
    at TuyaDevice._packetHandler (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:414:10)
    at packets.forEach.packet (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:315:43)
    at Array.forEach (<anonymous>)
    at Socket.client.on.data (/Users/Mudi/Programming/MyCode/IOT/Home Assistant/node_modules/tuyapi/index.js:311:19)
    at Socket.emit (events.js:197:13)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)
    at Socket.Readable.push (_stream_readable.js:224:10)

Since I was able to pull the status of the device at least when I put version 3.2, I figured I don’t have 3.3.

With 3.3, even node filename.js status does not work.

While looking at the pytuya docs I found this:

data = d.status() # NOTE this does NOT require a valid key

You may have a 3.2 version and the wrong local key. How did you get that value? If you add / remove the bulb from the app the key is regenerated.

Very interesting. You might be right! Thanks for the find and the info! I definitely have removed the devices from the app at least once and reconnected when they are flashing…

I’ll try with the new local key after fetching it…

Oh I really thought it was gonna work this time!

The local key has indeed changed. Tried with versions 3.2 and 3.3. But no luck. Same 2 errors as before unfortunately. Not changing the state of the switch… Tuya sucks.

Ok, so I finally managed to get everything working. That includes Tuya-api, python-tuya and most importantly - your custom component tuya_local that uses python-tuya inside Home Assistant.

Since I had 2 devices, I was getting confused with all the numbers and whom they belong. The last error was caused by me having assigned the wrong IP addresses respectively for both devices :exploding_head:

It’s good, i’m slowly getting used to HA. Now I’ve 2 basic devices up and running, I’ll try setting up a very floorplan.

And after that, modify the custom component to control color and brightness of bulb.

Thanks a lot for all the help!

Working well here!

Though I have a Tuya Light Switch with 3 switches, anyidea how to make that work? ATM It just controls the first switch.

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.