Unveiling Schlage Door Locks Powered by OwnerRez, Accompanied by Some Creepy Crawly Fixes!

I would also like to know this. Does it use the last 4 digits from the guests phone number?

Marlena, you can configure door codes to be the last four digits of the guest phone number while setting your Door Lock configuration and send to guests prior to check-in.

“There is a 12 character limit to access code names, so we couldn't fit the guest name in there as well and keep it unique so there are no naming conflicts.”

I think this was a bad decision. You should just have it setup by default to only send the code to the device a few days before booking, then deleted after booking. Using this setup it’s highly unlikely for there to ever be a conflict with the naming of each guest. You don’t need to fit the guest name within 12 characters btw, you simply take the first 12 characters of the guests first+last name.

The problem with the way you have it now is that it’s harder to make any edits or even view an entry in the Schlage app itself since then the user would need to correspond to OR first to get the booking number. 

I think you guys have it setup this way because you’re catering to the idea of having the codes sent to the device immediately upon booking. But that shouldn’t even be an option anyway because it creates a higher likelihood of conflict with either the name or the door code  

In one of the OR Facebook groups someone complained about how in the Schlage app you can’t see the guests names anymore. I agree that would be a reason to not switch over since I’d only save $1.40 a month. 

Great feedback all around.  Keep it coming.

Thrilled to see this integration go live! Great work, OR team! 

I echo the feedback about needing the guest name rather than the booking number to appear in the Schlage app. The current RemoteLock standard of using the guest name (even though it cuts off after the character limitation) is far easier and beneficial than a booking number that needs to be cross-referenced. 

Can you clarify/confirm that multiple locks attributed to a single property will all stay synced with the same code even if using the "Generate random code" option? There currently are conflicting comments by OR Team Members regarding this:

While not a dealbreaker, it would be extremely helpful to manage additional non-guest codes through the integration: team members, cleaners, pest control, maintenance, etc. That is a feature that I will miss when I make the switch over from RemoteLock as it's easier to bulk add/edit access to numerous property locks in one place than doing it lock-by-lock in the Schlage app.

TO OR TEAM MEMBER... I looked at the article sent, there is no option to set the last 4 digits... "The "Code length will be determined by the lock" is grayed out and there isnt a place anywhere to tell the system to generate the last 4 digits. I have a guest coming in tomorrow. And I just integrated with this service yesterday and have looked at all your resources and I cant find anywhere how to do this and make sure its the last 4. Please advise. 

It set a 7 digit number automatically and have no way to change it to just the last 4 digits. All our scheduled messages with check in instructions/door code are all last 4 digits. If this isnt something that we are able to set, definitely need to cancel this service as it defeats the whole point of needing control and flexibility. Just also realized the name issue. Canceling. A promising feature with lots of potential but def lacks the most valuable things having door lock integration.

First, thanks for working on this feature. I really do appreciate it and I'm posting this to improve the product. I hope it's taken that way. 

I have two locks. One is pushing 4 digit codes and the other is pushing 8 digit codes. They are both set up the same and have always had 4 digit codes previously. 

Several of us have asked when the codes will be deleted off the lock. Support keeps pointing back to the grace period. The grace period is a setting in the lock that tells it when the code should work. For example, 1 hour before check in and 1 hour after checking. That isn't the same as when the code will be deleted off the device. 

Finally, the decision to use the Booking # vs the Guest Name is flawed. Here's a mock up. Find the Remote Lock guest (John Doe) and the OwnerRez guest (Jamie Smith). 

@Ownerrez and/or Schlage integration requestors:

What was the purpose of spending valuable programming resources on this integration.

I assume that that all the people requesting it was because they thought it would be FREE (ie included in the cost of PMS subscription). I would be curious if there is any other reason.

In my opinion, this integration ADDS ZERO value to OR customers. It is MUCH inferior to the many 3rd party solutions already in place. It costs almost as much $4 vs $5 for Jervis (the least costly) and provides a fraction of the capability.

Meanwhile we have CRITICAL NEEDS that can't easily by supplied by 3rd parties like:

- Integrated INBOX

- Accounting integration that actually works - not just 80%

- Google VR integration

- list can go on....

Can leadership at OR please explain how things are being managed and prioritized - I am sure if you disclosed that you were going to charge $4/mo that 90% of the requesters would have down voted the request in favor of other features. I read threads where people joined over 2 years ago having been promised an integrated Inbox and instead we are creating features where I can't see how they offer anything extra from what is offered from 3rd parties

Can leadership please explain?

Excellent, thank you!!

Does the integration work with Parent/Child listings so I can assign one lock to multiple "properties"?

Hi Ocean Zen,

We don't like to openly debate users on our forums/blogs, so we typically let users talk amongst themselves without responding, but I feel like there are a couple of things you mentioned that should be corrected, or at least a broader perspective added.

1) We have a decent-sized developer and product team now - more than a dozen people in engineering/testing.  At any given time, 3-4 "big projects" are going on with the same number (3-4) in testing.  In and around that, many dozens of medium and smaller-sized features and enhancements are worked on, with dozens more bugs also being fixed.  Our change log updates weekly, with most weeks showing 15-20 updates.  (Again, that's per week).  So my first point is simply to point out that the team isn't spending months "just working on Schlage lock while QB, Google VR, Inbox, etc are ignored".  We are managing a large slate of coming projects, many of which are in development at the same time.

As an example of other big projects...

Google VR has been worked on, internally, for almost a year now and there are almost 1,000 listings from OwnerRez integrated through our Google VR integration.  It has been a difficult integration, but we've been pushing forward and making huge strides.  If you follow our Google VR feature request, you'll see some of that publicly noted.

QB has also already begun some significant changes.  I know this is an area you're passionate about.  We've heard you and, frankly, we knew we were behind on most of that feedback already.  QB is a significant lift that involves a lot more review/testing work.  We were in meetings with accountants, talking about strategy, several times over the past 18 months.  But before that, we've had to change some of the fundamental connection/logging aspects of the integration, so we've been down in the weeds on that part first.

Before Inbox cleanup, we've had to clean up messaging features (like Autoresponder) and work our way through some of the side features so that we can get to the main stuff.  That, too, has already been underway for a while.

Our PM system has a large V2 about to drop that we've been working on for 2 years which changes a number of significant things around commission, expenses, and statements.

I could hit half a dozen other major things, but hopefully you get the picture.

2) It sounds like you see Schalge as a minor thing that no one cares about.  Direct lock integration (Schlage, Yale, Kwikset,etc) has, for a long time, been highly requested by OR users.  Many PMs are paying hundreds or thousands per month to middle-ware platforms to the point where their middle-ware lock platform costs are higher than their entire OR bill, even though we do website, channel management, CRM, automated messaging, etc, etc far beyond simply setting locks.  This was not some minor integration we decided to do on a whim.  If you look at the Feature Request forum, you'll see that Schlage Encode has been one of the highest-voted requests for a long long time - far more than Inbox, QB and other items.  At conferences, a lot of medium and large PMs go on and on about their lock difficulties and costs.  Last year, when we increased our prices, we promised to look for ways to lower the overall bill of users in other ways - lock integration was part of that, given what we saw in the industry.  The $4/month price we are charging is the lowest anywhere and often half of what PMs are paying.  And we priced that to cover our API fees from Schlage plus development/support costs.  If you're a PM with 50 locks, the extra $100-600 per month (difference between $4 and $6-10/lock) adds up.

I am going to mention here that pricing is really hard to get right.  We aimed to cover our API/dev/support costs, and not make it a profit center, but also make sure we didn't regret going too low later.  If you're a PM with a bunch of locks, we absolutely are open to discussing a lower cost as we move forward and gauge adoption. We wanted this to be fast, easy, and get it out there with room to change/negogiate later.

3) I'm curious about your claim that the integration is "much inferior" to other lock platforms.  For those that are Schlage only, this first release has virtually everything you need to manage your locks from a business/automation standpoint.  Our team has been noting down feedback (like the "use guest name instead of ORB number" comments) but the nuts and bolts are pretty solid and baked directly into the product.  Have you used the new Schlage integration yourself and have specific examples of where it is significantly inferior?  If so, let us know, as we've released private betas for Igloo, Hubitat and others coming, and it will help factor into those integrations as well.

There's no doubt that a standalone lock platform (such as our many middle-ware lock partners) will provide a lot more polish - things like notifications for when a guest uses the code - and that's where the value is for users to use those partners.  We aren't trying to replace those partners, nor add a profit center for ourselves.  We are delivering a constantly-requested feature in a bare-metal non-fuss way for PMs that want it baked in.

4) Not all development work is the same in terms of speed and available resources.  It takes a very different design/tasking, dev, review, and testing roadmap for something like QB than it does for a standalone lock integration like Schlage.  Schlage didn't take that much effort relative to other big feature requests.  There is an API cost from Schlage, and some other administrative things we had to get in place, but the work itself rode on top of many other existing lock integrations (eg. how to generate codes, using last 4 digits of guest phone, grace periods, etc).

I hope this doesn't come off as argumentative - that's not my intention.  I appreciate your continued feedback and passion.  Your QB topic is a great example of what I mean.

Does the integration work with Parent/Child listings so I can assign one lock to multiple "properties"?

Yes.

All of our lock integrations, whether OR powered or third party, have a list of door locks, and each of those door locks can be assigned or associated with multiple "properties" in OwnerRez.

Once this is connected and mapped, you'll see the entire list of locks show up on every booking with their own codes, based on your code generation settings.

Can you clarify/confirm that multiple locks attributed to a single property will all stay synced with the same code even if using the "Generate random code" option? There currently are conflicting comments by OR Team Members regarding this:

If you connect one lock and associate it with multiple properties, it should have the same code at all of those properties, even if the "generate random" is selected.

If you connect multiple locks and associate all of them with the same property, each lock will have a different code.  Correction: all the locks will use the same code for the one property.  So when a booking is created, and the booking shows multiple door locks on the overview page, all the codes should be the same random number.

Caveat to that.... If your door locks at the property have different maximum code lengths, OwnerRez will detect that and auto-trim the code to work in each door, so it may appear to be different codes, but this is just because a particular door lock had to be trimmed down.

This is the same behavior that has always existed with all of our lock integrations (ie. third-party lock partners).  The "Code Generation" settings didn't change for Schlage.  We did add some logic to detect what Schlage can handle (eg. length of code, etc) but the underlying logic that creates codes based on random or last-four-of-phone stayed the same.

While not a dealbreaker, it would be extremely helpful to manage additional non-guest codes through the integration: team members, cleaners, pest control, maintenance, etc. That is a feature that I will miss when I make the switch over from RemoteLock as it's easier to bulk add/edit access to numerous property locks in one place than doing it lock-by-lock in the Schlage app.

Great idea. We don't have a task for this, but it would be really simple now that we show the active codes (where you can lock and unlock it, and see the battery) so being able to set/remove codes from on high would be pretty simple.

If you connect multiple locks and associate all of them with the same property, each lock will have a different code.

This is the same behavior that has always existed with all of our lock integrations (ie. third-party lock partners). 

What you just described is not how it plays out in my instance, just FYI. I have been and am still integrated via RemoteLock. For several properties, front and back doors both have Schlage keypads. In OR, I've got both locks assigned to a single property. I use the "generate random code" option (4 digits) and the same code is pushed to both locks for that property for each guest (new code for each guest, but the same new code is pushed to both locks each time). This has never been an issue with my current set up and integration. It sounds like you believe it will be an issue if I switch over to the OR direct integration. Am I understanding correctly? 

I have two locks. One is pushing 4 digit codes and the other is pushing 8 digit codes. They are both set up the same and have always had 4 digit codes previously. 

We are actively working on this.  Here is some back story...

Apparently, for older firmware on certain Schlage models, the code length is determined by the first code you put on the lock. This is typically the admin code you create when you first pair up the lock with the Schlage Home app. After that, every code needs to be the same length. This value will vary per individual lock, and is returned by the API.

In development, we discovered this, so prior to sending any code over the API, we first query the lock info to get the code length, then use that to trim/pad the code length as needed.

As it happens, yesterday, a firmware was released from Schlage that changes this so now the code length can be variable. We are waiting for a response from the Schlage dev team on how we can tell what the new supported code length is there (per lock) before we go in and change things.

To change the code length on the older firmware, you need to delete all existing access codes, and make sure the first one you create is the length you want the rest of them to be.

But this might explain why some people are seeing 4 and some are seeing 8.  It also explains why our team grayed-out the length and said "will be determined by the device".  We will update this when we get word back from Schlage.

Several of us have asked when the codes will be deleted off the lock. Support keeps pointing back to the grace period. The grace period is a setting in the lock that tells it when the code should work. For example, 1 hour before check in and 1 hour after checking. That isn't the same as when the code will be deleted off the device.

We are looking into this as well. In development, we deduced that the device would auto-delete codes based on the end time of the code, and testing did not catch that as well.  We are working to confirm whether Schlage devices auto-delete after the end time or the code list just keeps it there forever.  We will update this as well once we confirm.  If the device does not auto-delete them, we will update the process to do that on our end with a live call.

Either way, from a guest/usage standpoint, the code will not work after the check-out time.

If you connect multiple locks and associate all of them with the same property, each lock will have a different code.

This is the same behavior that has always existed with all of our lock integrations (ie. third-party lock partners). 

What you just described is not how it plays out in my instance, just FYI. I have been and am still integrated via RemoteLock. For several properties, front and back doors both have Schlage keypads. In OR, I've got both locks assigned to a single property. I use the "generate random code" option (4 digits) and the same code is pushed to both locks for that property for each guest (new code for each guest, but the same new code is pushed to both locks each time). This has never been an issue with my current set up and integration. It sounds like you believe it will be an issue if I switch over to the OR direct integration. Am I understanding correctly? 

Ah thanks for that fast feedback.  My understanding from engineering is that it works the exact same way as it did before.  If the property uses the same ONE code for BOTH locks, then it will continue to do that for Schlage.  The underlying "how to generate codes" lock did not change as part of this.  I will confirm this specifically and correct my answer above.

Thanks, Alece!

Thanks for your response Paul. That insight helps. 

Quick follow up. Maybe I missed it but a Low Battery Alert would be nice. I change my batteries at 50% so having the option to set when the notice goes out would be an added bonus. 

Quick follow up. Maybe I missed it but a Low Battery Alert would be nice. I change my batteries at 50% so having the option to set when the notice goes out would be an added bonus. 

We do show the battery level, as you probably know, but you're right - an actual alert would be great since you won't see that battery level unless you go looking.  Same with an alert when the guest uses the lock, telling you that they entered.  There is a lot that can be done, but the first release was about getting a low-cost bare-metal integration out there for everyone to start pounding on.

Thanks to you as well, Nathan!

Ah thanks for that fast feedback.  My understanding from engineering is that it works the exact same way as it did before.  If the property uses the same ONE code for BOTH locks, then it will continue to do that for Schlage.  The underlying "how to generate codes" lock did not change as part of this.  I will confirm this specifically and correct my answer above.

Ok, I was able to get with an engineer on this and we did some testing.  The code generation does not change for Schlage - it's the same as every other lock integration.

Here's a quick pic of us testing it:

(Ignore the purple buttons. That's extra stuff that only OR staff can see.)

We created two different locks and associated them with the same property and set "random" as the code generation setting.  We created a booking, and, as you can see, both locks are using the same random number.

A small caveat on this... If the two locks have different code lengths, the shorter would get trimmed. For instance, if the front and back door of your property both have a Schlage lock but one has a max length of 4 digits and the other is 8 digits, then the random number will get trimmed to 4 on the one lock.  That may look like the two locks are using different numbers because OwnerRez auto-trimmed it to 4 digits, but it will start with the same random number and try to set that in both locks.

I'll update my previous comment to correct this.

Wonderful to hear, Paul!! Thank you so much for digging right in to clarify this!! 

Suggestion: Use guest name instead of booking number as reference. See screenshot. If you need to manually update a code in the lock or change the time if the guest wants an early check-in, using the booking numbers is extremely cumbersome. Remote lock uses the guest name and that is a lot simpler then the booking number. Schlage has a 12 character limit for the name so the last name of the guest will have to be truncated in many cases, but as long as you have the first name it’s still easier than using the booking number.