The Advanced Example in Getting Started walks you through the creation of a Generic MQTT Thing.
The tl;dr is click on “Channel” and click on “add channel”
Ok, interesting issue. I followed what you said but went back to thing and didn’t see any channels. On a longshot I jupped over to Chrome and they they were. When I went back to internet explorer I saw they were barely readable. at the top, almost the same color as the rest of the banner. I fiddled with gama and contrast etc on that monitor and got them to show up faintly. Apparently the red to dark red is not enough to differentiate on the HTML page colors on IE. Moving on I’ll keep going.
I don’t know if you have Mqtt Explorer installed, but it is very helpful to just copy and paste the topics into OH.
That’s your screenshot. I circled what you need to click to get to the Channels tab in orange. Which browser did you take the screen shot from? Can you post a screenshot where the problem occurs?
Given that IE is pretty long since end of life and I don’t think anyone actually tests MainUI on it I wouldn’t be surprised if there were some odd behaviors of MainUI through IE. It should work correctly in Edge though. I don’t know if it’s something that can be fixed, but it might be something that could be addressed.
Note, there is currently a caching problem on Firefox. When you add a new Channel there, it might not show up. I know that there is definitely a problem with Items not showing up with Firefox. I’ve not seen the same reported for Things, but it would make some sense.
Close but…Spent lots of time on this, not sure I really need the transformation as the tasmota only has command on and off.
Summary: See item, see commands in log, broker at *.228 sees message from OH and from mqtt util. Only util makes it to switch.
Mystery but guessing OH broker sees (Green Line) message but not formatted correctly so no change made to switch. (could be knowledge of message formats)
Orange line points to result from util, light changes and status. Not using user client info could be issue?
Feels like I’m trying to put pegs in holes with blindfold on? Help point me in right direction? Must be messing up channel somehow?
sorry about small pic
Text is a lot easier to deal with than pictures where possible. Use the “Code” tab and use code fences.
```
code goes here
```
There is a lot of stuff in between OH’s MainUI and the device.
MainUI Widget <-> Item <-> Link <-> Channel <-> Bridge <-> Broker <-> Tasmota device
In addition, the data passed for each of those double arrows needs to be correct as well.
You need to confirm each step of the way.
Based on what I can surmise from the imageL
. .Going the other direction toggling the switch on the Tasmota side does result in a message being published to the MQTT broker. But is it received by OH? No evidence provided so . What we have is
MainUI Widget <-> Item ? Link ? Channel ? Bridge <-> Broker <-> Tasmota device
You need to answer the parts to get anywhere.
The best I can tell is you’ve created an MQTT Thing and haven’t configured any Channels at all. At least there is no evidence that you have done so. It also kind of looks like you’ve tried to use the Availability topic as your Switch.
You also need to identify:
stat/tasmota_C19E3F/STATUS and you’ll need to use a JSONPATH transform to extract the status from that JSON message.stat/tasmotaC19E3F/POWER and you just need to publish ON or OFF to that topic.But am I correct? You’ll find that information in the Tasmota docs.
The way it should look from the MQTT side of things (using my garage door opener as an example, I don’t have any Tasmota devices).
I won’t show the widget since you have that working and it’s largely irrelevant
Item, notice the Link. Note this is a place where the Code tab isn’t relevant for our purposes.
The Link. The important thing here is to see that it’s linked to a Channel and there isn’t a profile applied.
The Generic MQTT Thing. I’ll show screen shots but you will see that the code is much more relevant. It lest us see the whole MQTT Thing in context.
UID: mqtt:topic:mosquitto:cerberos_sensor_reporter
label: cerberos sensor_reporter
thingTypeUID: mqtt:topic
configuration:
payloadNotAvailable: OFFLINE
availabilityTopic: sensor_reporter/cerberos/status
payloadAvailable: ONLINE
bridgeUID: mqtt:broker:broker
location: Garage
channels:
- id: garagedoor1
channelTypeUID: mqtt:contact
label: Large garage door
description: Large garage door open status
configuration:
stateTopic: sensor_reporter/cerberos/garagedoor1/state
off: CLOSED
on: OPEN
- id: garagedoor2
channelTypeUID: mqtt:contact
label: Small garage door
description: Small garage door open status
configuration:
stateTopic: sensor_reporter/cerberos/garagedoor2/state
off: CLOSED
on: OPEN
- id: garagedoor1_opener
channelTypeUID: mqtt:switch
label: Large garage door opener
description: ""
configuration:
commandTopic: sensor_reporter/cerberos/garagedoor1/cmd
off: OFF
on: ON
- id: garagedoor2_opener
channelTypeUID: mqtt:switch
label: Small garage door opener
description: Small garage door opener controller
configuration:
commandTopic: sensor_reporter/cerberos/garagedoor2/cmd
off: OFF
on: ON
- id: online
channelTypeUID: mqtt:switch
label: Online status
description: Indicates online status of this sensor_reporter
configuration:
stateTopic: sensor_reporter/cerberos/status
off: OFFLINE
on: ONLINE
Notice how you can now see everything configured for the Thing all on one page from the Code tab. We can copy and paste from it too. It’s way more useful.
Broker Thing appears to be working for you so I won’t show it.
I don’t have a Tasmota device so can’t show this part if I wanted to.
Here is my sonoff basic switch configuration so you can compare:
UID: mqtt:topic:coffee
label: Coffee Machine
thingTypeUID: mqtt:topic
configuration:
payloadNotAvailable: Offline
availabilityTopic: tele/coffee/LWT
payloadAvailable: Online
bridgeUID: mqtt:broker:mqttbroker
location: Kitchen
channels:
- id: coffee
channelTypeUID: mqtt:switch
label: Coffee machine
description: null
configuration:
commandTopic: cmnd/coffee/POWER1
qos: 0
stateTopic: stat/coffee/POWER1
off: OFF
on: ON
Rich
As always, very grateful the help, I kept plugging and reading and finally got it to work. The issues was, “What to put in topics”. I was trying all kinds of derivatives. It would be nice if mqtt had a query? “What can I do”.
Once I set state and command topics appropriately and linked to thing, BINGO. There is some 14yr old somewhere that got this working in 10 mins. 
Anyway, I’ll study your email more, I’m sure there is some fog clearing info in there on something else I have yet to trip on!!!
This is the last segment from the OH2 so I’m going to decommission the PI2. I’ve been a two open hab family for some time with mqtt on old pi and new rules on PI4/OH4.
As a side note. OH2 would turn my 3 family room lights on at sunset. 1 then 2, then 3. OH4 on new pi (123) bam!
Please tell me there isn’t a OH5 in the works… I’d get committed for PTPD. Post Tramatic Port Disorder 
MQTT, like HTTP, Exec, moddbus, KNX, and others are very low level bindings. More-so than others, you need to understand the underlying technology to some degree to successfully use it.
In this case, Generic MQTT Things assume you know the topics you care about and what the messages will contain.
So, the topics shouldn’t have changed. So definitely use your old MQTT1 Item configs to figure out what to put into the Thing. Every parameter supported by the MQTT1 binding is represented in the Thing. It’s just that the Thing has more options.
Not yet. That probably won’t happen until openhab-core decides we need to move to a new Java version. If the past is any indication, I wouldn’t expect OH 5 for another year and a half. Probably more. And if the differences between OH 3.4 and 4.0 is any indication, massive rearchitecting everything like happened between OH 1 and OH 2, or huge new additions and changes in how end users approach configuring and using OH like happened between OH 2 and 3 are less likely.
yep