Protocol version 3.3 how to add this to mqtt

[andy0172]

I really like your script and used it the past year, then I do an update on my sockets damn

Now I got it working again with newest versions, but only with tuya-cli and not with mqtt anymore, due to missing command, might be you can help me getting it working again. This is my command to toogle the socket: tuya-cli set --ip '192.168.178.75' --id '68282475600194c05b0a' --key '5e72b8aeb3baa470' --dps 1 --set 'true' --protocol-version 3.3

[Fiftiz]

Hello, two solution

With IP : tuya/ver3.3/tuya-id/tuya-localkey/tuya-ip/state tuya/ver3.3/tuya-id/tuya-localkey/tuya-ip/command

or with discover : tuya/tuya-id/tuya-localkey/discover/state tuya/tuya-id/tuya-localkey/discover/command

may be you need to add : On/open value = 1 Off/closed value = 0

[tsightler]

I haven't yet merged in the support for protocol 3.3 to the primary tree so, for now, you would need to use the code here:

https://github.com/tsightler/tuya-mqtt

With that code there are two options for use devices that leverage tuya protocol 3.3, you can either change to using auto discovery, by replacing the IP address of the device with the word "discover". When using auto discovery, the tuyapi library on which this code depends can automatically detect the protocol. To use automatic IP discovery you just change the device topic to replace the IP address for the device with the word "discover", like so:

tuya/<tuya-id>/<tuya-localkey>/discover/state
tuya/<tuya-id>/<tuya-localkey>/discover/command

However, automatic IP discovery only works if the tuya devices being controlled are on the same subnet or perhaps there might be other reasons why you would want to specify the IP address. When specifying the IP address of the device, the tuyapi code defaults to protocol 3.1 unless you explicitly set the protocol. To do this, you have to set it in the tuya topic like so:

tuya/ver3.3/<tuya-id>/<tuya-localkey>/<tuya-ip>/state
tuya/ver3.3/<tuya-id>/<tuya-localkey>/<tuya-ip>/command

[pashok2398]

@tsightler Thanks, i having some issues with your PR, the switch working for the first time and i able to see the debug log, but after it changes the state looks like the api does not receives any commands and i see only

  TuyAPI Pinging 10.0.0.4 +10s
  TuyAPI Received data: 000055aa00000000000000090000000c00000000b051ab030000aa55 +64ms
  TuyAPI Parsed: +1ms
  TuyAPI { payload: false, leftover: false, commandByte: 9, sequenceN: 0 } +1ms
  TuyAPI Pong from 10.0.0.4 +1ms

[EmilSodergren]

@pashok2398 Hi, I have the exact same issue. After a full reboot the tuya-mqtt does not seem to receive status correctly. What I found is that a restart of the tuya-mqtt service AFTER issuing the first switch command seems to fix it and all consecutive commands are working.

[Fintasys]

I have the same issue. The first command is working and then it doesn't receive any commands anymore. After restarting the first command is working again. Glad I'm not alone. Anyone has an idea?

Edit: Found a fix! Disconnect all devices after running a command. https://github.com/stanicchris/tuya-mqtt/commit/5a6995bfe61747d296a94e7b044dc6174746e023#diff-77b0f2229a948021621b1c20c71cc214R355

[ben-kemister]

I was having the same problem (switches not working after first command) but I can confirm that the change stanicchris@5a6995b#diff-77b0f2229a948021621b1c20c71cc214R355 does seem to address the issue.

[tsightler]

Unfortunately, I've stopped using this integration as it's simply become too much of a pain to add new devices. I just convert everything to Tasmota. I'll still try to merge these changes in the next few weeks and attempt to at least have a working version out there.

[BigGeorgeTx]

Thanks for sharing your plans. I have a large number of Tuya devices (wall switches, wall plugs, powerstrips and bulbs). I have been using IFTTT with LIfe360 triggers, but with the pending break between Smart Life and IFTTT, I was looking for a new solution. I saw the two routes (Tasmota and your integration). Sounds like I better check out Tasmota.

[thomasdannenmuller]

Unfortunately, I've stopped using this integration as it's simply become too much of a pain to add new devices. I just convert everything to Tasmota. I'll still try to merge these changes in the next few weeks and attempt to at least have a working version out there.

Since Tuya move to Realtek chips, and then tasmosta is not an option anymore, it could be a good idea to merge you're work here ?

I have 1 switch, 2 plugs and 2 bulbs that are not ESP based anymore, and they works fine with tuya-cli. IMHO mqtt is good option for interoperability of those device with any open source home automation software.

Fetching id & key from tuya cloud is still not the ideal way to integrate local control over this devices, but at least it works and it not hacky anymore.

[tsightler]

What do you mean by "it's not hacky anymore" has there been some progress in finding better ways to get the keys? I was under the impression you still have to sign up for an account on Tuya, wait for them to approve it, then go through the process of registering via the CLI, then you only use the local control and no cloud access. Has some of this changed in some way? I haven't really followed the development lately.

I have recently purchased a few Tuya based 3-way dimmers that can't be easily converted to Tasmota so I have been considering dusting this thing off or perhaps implementing a new app that uses the Tuya Home Assistant API instead of full Cloud API since it's much easier to consume and only requires username/password. But, my big issue is time as I already have one project that I don't have enough time to maintain.

Well, and a second issue is that, reading the Tuyapi development page, it seems like it's only getting more and more difficult to support newer protocol versions.

[thomasdannenmuller]

By "it's not hacky anymore" I meant that the MITM method is deprecated, and the working approach is to bind your smart life app account to your tuya dev account (I've followed this procedure https://github.com/codetheweb/tuyapi/blob/master/docs/SETUP.md#listing-tuya-devices-from-the-app-recommended ).

With this I'm able to use both the local API and the cloud API. So as an example home-assistant integration, which use tuya cloud api, works as well as tuya-cli or Smart Life app.

What i found valuable in the tuyapi/tuya-cli/tuya-mqtt approach is that internet connection is not a consideration to have it working. Get rid of cloud services for home automation is a must IMHO.

Well, and a second issue is that, reading the Tuyapi development page, it seems like it's only getting more and more difficult to support newer protocol versions.

I'm not aware of that, could you link the relevant page here please ?

[tsightler]

As far as protocol support, see this very project https://github.com/TheAgentK/tuya-mqtt/issues/32 or the Tuyapi project https://github.com/codetheweb/tuyapi/issues/234.

I guess the above method of getting a key is at least a littler easier, but it still requires creating an account on Tuya, waiting for it to be approved, etc. Still not exactly something lots of users want to do. I've basically found myself believing the same as the Tuyapi maintainer. It's pretty difficult to want to maintain a project that you don't really use and is beyond the ability to many users. While tuyapi is still somewhat maintained, it doesn't look like it's going to be getting major updates going forward. Users will open issues not understanding the limitations of the project and of reverse engineering the protocols, etc. and there are just so many devices it's quite difficult to decide to maintain.

That being said, it's probably worth at least pulling in all the latest patches, cleaning up the docs and getting it to as stable a state as reasonably possible. I will make another attempt to find the time to do that over the next couple of weeks. And, it's an open source project, so, if you find it useful, feel free to fix it up and submit your own PRs.

[thomasdannenmuller]

I've discovered those tuya projects recently because I've stumbled on non tasmotizable devices. I have to say that browsing through all those projects I rapidly observed that the commit activity tends to decrease over time, and with the inputs you've provided I better understand that now.

It make sense since we are in a reverse engineering paradigme, and @codetheweb explain this just right.

If the effort is minimal for you to achieve a stable ver3.3, then it worth it i think too. But anyhow I won't be able to help far more than testing because I'm a complete newbee when it comes to JS...

Thanks very much for you'r feedback.

[tsightler]

Yep, it was easy in the early days because, in the initial Tuya devices, the local traffic was non-encrypted, just run a quick packet capture to get the device key and off you go. Then there were published "security exploits" exactly because this data wasn't encrypted, so Tuya had to implement encryption and we had to reverse engineer that encryption, but, at least under the covers, the protocol was basically the same and smart people than me managed to implement the encrypt/decrypt functions. But that battle just keeps getting more and more difficult.

I'd say, if you really believe that getting rid of cloud services is a must for home automation, then you should probably consider options like Z-wave and Zigbee connected devices which can be controlled locally with totally open source solutions. The wifi switches will pretty much always need a "cloud" because they need to make those devices friendly for the end user. While they advertise these as "hubless" devices, the reality is, the cloud service is the hub.

With Wifi devices, it's only the fact that some smart people were able to reverse engineer the devices that gives you the local control you/we desire and that process just gets more and more difficult. At least I have to give Tuya some credit, they've been reasonably accommodating of the market by allowing random people to sign up for developer accounts (that's pretty much unheard of in the industry) and they even made a special API endpoint for Home Assistant that is easier to consume, but it's still a lot of work to keep it all happening locally.

[tsightler]

Release v2.1.0 with protocol 3.3 support.

[thomasdannenmuller]

I've just made some initial testing, so far so good. I've tested toggling a smart switch, a smart plug, a smart led : everything worked smoothly. For the record, devices status is also instantly updated in the smart life app.

I'll do more extensive testing (colors, and DPS settings) by the end of the week i think.

As a little retribution I'll propose a merge to add a docker file with a bit of documentation if you like.

Thanks a bunch ;)

[tsightler]

There's still so much stuff I don't like in this code, it really needs a strong cleanup, honestly, not so much from the code perspective, but from a usability perspective, but I thought at least merging two years worth of changes was worth a shot. I only have a single dimmer to use it with the code these days, but it seems to work well enough for me.

That being said, I'm going to try next week to spend some time and build a 3.0 version of this project with the goal to simplify the use of this tool as much as possible, implement a "devices" file that holds the devices instead of requiring a topic, simplify the JSON state manipulation, etc. I'll also get rid of the key and IP and all of that from the topic, instead using the friendly name or id of the device only. The goal will be to make it as easy to consume for a user as possible given the current state of TuyAPI. It will of course be a breaking release, but I think that's OK if it is far easier to integrate with other home automation platforms going forward. Once that's built and seems to be working, I'll build a Dockerfile and some instructions.