After a number of months of dabbling, I was finally getting over the initial hurdle in writing a device handler. I got the Hub to send commands to a non-ST compatible device over my local network. And so when I finally start seeing some progress, I begin to also see some strange and inconsistent behavior between the simulator and my ST app on my phone. So, I pull out an older tablet that still has the classic app and it shows a different set inconsistencies. The initial confusion came primarily when initiating a state change in the simulator the new app would not respond to the change, but the classic app would. Even more strange, initiating in the simulator would cause the new app to set the primary attribute set 0, even though it had been clear set to something else on the simulator. On the other hand, when I use the tile to change the value via the new app, it would change in the simulator, but not in the classic. To compound things, when I would change the value in the classic app, it wouldn’t effect a change anywhere else, including the target device. Through this partial evidence, I began to wonder if I was developing for the classic app. I did some searching and found some documentation to that effect as well as an entirely new API that was REST/OAuth based and had an entirely new development environment. This seemed to suggest that my supposition about the classic app was at least somewhat correct.
The documentation for the new environment was just as terse and difficult to follow as the classic stuff. And finally, after blindly hobbling my way through some GUI tunnel for generating the device handler definition, I was was about to deploy to test. But, instead I received some arcane message: “Fail to call service API(Montage)”. Google cannot find that string on the entirety of the Internet. I was stopped dead in my track and after all of this I had little to convince me that the reward was going to be worth the effort.
I’ve spent scores of hours over this past year just trying to create a device handler that will let me let me adjust the volume of my network-accessible home theater receiver throughout SmartThings. I’ve poured through a bunch of code on Github, some very pertinent to my goal, some just for the examples of general device handler development. I’ve spend hours sifting through (what I see now is the classic) documentation. I’ve forced myself to slow and and just read it like a book, only to realize there are often chunks of detail missing that are cause to learn by trial and error rather than complete examples, tutorials or reference documentation. All I have to show for it is a clunky volume slider, that should also be showing other buttons, but for some reason it does not. The documentation is train wreck. The newer stuff certainly looks prettier and more like someone dabbled in something like Bootstrap, but it’s still unnecessarily terse, difficult to follow and the new IDE doesn’t seem to let me do what I want to in the end.
Between all that and some repeated recommendations and warnings that pop up in the new IDE, it really feels like Samsung wants developers who are financially funded and motivated working on their platform. That’s not me. This is just an evening hobby for me and I’m spending far more time figuring out how to use the platform rather than actually using the platform.
Unless someone can point out the super secret documentation and streamlined development environment that just works and lets me spend time developing for the platform rather than scratching my head, I think this ship is really starting to sail. Honestly, I’m really not whining or venting. This is more of a data point for Samsung. But after browsing this forum for quite sometime there seems a lot of sentiment that they are unconcerned. Well, then see post this as another wasted datapoint… unless of course, you have that easy button.
