So why all the fuss? It sounds like Samsung is cleaning up old ST code. Let the summertime cleaning begin!. So let me see if I’ve got this right, they are removing an unofficial feature that you guys had 2+ years to remove it, but didn’t, and now that the time has come to be deprecated you guys are throwing fits? Nice!
So you are commenting about a feature you don’t even understand, and you felt that was being helpful to insult us?
There’s been a far more pressing feature required since the release of Hub V2 in 2015: Hub and/or Location Migration. It’s been nearly 3 years and the function still isn’t provided. Time isn’t the problem.
There’s a difference between being “open and flexible” and allowing just any customer paste arbitrary code into the system to execute. Believe me, I don’t think that is/was a bad thing, but SmartThings as a company changed significantly in mid-2016 when the CTO was replaced. Why? Because the platform was having serious stability and perceived security issues, so Robert Parker was brought on board to re-architect for the real world.
Far fewer than 10% of SmartThings Customers paste in a Community developed (ie, non-certified, non-published) Device Type Handler and/or SmartApp. Most customers have never even briefly logged into the IDE. Most customers have fewer than 15 Things - heck, most are the few Things that come in the package kits.
Yes: Myself and Alex and a few hundred developers are extremely grateful the platform allowed rapid prototyping, sharing for Beta and iterative development, and even sharing for donations or support fees; but, unfortunately, it isn’t irrefutable that Samsung SmartThings wouldn’t be equally successful without having had this ability.
ActionTiles is an officially certified and published SmartApp, just like the few hundred officially certified and published compatible Device Types from dozens of vendors. These did not, do not, and will not require IDE cut/paste/GitHub access. For the sake of prototyping, lots of developers have emphasized to ST engineers that a method of pre-certification distribution is invaluable. But no such function has yet been announced.
So - I assure you - I’m on your side; as are many of the engineering staff at SmartThings.
But whether I’m just being Devil’s Advocate or just facing reality, Samsung’s plans are (somewhat?) clear: Their definition of “open” for this platform is changing and at least some of the reasons are obvious and justifiable from a business goal perspective.
Increase platform stability while focusing on the overwhelming majority of customers who don’t need, want and/or use ad hoc development features; all while still being an industry leader in openness and interoperability.
To bring this back to the subject of this Topic (Contact Book Feature): Having fewer ad hoc developers means fewer complaints when a feature is deprecated.
Hopefully certified SmartApp developers will be given better notices and accommodations for deprecations, but I won’t pretend to be that optimistic either.
That’s was the PR line from Alex Hawkinson (ex-CEO) and other former executives of the independent SmartThings subsidiary. I doubt it was reality - but even if it was… This is a substantially different management and company now. They still genuinely use the word “open” - but the details are important and purposefully different.
What’s so hard to understand about a contact book? Had no intention to insult you or anyone else, am sorry if I did. You guys seem so intense and rather
melodramatic about a feature that no longer exists, unless you activated in a very brief period a long time ago.
@tgauchat, thank you for your clarification.
It’s really a shame that something as simple as targeted notifications were never really a supported feature – along with user permissions. I really hope that webCoRE is a officially certified and published app – because in all honestly, webCoRE is the rules engine that makes the SmartThings platform do all the things easily. ActionTiles is a great interface for controlling the home. I use both extensively, and would be in a real pinch if either of those stopped functioning.
We’ll all find a way to get around the issues presented by the removal of the Contact Book, but I think it’s important that the @SmartThings staff knows that this hasn’t been handled well and us long timers would appreciate greater effort put into communicating things of this nature in the future.
It is not.
SmartThings is working on various Automation / Rules initiatives (they hired WebCoRE’s creator: but did not acquire the “product” itself), and Samsung has expressed multiple innovative visions for automation for a couple of years. The details are irrelevant, because they haven’t been implemented even in PoC form.
Pardon me iterating my point: WebCoRE is extraordinary and its value - to its users, including yourself - is unquestionable. But, really, only a very small fraction of all SmartThings customers use it. Even if published, I’m personally convinced that Samsung management does not think it is suitable for any substantial part of their target market.
Your right about the part about being intense. probably more so than I should be
I’m just irritated because I finally have everything functioning like I want in my home and now I need to restructure, and I believe they didn’t need to target this specific feature for removal at this time.
Even now it’s available for any user to enable the contact book using a certain URL in the IDE. Once you added a one contact the contact book management UI was present in the mobile app.
For users like me, it gave the ability to restrict the notifications set to my wife.
I think this decision really boils down to this. A very small percentage of users have/had contact book setup. Someone at some point decided it was fine to inconvenience that small % of users in order to (hopefully) move forward with their future development. And honestly, it sucks, but I get it. I can’t say i’m surprised since it has been a hidden feature for so many years. At the end of the day they are a business and will do what it takes to bring features to market that the majority of their users want in a way that is easy for them to use.
How do I put in multiple phone numbers to receive SMS’s for “intrusion, Smoke, Leaks and Customer” I thought before you could select as many of the contacts as you wanted but it looks like I can only put in one phone number.
I guess I’ll just offer my 2 cents- it wasn’t hidden. All of the documentation tells us to use the contact book when coding but to make sure it is backwards compatible for users who don’t set it up. Regardless of how many users used it or not (it was a way better way to handle notifications and right there on your phone), any of us trying to be good developers would follow SmartThings’ own guidance:
All mine are backward compatible, but the non-contact book methods are super limited. You have to code specially to send a SMS to more than one phone number, and everyone must get the Push if any one person wants the push.
I’d say this sucks doubly since SMS messages don’t go anywhere when you can’t connect to the cell network and only have internet connectivity, so you have to use push. A workaround to that is to have it SMS a Google Hangout number and then have push notifications for that turned on, but it’s wonky. I spend a lot of time abroad in this exact situation.
I just updated two of my smartapps to handle this. None of the documentation gives an example of how to do it, so I’d doubt many smartapps out there can handle it. Not that you want to change all your stuff, but my Super Notifier app should be able to handle a lot of the notifications you’re trying to get and now allows multiple SMS numbers. If it’s missing a capability, I should be able to add it for you too.
@tgauchat, you make great points and seem to have a good deal of insight into the inner workings of Samsung’s SmartThings. Thank you for taking the time to do a much better job explaining what they have failed to. It is greatly appreciated.
So now the real question… Can we find a way to replicate the basic feature set of the Contact Book externally? I’m open to ideas.
I’ve always believe there should be a Capability “Notification” which allows the Customer to create instances of various types of Notifier Methods: SMS, Pushover, PushBullet, Email, TTS Speaker, Carrier Pigeon, and so on.
Since a Device Type (e.g., a “Pushover Notification Device”) can have unlimited instances, you could create one for every person: Perhaps spawned as child devices.
Since a SmartApp can easily take mulitple instances of a Device, any SmartApp could easily loop through a set of Things of Capability Notification, and send a notification through this abstraction layer not knowing the eventual transport. i.e., the same message “Water Leak!” could be simultaneously sent by SMS, Pushover, Email, Speaker, … and Carrier Pigeon.
Surprisingly, this official Capability exists (or did exist?), but I have not seen a single SmartApp use it:
A great idea for Classic, however “Notification” does not show in the new documentation
Good observation, @arnb.
I will point out that the new documentation is definitely in “Beta” and it changes frequently.
Whether or not Capability “Notification” will be retained or deprecated is unknown. I don’t think its chances are very good, because I don’t know of any existing SmartApps that use it. But the new API’s paradigm is supposed to streamline the ability to request the addition of new Capabilities; i.e., there will be an opportunity to have it added back, if developers actually commit to making use of it.
Underlying point: SmartThings’s foundational architecture is pretty damn good - but without enough enthusiastic and persistent Developer Evangelist / Advocates, it has never been used properly and optimally by most developers. That may change under Samsung.
When you have this concept:ready for Beta testing, I’m available to test it.
Personally I am unhappy about losing the Contact Book, the remaining options are rather poor in my opinion.
I’ve spent the last couple hours working on a potential solution for web core routines. I started with using global variables so I only had to change a number once for all routines. Works ok but you can’t easily see everywhere a number is used.
Then I came up with another idea and gave it a quick test. It seems to work fairly well. Then I jumped back here and saw @tgauchat had suggested the same thing while I was toiling. That was to use a new device type for the contact. I had created mine with name, phone and email attributes.
I’m fairly new to coding this stuff so I did it crudely, to see if it worked, by creating the DTH, contact devices and a small webCoRE routine to load the contact devices (I’m sure a more experienced person could build a parent/child setup that is cleaner).
Then in my main webCoRE routines I sent SMS notifications to the “contact” device using the PhoneNumber attribute I had loaded in each contact device. (I did have issues with loading the number unless I used the (999)999-9999 format. It always wanted to load it as a long number or something which totally changed the value. )
It all works pretty well on my iPhone 6 but seemes to be very delayed on my wife’s iPhone 7. Need to do some more investigation on why.
Nice thing is I can see every webCoRE routine that each contact is used. Wish I had a similar solution for the standard smartapps.
The real reason is maximizing ROI. Your point is well taken, but (probably) secondary.
Hey guys, I haven’t been active on this forum because I have migrated to Hubitat but stumbled upon this thread. Sad to see this happening but not surprised and it’s one of the main reason I jumped ship back in February.
In any case, I thought the code below might be at least helpful and inspire the talent over here to find their own workaround. On hubitat we don’t yet have a mobile app so @ogiewon came up with this DTH. It works great as a notification system using the speech and notification capabilities. Take a look and adapt it to ST as needed. There are also Pushbullet and Join versions of this in the Hubitat forums.
We can’t keep complaining about ST without bringing this up!