Hmmm… That’s fairly problematic. If either the MQTT or the sync service gets restarted and loses track of device states, there’s no good way to know when to call /config vs when to call /state. I’d have to make sure MQTT was set up with persistent storage and then use that as the “source of truth” to determine if a device should be created or updated.
Oh wait - I was incorrect. Just looked at the code and it does do a check to see if the device for that topic already exists and if so, ignores the creation request. So hopefully you are ok.
2 Likes
Great news and lines up more with what I’m seeing in my tests. Thanks!
1 Like
Todd,
It seems almost everyday smartthings stops responding to the MQTT events, it also stops respooling to @hongtat tasmota web requests. This sounds like a general smart things issue, I can reboot and it then works fine.
Do you have any idea why this would be happening?
Also including @nayelyz
Do you have the CLI installed? It may be helpful to get some driver logs?
It’s also possible that you have some network issues on your LAN.
I do use the CLI, next time it happens I will capture the log.
Hello
As always thank you for your great work.
I premise that I am novice with mqtt.
I am trying to integrate with mqtt a shelly 2.5 with tasmota. The device is integrated and fully functional in HA with mosquitto.
I installed the MQTT Devices drive and connected the broker without problems but I can’t figure out how I need to configure the 2 switches of the shelly 2.5.
Could I have an example of the right configuration?
I add that I have other tasmota devices integrated with Tasmota Edge drive, but with this specific device I have synchronization problems while on HA it is perfectly working so I was trying to integrate it in ST in other way
The first thing we need to figure out is what exactly is the topic and message format that the Shelly device is sending out when the relays change state. We’ll need to make sure the message data can be interpreted by the Edge driver, but I don’t anticipate that being a problem as long as the data is parse-able JSON or a simple text string.
Can you find out and post here, then I can advise on the right config for the Edge MQTT device.
I took a quick look at the Shelly docs for the 2.5, and this is what I’m seeing:
shellies/shellyswitch25-<deviceid>/relay/<i> for each relay <i>; reports status: on, off or overpower
So let’s say your deviceid is ‘xxxxxxx’:
You’ll create two MQTT Switch devices - one for each relay (0 & 1)
For Relay 0:
Your Subscribe Topic setting would be:
shellies/shellyswitch25-xxxxxxx/relay/0
Your Expected Message Format would be ‘string’
JSON Key - unused
Switch ON Value should be set to “on” (lower case)
Switch OFF Value should be set to “off” (lower case)
Publish Switch State Changes leave disabled.
Follow a similar setup for the second switch device for relay 1 (topic: shellies/shellyswitch25-xxxxxxx/relay/1)
Thank you. But I think that is the configuration for shelly with original firmware. Anyway I understood how it works and to configure it with the right commands for tasmota, now everything works perfectly. Thanks again for the great work
1 Like
Once someone says “Tasmota,” as the OP does in this case, it means they have flashed the firmware of the device and replaced it with the Tasmota firmware. At that point none of the original Shelley docs will apply.
Use of the Tasmota software was popular in the community for tech savvy people who wanted to use a Wi-Fi device to communicate directly with the smartthings cloud, rather than going through the manufacturer’s cloud.
I know the OP wanted to use the MQTT method, but we should probably also mention that @hongtat does have an edge Driver for Tasmota-flashed devices which covers literally thousands of models.
1 Like
TAustin,
I asked you about Purple Air integration and VOC data in another channel, but as I was reading more online I did see that Airthings has MQTT capabilities and this may allow me to circumvent the cost associated with the Purple API. I was wondering if you could add a AirQuality Detector device type for your MQTT Device Creator.
Thanks,
B
1 Like
Yes, that should be doable. Find out how it sends its data: what topic(s) it uses, data attributes available, and format of data in the MQTT messages (e.g. JSON formatted or simple string).
1 Like
I’m back with a new question 
.
Is it possible to create virtual MQTT switches on HA so you can synchronize it with ST using your Driver?
If yes, can you show me how to do it?
I have tested virtual MQTT switch using ST and RPi Python code.
Using these settings, the information is updated in both directions.
I’m struggling a bit with MQTT Device Creator V1.7, and wanted to check if there were any known pitfalls I might be tripping over.
I’ve got Mosquitto running on a Raspberry Pi on the same subnet as my SmartThings hub, and have confirmed that I can bounce messages off it using the mosquitto-client tools. In Theory it’s still configured to accept anonymous connections, but I was unable to convince Device Creator to actually make a connection when I left the user and password unset.
So I created a mosquitto user – actually, I created two, since Device Creator keeps uppercasing the first letter of the username. I’d originally created the user with a lowercase initial letter, and thought that might be the cause of my connection problems.
Unfortunately, that hasn’t resolved the issue. User, password, and broker IP address are correct (I just rechecked for typos), but Device Creator reports its status as Connecting… and never changes that.
If I try creating a Temperature device, I do get notification from Alexa that SmartThings has added that device. And it shows up in the device list reporting connected (as does Device Creator) even though neither of these is actually connecting to MQTT yet.
Opened the Temperature device and set its subscribe topic to Test/temp_sub. Set the publish topic to Test/temp_pub. Went back to the device’s main screen; it’s still showing status as Not Subscribed, and will not let me move the Set Temperature slider.
When I ssh into the Pi (which also confirms the address), the mosquitto logfile shows it as running (version 2.0.11), listening on port 1883, but shows no messaging activity since my manual tests.
So… clearly something’s amiss in the MQTT connection. But I’m not sure what. Any diagnostic suggestions would be greatly appreciated!
(BTW, it looks like it ought to be straightforward to write an interface from this to the Heyu package which communicates with an old X10 bridge. That isn’t my primary concern right now, but I’ve set up Heyu on the Pi and added this to my pending-projects list. But first I need to get the SmartThings-to-Mosquitto link up!)
In my experience the only thing that helps is that you reboot you ST hub.
1 Like
Should have thought of trying a reboot, I suppose. I’ll do so and report back.
1 Like
Alas, no joy.
Running some tests now to make sure mosquitto isn’t set to local-only. The log says it isn’t, but I want to bounce some traffic through it to make sure.
(Complete side note: I’m booting the Pi from a large thumb drive. Works, mostly, but occasionally there seems to be a timing issue. So I’ve got the Pi’s power on a smartswitch to let me power-cycle it remotely. Sigh.)