How would this be any different from a switch? What if instead of having a separate ‘light’ device, I gave you the option to change the icon of the switch device to a light; would this meet your needs?
I have an update to the new MQTT Devices driver. There’s been quite a number of changes made in the code, so I hope I haven’t broken anything for the devices you have already created.
Once you have the driver update (Version 2022-11-16T06:36:16.360248938), you WILL need to delete your MQTT Device Creator (only) and get it recreated with an Add device / Scan for nearby devices. This will enable creation of the new device types I’ve added. You’ll have to reconfigure your Broker credentials and IP in the new creator device. The other MQTT devices you’ve already created should not be affected.
Here is a summary of the changes:
- Added new device types: acceleration/vibration, lock, presence, sound, water (moistureSensor)
- Enhanced JSON key parsing to support more complex notations, including array indexes
- Fixed handling of boolean JSON values
- Added max dimmer value config option to dimmer (create a new device to see the new option)
- Fixed problem with dimmer value publishing
Regarding the sound device - it accepts a numeric value (assume to be 0-100) which is represented on the device Controls screen as a volume slider. There is a Settings option to configure a threshold value at which the sound sensor state will change to “sound detected”. Note also that manually changing the volume slider will not result in any messages published back out, but will affect the sound sensor state according to the configured threshold.
Please let me know if anyone has any problems.
4 Likes
your a star the sound sensor works great thank you very much.
martin
2 Likes
Just got back from out of town - looking forward to testing all of these great updates. They look very promising!!!
1 Like
Must be doing something wrong. Hopefully simple solution. Everything installed well and shows connected & subscribed. Contact device created without issue but doesn’t reflect state changes. IDE shows Last Activity as changed but still nothing changes in the ST device. I did notice in the IDE that seemingly required fields are blank such as “Hub” and “Device Network ID”. Probably normal. Thoughts? Thanks.
The IDE is part of the old architecture and is not accurate for a device using an edge driver. You should be using a different method to check on the new ones, probably @taustin’s API +.
FAQ: Why does the IDE list “placeholder” for my device? Can I change that?
And this:
Can you post your contact device settings?
Thanks guys. Device settings as follows for simple open/closed:
And you’ve subscribed to that topic using mosquitto_sub and see the messages being sent? Do they contain just the simple “open” or “closed” string with no other characters?
Have been running mosquitto for years monitoring this topic with MQTT Explorer where I see state changes instantly. It sounds like I need to run a mosquitto_sub command for it to be recognized? I’ll research and implement. Yes, simple open and closed, nothing else included. ST’s persistence of capitalizing the first letter of everything, including passwords is aggravating but yes, open and closed.
No, I’m only suggesting to use that utility to get a view of the exact message payload being sent. Maybe you already see that in MQTT Explorer- I’m just not familiar enough with it to interpret what I’m seeing. For example, looking at this it looks like the message payload might be “state=closed” and not just “closed” (??)
I’m familiar with MQTT explorer and that won’t fix it. The way it works is that everything after the = is the payload. Let me spin my test broker up and I’ll chime back in after I do some testing.
Ran the mosquitto-sub. Results as expected. For some reason ST is just not picking up the state changes. I’m sure I must have tripped up in the app set up somewhere. I’ll delete and re-install.
Thanks for all the help. Didn’t intend to get you bogged down in this. Much appreciated!
Before you delete, can you double check that the configuration for open and closed are actually open and closed - (not ‘Open’ and ‘Closed’)? I just did some tests and if you don’t delete the ST imposed auto capitalization when you’re creating the config it won’t pick up.
edit: by the way this is no way reflective of @TAustin it is some strange bug on the ST side of things sadly
1 Like
Haha. That’s the first thing I checked when I started this. I first noticed it when entering the mqtt broker host name and pw, mine is not capitalized but I did what you did and forced it to lower case. Even though ST shows it as capital, it did connect. So the states are entered as open and closed.
Good catch…and just to be 100% sure we covered all the bases, that first S in topic is lowercase too? You probably caught that as well but that’s the only other thing I can think of at this point.
Exactly, smartthings, not Smartthings as Smartthing says. 
edit: I even went into mosquitto to make sure there were no trailing spaces after open and closed.
We may need the driver logs to figure this out. Could you download the SmartThings CLI?
Just make sure there aren’t any accidental trailing blanks either in the device settings fields…