[RELEASE] New MQTT Bridge with Tasmota Sonoff Wifi and RF Integrations and other custom MQTT

I have significantly refactored and update the old smartthings MQTT bridge.
Please find it at

This is really beta version 1.0 as nobody besides myself has tested it outside my development environment

I am using it to integrate my Tasmota flashed devies, Custom MQTT devices and Sonoff RF devices using RF bridge.

They have been working flawlessly for me so far.

My hope is that if you have an MQTT broker already running you can get up and running in less than 15 minutes with working devices etc.

Please leave any issues and comments on github. I can’t promise how soon i will be able to get to them but I will try my best. I really could not find any things like this so for anyone using Tasmota this hopefully will be helpful.

This sounds very promising. Have you tried it with Sonoff Mini?

Is there any change you could make a video on the install process. Im not sure I’m getting the Windows part right…

I have 10 sonoffs mini and 3 sonoff basics I am using it with without issues. Not sure which part of the install process you are referring to - running it as windows as a service? have you been able to run it from the command prompt?

the other install components are node js npm install and the smartthings IDE.

Good to hear that Mini works. That one seems to have caused troubles on all the other device handlers I’ve found.

Maybe I’m just stupid, but I find the install process description on Windows a little inadequate?
And I already have Node js running for the Web-Cast API (for Chromecast and Google Home integration). Will that cause any problems?


  1. On windows command propmt (I usually run in administrative mode) cd into the nodejs directory (C:\Program Files\nodejs)
    from that directory run
  2. npm install -g mqtt-bridge-smartthings
    that will automatically download all the dependencies and setup - other installed packages should not make a difference.
  3. In windows explorer go to C:\Program Files\nodejs\node_modules\mqtt-bridge-smartthings and there create ‘config.yml’ and ‘devices.yml’ for your situation using the examples.
  4. go back to the command prompt and from the same directory C:\Program Files\nodejs run the command mqtt-bridge-smartthings

this should start the server and you should see the logging on the console.

Do you have an MQTT boker running separately?

Then follow the directions for smartthings IDE to set up the device handlers, the bridge and the smartapp.

Once you are comfortable everything is working fine you an set the process to run as a service so it automatically start and everything should be handled automatically.

if you are using sonoff’s also make sure to set the timezones etc otherwise your timestamps will be wrong. From the web console I run the following backlog commands

Backlog ntpServer1 0.us.pool.ntp.org; ntpServer2 1.us.pool.ntp.org; ntpServer3 2.us.pool.ntp.org; Sleep 250; TIMEDST 0,2,3,1,2,-300; TIMESTD 0,1,11,1,2,-360; Timezone 99; WifiConfig 2; Latitude xx.xxx; Longitude -xx.xxx; SetOption55 0
Backlog setoption53 1; powerretain on;SwitchRetain off; ButtonRetain on; ButtonRetain off
Timezone 99 is CST for me. Enter your specific longitude / latitude (that gets local sunrise /sunset)

make sure you also configure the MQTT on the sonoff devices - should write a small readme on that too - for me I set the unique topic like “SNF-M1” etc, for each sonoff and then for full topic I jsut prepend smartthings as "smartthings/%prefix%/%topic%

hope this helps
(I just added this info in the WindowsInstall.md and Tasmota.md files)

To get up and running quickly follow this simplest sceario.
From _devices.example copy the simplest device section into a ‘device.yml’ files, change the particulars according to your set up.

In IDE by code install the mbs-bridge device handler and mbs-smartapp-lite
create a virtual smartthings switch device.
configure settings in mbs-bridge
map the create switch to the smartapp in the smartapp settings and hit save.
You should be all set. and the switch should be working

Thanks… That made it all a lot more clear :slight_smile:

I’ll take a look on it in the weekend and return with my findings :slight_smile:

Ohh, and no. I haven’t got an MQTT broker running. Should I?

this may sound like an odd question but if MQTT is now built into the Devworkspace, is this now redundant? Why use this path rather than use the new platform? BTW I want to use MQTT, as I have Sonoff and Shelly switches with tasmota but I’ve got a shelly 4pro which I cant flash and was about to use my own driver with REST api, then saw they annouced MQTT in the new dev worspace. So I thought I might start playing with that environment as it looks like we can write our own code now!

sorry meant to send this link…

You need to have access to some kind of an mqtt broker running somewhere that will broker the messages between tasmota and this server. This is not an MQTT broker. this is a bridge between smartthings and and MQTT broker. The MQTT broker talks with tamsota and talks with this bridge.

If your working environment has a built in mqtt broker running then just specify that in the config file. I have mosquitto running on my windows because i need it for other projects too. Even in tasmota you will have to point to an MQTT broker (same one as this one), otherwise Tasmota cannot use MQTT

thanks and that all makes sence… what I meant was they look like they are making ST a mqtt broker and building inherent support in ST.

but this is all new so I dont know till I start playing with it. I just wondered whether to look at a new route or take advantage of your great work?

OK I found my answer… your way for now!!!

Need to read it further down in chain as the staff answer the question for us.

(Just got the the part where you added a comment… so you know all this!!!)


Thanks for the video had not seen it. Its odd they introduce it as an MQTT video but then showed a Wifi esp8266 examples - we already have st_anything library for that.

to me it looks like they might embed a cloud MQTT broker but there are several public MQTT brokers available now if you dont want to run your own broker. With smartthings cloud issues i really wanted to run something local.

Also the video seems to be about building a device handler for specific devices so each manufacturer will build their own device handler, specify their prop format for events and command topic, and define implementation on how to handle it. (I have kind of done that with my device handlers)

The reason i made this was there was no one universal MQTT topic format for commands and events for IoT. HassIO has its own, tasmota has its, so on and so forth.

This bridge makes it possible to integrate any kind of MQTT topic (by entension any MQTT enabled device) into a device in Smartthings. So I could create a composite device with a tasmota switch and an MQTT lamp from some other vendor.

Hass IO MQTT rule engine is much more sophisticated, this is a very simplistic engine, but in its simplicity I have also found it to be very powerful. I can basically integrate any MQTT device with any smartthings virtual or actual device. I just have to make sure attributes or commands that I map to are implemented for that smartthings devices (could be predefined like switch on / off or custom like mine).

I created some sample device handlers to show how easy it could be.

I guess we could create an onboarding and other process stuff but commercial device manufacturers are more vested to do that

yes and also from the other post (you’ll see I referenced you) as I started to read the info, it looks like the MQTT broker only talks to the ST device client (their own client software). So I dont think they are enabling an open MQTT environment for any client. Bit it isnt clear from the limitted info.

Also, I agree… I want a local MQTT broker not one in the cloud, and the inference from the other posting, is that is a future thing.

Interesting your other comments at the end. I was going to consider moving to HASS but that felt like I was dumping ST for no real reason. I’ll have a play with your bridge as I do need to support a couple of devices which are MQTT and also it will address the shelly device issue where they are not all supported by tasmota.

I personally have not played with the Hass IO but I did look at their device scehma, and they have a lot more sophisticated customizations than what I have built - my code is pretty plug and play though - i wasnt sure if the Hass IO MQTT engine could be imported into my project as a seprate module but if it could it would work well. For now I have only used lights, sensors and RF and getting immediate responses. I was also using bretts device handlers but the lag and 1 minute polling really was the issue - since all my mini’s are plugged into physical switch boxes

forgot to say… yes re ST_anything… I’ve built a few devices using that… and my smoke alarm is connected to one… (in UK building regs mean smoke alarms need to be mains connected so all those IoT smoke alarms are not approved for new builds and extensions!) I just connected the smoke alarm to a relay base and use a nodeMCU with ST_anything.
Also, I have my myLights all controlled via nodeMCUs and fireboy1919 device and app. Much cheaper than hue at sub £15 for a RGBW GU10 !!! again the controller I built can work using MQTT.

yep i dont like the lag from Brett either… when Im up and running I’ll let you know how my testing goes.

thanks. I have my entire security systems door, windows, motion sensors through St_anything.

I have mosquitto installed… I have a few different tasmota devices with MQTT setup. Using MQTT i can see everything is fine.
I’ve even put in the prefix ‘smartthings’ in the tasmota device console to give me
The config and the devices YML files have been configured…
config.YML set to talk to mosquitto
devices.YML to assume a single switch using the simple switch option with the name the same as the device in smartthings.

The smartapp and the devices have been setup… using the tasmota switch and the MQTT bridge and the name.

BUT there is no talking at this point.
If I could see what is being passed too (see this in the debug log in ST) and what is then recieved in the bridge, this would help. but currently I havent a clue where the problem might be.

Any hints welcome.

I would start by looking at the log in the events%date%.log in the log directory.
That should show you exactly what is happening.

Did you configure the Bridge option - IP, port, MAC Address - that is very important.
In the smart app when you click save - that should resubscribe everything.

If there is formatting error in any of the config files the server will basically not read them - but I would start with the events.log and if you could post here that would be great.

Any exceptions would be in the error%date%.log file in the same directory

and in ST also there should be debug log for the bridge, smartapp and the device which will show what is being passed

so extensive debug and logs both on server and in ST for now