Yes, but the question was about the app, and the SmartThings app currently always requires an active Internet connection to the smartthings cloud in order to talk to the hub, even if both the hub and the phone are on the same Wi-Fi network. You can see that in the upper right corner of the official schematic I posted.
Again, they didn’t have to design it that way, but they did.
Also, my guess is that almost all device manufacturers would choose to do a Matter integration before doing anything that was smartthings – specific. It’s just a better use of their resources. And a matter integration would give you local operation of the device whether you have a hub or not. But it still wouldn’t change the fact that the SmartThings app needs the cloud.
I’m not going to get into an argument about the SmartThings architecture. I bought it years ago and the improvements are greatly appreciated.
If you wish to use SmartThings and want all local, then utilize a button device to initiate scenes or automations.
Our primary interface used to be buttons. Today, it is primarily Alexa, which is cloud based anyway. I use the app for configuration and not day to day operation.
I was really disappointed when I learned Zwave was effectively being deprecated from ST’s newer hubs. While I may not fully understand all of the technical or political pros/cons, I’ve yet to change a single battery in ANY of my Zwave sensors in 4 YEARS!! (They’re also placed at much further distances from my router with far more physical barriers.) Contrast that with the 2-3x annual battery replacements I’ve had to perform with my functionally equivalent Zigbee sensors which mostly sit within spitting distance of my hub. My zigbee devices also seem to cause occasional ‘hiccups’ (congestion/interference) with my WiFi; not so much with the Zwave ones.
I know Zwave isn’t perfect by any means, but I think there are still some very strong use cases for it. Switching to a v3+ hub would’ve meant dumping tons of devices, replacing them with thread/zigbee equivalents, and potentially winding up with less performant WiFi and even more battery replacements. No thank you! Not a fan of planned obsolescence, especially when it’s arguably regressionary.
I’m glad ST didn’t deprecate the v2 HUB and that we basically achieve (better than) v3 feature parity by simply adding a thread border router onto our network. Easy peasy. ¯_(ツ)_/¯
You got the Quirky Tripper working? I been off here for a year or so. Now i’m confused on whats going on. lol. all i want is my Quirky Tripper to work again.
I have several devices that still have not changed over to Edge drivers, including a Kwikset lock (Smart Code 910). I am reluctant to remove the device because I don’t want to lose functionality if it won’t re-add. Any help would be appreciated.
For your peace of mind … you may want to go ahead and rip the bandage off. Exclude the lock and add it back. Of course, you may need to recreate any Routines that it was associated with. If there are issues, community members will always assist.
OR wait until ST migrates it when you least expect it. Nothing will go wrong… right?
If you do delete and add it back, create a virtual device to use as a placeholder in your routines which you can delete when you add your locks back to the routine. This way the routine won’t get deleted when you delete the lock.
I have Kwikset locks but there all Zigbee and they work perfectly with Mariano’s Zigbee Lock MC. I have heard the Zwave Kwikset locks work with Philh30’s Zwave Lock driver but I don’t have any Zwave units so no way for me to say for sure. I would find the fingerprints for your lock first and then check the appropriate driver yml file to make sure your fingerprints are included.
I got it changed over! Thanks for all the help! It was a Z-wave lock and everything works but there are no additional features/options when I look at the device in ST.
There doesn’t seem to be a separate profile for Kwikset locks, but for Schlage you get quite a few more settings. Additionally, his beta version exposes unlockCodeName in the device panel and in Routines as a trigger.
From what I understand, if it’s a Schlage 468 or 469 lock, then you need to load the Z-Wave Lock PH Beta driver not the Z-Wave Lock PH v1.00 driver for the additional features.
1.00 has the additional lock settings. The beta version fixed a bug in the default lock handler that caused the lock code names to be reset. It also added and exposed the unlockCodeName attribute.
No need to open another ticket because another member’s device was migrated before yours. There is no set schedule that devices of a particular brand are migrated at the same time for everyone.