Control Tasmota flashed devices via MQTT

[hafniumzinc (T)]

Overview

This tutorial follows the setup and installation of a Sonoff Basic. However, many Tasmota flashed devices have an on/off capability, so this tutorial is relevant for other Tasmota flashed devices.

A Sonoff Basic is a simple mains relay, which can be flashed with Tasmota firmware and controlled from openHAB using the the MQTT binding. You can splice the Basic into anything mains powered (check the power rating first!) that you wish to switch on or off.

Ingredients

You will need:

1. Sonoff Basic flashed with Tasmota

Configuration is described below. I bought my Basics from here, and I used this USB programmer.

There are lots of tutorials on how to flash the Basic. Consult the Tasmota documentation to start.

Click to see my notes on flashing Tasmota

I flash the device using esptool.py. There are a number of options available, with Tasmotizer probably the most user friendly. If you have a Tuya device, flashing is even easier and you can ignore the rest of this step.

1. Get device into programming mode
   a. Disconnect USB programmer from PC
   b. Connect all cables to USB programmer and device
   c. Short IO0 to GND
   d. Connect USB programmer to PC
   e. Wait a few seconds, then disconnect IO0 from GND

2. Flash device
   a. Erase, then flash.

sudo esptool.py -p /dev/ttyUSB0 erase_flash
sudo esptool.py -p /dev/ttyUSB0 write_flash -fs 1MB -fm dout 0x0 /home/mypc/Downloads/tasmota.bin`

2. openHAB with MQTT binding

1. Navigate to PaperUI, usually at http://<openhab-ip-address>:8080/paperui/
2. Go to Add-ons -> Bindings -> MQTT Binding and click Install

3. MQTT broker

Install Mosquitto. Don’t use openHAB’s built-in broker. Install Mosquitto.

Click to see my installation notes

On many distributions, Mosquitto is available from the standard repositories, so something as simple as the following might work.

sudo apt install mosquitto

Mosquitto will be installed as a service, which means it will start automatically and just continue running in the background. If you restart your device, Mosquitto will also restart.

There is usually no need to change the default configuration.

Click here if you don't think Mosquitto is working

To check if it’s running, just type the following into a terminal:

sudo systemctl status mosquitto

If all is running well, you should get something like the following:

mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
   Loaded: loaded (/etc/init.d/mosquitto; generated; vendor preset: enabled)
   Active: active (running) since Wed 2020-07-15 22:28:39 BST; 1 months 9 days ago
     Docs: man:systemd-sysv-generator(8)
  Process: 370 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/mosquitto.service
           └─457 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

Jul 15 22:28:38 raspberrypi systemd[1]: Starting LSB: mosquitto MQTT v3.1 message broker...
Jul 15 22:28:39 raspberrypi mosquitto[370]: Starting network daemon:: mosquitto.
Jul 15 22:28:39 raspberrypi systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.

If you don’t, a common issue is that something else is already using the standard MQTT port of 1883. Perhaps you have previously installed another MQTT broker (maybe the one that comes with openHAB)? Either way, whatever it is, must be stopped before mosquitto can run!

Method

We’ll split the method into two: configuration of the Tasmota flashed Sonoff Basic, and configuration of openHAB.

1. Configure Tasmota

You will already have connected your Sonoff Basic to your WiFi network.

a. Configure module

In a browser:

1. Navigate to your Tasmota device’s configuration page: http://<tasmota-ip-address>/md
2. Change the Module type to Sonoff Basic (1).
3. Click Save. The device will re-start, and kick you back to the Main Menu.

The Main Menu will now have a button called Toggle. Click this, and your Sonoff Basic will switch ON and OFF!

b. Configure MQTT

In a browser:

1. Navigate to your Tasmota device’s MQTT configuration page: http://<tasmota-ip-address>/mq
2. In Host, enter the IP address of the device which is running Mosquitto.
3. In User, enter a unique name for this device.
4. In Topic, enter the same name as you did for User.
5. Leaving everything else as it is.
6. Click Save. The device will re-start, and kick you back to the Main Menu.

2. Configure openHAB

openHAB can be configured via PaperUI, or via files. The method below uses files, as it is far easier to share textual configurations than screenshots of a user interface - just copy, paste and save!

Files are saved in specific folders within your openHAB Site configuration folder. Find where yours might be for Linux or Windows installations by checking the tables.

a. Things

We will create two Things files. The first will point to Mosquitto, connecting openHAB and Mosquitto together. The second will point to the Sonoff Basic, via Mosquitto, connecting openHAB to the Sonoff Basic.

i. mqttbridge.things

Create an empty text file called mqttbridge.things inside the things folder in the openHAB Site configuration folder. Make sure the file ends with .things, and not .txt or something similar. openHAB keeps a continuous watch on these folders, and will read any files with the correct filetype!

Inside mqttbridge.things copy and paste the following, and save:

Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" [
	host="192.168.1.92",
	secure=false,
	port=1883,
	clientID="OpenHAB2",
	username="",
	password=""
]

Change the IP address for that of the device which is running Mosquitto. If you configured a username and password, add those details too. For a full list of options when it comes to configuring an MQTT bridge, check the documentation.

ii. mqttdevices.things

Create an empty text file called mqttdevices.things inside the things folder in the openHAB Site configuration folder. Copy and paste the following into that file, and save:

Thing mqtt:topic:swBedroomSideLight "Switch Bedroom Side Light" (mqtt:broker:MosquittoMqttBroker) {
	Channels:
		Type switch : power "Power Switch" [ 
			commandTopic="cmnd/swBedroomSideLight/POWER", 
			stateTopic="stat/swBedroomSideLight/POWER",
			on="ON",
			off="OFF"          
		]
}

Click here for a wordy explanation of the above configuration

First, we define the Thing

• Thing mqtt:topic:swBedroomSideLight
  • We have created a Thing…
  • …using the mqtt binding…
  • …this Thing is a topic type (as opposed to the bridge type created earlier to connect (‘bridge’) to Mosquitto)
  • …this Thing is called swBedroomSideLight. I have given it the same name as that configured in the Tasmota MQTT configuration, although it doesn’t have to be - it just has to be unique to openHAB.
• "Switch Bedroom Side Light"
  • This is a friendly label for the Thing, useful sometimes when using PaperUI.
• (mqtt:broker:MosquittoMqttBroker)
  • This defines our Thing as something which connects through our MQTT bridge to Mosquitto.

Then, we define its Channel

• Type switch : power "Power Switch"
  • We have created a switch type Channel (other channels are available)…
  • …which openHAB now calls the power Channel. This is a unique name that you give to the Channel, and must not be repeated for any other Channel in the same Thing…
  • …and has the friendly description of "Power Switch".

Then, we configure the Channel

• commandTopic="cmnd/swBedroomSideLight/POWER"
  • This is the topic that openHAB will send a message to when the Channel receives an ON or OFF command from openHAB.
  • Note that this is standard syntax for a default Tasmota:
    • cmnd - All commands to the device are sent to the cmnd topic.
    • swBedroomSideLight - We want the command to be routed to our device. Specifically, we want the command to be routed to the exact name that we specified in Topic during Tasmota MQTT configuration, which was swBedroomSideLight.
    • POWER - This is the command or function that will be run on the swBedroomSideLight device itself.
• stateTopic="stat/swBedroomSideLight/POWER"
  • Very similar to the commandTopic, but this time we’re setting openHAB up to listen on this specific topic, because Tasmota will send messages on this specific topic any time the POWER command is run on the device.
• on="ON", off="OFF"
  • Because this is a switch type Channel, we can send on or off values to the commandTopic. In this bit, we’re saying:
    • When sending an on message, send the word ON.
    • When sending an off message, send the word OFF.
  • So now our Tasmota device will receive either the word ON or OFF to the POWER command, which is what it would expect.
  • Additionally, this bit of the configuration also works in the other direction: whatever comes through the stateTopic is also sent through this transformation, but in reverse. So if an “ON” message is sent from the Tasmota device on the stat/swBedroomSideLight/POWER topic, openHAB will correctly interpret that as on.

b. Item

After definining a Thing, which is a link to a physical object, we now define an Item, which openHAB can use in rules and sitemaps, and which connects to a Thing Channel.

Create an empty text file called mqtt.items inside the items folder in the openHAB Site configuration folder. Copy and paste the following into that file, and save:

Switch sBedroomSideLight "Bedroom Side Light"  { channel="mqtt:topic:swBedroomSideLight:power" }

Click here for an explanation of the above configuration

• We have created a Switch type Item…
• …with the name of sBedroomSideLight. This name is unique - no other Item may be called the same…
• …with a friendly label "Bedroom Side Light"…
• …and it is connected to the power channel of the swBedroomSideLight MQTT Thing.

c. Sitemap

The Sitemap is your personal, configurable user interface. You can access the user interface through http://<openhab-ip-address>:8080/basicui/ or via mobile applications, but configuration is via files only.

Create an empty text file called myHome.sitemap inside the sitemaps folder in the openHAB Site configuration folder. Copy and paste the following into that file, and save:

sitemap myHome label="My Home" {
   Switch item=sBedroomSideLight label="Bedroom Side Light"
}

Click here for an explanation of the above configuration

• sitemap myHome label="myHome"
  • We’ve created a sitemap…
  • …which openHAB knows as myHome. Note that the name of the file and the name of the sitemap (this name) must be the same…
  • …which has a friendly label My Home.
• Switch item=sBedroomSideLight label="Bedroom Side Light"
  • The sitemap includes a Switch widget…
  • …which is connected to the sBedroomSideLight Item…
  • …and has a friendly label "Bedroom Side Light". In fact, we could leave label="Bedroom Side Light" out of this configuration completely, and openHAB will use the friendly label of the Item itself when displaying on a user interface.

Which will give you something which looks like this in BasicUI:

You now have working switch which you can toggle on and off!

Summary

We’ve now:

1. Setup an MQTT broker.
2. Configured a Tasmota device to talk to and receive messages through the MQTT broker.
3. Configured openHAB to talk to and receive messages through the MQTT broker.
4. Subscribed openHAB to the POWER command and state topics of our Tasmota device, via the power Channel of our Thing.
5. Connected a Switch Item to the power Channel.
6. Displayed the Switch Item via a Sitemap.

Everything is connected: the Sitemap Switch connects to the Switch Item, which connects to the Thing Channel, which is bridged to the MQTT broker and subscribed to the topics defined by the Tasmota device.

Common issues

• Everything to do with MQTT, and openHAB, is case sensitive. sBedroomSideLight is not the same as sbedroomsidelight. Be especially careful with MQTT topics!
• The names of the Things and Items files can be anything you want. However, the name of the Sitemap file must match the name of the sitemap itself (the word after Sitemap in the file itself).
• The filetypes (end of the filename) are important.
  • .things for Things files.
  • .items for Items files.
  • .sitemap for Sitemap files. Note that there is no s (or plural) at the end of this one, as each file only has the configuration for a single Sitemap.
• Mind your brackets (), curly brackets {}, square brackets [] and commas, especially in the Thing configuration.

[hafniumzinc (T)]

Slightly more advanced configurations

This post assumes that the Things, Items and Sitemap files are already configured as in the previous post.

Topics

1. Device online/offline status
2. The STATE message
3. Device Wi-Fi signal quality
4. Status on startup

---

Device online/offline status

In order to know whether our Tasmota device is actually reachable we can interrogate the Last Will and Testament (LWT) topic.

Click here for a simplified description of how this works

1. When Tasmota connects to the MQTT broker, it sends a message Online to the device LWT topic.
2. At the same time, Tasmota also tells the MQTT broker what message to use if it goes offline, namely Offline.
3. The MQTT broker is now in charge, and when it no longer has a connection to the Tasmota device it will broadcast the Offline message on the device LWT topic.

a. Things

i. mqttdevices.things

Add a new switch type Channel called reachable to the existing thing, as below:

Type switch : reachable "Reachable" [
	stateTopic = "tele/swBedroomSideLight/LWT",
	on="Online",
	off="Offline"
]

Click here to see the resultant things file.

Thing mqtt:topic:swBedroomSideLight "Switch Bedroom Side Light" (mqtt:broker:MosquittoMqttBroker) {
	Channels:
		Type switch : power "Power Switch" [ 
			commandTopic="cmnd/swBedroomSideLight/POWER", 
			stateTopic="stat/swBedroomSideLight/POWER",
			on="ON",
			off="OFF"          
		]
		Type switch : reachable "Reachable" [
			stateTopic = "tele/swBedroomSideLight/LWT",
			on="Online",
			off="Offline"
		]
}

b. Item

Inside mqtt.items, add the following line:

Switch sBedroomSideLightReachable "Bedroom Side Light" { channel="mqtt:topic:swBedroomSideLight:reachable" }

c. Sitemap

We have some options when presenting this online/offline information.

Switch

i. Switch

A simple display method is to use a Switch element, which will show ON when the device is online, or OFF when it is offline.

Add the following into myHome.sitemap, underneath the original Switch Item:

Switch item=sBedroomSideLightReachable label="Bedroom side reachable [%s]"

Note that you are able to toggle the switch but nothing will happen, so this perhaps is not the most ideal method of displaying whether the Tasmota device is reachable.

Text

ii. Text

We can use a Text element to display a read-only status.

Add the following into myHome.sitemap:

Text item=sBedroomSideLightReachable label="Bedroom side reachable [%s]"

But showing ON or OFF isn’t quite right.

Text with mapping

iii. Text with mapping

We can use a Text element to display a read-only status, and display either ONLINE or OFFLINE instead of ON or OFF. This is achieved using a MAP transformation, which requires the installation of another add-on, and a new file!

Install MAP transformation service

1. Navigate to PaperUI, usually at http://<openhab-ip-address>:8080/paperui/
2. Go to Add-ons -> Transformations -> Map Transformation and click Install

Create MAP file

Create a new file called switch2online.map and save within the transform folder in the openHAB Site configuration folder.

Inside switch2online.map copy and paste the following, and save.

OFF=OFFLINE
ON=ONLINE
NULL=UNDEFINED
-=-

Create Sitemap element

Add the following into myHome.sitemap :

Text item=sBedroomSideLightReachable label="Bedroom side reachable [MAP(switch2online.map):%s]"

The label now includes a link to the MAP transformation service, with our recently created file. We send the word ON or OFF (via the %s) to the MAP transformation service, and it uses the data in the file to return either ONLINE or OFFLINE.

For more information on transformations (MAP isn’t the only one!), see the documentation.

Text with mapping and colours

iv. Text with mapping and colours

Depending on the status, we can colour the ONLINE and OFFLINE differently.

Ensure the MAP transformation service is installed - see above.

Add the following into myHome.sitemap :

Text item=sBedroomSideLightReachable label="Bedroom side reachable [MAP(switch2online.map):%s]" valuecolor=["ON"="green", "OFF"="red", "NULL"="red", "-"="red"]

Note that the colours are based on the original value of the Item (i.e. ON and OFF, not the value after it has been transformed.

For more information on dynamic colouring of labels, see the documentation.

---

The STATE message

In addition to the RESULT topic, to which Tasmota publishes a message every time it performs a command, a default configuration of Tasmota will send out a message on the STATE topic every 5 minutes (300 seconds). Simply, this message contains information about the current state of the device.

For our device, Tasmota will publish a message to the following STATE topic:

tele/swBedroomSideLight/STATE

and a normal message published to this topic looks as follows:

{"Time":"2020-09-06T19:14:24","Uptime":"12T23:00:11","UptimeSec":1119611,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"ACPRO1","BSSId":"E0:63:DA:65:EA:4A","Channel":6,"RSSI":84,"Signal":-58,"LinkCount":1,"Downtime":"0T00:00:07"}}

This mesage is in a JSON format.

Click to see this message with slightly more friendly formatting

{

   "Time":"2020-09-06T19:14:24",
   "Uptime":"12T23:00:11",
   "UptimeSec":1119611,
   "Heap":26,
   "SleepMode":"Dynamic",
   "Sleep":50,
   "LoadAvg":19,
   "MqttCount":1,
   "POWER":"OFF",
   "Wifi":{
      "AP":1,
      "SSId":"ACPRO1",
      "BSSId":"E0:63:DA:65:EA:4A",
      "Channel":6,
      "RSSI":84,
      "Signal":-58,
      "LinkCount":1,
      "Downtime":"0T00:00:07"
   }
}

This message contains a number of details, including:

• How long the device has been on for (Uptime and UptimeSec)
• The current state of the relay (POWER)
• Wi-Fi signal quality/strength (RSSI and Signal)

Depending on the device, Tasmota might provide more details in the STATE message. For example, the message below comes from a MagicHome RGB LED controller, flashed with Tasmota:

{"Time":"2020-09-06T19:20:21","Uptime":"62T08:16:02","UptimeSec":5386562,"Heap":26,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":99,"MqttCount":5,"POWER":"ON","Dimmer":81,"Color":"06CF00","HSBColor":"118,100,81","Channel":[2,81,0],"Scheme":0,"Fade":"ON","Speed":5,"LedTable":"ON","Wifi":{"AP":1,"SSId":"ACPRO1","BSSId":"E0:63:DA:65:EA:4A","Channel":6,"RSSI":66,"Signal":-67,"LinkCount":2,"Downtime":"0T00:00:44"}}

Click to see this message with slightly more friendly formatting

{
   "Time":"2020-09-06T19:20:21",
   "Uptime":"62T08:16:02",
   "UptimeSec":5386562,
   "Heap":26,
   "SleepMode":"Dynamic",
   "Sleep":10,
   "LoadAvg":99,
   "MqttCount":5,
   "POWER":"ON",
   "Dimmer":81,
   "Color":"06CF00",
   "HSBColor":"118,100,81",
   "Channel":[
      2,
      81,
      0
   ],
   "Scheme":0,
   "Fade":"ON",
   "Speed":5,
   "LedTable":"ON",
   "Wifi":{
      "AP":1,
      "SSId":"ACPRO1",
      "BSSId":"E0:63:DA:65:EA:4A",
      "Channel":6,
      "RSSI":66,
      "Signal":-67,
      "LinkCount":2,
      "Downtime":"0T00:00:44"
   }
}

In addition to the previously highlighted details, this STATE message also includes:

• Current dimmer level (Dimmer)
• Current colour (Color and HSBColor)
• Fade status, and speed during fade (Fade and Speed respectively)

The following couple of examples use this STATE message.

---

Device Wi-Fi signal quality

Within the STATE message (see above) there is a Wifi group, within which is the RSSI key/value pair. RSSI in this case is a measure of the quality of the signal: a signal strength lower than -100dBm is 0%, anything greater than -50dBm is 100%, and anything in-between is, well, inbetween %!

For this example, we are going to have to extract the value of RSSI from the STATE message. Because the message is in a JSON format, we can use openHAB’s JSONPath Transformation Service.

Install JSONPath transformation service

1. Navigate to PaperUI, usually at http://<openhab-ip-address>:8080/paperui/
2. Go to Add-ons -> Transformations -> JSONPath Transformation and click Install

a. Things

i. mqttdevices.things

Add a new number type Channel called rssi to the existing thing, as below:

Type number:rssi "RSSI" [
	stateTopic="tele/swBedroomSideLight/STATE",
	transformationPattern="JSONPATH:$.Wifi.RSSI"
]

We use the transformationPattern configuration to extract the RSSI value from the Wifi group.

Click here to see the resultant things file.

Thing mqtt:topic:swBedroomSideLight "Switch Bedroom Side Light" (mqtt:broker:MosquittoMqttBroker) {
	Channels:
		Type switch : power "Power Switch" [ 
			commandTopic="cmnd/swBedroomSideLight/POWER", 
			stateTopic="stat/swBedroomSideLight/POWER",
			on="ON",
			off="OFF"          
		]
		Type switch : reachable "Reachable" [
			stateTopic = "tele/swBedroomSideLight/LWT",
			on="Online",
			off="Offline"
		]
		Type number:rssi "RSSI" [
			stateTopic="tele/swBedroomSideLight/STATE",
			transformationPattern="JSONPATH:$.Wifi.RSSI"
		]
}

b. Item

Inside mqtt.items, add the following line:

Number nBedroomSideLightRSSI "RSSI" { channel="mqtt:topic:swBedroomSideLight:rssi" }

c. Sitemap

Add the following into myHome.sitemap:

Text item=nBedroomSideLightRSSI label="Connection quality [%d %%]" icon="qualityofservice"

Note that the qualityofservice icon is a dynamic icon (i.e. it can change depending on the value of the openHAB Item), but only for the numbers 0, 1, 2, 3 and 4. It will not work with the percent values provided by Tasmota, so the icon will remain static. A couple of methods of solving this issue are discussed in this post and onwards.

---

Status on startup

With the configuration in the first post, openHAB knows what state the relay is in because it receives a message on the stat/swBedroomSideLight/POWER topic. However, Tasmota only sends a message on this topic when the state of the relay is changed, which means that after a restart of openHAB, openHAB doesn’t know what the state of the switch is.

One method of solving this issue is to use Persistence - continually (if configured) saving the state of openHAB Items into a database, which openHAB can then interrogate when it restarts to set all the switches (and other things) to the last-known states.

However, if you don’t want to install extra add-ons, and don’t mind waiting up to 5 minutes for openHAB to learn the state of the relay, you can use the STATE message - remember that it provides, amongst other things, the current state of the relay with the POWER key/value pair.

And the magic here is that we can attach more than one Thing Channel to a single Item!

a. Things

i. mqttdevices.things

Add a new switch type Channel called state_power to the existing thing, as below:

Type switch:state_power "State Power" [
	stateTopic="tele/swBedroomSideLight/STATE",
	transformationPattern="JSONPATH:$.POWER"
]

We use the transformationPattern configuration to extract the POWER value.

Click here to see the resultant things file.

Thing mqtt:topic:swBedroomSideLight "Switch Bedroom Side Light" (mqtt:broker:MosquittoMqttBroker) {
	Channels:
		Type switch : power "Power Switch" [ 
			commandTopic="cmnd/swBedroomSideLight/POWER", 
			stateTopic="stat/swBedroomSideLight/POWER",
			on="ON",
			off="OFF"          
		]
		Type switch : reachable "Reachable" [
			stateTopic = "tele/swBedroomSideLight/LWT",
			on="Online",
			off="Offline"
		]
		Type number:rssi "RSSI" [
			stateTopic="tele/swBedroomSideLight/STATE",
			transformationPattern="JSONPATH:$.Wifi.RSSI"
		]
		Type switch:state_power "State Power" [
			stateTopic="tele/swBedroomSideLight/STATE",
			transformationPattern="JSONPATH:$.POWER"
		]
}

b. Item

Inside mqtt.items modify the existing sBedroomSideLight Item to include the new channel:

Switch sBedroomSideLight "Bedroom Side Light"  { channel="mqtt:topic:swBedroomSideLight:power", channel="mqtt:topic:swBedroomSideLight:state_power" }

And that’s it. Everytime the STATE message is received, openHAB can update the sBedroomSideLight Item to the reported value.

[christoph_wempe]

Just two things I would add based on my experience:

1. Use Tasmotizer to flash your device. It is a new tool, but very easy to use.
2. If you plan to flash and configure more devices, I would recommend to buy an extra USB-Wifi-Dongle.
   This way you can stay connected to your home network and simultaneously connect to the default Tasmota-WiFi of your recently flashed device. It is a PITA if you do the initial configuration with your smartphone or have to change your WiFi every few minutes between home and Tasmota.

[hafniumzinc (T)]

Thanks for the feedback - good points!

@christoph_wempe

Use Tasmotizer to flash your device. It is a new tool, but very easy to use.

When I first started out with Tasmota I did use a standalone copy of Tasmotizer. This worked fine for a bit, but then I started to get issues related to the UI itself - the program wouldn’t start. I’m on Ubuntu 18.04. As I had to start Tasmotizer from the terminal anyway (it needed sudo because it wants write access to /dev/ttyUSBx/), I just dropped it and replaced the terminal command with the esptool.py examples I show above - less user friendly, but a faster workflow.

Out of curiosity I just tried re-installing Tasmotizer using sudo pip3 install tasmotizer, and starting it sudo tasmotizer.py, and I get the following:

No protocol specified
qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

Aborted

Curiously, if I start without sudo, Tasmotizer does startup, but is then denied access to /dev/ttyUSB0 when trying to flash.

I’m sure there’s a simple fix out there, though I’ll stick with esptool.py. I have now added a link to the relevant section of the Tasmota documentation in the guide above!

[Udo_Hartmann]

As third option, there is tuya-convert, this is a tool which is using a hack to flash tuya compatible hardware OTA, i.e. without the need of soldering

[rpwong (Russ)]

Tuya-convert is impressively easy to use. I’ve done it three times without issues, and the devices are surprisingly reliable considering how inexpensive they are.

Here’s a link for the benefit of future readers. Between these two posts, the topic is well-covered.

Tutorial: Cheap, Tuya-based, Smart Plugs. HowTo reflash them and use them with OpenHAB

Cheap Smart Plugs (With power monitoring!) [image] The Mission: Based on this thread about cheap, wifi-based smart plugs, it was suggested I do a write-up on how to flash them and how not to brick them (like I did ) Why: Smart plugs are probably the first or second thing you’ll want to do with your new smart home. But, there are a number of issues to smooth before you can use them. Once smoothed you’ll see that it’s actuallly a doddle to get these plumbed in to your system. W…

[denominator (James Bowler)]

Good write up.

Here are some more examples. Integrated into google home aswell

Ifan03

Items

Switch Dining_light "Dining Light" { ga="Light", channel="mqtt:topic:myMQTTBroker:fan1:Power1" }
Dimmer Dining_fan "Dining Fan" { ga="Fan" [ speeds="0=off:zero,1=slow:low:one:on,2=medium:two,3=high:three:100", lang="en", ordered=true, roomHint="Dining" ], channel="mqtt:topic:myMQTTBroker:fan1:fanspeed" }

You can change what you say to google in speeds like 1=turtle:slow

Bridge mqtt:broker:myMQTTBroker [ host="192.168.1.148", secure=false, username="super", password="secure" , clientID="myMQTTClient" ]

{
    Thing topic fan1 "Dining FAN" {
    Channels:
        Type switch : Power1   "Dining Light "  [ stateTopic="IFANdining/stat/POWER", commandTopic="IFANdining/cmnd/POWER", on="ON", off="OFF" ]
        Type dimmer : fanspeed "Fan Speed"      [ stateTopic="IFANdining/stat/FANSPEED", transformationPattern="JSONPATH:$.FanSpeed", commandTopic="IFANdining/cmnd/FANSPEED", 0="OFF", 1="LOW", 2="MED", 3="HIGH", 2=100  ]
      }

    Thing topic ir1 "IR Blaster" @ "Lounge" {
    Channels:
        Type string : sending  [ commandTopic="IRblaster/cmnd/IRSEND" ]
        Type string : reciving [ stateTopic="IRblaster/tele/IRRECEIVED" ]
      }

}

IR Blaster Flashed with tasmota.

Items

String  IRBlasterSending  "TX"   {channel="mqtt:topic:myMQTTBroker:ir1:sending"}	//Main channel to send to blaster
String  IRBlasterReciving "RX"  {channel="mqtt:topic:myMQTTBroker:ir1:reciving"}

Kogan Smart Kettle

Thing topic Kettle "Kettle in Kitchen" {
    Channels:
        Type switch : PowerSwitch  [ stateTopic="kettle/stat/POWER", commandTopic="kettle/cmnd/POWER", on="ON", off="OFF"]
        Type string : Data  [ stateTopic="kettle/stat/RESULT", transformationPattern="JSONPATH:$.TuyaReceived.Data" ]
        Type string : WarmMode [ commandTopic="kettle/cmnd/TuyaSend4"]
        Type string : tuyarecieved  [ stateTopic="kettle/tele/TUYARECEIVED"]
        }

Items

Switch  Kitchen_Kettle             "Kettle"                 (gTuya)           {ga="Switch", channel="mqtt:topic:myMQTTBroker:Kettle:PowerSwitch"}
String  Kettle_Data                "Imcoming Data"                            {channel="mqtt:topic:myMQTTBroker:Kettle:Data"}
String  Kettle_WarmMode            "Warm to"                                  {channel="mqtt:topic:myMQTTBroker:Kettle:WarmMode"}
String  KettleTuyarecieved         "Incoming Data"                            {channel="mqtt:topic:myMQTTBroker:Kettle:tuyarecieved"}
Number  KettleTemperature          "Temperature [%.0f °C]"

Rules to get temp of kettle from hex to deg c

rule "Convert JSON to Item Type Number"
  when
    Item KettleTuyarecieved changed
 then
    val newValue = transform("JSONPATH", "$.TuyaReceived.DpIdData", KettleTuyarecieved.state.toString)
    
    if (KettleTuyarecieved.state.toString.contains('"DpId":5')) { 
        val decVal = Integer.parseInt(newValue, 16) as Number
        KettleTemperature.postUpdate( decVal ) 
    }
end

Will only update temp when it changes

[Kim_Andersen]

Totally agree with tuya-convert. I have 4 wifi plug outlets (3.part brand name) with energy monitor. It took just about 5 minuts each, then I had Tasmota on them ready to go with mqtt.
Alot faster than flashing sonoff device using serial.

[hafniumzinc (T)]

Thanks @Kim_Andersen and @rpwong! I don’t use Tuya devices myself, but have added a sentence into the flashing notes to link to the suggested forum topic!

[hafniumzinc (T)]

These examples are great, and if you haven’t already I would strongly urge you to post them as separate topics within this forum in the Solutions category! Three things I would recommend, after my experience as a beginner:

• Add the device name in the thread title, as well as the communication method (MQTT). If it uses Tasmota, include that too!
• Provide complete examples which include the MQTT bridge - many examples omit the bridge itself, so when you’re first starting out it can be quite confusing!
• It looks like your Tasmota Full Topic is %topic%/%prefix%/, rather than the currently default %prefix%/%topic%/ - might be worth mentioning that too, and maybe showing the Tasmota MQTT parameters. There’s a mixture on this forum, and it’s rarely mentioned, which caused me some headaches when I started out!

[lucky62]

Seems that when two channels are linked to the same item, then the item is displayed twice in UI (PaperUI/Control, ClassicUI).

See#341

[hafniumzinc (T)]

PaperUI is not designed for everyday control of openHAB - it’s for administering openHAB.

ClassicUI was designed for openHAB1.

All Sitemap examples assumed BasicUI, as shown in the screenshots.

[rossko57]

ClassicUI is perfectly usable with openHAB2.
Like BasicUI, what it shows is entirely controlled by sitemap file. What goes in the sitemap is entirely up to you. You can put duplicates if you want.

Are you by chance using openHAB in “Simple Mode”, which auto creates Items? This quickly becomes a nuisance if you are also adding Items manually.

[tacticaljack (R.E.Smith)]

hafniumzinc –

THANK YOU so much for this post. It has taken me almost a year to find the information you placed into this thread.

I had given up hope of ever finding this information. I have been forced into using PaperUI to define my SONOFF devices. This is fantastic info.

This appears to be OH2 configs, yes? Do you know if / how it changes for OH3?

Again thank you so much. I have a buddy that is suffering from the same lack of docs, he will also greatly appreciate this post.

[hafniumzinc (T)]

@tacticaljack

This appears to be OH2 configs, yes? Do you know if / how it changes for OH3?

If you continue with config files you won’t have to change anything for OH3

[tacticaljack (R.E.Smith)]

That was my assumption, but you know where assumptions can put you!

[hafniumzinc (T)]

@tacticaljack

but you know where assumptions can put you

Indeed!

With OH3 you do have some other options, which you may prefer:

1. Obviously, you can stick with the files, and nothing changes
2. You can utilise the UI completely, and get all clicky clicky
3. You can partially utilise the UI, and complete the process using YAML
4. You can use the auto-discovery option

[tacticaljack (R.E.Smith)]

hafniumzinc -

(edited, removed original content, substituted the following)…

I finally got my Dual R2 unit up and running from config files. Thank you for all of the help and clarification that your original 2 posts provided.

[tacticaljack (R.E.Smith)]

Is there a way to include a device location such as @“Living Room” in the mqtt thing config? I tried this …

Thing mqtt:topic:eab2edb0:RS_Music_Room “RS_MR” @ “Music Room” (mqtt:broker:eab2edb0)

Generates a missing “)” error.

[hafniumzinc (T)]

You should be able to, but add it after the reference to the Bridge/Broker Thing, not before. This is my bible:

openhab/openhab-addons/blob/main/bundles/org.openhab.binding.mqtt.generic/xtend_examples.md