Some form of add/remove process will be required on/before 12/31/22
For those of us running businesses on these SmartApps that depend on these tools, locations that may be hundreds of miles away, it seems like there’s a few options:
Find an alternative ecosystem with a history of more reliable (or native) support for similar functionality (Hubitat, Thread, etc)
For locks, set multiple backup permanent codes in our locks while things like LUM/RLA are still working, similar to backup key the doormat that would continue to function even if the worst case scenario of losing all connectivity to SmartThings happens
As a short term rental owner/manager, the potential dropping of support of these custom SmartApps on New Year’s Eve is a particularly awful time to pull the plug on anything - both from a logistical/business continuity side, as well as the reality that Samsung support teams will likely be skeleton crews over the biggest holiday of the year and unable to realistically provide support for the thousands of SmartThings users not even aware of these changes or reading these forums who are suddenly locked out or unable to control their homes.
While I love my Schlage locks, I’ve also been testing out newer locks that offer direct API integration, like the Igloohome solutions that work completely offline, yet still offer direct AirBnB integration and duration-based codes.
So as a short term rental owner that uses SmartThings and a developer, I am walking away from SmartThings for the following reasons:
Need for local execution: Many of my custom SmartApps protect my houses from my renters: ex: preventing my renters from turning off the heat in the middle of winter, and water leak detection. Any dependency on remote execution is dangerous. To get these to run locally, I need to use the Rules syntax. As a computer scientist I am appalled at the use of JSON to hold execution based rules.
Lack of Python Support for Cloud Connections: The use of Lambda for event processing, in my opinion, is a good choice; however, restriction these functions to ether Node.JS or Java is short sighted. Although Node.JS is a fine environment, Java based lambda functions suffer from poor Cold Start times. This is a well known problem in the industry and AWS knows it. Python has become very popular in AWS Lambda because of it runs quickly and does not suffer from Cold start issues.
Poor support: It seems that Samsung has abandoned this community. We are the community that helped to make SmartThings a success BEFORE Samsung’s acquisition.
Items 1 & 2 are very poor engineering choices. It makes me wonder what other poor engineering choices SmartThiongs is making.
I have ordered a Hubitat and will be testing soon. If I have to change my locks from Schlage to a better supported solution just to get local execution, better support, etc I believe it is just a cost of doing business or an insurance cost.
I will report back to this thread on my findings and experience with Hubitat.
If there are other solutions out there that people are trying, let’s keep the conversation going on a SmartThings replacement.
Personally think everyone is jumping the gun too easily now that there’s a considerable extension to December. The reliability of Rboy apps over the last 5+ years has been second to none. I’m sure the new edge app will be just as reliable and SmartThings will be happy once all devices are running locally. So ima wait it out.
Rboy’s apps and support over the years have been a revelation, but I suggest those relying on this functionality for a business would do well to have a Plan B.
Your custom SmartApps currently do not run locally, so why is this now a concern? The impetus behind Edge/Lua is local execution, so it seems that issue is resolved now.
Very helpful, thanks. Let us know how you get on personally with your test, especially the locks.
There is a huge thread on Hubitat community stretching back to 2020 discussing all the problems getting Schlage locks to work properly, which led to Hubitat removing Schlage from their list of compatible devices ! Easier to do than fixing the problem, it seems.
Well that’s interesting to know. Thanks. I’ll definitely want to be sure before I install the Hubitat in my AirBNB.
I have had trouble with just one of my Schlage lock locations right along, using SmartThings (inaccurate status reporting, specifically), problems which could easily be attributed to the lack of a very close repeater, as the video emphasizes.
I wonder if that’s the crux of it with Hubitat as well.
I’ll add a (another) repeater to my SmartThings system first, since it appears I have a little more breathing room with the new December deadline.
So, I’m trying to figure out how I will be “hit” by these new changes coming.
I have a IDLock 150 and have been using Rboys Device Handler and this smartapp to control it.
I cannot conclude from reading here, if they will still (both DTH and Smartapp) be working after december 31 or what should I do to continue to be able to program it?
They will definitely not be working in their current DTH/SmartApp form. It seems Rboy is working on another solution but they have been shockingly vague unfortunately.
There are Zigbee and Z-wave Edge drivers that ST has developed. You can find them here:
and take a look at the fingerprint files to see if your lock is supported. I haven’t converted my locks yet so not sure what capabilities are provided by these drivers.
As far as managing lock actions and codes, the only option at the moment seems to be Smart Lock Guest Access and Routines. Both are fairly limited in what they can do with SLGA limited to adding codes to locks (not even able to have a single code operate multiple locks). Hoping Rboy is going to be able to transition LUM into the new architecture at some point as I rely on custom actions for specific codes to trigger a number of different actions.
