This indeed looks like a great option - thanks!!
Is it only available through the rules API or should it also be available to trigger using a UI based automation? (Can’t find the latter)
I’m afraid it’s only available through Rules and not the SmartThings app automation routine creator.
Probably not relevant to your needs, but I’ll mention that it can also be utilized via the SmartThings RESTful API interface.
No worries. I will give the rules API a play.
I do have another workaround using your other HTTP WebRequestor device which I use for now, but would like a cleaner integration with less devices involved .
Hi - Wanted to follow up with you to see if things are working or not. My apologies for not getting back to you on the github issue you posted.
Please DM me here and I’m happy to help.
Was there someone here asking for a vacuum/robot device type to be added to the MQTT Devices driver?
I know somebody somewhere asked for this (community, direct email, github?), but I’ve lost track of who it was
Just FYI: It’s been a week reestablishing a working firewall on the new addresses at 170.17.interfacenumber.whatever (old Cisco firewalls are not the most intuitive device available!). But I do now have the Device Creator and a test Temperature device talking and listening to my mosquitto server, on an address in the 172.whatever range…
Two wishlist/confusion items:
- Apparently Farenheit and Celsius temperatures, despite being in different boxes, are a single value. Changing degrees C, from slider or from MQTT event, changes both. That’s fine, but someday I’d like to have a single screen that would both report current temperature from a thermometer and display/change target temperature set on the thermostat. I presume that’s “just a simple matter of programming,” writing a new driver to be managed by the Device Creator. Strictly wishlist; I can develop against this one.
(I presume the reason pub and sub are able to use separate MQTT targets is to reduce the risk of message storms as set and acknowledge chase each other around the system?)
- The Temperature device’s slider range is -90 C to 140 C. The UI widget does nicely say “out of range” if I send it a value beyond those. But for some applications, such as household thermostat, it would be nice if I could adjust the top and bottom, reducing the range and enlarging the touch-target for each temperature so I could hit, eg, 20 F (68 C) more easily when setting it from the phone. (I’m never going to actually want the house reporting temperatures below 32F or above 130F; anything beyond that is out of my range.) Putting parameters for scale on the config page would be nice, if you can do it easily. Meanwhile, it seems I can set in single-Celsius-degree increments by rolling my finger after touching to gradually shift the touch point left or right, so again this is a fairly low-priority suggestion.
Is there no way to get the ST hub to act as an MQTT broker?
I have Nuki, and theres an option to use MQTT, but I would not want to run yet another hub 24/7.
Many thanks.
K.
I wish! Unfortunately there is not a way to do that.
Shame, I wonder if Samsung could add such functionality. I’ll email them with a feature request, probably never happen.
Their focus is on Matter for LAN devices and they probably view MQTT as not a priority. There are other technical considerations why it may not be a good idea to make a broker available on the hub. For example, it just adds another workload and complexity they wouldn’t want to get in to.
I’m not familiar with the Nuki products, but a quick look at their website and it looks like they have a web API available, so there may be other options to get it integrated into SmartThings if you can’t find a driver for it.
EDIT: Looks like you also need something called the Nuki Bridge to use that web API…
I have the pro version which doesnt use the bridge, dont know a lot about web API…is that perha0s something your web requester could work with?
Many thanks.
K.
Yes that’s exactly what I was thinking - but it’s a moot point without the bridge. Unless you can confirm your device supports the API?
If there an option to use an API token, that would be our best bet. Usually anything that requires an OAuth2 authentication would be difficult, if not impossible, to implement in the Edge environment.
See if you can generate an API token for yourself, then we can try to use webrequestor to send the device some commands. I don’t know how popular these Nuki devices are, but it may even be worth considering a dedicated driver for them if the API is easy to work with.
Let’s continue this conversation in a separate private thread, so DM me for your next reply (click on my user icon and click ‘Message’).
@TAustin
The MQTT Devices driver has worked perfectly all the time.
Today I added one MQTT Temperature device.
The Device Creator got stuck in this situation.
Yet a new device was created.
I found error message Required field missing: unit in driver log:
2023-09-17T15:05:34.831354076+00:00 TRACE MQTT Devices V1.7 Received event with handler device_lifecycle
2023-09-17T15:05:34.870627409+00:00 INFO MQTT Devices V1.7 <Device: device id (MQTT Temperature)> received lifecycle event: added
2023-09-17T15:05:34.882919076+00:00 TRACE MQTT Devices V1.7 Received event with handler device_lifecycle
2023-09-17T15:05:34.886101409+00:00 INFO MQTT Devices V1.7 <Device: device id (MQTT Temperature)> received lifecycle event: doConfigure
2023-09-17T15:05:34.902133076+00:00 TRACE MQTT Devices V1.7 Found DeviceLifecycleDispatcher handler in MQTT Devices
2023-09-17T15:05:34.902977743+00:00 INFO MQTT Devices V1.7 device id: MQTT_Temperature_1694963133.861> ADDED
2023-09-17T15:05:34.904170743+00:00 ERROR MQTT Devices V1.7 MQTT Temperature thread encountered error: [string "st/dispatcher.lua"]:233: Error encountered while processing event for <Device: device id (MQTT Temperature)>:
arg1: added
arg2: table: 0x1a5be00
[string "st/capabilities/init.lua"]:226: Invalid value for Temperature Measurement.temperature value: {value=20} error: Required field missing: unit
2023-09-17T15:05:34.952199743+00:00 TRACE MQTT Devices V1.7 Found DeviceLifecycleDispatcher handler in MQTT Devices
2023-09-17T15:05:34.953102076+00:00 DEBUG MQTT Devices V1.7 device id: MQTT_Temperature_1694963133.861> INITIALIZING
2023-09-17T15:05:34.954604076+00:00 INFO MQTT Devices V1.7 <Device: device id (MQTT Temperature)> emitting event: {"capability_id":"partyvoice23922.status","attribute_id":"status","state":{"value":"Not Subscribed"},"component_id":"main"}
2023-09-17T15:05:34.956520409+00:00 DEBUG MQTT Devices V1.7 MQTT Temperature device thread event handled
2023-09-17T15:05:34.969932743+00:00 DEBUG MQTT Devices V1.7 MQTT Temperature device thread event handled
2023-09-17T15:05:34.970790076+00:00 INFO MQTT Devices V1.7 Device doConfigure lifecycle invoked
2023-09-17T15:05:34.972143076+00:00 TRACE MQTT Devices V1.7 Found DeviceLifecycleDispatcher handler in MQTT Devices
2023-09-17T15:05:34.988818409+00:00 DEBUG MQTT Devices V1.7 MQTT Temperature device thread event handled
2023-09-17T15:05:35.561393076+00:00 TRACE MQTT Devices V1.7 Received event with handler device_lifecycle
2023-09-17T15:05:35.565942743+00:00 INFO MQTT Devices V1.7 <Device: device id (MQTT Temperature)> received lifecycle event: infoChanged
2023-09-17T15:05:35.579885410+00:00 DEBUG MQTT Devices V1.7 MQTT Temperature device thread event handled
2023-09-17T15:05:35.580747410+00:00 DEBUG MQTT Devices V1.7 Info changed handler invoked
2023-09-17T15:05:35.581953743+00:00 TRACE MQTT Devices V1.7 Found DeviceLifecycleDispatcher handler in MQTT Devices
Oh boy - thanks for reporting that. This was a change that SmartThings made that required all temperature-setting to now include units. I’ll fix this and push out an updated driver.
I have an idea, but I don’t know if it is feasible
Is it possible to create a virtual device that sends a variable payload to an topic, for example with an automation?
I thought it could be a virtual speaker, we could create a routine in ST that would send a notification to that speaker and then send it as a payload.
It is definitely feasible! There is a capability built into the creator device that allows you to do just that. See this section in the readme file.
This should be fixed now; can you confirm?

This should be fixed now
The problem is now fixed.