In your current configuration, when you make a change in the SmartThings app to the device, a JSON-formatted MQTT message like this well be sent:
{“Dimmer”: 50, “POWER”: “on”}
on topic ‘cmnd/tasmota_5A3575’ . Be careful the upper/lower case of your keys is correct.
You’ll have to verify that your tasmota device is expecting that.
After an research about Tasmota firmware, here is the conclusion.
By default, Tasmota expects to receive a simple text-only command like on, off, or toggle and not a JSON-formatted MQTT message like {“power”:“on”}. In contrast, upon receiving a simple-text command, it will reply with a JSON MQTT message.
So, to input any command as valid JSON it is necessary to use the json command in the Publish Topic: cmnd/tasmota_5A3575/json
example: cmnd/tasmota_5A3575/json {“Dimmer”: 50, “POWER”: “on”}
Now works like a charm.
Thank you Taustin.
Any chance someone can use this to create a ratgdo driver?
Should be possible, yes. If the discovery handler can deal with door devices, it may possibly be pretty simple. Hardest part is probably setting up the broker on a machine somewhere.
Hi @TAustin,
Thanks again for these great edge drivers! Very useful. Something I was wondering, would it be possible to have a “Garage door” device available in the mqtt device creator device list? The shade may not always be an ideal option for a typical “DIY” garage door opener setup.
Many garage door openers are operated by a momentary button push. The same input signal to the door motor serves as open and close (and often pause), depending what is the status of the garage door motor.
In addition to that, the DIY setups often include a separate door open/closed sensor. So if I tried to use the “shade device”, and wire my open/close sensor signal to “shade device” open/close action, and use the “publish changes” to drive the door motor, then any time the door open sensor malfunctions (eg, shows open because of bad contact, etc), the shade device would receive open signal from the door sensor, publish it, and the door would open. Maybe the script managing the door opener and the door sensor could check if there was recently a sensor status change coming from the door sensor, and then avoid operating the door, but the implementation gets complicated and may be prone to security risks. What makes things even more complicated is that the garage door is frequently operated with a completely separate RF remote by my spouse, so the open/close signals can come from external sources as well without the smarthome system having any knowledge if this.
What I would suggest is a generic garage door device that has 3 values: “OPEN”, “CLOSED”, and “OPERATE”. “OPEN” and “CLOSED” mqtt messages only change the open/close status shown on the device card. These values only ever changes when the “OPEN” or “CLOSED” message is received from the mqtt network. The button on the device card (similar button is on the shade device) would (in contrast to shade device) only be connected to the “OPERATE” message. Ie, pressing the “OPERATE” button could be set up to publish “OPERATE” message which would drive the door motor (but clicking the “OPERATE” button would not change the device card open/close status - this would require a signal coming from the door open/close sensor through “OPEN” or “CLOSED” message.
I hope my explanation makes sense. Please let me know if you have some good existing solutions I may have missed, or if my suggestion makes any sense. Cheers.
First, thanks for your hard work so far. I’ve been living without my many MQTT devices since the deprecation of groovy. I had written a lot of my own drivers. I’ve been able to get switches, motion sensors and water sensors working just fine.
The one thing really missing that I would need is RGB(WW) lights. I may fork and work on it myself, but if you’re already working on it, let me know.
do we need a specific code or something? I get “…not have permission to access the specified invitation” when trying to add your channel.
There was a problem with the ST platform over the last few days affecting channel invites. It appears they have fixed it and you should be able to access the invite now.
My thanks again @TAustin
I have been taking the ‘if it works don’t fix it’ approach to my existing lantrigger/edgebridge setup, but a hw failure took out my edgebridge server & I wondered if anyone had an mqtt solution … 30 minutes later and MQTT Devices is humming along nicely 
hi @TAustin im having a problem trying to get humidity mqtt to work its driving me crazy,
the topic is tele/octoprint/plugins/enclosure/dht11
json is set to humidity.value
but im not getting anything .
any help would be great .
thanks
martin
All I am new here and new to MQTT but have been working with SmartThings and multiple home automations for many years. I found this topic and related based on a problem I am trying to solve but after all of my research, I am not sure that the solutions I have seen here will help me accomplish what I want to do or if I simply need to buy a zigbee antenna and use zigbee2MQTT. I was hoping to use MQTT and some of the wildcard capabilities to make my updates more dynamic and “permanent”.
I have this switch Xiaomi WS-USC03 but labled from Aqara and have it integrated to my ST hub. I want to be able to modify this property: “Flip_indicator_light” for every switch I install. There will be a dozen or more. This is not something exposed in ST. In the doc linked above, it indicates modifying the value using a zigbee2mqtt command so that is what led me down this path.
I have an MQTT broker set up and have integrated Todd’s Device Creator and Discovery drivers. I was going to work on the SmartApp next but I don’t think any of this will do what I want and need some guidance. It looks like the SmartApp will take states from the current properties of the switch and publish them on MQTT but it does NOT look like anything in the chain will pick up the new properties that I place in MQTT and translate them back to the switch integrated with ST.
As far as I know, the switch does not have a direct MQTT integration of any sort so I would need to go through something in ST to get the commands back out to the switch if I understand correctly.
Can anyone validate my thinking or send me off in the correct direction?
Hi @TAustin ,
I’ve just installed MQTTDevice on my smartthings and I’m not able to get the connection to my MQTT broker (Mosquitto installed on my raspberry pi). I don’t have any pwd/user setup and I’m using my RPI IP adress:1883. I have many automation running on Node-Red and already using MQTT locally on my RPI.
I’ts the first time I’m trying to connect to my broker from outside the RPI.
Any idea of what I should try to make the connection?
Thanks
@TAustin, I’m still hung up on these icon discrepancies. I did a little digging through github. Do you think removing the meta data from dimmer profile yaml will make it select the same icons as the switch?
For example, deleting:
metadata:
ocfDeviceType: oic.d.switch
from:
As I don’t see the metadata in:
https:/
/github.com/toddaustin07/MQTTDevices/blob/main/hubpackage/profiles/mqttswitch_v2b.yaml
or:
https:/
/github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/main/drivers/SmartThings/philips-hue/profiles/white.yml
And both the hue dimmer and the mqttswitch uses the same icon even though the hue dimmer is category light and mqttswitch is category switch.
Additional info from this thread:
https:/
/community.smartthings.com/t/list-of-compatible-categories-ocfdevicetype-used-by-smartthings-skill/262388/3
So it looks like this metadata, ocfDeviceType is not used in the default edge drivers and this metadata has higher precedence to select icons.
Please look into this if you can, and thanks so much in advance if you do.
(Sorry, for the multiple broken links. I can only post 2 links in my response)
When I was setting this up the key seemed to be setting both of the following:
listener port
allow_anonymous true
This is a good simple page to refer to as well: Quick Guide to The Mosquitto.conf File With Examples
For me it works if I do not specify the port in ST. I’m also using the default 1883. Also, you may need to modify your MQTT broker settings to allow connections outside the local machine. See the config for Mosquitto in my instructions: GitHub - hokkanen/st-mq
edit: Looks like @Al_Maslowski-Yerges already suggested this. 
Small update to this. I set up my garage door openers, and it works better than I anticipated. I didn’t realise the shade device only publishes the message if the shade status originates from ST. That means I can use the subscribe topic to listen for the garage door sensor status, and use the publish topic to send requests to open/close the door. Great!
The only remaining (tiny) improvement suggestion are setting up an option to decouple the “Open/Closed” status from the ST button, so that the user could rely solely on an external “Open/Closed” sensor. Now, the device status changes to “Open/Closed” even if the cover do not open or close. Additionally, the history logs occurrences named as “Shade level”, " Window shade", etc. I think it would make sense to change these to something like “Cover status”/“Cover level” to be more generic. But these are really small things, I’m pretty happy with my setup now, thanks @TAustin.
Maybe all are busy with holiday’s with family and friends. And you should be! However, let me try this in easier to read bullets and summary form:
I have all of the Smart App, MQTT Devices, MQTT-Discovery apps installed and integrated with my MQTT broker successfully on my local LAN with Raspi and an Aeotec SmartThings hub.
I believe I have learned that these apps all provide some aspect of integration across other platforms (HA, Code-Red, etc) and devices which can publish and subscribe to MTQQ messages on a broker.
i can see and publish messages without issue from any device on my local LAN.
The Smart App publishes state changes from covered ST devices onto the broker without issue.
Assuming this is all correct, I have not been able to get any action to take place on a standard SmartThings device from publishing to any topic either manually or through an app onto MTQQ broker.
In fact, the devices created either automatically or manually through the @TAustin apps also do not update state based on messages published to the broker.
Not sure what to check or where to start. I have not found any diagrams or step-by-step guides that get me past the ability to publish and subscribe from the broker and to actually execute an action on a standard or virtual ST device.
Hi - glad you found a solution. I’ll consider your suggestion for my next update. Thanks.
For any other newbies who find this, my problems were all related to JSON with MQTT and getting the topics and payloads correct and formatted as expected. This site was helpful Using MQTT APIs For IOT -Beginners Guide
my search-fu isn’t working well, can anyone explain/link to what setting I need to make on my Mosquito broker running in Home Assistant in order for this driver to see the devices it has?
