Hi, I noticed that you have Remotelock integration.
Hence I signed up for a year service on the Remotelock site and I integrated my Vera z-wave locks to the site (they have an integration to Vera controllers). Once this was done, I was able to bring my z-wave controllers into Remotelock and control their locks via that site.
I then activated your Remotelock integration. It connects to the site and when I click on the Property Mapping button, it says "Error getting available locks for account: No available locks in account". However there are six locks on my Remotelock account that were integrated though my vera z-wave controller. Any thoughts?
Encountering the same. Any ideas from the OwnerRez team?
(Maybe there's just a delay in syncing info over; I'll try again in a few hours or tomorrow and see if it works then.)
I talked to the Remotelock team and apparently Zwave is not a lock that they can send through the API yet. Not sure if they will resolve this or not.
On a side note, I have a number of locks on my vera zwave. It grabbed all the locks and therefore I got a large charge as they charge for lock requested. I canceled my account with them (for the reason mentioned above and the fact I was charged a lot). I put in a request to refund my money. After several requests (and responses saying "sure we will refund") it is not going on three months and my account is still gone and no refund. I am still working on it. The remotelock people are friendly, but do not seem to be able to deliver.
It would be great if OR natively allowed us to program the lock through an api directly. I think it can be done with Vera and Zwave, but I would think the API would be complex. Of course I would be willing to be a tester if OR ever wanted to do that. I just don't think a lot of people have Vera/Zwave, (which is admittedly a more techie lock solution than the pre-packaged - simple-to-use stuff you get from August lock, and other home depot / Rona purchased hardware).
Sorry for the delay on this. I wanted to discuss internally because our RemoteLock support is kind of up in the air right now. We support the "old methods" really well but some of the new stuff we don't. As it happens, we are in the middle of upgrading our RemoteLock support to handle their newer APIs and we are adding Kaba as well.
We would like to support Vera and Zwave but it's more complex because it's not just locks but many other devices. The protocol is must more generic than other "just locks" vendors like eRL, Kaba and RemoteLock.
The RemoteLock API lock should fix this soon. I don't have an ETA yet though.
Good news, folks: the RemoteLock API now does support z-wave locks!
We used RemoteLock for awhile. Our challenge was in their pricing model for the number of properties that we have. They do charge by lock (the first element of their pricing) but you also need to keep in mind the number of active "guests" (second element of their pricing)that you will have in their system at any given time. Their pricing structure does not link the locks to the guests... and at their lowest price level (with OR integration) you get 150 guest users, next step up is 300 and then Enterprise is unlimited. With each step up in price level you pay that fee per lock even though the issue is tied to the total number of guests that are needed. The important consideration here is guest count this is at the account level not the lock level so in our case with 30 locks it meant we could only have approx 5 future reservations per lock because the booking goes to their system at the time it is created. We have many more than 150 active bookings in our system at any given time and for us to step up to even the next level it would have made our lock management more expensive than our entire OR system. For us it was a surprise, so if you are going to do RemoteLock make sure you understand how many reservations/bookings ("guests") you will have open at any given time. We are currently testing alternatives as electronic door locks are not going away in this world of contactless checkin.
Hmm. Do you know what the enterprise and other pricing levels are?
Guess your forum software doesn't allow images/attachments, but I'm on a (grandfathered?) VR Pro plan that's $12/month plus $5 per lock. It allows 200 users+guests.
The Business plan allows 100 users and 300 guests for $9/month+$9/lock.
The Enterprise plan allows unlimited users+guests for $12/month+$12/lock.
I'm not quite at the point of needing to upgrade but if I continue to add properties, it'll be a potential issue for me. OR could help this by making when the guest data is transmitted to RL a configurable option--say, "assign a code 14 days prior to stay," and only send the data to RL at that time.
Hopefully by the time I start getting to where 200 guests is an issue for me, you'll have gotten this implemented... :)
That's an interesting idea! Could be good for security purposes too -- no need to generate a code now for a booking next year.
We'd need to come up with a way to handle downstream implications though. Right now there's an assumption that if a booking will have a code, it always has it generated. Some folks have triggers on booking create that will send out codes, and it wouldn't be populated at that point with this option.
I suppose we could make this be default to creating codes on booking creation, and then add a new option for "wait until X days before arrival to generate code". If you chose the option, then it's on you to configure your triggers to match.
Chris I believe the way that the integration with RL works now (correct me if I am wrong - this has been a gray area for me) is that it will reach out to RL to create the code at the time of the booking creation - Doesn't RL have the booking information at this time? Also from a security standpoint it isn't a big deal because the reality is RL doesn't send it down to the door lock until a few days prior anyway. (Many of the locks have restrictions on the number of holding places for codes and if you send them all down to the lock it overlows the lock.)
As far as I'm aware, there isn't an option to only trigger the email/sms IF the lock code field is not empty. So yes it would be up to the individual to control their triggers and you would likely only need to have the data in the door locks a few days ahead of time. The best solution would be to generate the code at time of booking similar to what you do with BRIVO but hold off sending it to RL until X days prior to arrival - perhaps another triggered event to send the doorlock to the RL API for the booking when the conditions (triggers) are right. Not enough to make me go back to RL for their ZWAVE Integration with VERA. We are migrating all 30 properties to BRIVO after testing with them last week and VRScheduler is adding the door lock guest checkout code capability to their app as I type.
Here is the link for RL pricing. At a minimum you have to have Premium to use the OR lock integration. Sorry this link doesn't show pricing unless you are logged in... Sorry Ignore or admin delete this post.
I am at the opposite end of the spectrum from PacViewLodging as I am only a ‘little guy’ who is now down to one property. However, I do have a great interest in home automation (for both personal home and my vacation property). I have a Vera Zwave device at the vacation rental that has been working for many years and it nicely controls all my lights, my pool, and the 5 separate outdoor locks.
As per the earlier part of this discussion, I did end up going with RL to manage one of my five locks on the property (the main door one) because of the OR integration with it. Yes, I would have liked all my outdoor locks to be managed, but RL has a crazy scheme (as mentioned by PacView) that charges per lock and it is $6 per lock. So, managing the main door is my tradeoff of $6/month vs $30/month. The convenience of the integration is work the $6/month for me even though I only have the one property.
The integration works the way that PacView says. During an OR booking the code is generated and sent to RL immediately. You can see the booking and code and dates on RL and you can also see that it has not yet downloaded the code to the lock. This is to avoid overloading the lock … which I believe mine has a 50 code limit from Vera… from being overloaded. At the 3-day mark, RL downloads the code to the lock. The integration from OR -> RL -> Vera is impressive. Any changes in OR (even in check-in times) are cascaded down to the lower systems almost immediately. Even if RL has updated Vera (within the three days) changes are cascaded down. If the Vera is down, RL keeps trying and will warn me up update failures. This works out well within my messaging strategy to my guests as I use the OR generated code at certain trigger points. I have little (or no) reason to ever change it.
As I said in another post, I would love to work with OR to develop its own API to update the lock through Vera. The API works flawlessly from RL so it certainly exists and works well. I am just not technical enough to understand it. I know because it is a lock you need to go through the Vera servers with authentication to update it and RL has certainly implemented that well. If OR had an API for Vera it would be nice to avoid the monthly fee to a third party. However, as I can imagine from OR’s perspective, it really depends on how many people have a Vera that controls their locks and if it is worth it.
Just wanted to circle up here and mention that we have recently added the delayed code generation option: https://www.ownerreservations.com/blog/last-4-of-phone-for-door-code-autocreate-listing-sites-cleaning-fees-on-statements-charge-snapshots-delayed-code-generation