Yes. Right now, node-red sees ‘smartthings/device_name/device’ coming in. I assume that doesn’t change, ro if it does, I can change it to whatever the mosquitto logs come up with.
If I’ve understood the above - I’ll try and summarise below
- You currently have 2 IKEA remotes in smartthings, nothing else - these are ZigBee devices
- Your main home automation platform is node red, you currently have that integrated into st so that you can use your IKEA remotes inside node red.
- You got an email about the change, and removal of groovy.
- You want to keep the remotes in st, but have st integrated into node red.
If all of the above is true, here’s what I think you need to do
-
For the IKEA remotes, they should automatically switch to an official edge driver at the point of the switch over as long as you are currently using the official DTH for them. You could install the edge driver now and switch them over yourself if you wanted.
-
For node red, you need to make sure the integration you are using works as a modern smartapp that you host and secure using ngrok. You can use this one node-red-contrib-smartthings (node) - Node-RED I think.
I hope this helps
1 Like
I’m glad you’re helping here, thank you! I’ve kind of lost the plot…
3 Likes
realy struggling with mqtt at the moment ,
when i press the inject node i get
fron the in node so something is being sent ,
nothing is being received in smartthings ?
have smartthings mqqt settings with username and password and topic -smartthings/switch/fan/on.
any sugestions would be great
thanks
martin
forgot to mention im using node-red-contrib-aedes broker
Should the topic have “/on” or is that the payload, seems to be duplicated?
Hi! Thanks a lot for the MQTT edge driver, it helps a lot in my setup by integrating Smartthings and Home Assistant: I use webhooks to send updates from ST to HA (thanks for that driver as well!), and MQTT to send updates from HA to ST. It allows me to integrate my LG TV, ecobee thermostat, electricity hourly pricing between two smart home systems using virtual devices.
However, there is always a however: sometimes MQTT messages from HA to ST never go through. There is a workaround: I go to MQTT Discovery and push the reconnect button, and usually it works 12-24 hours straight, and then it gets stuck again. I tried minimizing the amount of MQTT messages running in the system: first I had them running every five munutes, (I use a virtual level to track the electricity price, rounding it up), so I created a template in HA to only push the new value when the rounded number changes… But it doesn’t help.
Unfortunately, I can only manually trigger the refresh of the MQTT Discovery device, otherwise I’d create couple automations to do that twice a day without my assistance…
Did you notice the same behavior? I can collect logs, but it’ll be my first try collecting logs with Smartthings, so I’ll have to learn a lot 
Or if you can add the capability to have MQTT Discovery being refreshed by an automation, I can use the automated workaround.
PS: ST is running on the Aeotec hub, HA is in Win11/VirtualBox, mosquitto 2.0.15 running as a service on the same Windows machine.
We need to get to the bottom of why your driver seems to be losing connection with the broker, if indeed that is what is happening. And yes, we will need to run logs over a 24 hour period so we can catch any errors that are happening. Do you have the CLI installed? If you can run it on a Windows machine, simply download and run the install file here.
Once you have that, send me a direct message and I’ll walk you through getting the logging going so we can diagnose this.
Are you using the MQTT Discovery/Handler Edge driver? Can you please post your device Settings for the MQTT Discovery device so we can see how you have it configured?
Did you actually get the MQTT switch device created already? You would have had to do that by using an MQTT client like this:
mosquitto_pub -h localhost -t “smartthings/switch/fan/config” -m “create it!”
(Note the actual message payload doesn’t matter. )
If your MQTT Discovery device is properly configured and connected to your broker, once you publish that message, a new MQTT switch device should be created in your SmartThings ‘No room assigned’ room.
Only if you’ve successfully complete those steps, can you expect to have the message published from Node Red trigger the switch device.
@gst is correct. The way you need to send your message is as follows:
Topic: “smartthings/switch/fan/state”
- Message payload = “on”
and
Topic: “smartthings/switch/fan/state”
- Message payload = “off”
This is assuming you are using the MQTT Discovery driver, which I’m not 100% sure of! If I’m wrong about that, please let me know and disregard this and my prior post!
1 Like
broker
switch 1
i can send and receive from node red to windows mqtt app or app on mobile
but thats all
Hold up! You have two different drivers going on the SmartThings side so I think you have things a bit confused.
The driver you are using for your device called MQTT Switch is one that I’ve just been developing, and haven’t even made public yet, so I’m surprised you even found that. I’m going to direct message you so we can sort this out.
1 Like
I’m sharing a new MQTT driver today - MQTT Devices V1 - that addresses a use case not covered by my previous MQTT drivers: specifically, cases where the MQTT topic used by your device or application cannot be configured. One example is Tasmota devices that publish MQTT messages to a specific topic and respond to messages on a specific topic.
How is this different from the MQTT Handler/Discover driver?
The MQTT Handler/Discovery driver requires messages to be published to a specific topic format (starting with ‘smartthings/’), and was implemented as a SmartThings version of the Home Assistant MQTT Discovery feature. It allows for devices that support HA’s implementation to be integrated with SmartThings. Another feature is that a new SmartThings device is created by sending an MQTT message with a specific topic format.
With the new driver (MQTT Devices V1), devices are created within the SmartThings mobile app using a ‘master’ creator device (not unlike my vEdge driver) and then are individually configured to respond to whatever topic string you want. It supports MQTT messages that are JSON-formatted, as well as simple strings.
Initially, the new driver supports Switch, Momentary Button, Contact, and Motion type devices, with more to come. The Switch and Button devices can also be configured to publish MQTT messages when the switch or button state is changed within SmartThings.
For more information, please see the README file in the github repository.
Thanks go out to @gst and @montyfert for being initial testers of this new driver.
7 Likes
Just wanted to say your stuff is amazing! Really good work, and a great contribution to the community. 
7 Likes
thanks for the excelent drivers and all the help
martin
2 Likes
hi @TAustin, is it requires mqtt broker or it can connect directly? I don’t have experience with it. But read than it easier way to connect any device directly to home assistant. Just curious if it has a same way to connect with smartthings ?
You will need a broker running on your LAN. Mosquitto, for example. I don’t know HA, maybe it has a built-in MQTT broker?
Sorry for the delay. I have CLI installed now, however, today I have the MQTT running flawlessly for 36 hours already. I wonder if the hub FW upgrade did something. I’ll ping you in the direct messages if I see the issue again.
1 Like
Thanks. I try to configure V1 in the device settings menu. It requires me to provide a ip-adres with a minimum of 10 characters. What about the following alternative? 10.0.0.9 has only 8 characters 
Is it possible to change this?
add leading zeros?
1 Like
omg I didn’t even try… 
yes, good suggestion, the setting 10.0.0.009 is saved
but no, it can’t find the broker on that IP (Status: ‘Reconnecting’)