Step-by-Step guide for adding Tuya-bulbs, Wi-Fi smart LED (Smart Life app) to OH2 using tuya-mqtt.js by AgentK

Hello community,

I spent the last few days searching through the forum to get some Tuya-Bulbs (they usually sell as “Smart life”) working in OH2.

I noticed that it is hard for a beginner to get this done, because all information is spreaded in different threads and postings, so I decided to put it all together in a step-by-step walk through here.

I also found a rather elegant way to get the essential Tuya parameters (Tuya ID and LocalKey) which I also want to share here.

Furthermore, I found out the Tuya-MQTT-Binding from AgentK to be reliable and fast, so I used it.

Let’s start:

Prerequisites:

  • OH2 up and running, accessible by ssh or console
  • One or more LED-Bulbs configured in the Smart-Life app (should be controllable by the Smart Life app)
  • Basic OH2-Knowledge (add Bindings, find config-files and edit them)
  • Installed node.js

We start with installing Mosquitto. Do so by opening

sudo openhabian-config 

and choose “Optional components”. Choose Mosquitto from there and install with default settings.
Important: During installation, you are asked for a user, accept default (openhab) and leave password blank!

Next, install MQTT-Binding using Paper-UI.

After installation, open services/mqtt.cfg and uncomment/fill the following paramaters:

broker.url=tcp://localhost:1883
broker.clientId=openhab
broker.user=openhab

Everything else is left untouched. Save mqtt.cfg and exit.

Next, install the Tuya-MQTT-Client from AgentK. Use the instructions given in the README.md

Start the script is running with

/usr/bin/node /etc/openhab2/scripts/tuyaapi_mqtt/tuya-mqtt.js

Now we move over the the most complex, but also interesting part. To control Tuya-Devices, we need to know their IP, DeviceID and LocalKey. First two are easy, but the key needs some tricks. But let’s do it step by step.

To find out the DeviceID of a Tuya-bulb, open the Smart Life app. Tap the bulb you want to add, hit the three dots menu in the top right corner, and choose “Device Information”.
You will find a Virtual ID, note it down. This is the DeviceID of the bulb. Mine for example is 12204702807d3a252d43. Also note the MAC-Adress, we need in the next step.

Next, we need the IP of the bulb. But be careful, we need the internal IP of the bulb in your network, the app shows the external IP of your router. To find the internal IP, note the MAC adress. In my case:

 80:7d:3a:25:2d:43

Then, issue a

arp -a 

on your console. You will get a list with IPs and MAC-Adresses, find the MAC of your bulb and note the correspondig IP. In my case:

ESP-252D43.fritz.box (192.168.75.119) at 80:7d:3a:25:2d:43 [ether] on eth0

Note the IP-Adress.

Now comes the difficult part, getting the Tuya LocalKey. There are a lot of methods around using MITM-attacks and Proxies, but I found a “easier” way.

The Smart Life app stores the LocalKey in a XML-File on your phone/tablet. Usually you can’t access it until the phone is rooted. But don’t worry, no need to root your phone, there is a easier way.

We will install a Android emulator, root it, install the Smart Life app and extract the keys. To do so, go to

https://bstweaker.tk/

and download the latest BlueStacks Tweaker (Link is on top of the page) and Bluestacks installation (down below) according to your OS (32/64Bit).
Also go town to “utils” and download SuperSu 2.82-SR5.apk and Root Checker Pro 1.6.2.apk.

Then install Bluestacks, and after installation, follow the first instructional video on the page to root Bluestacks.

With rooted Bluestacks, go to Play Store and Download “Smart Life” app. Make sure to run it once, login and access your bulbs once!
This is essential because only when doing so, it will get the configuration to our Bluestacks rooted phone!

Next, install “ES File Explorer” from Google Play store.
Set ES File Explorer to “Root Mode” (Scroll down left to find “Root Explorer”)

a warning will popup if root sholud be granted, grant it.

2018-12-10%2012_13_49-BlueStacks

Now on the right, navigate to

/data/data/com.tuya.smartlife/shared_prefs

You end up in a folder with some XML-files, this is where we want to go.

Find the file called

preferences_global_key_<some chars and numbers>.xml 

and click it. ES File Explorer will open it. On the first look, this file looks weird, but you will find the ID of your bulb there, and next to it… the desired local key!

Note it down carefully (in my example: 0399de7c4a27915b), and if necessary repeat the procedure with other bulbs you have.

Close Bluestacks and continue in Openhab.

With the knowledge of IP, ID and Key of our bulb, we set up an item. The order of Tuya-Information we need to pass to the MQTT is:

tuya/lightbulb/<tuyaAPI-id>/<tuyaAPI-key>/<tuyaAPI-ip>

For my example

<tuyaAPI-id> 12204702807d3a252d43
<tuyaAPI-key> 0399de7c4a27915b
<tuyaAPI-ip> 192.168.75.119

So the complete item looks like:

Switch tuya_test1 "LED2" <light>   {mqtt="<[broker:tuya/lightbulb/12204702807d3a252d43/0399de7c4a27915b/192.168.75.119/state:state:default:.*], >[broker:tuya/lightbulb/12204702807d3a252d43/0399de7c4a27915b/192.168.75.119/command/on:command:ON:true], >[broker:tuya/lightbulb/12204702807d3a252d43/0399de7c4a27915b/192.168.75.119/command/off:command:OFF:false]"}

Now add the item to your sitemap:

Switch item=tuya_test1

…and enjoy switching the Tuya-bulb in OH2.

Some remarks:

As you noticed above, we started the tuya-mqtt.js by hand in console. As I wanted it to start in the backround at reboot, I added it to /etc/rc.local before “exit 0”:

...

 /usr/bin/node /etc/openhab2/scripts/tuyaapi_mqtt/tuya-mqtt.js < /dev/null &

exit 0

If someone has a more elegant way, please let me know.

Another remark: The tuya-mqtt.js script stops working if a Tuya-Device is for example physically removed and needs to be restarted. Because of this, I added it as a service to systemd like this:

cd /lib/systemd/system/
sudo nano tuyaapi-mqtt.service

Content:

#!/bin/sh -
[Unit]
Description=tuyaapi-mqtt

[Service]
ExecStart=/usr/bin/node /etc/openhab2/scripts/tuyaapi_mqtt/tuya-mqtt.js
Restart=always
User=openhabian
Group=openhabian
Environment=PATH=/usr/bin/
Environment=NODE_ENV=production
WorkingDirectory=/usr/bin/

[Install]
WantedBy=multi-user.target
Alias=tuyaapi-mqtt.service

Issue the following commands:

sudo chmod 644 /lib/systemd/system/tuyaapi-mqtt.service
sudo systemctl daemon-reload
sudo systemctl enable tuyaapi-mqtt.service
sudo systemctl start tuyaapi-mqtt.service

This runs the script as a service at reboot and startup, and automatically restarts the script if it fails for whatever reason.

With this solution, I realised a fast responding and reliable Tuya-Switching. And because the tuya-mqtt.js reports the state back to OH2, the corresponding switch always shows the actual state of the lamp, even if you switch it outside of OH2 (e.g. using Smart Life app or Alexa).

Thanks a lot to AgentK for developing the script and the support! Also to @tsightler for the update of the script to work with the new MQTT-Binding.

Update for MQTT-Binding 2.4

Since the initial version of this guide, Openhab 2.4 was launched and brought us a new binding for MQTT. In the following steps I want to show how to migrate to the Openhab 2.4 MQTT binding.

First of all, let’s get rid of Mosquitto (if already installed), there is a embedded MQTT broker in Openhab 2.4 which we will use. Issue the following command:

sudo apt-get remove mosquitto

Next, get the latest version of AgentK’s tuyapi-mqtt-script. I would suggest to completely remove the directory:

cd /etc/openhab2/scripts
rm -rf tuyaapi_mqtt

Get the new version of the script:

cd /etc/openhab2/scripts
git clone git@github.com:TheAgentK/tuyaapi_mqtt.git
cd tuyaapi_mqtt
npm install 

Create your configuration file:

cp config.json.sample config.json
nano config.json // edit the configuration file only if not using default configuration of MQTT broker

Start command

node tuya-mqtt.js

// For debugging purpose
DEBUG=* tuya-mqtt.js

Alternatively use the hints above to make the script auto-starting at system start.

Next, go to Paper UI (Addons -> Bindings). Uninstall the legacy 1.x Binding and install the new binding.

Now we need the embedded MQTT broker. To do so, go to Addons -> Misc and select “Embedded MQTT Broker”. For our basic setup, the broker needs no further configuration.The embedded Broker should also appear in your “Things”-List.

Yes I know, it seems endless, but we are almost done :wink: Next we need a MQTT bridge which connects our MQTT-things to the broker. Go to Inbox, select “+” to add a thing, choose MQTT-Binding and “add manually”. We need the “MQTT Broker”. Enter “127.0.0.1” as IP-Adress. That’S all and save.

Now, again we to Inbox, select “+” to add a thing, choose MQTT-Binding, and this time the “Generic MQTT Thing”. And while we add it, we select the MQTT-Bridge we have created in the step before:

Then we go back to “Things” and find our “Generic MQTT-Thing” in the list. We click it, and with “+” we add a channel of type "On/off Switch:

Populate the “State Topic” and “Command Topic” with the follwing pattern:

tuya/<tuyaAPI-type>/<tuyaAPI-id>/<tuyaAPI-key>/<tuyaAPI-ip>/state	
tuya/<tuyaAPI-type>/<tuyaAPI-id>/<tuyaAPI-key>/<tuyaAPI-ip>/command

Be careful when choosing the channelID cause it can not be changed later, I used “tuyabulb01” for example, and “Tuya LED 1” as Label. It is very helpful to identify the lamps later in the UI:

And finally… link the new channels to your items. You can group items to switch single bulbs at once, I did so for my sleeping room:

Group:Switch:OR(ON, OFF)   group_OG_Schlafzimmer_Licht   		"Licht Schlafzimmer"  			<light>				(ogLight)
Switch tuya_OG_Schlafzimmer1   <light> (group_OG_Schlafzimmer_Licht)  {channel="mqtt:topic:60f6993b:tuyabulb01"}
Switch tuya_OG_Schlafzimmer2   <light> (group_OG_Schlafzimmer_Licht)  {channel="mqtt:topic:60f6993b:tuyabulb02"}
Switch tuya_OG_Schlafzimmer3   <light> (group_OG_Schlafzimmer_Licht)  {channel="mqtt:topic:60f6993b:tuyabulb03"}

Tataaa, you are done!

Just in case we restart OH2:

sudo systemctl restart openhab2.service

And after restart, you should be able to control your Tuya-LEDs in OH2 with the new MQTT Binding. Enjoy!

17 Likes

Hello,
great step-by-step guide and thanks for using my MQTT client project.

I use the NPM package “forever” to start the script. Forever takes over the role of the CronTab and your script to check if it is still running. (https://www.npmjs.com/package/forever).

But I will check the error and try to fix it.

Maybe this is more elegant :wink:

Best regards
AgentK

2 Likes

Thanks a lot for this hint, I will give it a try and replace my script-based solution with “Forever”.

Kind regars,

Holgi

Great guide for a beginner like me, but when I follow the instructions from AgentK (I am working with Putty) I get an error saying “Permission denied (publickey)”.
As I am not really good in working with Linux and have no experience with GitHub is there any other way to install the tuyaapi_mqtt or can someone explain to me how to avoid this error?

My second problem: After installing the MQTT Binding I do not have any mqtt.cfg in the services directory, can I just save your code as a new file there?

Thanks a lot.
nephrotranz

1 Like

Hi, the “permission denied” occurs when you try to clone the files from github, right?

What you have to do is: Use ssh-keygen (or puttygen) to create a public/private key pair, put them in openhabian’s .ssh folder. Then, go to your Githup-Profile, settings, and store public key there. Then you can clone the project.

The mqtt.cfg should be there after installing the binding. Did you install Binding or Action?

Thanks for your help.

I installed and re-installed the binding several times yesterday, but no cfg-file.
Is it possible that the binding is working different in OH 2.4? I updated yesterday.

Regards
nephrotranz

Oh yes, the bindings work differently!

The guide refers to the OH 1.1 Binding of OH 2.3, I still did not figure out how to use the new 2.4 Binding.

To follow the guide, go to Paper UI -> Configuration -> System and enable Legacy 1.x Bindings in Add-on Management. Then you can install the MQTT 1.x Binding and continue like in the guide.

As soon I managed to figure out how to migrate to 2.4 Binding, I will update the guide.

1 Like

I’m completely new to OpenHAB but managed to get this working using the instructions above and just wanted to say thanks for posting this. I admittedly used the 1.x binding even with 2.4 because I had no luck trying the new binding method, but that’s likely to be due to my current poor understanding of the OpenHAB 2.4 MQTT bindings, and the 2.x binding in general. I plan to give it another try soon but, for now, using legacy bindings was easy enough and seems to work fast and reliable.

I was able to create rules to trigger based on state changes in near real time which was exactly my goal. Now I no longer need to use the unreliable and slow IFTTT integration for these switches and I’ve learned enough about OpenHAB to pique my interest in trying other things with it. I really appreciate the efforts of the community to support this and share. If I manage to figure out the 2.4 bindings I’ll post here.

Hi @HolgiHab

Thanks for the great tutorial.:+1:

Is it possible to use this with a different user name and a password? I ask b/c I already have my mqtt setup and really don’t want to change all the other connected devices.

Thanks

1 Like

I spent some time trying to get the 2.4 binding working and, for the most part, simply following the generic instructions works fine, however, the toggle on/off is a problem since it seems that the new 2.4 bindings expect a single MQTT topic for all commands while these switches use separate topics as above:

tuya/socket////command/on
tuya/socket////command/off

I saw in another thread the suggestion to create two channels and attach it to the same item. This seemed like it would work, I was able to see the switch status when the switch was toggled either via OpenHAB or external, however, the actual result of attempting to toggle the switch via OpenHAB seemed to be totally random.

It appeared to me that both channels acted on the command so you just ended up with whichever state happened to be the last one sent making it appear completely random. Perhaps there’s some method to do this that I don’t understand.

I did formulate an ugly workaround by creating a read-only (status topic only) generic MQTT thing and created a rule which triggers on received command and sends the on/off topic using publishMQTT. This seems to work just fine, but there’s probably a better/more correct way that is just not obvious to me. Regardless, here’s the basic rule I use:

rule "Toggle Tuya light/switch on/off via MQTT"
    when
        Item tuya_light received command
    then
        switch(receivedCommand) {
            case ON : actions.publishMQTT("tuya/<tuyaAPI-type>/<tuyaAPI-id>/<tuyaAPI-key>/<tuyaAPI-ip>/command/on","")
            case OFF : actions.publishMQTT("tuya/<tuyaAPI-type>/<tuyaAPI-id>/<tuyaAPI-key>/<tuyaAPI-ip>/command/off","")
}
end

Hey Tom,

thanks a lot for this rule, can you also post the definition of the status topic MQTT thing?

Regards,

Holgi

I was actually able to write a small patch to the tuya-mqtt library which AgentK has merged into his tree. If you are using the existing bindings it does not change current behavior, however, it now allows for sending to the command topic directly and acting on the message payload vs having to publish two different topics. This works perfectly with the OpenHAB 2.4 MQTT bindings, you simply set the topics as follows (using values from the examples in the original post):

State Topic:  
tuya/lightbulb/12204702807d3a252d43/0399de7c4a27915b/192.168.75.119/state

Command Topic:
tuya/lightbulb/12204702807d3a252d43/0399de7c4a27915b/192.168.75.119/command

Do this and your Tuya swtiches and lights should work perfectly with OH 2.4 MQTT binding, no rules required or any special configs required.

It looks like the bulbs are also sold under the name “Arilux”
See:

Could you update your post to include this brand name?

@vzorglub

I added “Arilux” to the tags, I will search for more brand names and add them, there are just too many to include them all in the title. Mine were sold as “Avatar”.

1 Like

Silly question, but these bulb connect to wifi direct? No bridge?
I am looking for a lighting solution BUT I already have too many devices on wifi and I don’t want to add another 25 or so. I can’t afford a router able to handle that

Yes, they connect directly to Wifi. The “bridge” itself is a cloud/server-based solution, called Smart Life. You set up account there, load app on your phone and ready to go. With the tuyapi wrapper/mqtt bridge you can control them locally, after finding the ID and Key like I described in the original post.

This is why I like this solution so much, cause once you have them “locally” in OH2, you can “cut” the connection to the server/cloud, it is only needed for initial setup then.

Setting up the prerequisites to find out the local key is actually the hardest work, but once you figured this out, you can easily add new lamps. I started with two lamps, took me one hour to get the key. Then with the third one, it took only 5 minutes.

But you are right, your Wifi/router gets more and more load as you add more devices… on the other hand, they are much cheaper than e.g. Z-Wave. Especially the Wifi-Plugs are very cheap.

1 Like

Hi Holig,

Thanks for updating your guide with instructions for 2.4. One question I was wondering about as I noticed you dumped mosquitto and went with the embedded MQTT broker. I did the same at first, but ended up reverting back to mosquitto as I could not get the embedded broker to save state. For example, when I would restart OpenHab, which restarts the embedded broker, some of my lights would randomly turn on, as if they remembered a prior state.

When using mosquitto I never had this issue. I spent 15-20 minutes trying to understand this behavior, but eventually gave up and just went back to mosquitto while still using the 2.4 MQTT bindings. This is probably OK for me anyway as I have several other tools integrated with MQTT so using a broker outside of OpenHAB probably makes sense anyway, but mostly I was just curious if you’ve seen this behavior.

Hi Tom,

first of all thank you for sharing your experience about the embedded broker.

As I actually got it finally working only today, I did not have many restarts so far. But I will keep an eye on it and let the community know if I run into the same issues with the embedded broker.

One question, when using MQTT Generic Things, you configure them to the Bridge or the Embedded Broker? I actually wonder what would make the difference. For your understanding, is it necessary to use the bridge at all when using embedded broker?

Hmm…I did not use a bridge when I attempted to use the embedded broker since the embedded broker was listed I assumed it was OK to use it directly.

Yeah, if I understand right, the bridge is only necessary when “talking” to an external broker. So actually one could skip this step when using internal broker.