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.
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.
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.
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:
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
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.
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”.
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.
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.
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?
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.
Yes, with the so-called “man-in-the-middle”-method. In a nutshell, it includes setting up a proxy on a smartphone and let the bulbs connect to the phone during the initial setup, while you capture the information sent by the bulbs with the proxy.
Find a instruction here:
In my case, the bulbs already have been set up, and I did not have a iPhone I found the method with emulator more convenient as you have a plain text file where you just need to copy&paste the local keys.
Really nice comprehensive guide. @AgentK Nice work getting on the MQTT setup.
I’ve added links to your post and github on my post and github.
I’ve got a python script which automatically gets all the device ids and ips of the devices on your network. It removes the pain of having to manually find the id, and arp and then greping the mac. Feel free to copy or use it in your guide/github. It also gets the device state if njstuya is installed, but works fine as a standalone. https://github.com/unparagoned/njsTuya
I am working on a video to show people how to use the tuya binding but, am having a little bit of trouble. I keep getting this:
(node:28317) UnhandledPromiseRejectionWarning: Error: Error communicating with device. Make sure nothing else is trying to control it or connected to it.
at Socket.client.setTimeout (/etc/openhab2/scripts/tuya-mqtt/node_modules/tuyapi/index.js:471:35)
at Object.onceWrapper (events.js:273:13)
at Socket.emit (events.js:182:13)
at Socket._onTimeout (net.js:453:8)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
at listOnTimeout (timers.js:263:5)
at Timer.processTimers (timers.js:223:10)
(node:28317) 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:28317) [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.
I would really appreciate any help I can get. Thank you in advance!