yep, succeed: I added portnr to IP address: 10.0.0.9:1883
Status: connected to broker
1 Like
Thank you for reporting. I will change the minimum length to 7.
2 Likes
You’ve really outdone yourself with this one. This is essentially what I’ve been looking for all wrapped up in a neat little package. I don’t think I’d still be on the SmartThings platform if it wasn’t for you and your excellent code. A sincere thank you for all that you do for the community is in order!
HA doesn’t have a broker built in per se, but one can easily use the add-on store to install the Mosquitto broker (as long as you’re running Home Assistant with Supervisor).
3 Likes
Been testing this out for the last hour or so and so far I’ve really only had one hiccup. Looks like there’s a limit of 32 characters for the subscribe topic, and I have several devices that have topics that are longer.
Is the 32 char limit a ST thing, or is it something that you could increase on your end?
Otherwise I’m blown away at how freaking awesome this is!
1 Like
I can expand it. What do you recommend?
1 Like
Thank you for the kind words! 
1 Like
I just looked through a bunch of my topics and there are a few where the data lives several layers deep. I would suggest at a minimum doubling it, if not taking it to 100 just to give that extra wiggle room, as long as it wouldn’t somehow negatively impact performance or cause other issues.
1 Like
Hi @TAustin,
My Knowledge of MQTT is very limited but for me the main issue is having a second always on LAN device plus a smartthings running.
Am I correct in thinking MQTT allows you to subscribe to more information from a device than ST provides as stock?
If a second device is needed then I can’t see the benefit as I might as well run HA again. Not knocking what you’re doing at all as I couldn’t do it.
Also with @JDRoberts pointing out that hubitat already supports this, it’s another knock for St?
Also with @JDRoberts pointing out that hubitat already supports this, it’s another knock for St?
I wouldn’t say it’s a knock. Every system has pluses and minuses, but beyond that, different companies have different target markets.
Hubitat was built by and for power users. MQTT is a natural fit for them.
The vast majority of SmartThings users, however don’t even have a hub. Likely well over 90%. (They have a Samsung smart television or appliance.)
Even of those that do have a hub, ST staff has said publicly that the typical user has fewer than 15 devices and never uses any custom code.
So most ST users likely neither want nor need an MQTT integration. I can understand the company not spending any resources to provide one. 
On the other hand, SmartThings was the very first company to have a Matter-certified device. Matter integration is something they ARE spending a lot of resources on, and is something that their primary customer base likely will care about. 
(This forum, of course is full of power users, and that’s a good thing. We all help each other, and some community developers, like @taustin, do amazing work. That’s definitely a good thing.)
There will be people who find Hubitat more suited to their needs and people who prefer SmartThings. And some who run both. Choice is good.
1 Like
any plans to support a Dimmer/switch?
Hmmm…for me I need MQTT to allow inter-operation between other platforms (mainly node-red)
Node-red is a much more friendly environment for old developers past their sell by dates
2 Likes
OK - I think I will just remove the max characters specification altogether. I’ll get you an update soon so you can proceed with your setup.
2 Likes
I will include that in my next update!
3 Likes
Question regarding the dimmer/switch implementation. Would you want to have a regular switch included or are you looking solely for the switchLevel capability (0-100 value)?
If we were to include a regular switch, then there is the question of how it is linked with the level, if at all:
One scenario, for example, where the switch state is determined by the level:
- If level == 0: set Switch OFF
- If level > 0 : set Switch ON
Another scenario where the level value is determined by the switch:
- If Switch ON: set level to 100%
- If Switch OFF: set level to 0%
OR switch is completely independent of level.
Lots of variations here, so I’d like to understand your use case a bit more. Device settings options could be added to make this behavior configurable.
And one last question: for the dashboard, would you want to see the level value or the switch state? (This could also be configurable.)
1 Like
FWIW, in both the Z wave and Zigbee independent third-party specifications, the on/off binary switch capability and the multilevel are two distinct functions. 0% doesn’t have to mean off and 99% or 100% doesn’t have to be on.
Among other things, this allows you to set the level while the device is off so that it will be ready for the next time it turns on. Historically, this has been a frequent request for smartthings: people want to be able to change the level setting without actually turning the light on. Sometimes this is time-based. For example, between midnight and 6 AM you want the level to be set to 25%, but that doesn’t mean you want to turn it on then. You just want it to be ready to turn on, in particular, you want to be ready if someone turns it on physically at the wall.
So personally, I would recommend continuing to treat this as two distinct functionalities.
The inclusion of the binary switch functionality is required if the device is going to be able to respond to an “all on” or “all off” group command, which is why you see it in the specifications.
2 Likes
That’ll be great - I’d suggest dropping the limit from the subscribe topic and the publish topic for max flexibility.
I second this and look forward to even more functionality!!! You love to see it!
1 Like
yup. Most dimmers remember their last setting. If a dimmer is at 60% and on, and you turn it off by switching it off (not turning it e.g.) and then when you switch it back on the position will be 60% again.
Indeed, two functions, but in one msg.
As per example:
Dimmer 60% and OFF:
{“Battery”:255,“LastUpdate”:“2022-10-20 21:17:11”,“Level”:60,“RSSI”:12,“description”:“”,“dtype”:“Light/Switch”,“hwid”:“11”,“id”:“zwavejs2mqtt”,“idx”:58,“name”:“Keukenblad”,“nvalue”:0,“stype”:“Switch”,“svalue1”:“0”,“switchType”:“Dimmer”,“unit”:1}
Dimmer 60% and ON
{“Battery”:255,“LastUpdate”:“2022-10-20 21:17:11”,“Level”:60,“RSSI”:12,“description”:“”,“dtype”:“Light/Switch”,“hwid”:“11”,“id”:“zwavejs2mqtt”,“idx”:58,“name”:“Keukenblad”,“nvalue”:1,“stype”:“Switch”,“svalue1”:“0”,“switchType”:“Dimmer”,“unit”:1}
Would be nice if mqtt contains e.g. {“brightness”:60,“on”:false}
or {“brightness”:60,“on”:true} or something similar
1 Like
Driver UPDATE: Version 2022-10-21T02:01:51.252609927
Changes:
- Lowered minimum length of Broker IP address to allow for n.n.n.n
- Removed min/max number of characters for all topic strings
- Added Alarm and Dimmer device types
Once you have the driver update on your hub, you still may see a delay in seeing the alarm and dimmer options in the create button list. Try reloading your app to force a cache update, or just wait a bit.
If you still see the old character limits in device settings, try creating a new device.
3 Likes
Got the new driver but got an error after trying to add an alarm…now I just get the cloud with the slash through it.
I have the same picture in ‘select&create mqtt device’, without adding a new device. I think the slashed cloud is there since the update (automatically updated btw). Can’t create any new device. Though the app is still working regarding sending/receiving mqtt as is confirmed by the status ‘connected to broker’.