So glad to hear it! We’ll be in touch.
Nuki 2.0 is not listed. So sad…
We manage a lot of homes with OwnerRez as a channel manager, have a tech background and know the guys over at Seam. Would love to give you some UI feedback of what the daily life of a property manager looks like. We DM’d you our contact info.
1 Like
Do you have pricing yet?
@Jeremy_Brown you posted a a link to Seam as a list of devices you support so I think you should clarify that you are not developing a Smartthings native Edge app that will run locally on the hub (and work similarly to RBoy in that it will store the schedules locally and be able to activate the codes on the locks locally at the right time)
While a web application on top of Seam will help it will only interface with the locks over the web through the hub.
I just think it is important to highlight the differences in this forum.
If I have misunderstood, please clarify. Thanks
Hi Rich - we haven’t nailed that down quite yet. But, we will very soon. If you haven’t already passed us your email through the site form, we’d love to have you do that. Then we can reach out as soon as we have that info for you.
Jeremy
Just for clarity…
SmartThings Edge is only one part of the new SmartThings architecture and applies only to Edge Drivers, which are the replacements for the old groovy Device Type Handlers.
There are no “Smartthings edge apps“ because we as customers are not allowed to add code to the hub that would run an app.
Instead, the app has to be hosted somewhere else (that could be your own server or a cloud service) and then communicates with the SmartThings cloud through the REST API. These are now called “endpoint apps“ because they are accessing smartthings through a REST API endpoint. Here’s the official schematic:
So there will always be a cloud component for custom SmartApps, although that was also true of the old Rboy SmartApps, as under the old architecture, all custom groovy code ran in the smartthings cloud, not on the hub.
It is possible to write an app that will run locally if you have your own server device and then contact the hub through an edge driver using the local LAN. That still doesn’t make it an “edge app.” Instead, it’s an “edge service.” The community has created a few of these, including one for MQTT integration, one that works with a harmony hub, etc.
You can find these on the quick browse lists in the community-created wiki by looking for the list for “edge services.”
https://thingsthataresmart.wiki/index.php?title=Quick_Browse_Lists_for_Edge_Drivers
So…
Custom smartapps will all have a cloud component under the new 2023 architecture, although they also did under the old architecture.
It’s possible to write something that runs locally, but it won’t run locally on your smartthings/Aeotec hub. Instead, you will have to provide a local server device, and then write both the code that runs on that server, and a custom edge driver to communicate with it.
2 Likes
Thanks for the clarification! You’re right…our product won’t be a native smartthings app like RLA was. But, instead, it will be a web app that integrates with smartthings locks. I’ll revise my original post to make that distinction.
Thanks for your help!
Jeremy
Again, just for clarity, Rboy’s RLA app was never a “native SmartThings app” and never ran on a smartthings hub.
It was a groovy custom smartapp from a commercial third party which ran in the free Smartthings cloud, like all groovy custom code. Each individual customer who wanted to use it had to add it to their own account in that cloud.
The difference was that under the old architecture, individual customers could host this type of code for free in the SmartThings cloud, and now that option is no longer available. Hosting has to be provided either by the code provider or by the individual customer (who can use their own server device or a cloud provider like AWS). The method is up to the code developer.
Communication with the smartthings account is then via the REST API in the smartthings cloud.
The native smart lock feature is SLGA, Smart Lock Guest Access, which is listed under “Services” in the SmartThings app.
@JDRoberts Jeremy, thanks for the clarifying post and follow-up. Can you clarify a bit further… it seemed that once the chech-in/out dates/times were set in the RBoy app they would still be communicated to the lock device even if the Internet was down at that time (maybe I have the wrong impression as I didn’t do a controlled experiment), and if that is true it means that some of the data/logic would have to have been local to the hub. SLGA, which also seems to be local doesn’t have that capability. If I have the right impression of the operation of the RBoy app would that mean that it was part in the cloud part in the hub, or do I have a misunderstanding of how it worked. Thanks
I don’t know the specifics of how the Rboy smartapp updated the locks, but ALL custom groovy code under the old architecture, both DTHs and SmartApps, ran in the SmartThings groovy cloud, which required an active internet connection. So anything that you added yourself through the
IDE. And everything in Rboy’s library.
This has been much discussed in the forum over the years, so there are lots of threads on it.
With regard to locks, the passcodes themselves are typically stored in the lock’s own memory, so they would continue to operate even if you took the hub off power.
But creating/changing passcodes, or any other features done with the smartapp, would require an active internet connection.
AN EXAMPLE FROM PRE 2023 OLD ARCHITECTURE
Under the old architecture, the hub was mostly a box of radios. So let’s say you had an automation to turn on the interior entry light when a specific passcode was entered between sunset and sunrise, and you were using an Rboy DTH and some custom smartapp to turn on lights based on passcode.
A) A person enters the passcode on the lock.
B) The lock sends a radio message to the hub that that passcode was used to unlock it.
C) The hub doesn’t care what the message says. It just knows it received a message, so it uses the internet to send that message to the cloud piece for processing.
D) The custom DTH in the cloud receives the message and identifies the passcode.
E) The custom smartapp in the cloud is subscribed to events for that particular device. It gets the passcode information from the custom DTH, knows what to do with it, and asks SmartThings to use the internet to send a message to the hub to turn on the entry lights.
F) The cloud uses the internet to send those instructions to the hub.
G) The hub gets those instructions and uses its radios to send individual messages to the lights.
———
So, sure, the hub is involved, but only to send/receive simple messages from the lock.
The custom code, including Rboy code, that made the decisions about what messages to send and when, and what to do with messages received, all ran in the cloud.
Under the new Edge Driver architecture, step C gets skipped and Step D runs on the hub instead of in the cloud. But that’s just knowing which passcode was received. The logic for doing something based on a particular passcode still requires a custom smartapp. And it still gets passed up to the cloud using the internet. Step E) is handled somewhat differently, but it still isn’t running on the hub. And then F) and G) happen just as they always did.
SOME NEW ARCHITECTURE OPTIONS
There are multiple other brands of home automation systems that don’t use a cloud piece in the middle of the eventhandling process the way SmartThings does. They’re just designed differently. They still use the cloud for voice control or remote access or sometimes initial device setup, but they don’t have anything like step E above where messages have to be passed up to the cloud to get processed.
In the new architecture, it is possible to have the SmartThings hub pass a message locally to another system and let that system handles the decision making. And then pass a message back to the SmartThings hub so it can send out device control messages locally. so instead of the SmartThings hub being a box of radios for the ST cloud it becomes a box of radios for a different local home automation system.
That’s all doable but requires additional devices, additional code, and probably some technical expertise to get all the pieces up and running. And I haven’t seen anyone do one for locks yet.
But it could be done with the new architecture. You could run SmartThings and Hubitat or Home Assistant or Apple Home or another mostly local system and remove a lot of the internet-dependency.
But that’s not how the old Rboy code worked and it’s not how the new options that have been discussed in this thread so far work, instead, they all have a cloud piece where the logic runs.
Oh, and the SmartThings mobile app itself, old architecture or new, always requires an internet connection to communicate with the hub, even if both the phone and the hub are on the same WiFi network. They didn’t have to design it that way, but they did. 
=======
Sorry for such a long answer. That’s what happens when an engineer answers a question. 
TL;dr : under the old architecture, all custom groovy code, including code from Rboy, required an active internet connection. It ran in the cloud, not on the hub. As far as custom code goes (anything you added yourself through the IDE), the hub just acted as a box of radios to send messages to/from local devices. It didn’t decide what messages to send or when.
2 Likes
Thanks so much for the clear description! I never really knew, or thought it through, though I thought that what the hub was doing was more than it was!
Now I’m even more convinced that Hubitat makes more sense for lock-security than SmartThings does.
1 Like
@HChanW We always recommend for mission critical cloud applications to have a backup Internet connection. That would serve you better with redundancy than having stuff locally on site that has to be maintained, backed up and subject to failure. With locks, if it is that mission critical, you could put a backup code in. How unstable is your Internet? Do you have backup LTE options creating redundancy?