Integration Solutions using MQTT

Hey there. Glad you got things working with your esp8266 and MQTT.

Yes, I can add a power device to the MQTT Devices driver. Give me a week or so and I should have it done.

Todd,

On the MQTT Energy device there is a a button for reset energy button on the page. What does this do? Is it publishing something back to the MQTT broker or just resetting locally?

It is only is local reset of the total energy consumption back to zero. It is a function of the energyMeter capability.

So, my device is reporting energy consumption since its last reset, as an example my furnace reports that it has used 880 WH since I reset it yesterday. It looks like the graph in the app is showing the incremental usage by hour. Am I looking at this data correctly?

Yes, I think you have it right. That graph can be rather wonky when it doesn’t get updated at least once an hour.

@ragoss, from your recent posts, it looks like you’ve figured out how to configure MQTT on a Tasmota device. I was puzzled yesterday about the prefix, too, until I figured it out.

In short, I use “cmnd/tasmota_xxxxxx/Power1” as the subscribe and publish topics in a SmartThings device using @TAustin’s MQTT Devices V1.3 driver for a Sonoff Basic. Obviously this is dependent on your MQTT setup, so I’ll describe mine.

I had 20+ Sonoff and FEIT devices flashed with Tasmota using the old Tasmota Connect Groovy driver and then the Tasmota Edge driver. I decided to connect them in parallel with MQTT due to the connections becoming unreliable.

Since I have a Home Assistant instance:

  • I used the easy setup for the Mosquitto MQTT broker in it, and went with the default configuration.
  • On the Tasmota devices in the MQTT Configuration, I only changed Host, User, and Password. I left topic as tasmota_%06X and full topic as %prefix%/%topic%/
  • In the Tasmota devices in Other Configuration, I set Device Name to the likes of “sonoff-11-basic-upstairs-office-lamp” and Friendly Name 1 to the likes of “Upstairs Office Lamp”
  • In the Console of the Tasmota devices, I issued command SetOption19 0 to allow them to be automatically discovered by Home Assistant

Devices were discovered and operable by Home Assistant using MQTT in parallel with SmartThings using HTTP.

To get SmartThings MQTT control:

  • I installed only the MQTT Devices V1.3 Edge driver,
  • pointed it to my Home Assistant MQTT broker,
  • created a switch device,
  • set the device’s Subscribe and Publish topics to cmnd/tasmota_xxxxxx/Power1, and
    [EDIT: It’s better to set the Subscribe topic to stat/tasmota_xxxxxx/POWER and the Publish topic to cmnd/tasmota_xxxxxx/POWER. Stat is better than cmnd for subscribe because then the SmartThings device displays the actual state of the switch, rather than a command it heard on the MQTT stream that the device also may have or may not have heard and reacted to.]
  • Capitalized “ON” and “OFF” in Switch ON Value and Switch OFF Value, respectively.

I was able to get a switch to work with a different set up.

I am not sure what the difference are, but this seems work.

1 Like

I’m reminded now that I forgot to mention that I had to capitalize “ON” and “OFF” in Switch ON Value and Switch OFF Value, respectively.

I wasn’t able to get “stat” to work for subscribe, but I just tried it with POWER instead of Power1 and it works. Thanks! Stat is better than cmnd for subscribe because then the SmartThings device displays the actual state of the switch, rather than a command it heard on the MQTT stream that the device also may have or may not have heard and reacted to.

I left my JSON Key at the default of Switch.Action, which seems to work.

I have been using MQTT explorer to monitor what is going on with the MQTT traffic, this is where I saw the Capital ON / OFF. I am sure there are other tools that do this as well, this was just the first one I found.

image

Good call. Yesterday, I was looking around for it or some other MQTT exploring tool I thought I had installed, but couldn’t find it. So I used the logging in the SmartThings CLI and caught sight of “Power1”, used it and it worked. I gotta install MQTT Explorer.

@TAustin, fantastic work on these MQTT drivers! Thank you.

Does it make sense to set the default Switch ON Value to “ON” rather than “on” (and ditto with Switch OFF) due to Tasmota using capitalized values?

Please correct me if I’m wrong, but my thought is that Tasmotized devices may be the majority of SmartThings devices that people want to connect through MQTT.

I am still learning the MQTT structure but it appears

I think if you use stat/tasmotaxxxxx/RESULT you will get the json “POWER”: “ON”
where with stat/tasmotaxxxxx/POWER you get the literal value of ON/OFF

It appears the json coming from the device is “POWER”: “ON” but this does not seem to work.
@TAustin is this what the JSON is expecting?

1 Like

With the work that @hongtat has done with the Tasmota edge connect, I am really not sure if MQTT is will be used that much for Tasmotized devices. So far I have not really seen any requirement that I have that is not in Tasmota edge connect. There was an issue with contact sensors that have since be added that I would have used MQTT for, if not added. My main purpose in using MQTT is for a power monitoring system I have using with ESP8266 that provides 16 energy monitors I have not found a way to do this in Tasmota). I am working with the Tasmotized devices mostly as a way to learn the MQTT capabilities and syntax. But, I very well may discover other uses. :grinning:

1 Like

You probably don’t want to use /result…here’s an example of a tasmotized wyze plug that I’ve been using with great success.

Definitely use the capitalized ON and OFF for the switch values

1 Like

Yes, functionally Tasmota Edge is able to do everything I need. Reliability has been an issue for me for 2-3 months. I may have pushed it too far with my 31 devices. @hongtat has made the first modification to address the problem. I’ll be testing it for the next few days.

I don’t know if it’s necessarily the case that most of this driver’s users are using Tasmota devices; I don’t have any statistics on that. If I think about it in my next update, I can change it to all caps.

1 Like

Do you have the ‘Expected Message Format’ settings option set to ‘JSON’ ? Looks like @fooktheta has it right and working.

Yes with tasmota it’s a little tricky, since you have to use two different topics for the Subscribe Topic and the Publish Topic, but after a little trial and error, it has been wonderful. None of it would be possible without your great work, it is so very much appreciated!

And I’m happy to help troubleshoot with @ragoss or anyone else that needs it, it’s the least I can do to show some gratitude.

1 Like

I believe that the “tele” topic only get update periodical based on the teleperiod, so by looking at this topic there will be a lag in reporting the status of the device.

From the tasmota documentation website

  • tele - reports telemetry info at specified intervals
1 Like

Hello all,

Just wanted to say “thanks for these drivers !”
I sort of use them to forward sensor state from smarthings to HA.
The way i used it:

  • create an MQTT switch device
  • create a standard automation that sets and resets this MQTT switch based on the real sensor switch.
    This in fact is a really easy “automation”.
    The only disadvantage is that for each “state” you want to forward, you need to create an MQTT device. Personally, i only have 3 sensors to forward.
    I should be using the SmartApp to forward all states from ST to HA but then i need to setup ngrok and a new docker container etc etc which i did not like. The above solution is enough for me.
    Next step is try to automate a switch in both directions from HA to ST and from ST to HA.
1 Like