SmartThings Community

MQTT Bridge [device + app]

I’ve also switched over to your latest server.js and no joy (yet). I made one minor change and that was to change the 8080 references to config.listen.port (and added listen: port: 28080 to the config.yml file). My logs can be found here:

Access log
Events log

Thanks :slight_smile:

@ncherry I would LOVE to see a PR with those changes at some point. Configurable port is a great idea, and the battery/temperature features are excellent.

These logs are helpful showing that there is no problem sending messages to the Hub. I need the logs from SmartThings. If you goto you can see live traffic for your devices/smartapps. Can you give me the logs of the MQTTBridge Device and SmartApp during the time you send your message? Also do you have your MAC Address set correctly?

Another really important thing for people is to statically assign IPs for the Bridge and Hub, otherwise if your router reboots, you could get new IPs and both configurations would be wrong.

EDIT: Found it! Take a look, the bridge is configured for “/smartthings/” while the mqtt message is “smartthings/” Best thing to do is add to your config.yaml

PR? Sorry I usually code by my lonesome and I’m only pushed into using git a lot more lately. No more, making just one more change for the 5th time and messing everything up, Yea!. :wink:

This was updated a few minute ago:
Linuxha’s fork of smartthings-mqtt-bridge

Here’s what I see in the living log:
1:14:05 PM: debug Forwarding device event to bridge: {“path”:"/push",“body”:{“name”:“Outlet”,“value”:“0”,“type”:“power”}}
1:14:05 PM: debug Sending ‘{“path”:"/push",“body”:{“name”:“Outlet”,“value”:“0”,“type”:“power”}}’ to device
1:14:03 PM: debug Forwarding device event to bridge: {“path”:"/push",“body”:{“name”:“Outlet”,“value”:“off”,“type”:“switch”}}
1:14:03 PM: debug Sending ‘{“path”:"/push",“body”:{“name”:“Outlet”,“value”:“off”,“type”:“switch”}}’ to device
1:13:36 PM: debug summaryData: [[icon:indicator-dot-gray, iconColor:#878787, value:Disarmed], [icon:indicator-dot-green, iconColor:#79b821, value:Everything OK]] - [[icon:indicator-dot-gray, value:Disarmed, iconColor:#878787], [icon:indicator-dot-green, value:Everything OK, iconColor:#79b821]]
1:11:34 PM: info Waiting on events…
1:11:34 PM: info For past logs for individual things go to the My Devices section, find the device and click on the Events link on the device information page.
1:11:34 PM: info This console provides live logging of your SmartThings.

Very odd I see the push from the table (the power = 0, Switch = Off) but no switch on a short time later:

From my Linux box

$ mosquitto_pub -r -t ‘smartthings/Outlet/switch’ -m ‘on’

And the end of the logs:
info: Loading previous state
info: Perfoming configuration migration
info: Saving current state
info: Connecting to MQTT
info: Configuring autosave
info: Configuring API
info: Listening at http://localhost:28080
info: Incoming message from SmartThings: smartthings/Outlet/switch = off
info: Incoming message from SmartThings: smartthings/Outlet/power = 0
info: Incoming message from MQTT: smartthings/Outlet/switch = on
info: Incoming message from SmartThings: smartthings/Multipurpose Sensor A/temperature = 65
info: Incoming message from SmartThings: smartthings/Motion Sensor/temperature = 63

And updated logs can be found here:

Access log
Events log


Sent to SmartThings (
accept: application/json
content-type: application/json
content-length: 46
Connection: close


Received from SmartThings:
Connection: close

No further update to the live logs (???)

Just finished a triple check of the MAC address. It matches the machine with the Node server.js running on it. I’ve also made sure that it has this format: 00:01:ab:cd:ef:22 (that’s not my mac address). No offense but I won’t post it as it could be used in an attack vector.

Well pray for me, I have to walk the dogs now as it’s finally in the double digits but still feels like only 5F. I do much better at 105F than 5F (my dogs don’t though).

The MAC address should be in the format “0001abcdef22”.

The MAC address format doesn’t matter as when you click the “save” in the SmartApp it will automatically convert it correctly for you. Double-check the Device Type preferences in the UI, it should have it as the “deviceIdentifier” (without the “:”)

Basically looks like this (in Preferences on the SmartThings site):
Mosquitto Device Mosquitto
MQTT Bridge IP Address - MQTT Bridge IP Address * [ ] MQTT Bridge Port - MQTT Bridge Port * [ 28080 ]
MQTT Bridge MAC Address - MQTT Bridge MAC Address * [ 0001abcd2201 ]

I’ve been looking for a simple and cheap way to IoT-enable various things in my house which currently aren’t integrated into my HA environment. Several of these devices have power buttons that are momentarily engaged by the user in order to turn the device on or off. The sketch below will allow me to connect a ESP8266 to an existing device to toggle the power switch, and to monitor the device’s power state in order to update ST when someone powers the device on locally. This will let me turn dumb things into simple smart things when combined with the MQTT bridge and a virtual switch device in SmartThings.

My example use case is a hot water kettle. This kettle has a built-in PID controller to maintain temperature and it’s great at it’s job. However, I’d like it to fire up in the morning so it’s ready when I get into the kitchen to make some coffee. To do so, I need a way to press the power button every morning before I get into the kitchen. With an ESP8266 and an optoisolator I can WiFi-enable the device’s power button to allow ST (or any other MQTT-compatible HA platform) to send power commands to the kettle.

You can find the ESP8266 code here:

From the readme:
Many devices have a power button that can be momentarily pressed to toggle power on and off. Further, the device will often have something like a power LED that can be monitored to determine the device’s power state.

This sketch will monitor the configured MQTT topic for “on” and “off” events. It will also monitor a selected pin to determine if the local device is “on” or “off”. If the local state is “off” and an “on” message is received, it will momentarily toggle the output pin to turn the device on. Likewise, if the monitored device is “on” and an incoming message for “off” is received, the power button pin will be toggled to turn the device off.

The sketch will also monitor the power LED and publish an outgoing MQTT message when the power state changes. This will capture local user interaction and update MQTT with the new power state.

Finally, the sketch will periodically announce its local state every minute.


  • The power button pin can be connected to a relay or an optoisolator or similar device to actuate the device’s power button. A pull-down resistor will probably be needed.
  • The power monitor pin can be connected to one leg of an LED or maybe VCC of the controlled device to detect the power state. Keep in mind input voltage limits.
  • Various versions of the ESP8266 have requirements regarding GPIO pin state during power on. Be careful about which pins you choose in this sketch.
1 Like

Was this meant to be a separate thread? It should be. It is interesting.

I don’t see why the ESP8266 wouldn’t be able to do it. You can either monitor the LED or the power usage. I haven’t attempted this myself but it should work. I’ll have a look at the links later. I need to thaw a bit yet and I’m setting up the switch to SPAN (Switch Port ANalyses) so I can see what the SmartThings sees and the Tablet sees.

Well, it requires the MQTT bridge so I posted it here as an example of what’s possible. This is working with my tea kettle right now. Any device that uses a momentary-contact power button and which has some way to monitor power state should work. You may need to level-shift the power monitor to 3.3v, and the power button control will likely need a relay or an isolator (but could probably work with a simple transistor).

Still, it appears to work reliably over the short term. I’ll see how well this does after a week or two in service…

Close, but I want to double-check the DeviceNetworkID (which should be the same as that mac address).

Okay, so what I can tell from the logs (so far) is that the bridge IS sending a message to SmartThings, but SmartThings isn’t accepting it (usually due to the MAC address thingy).

I expect once I resolve the issues I have that I’ll be able to link SmartThings, MQTT, various Node.js/Node-Red, scripts and Misterhouse together (for World Domination! :wink: )

One day I really need to sit down and start documenting this ‘setup’. I have way too many examples of all sorts of things running. X10, Insteon, IR, digital/analog, IR, various information … and I’ve got more being added every day. Not really practical but a whole lot of fun. :slight_smile:

St John, yes I thought that also. All the searching seems to suggest that also. But I’m pretty sure the mac is correct. I work with MAC addresses all the time when setting up my DHCP server (the Linux server is static IP & MAC, the SmartThing is DHCP).

Worse comes to worse, I setup a Pi and move the Node.js to there instead.

You’ve neatly summarized like 90% of my environment :smiley:

1 Like

Did you double-check the device network id matches your mac address?

And did you re-click the save/done button in the SmartApp?

1 Like

Sorry it took so long, I was checking everything. The MAC in the upper section of the picture matches the MAC in the lower section (except for case and the upper lacks the colons).

I setup the SPAN on my switch and found that my tablet never talks directly to my ST hub. The ST folks did a good job, that conversation was encrypted (TLS). So I’m a bit stymied as to why the hub doesn’t do anything with the data sent to it. I’m expecting that the bridgeHandler would deal with it. I’ve added more logging but I don’t see anything.

I’m not super clear on what ports your spanning here. As you noticed, the mobile app communicates with the ST cloud (and not the hub). You’re going to need to watch traffic between the MQTT hub and the SmartThings hub.

It might be a good idea to try the docker container first just to ensure that everything is configured correctly and all dependencies are accounted for.

The port I’m SPAN’ing is the port of the ST hub. I’m forwarding it to my Linux server where my Wireshark resides.

I’m about to do another experiment. I’ll let you know the outcome.