Custom device handlers to fool Stringify

It seems that Stringify can be picky about what devices that it will allow you to integrate. Does anyone know what is going on behind the scenes when adding ST devices as Stringify “things”?

I would think that a switch is a switch or a media player is a media player as long as they support the right capabilities, attributes, and commands. How is Stringify finding out that my device brand is not supported? Are they inspecting the name, namespace, author, or some other attribute?

I also think they are inspecting device states and expecting certain statuses because there are cases where Stringify won’t add a “thing” that isn’t active.

Why does any of this matter? I’m trying to create customized device handlers and Stringify isn’t liking them, so I want to know exactly how I can fool them into thinking it’s a supported device. An example is that I’m modifying the Sonos device handler to use for a custom audio device. So far I haven’t been able to spoof it.

Don’t know if anyone here knows these details - maybe the Core developers?

1 Like

This is a really interesting Topic.

Personally, I’d say that if Stringify imposes the limitations you describe, then they are not in compliance with SmartThings’s paradigm (the “Capability” model), and they should not have had their SmartApp approved for publication.

Of course, compliance to the platform standards might not be an official criteria for publication approval. As long as the SmartApp doesn’t have performance issues, the maybe it was found to be OK. Or maybe it was their Silicon Valley connections (some very high profile folks were in Stringify’s management team for a while, until they ran out of cash and luckily were acquired by Comcast Xfinity Home).

I would assume at this point that the integration will not improve… unless SmartThings/Samsung decides to spin up a relationship with Comcast too.

1 Like

I’m still trying to figure this out, but complicating matters is the fact that the device handler I’m using & modifying (Sonos music player) was deprecated in favor of the new Super LAN connect stuff. So I don’t think I can even see the newest device handler. One thing I found interesting in the ‘old’ handler code is a mysterious function named setModel, which sets an attribute “model” with a string. The function is not referenced anywhere else in the code and it’s not declared as a device command. It would be interesting to know if this “model” attribute is ever getting set and to what. I don’t have an actual Sonos to hook up so I can’t investigate.

Is there anyone with a Sonos who would be wiling to check this out?

I’m wondering if ST provided Stringify a backdoor to find out the brand/model…

I’ve been searching an answer for very similar question. SDM (stringify-developer-module) was released in 2017 according to stringify news. This was node.js based implementation targeting RasPi. I tested it on Mac.with some tweak. Hopefully this helps. https://github.com/phyunsj/iot-device-simulator-2-stringify

BTW, according to a stringify engineer (https://forums.stringify.com/t/developer-module-sdm/3403), SDM is not actively maintained at this point.