Yeah, that’s a function of having so many “options” for codes being enabled. You can remove these and rerun the setup. But unless it’s slowing your device down, there’s no need. If you use a good naming scheme, you can avoid the noise in the developer tools.
I’ve been thinking about that. If we could provide a text editor or form, people could check which permissions they want.
How many locks are you using? How many units? Do any of the units have multiple locks?
Ideally you would setup an integration for each lock, and if you have multiple locks per unit you would “slave”each lock to the “master” lock. That way you only have to set a code one time. However I recommend you start with a simple approach.
- Create 5 or so slots for each lock.
- Make slot 1 on every lock the “owner” slot, active 24/7/365. Use the same code for every lock. Protect this number!
- Slot 2 should be for cleaners. Make it active on any schedule you wish or 24/7
- Slot 3 for maintenance. Activate it on an as needed basis (date range) or 24/7
- Slot 4 for Guest Smith. Active on occupancy date range. Give them extra time for checking out so they don’t get locked out
- Slot 5 for Guest Jones. Active on their date range.
As Guests stay expires, you can clear their slot or overwrite them with new Guests.
You would do the same for every lock. KeyMaster is essentially a database of locks and codes. This approach would require you to setup the business slots on every lock. But you could slave the locks to a master lock and only have to program them in a slot once. You wouldn’t slave guest slots, those would be programmed individually.
1 Like
We currently have 14 units (about to add 2 more), only one lock in each. Yes to the basic strategy you’ve laid out. I was thinking 10 slots though (that’s really neither here nor there, but we have multiple cleaners).
I envision each unit running it’s own instance of HA on it’s own mini PC/whatever in the unit. Ultimately what I want to figure out how to do is integrate with the booking calendar so that KeyMaster automatically programs the codes as the reservation is booked and then deletes them once the reservation is over (or overwrites expired ones as needed with new codes).
So basically the current version of KM has everything I need currently except for the calendar integration and auto-programming.
Personally I think having that many instances of HA would be a pain in the ass. If the units are close to each other and/or share common walls you probably could get away with a single instance of HA. I take it all of your units are on the same WiFi network? I use HA with LetsEncrypt in Docker, so my HA is accessible on the internet via http://HomeAssistant.example.com, but I also had to setup a reverse proxy. If you have multiple instances, I don’t know how you would implement it. I suppose you could do HAunit1.example.com, HAunit2.example.com. Still seems like a pain. I’d look into how feasible it would be to have all of your locks on the same Zwave (not WiFi) network and use only one instance of HA. You might have to install some Zwave light switches to increase your range. Others on this forum can help you with that.
As far as having your booking system create a code, I’d have to discuss this with my KeyMaster colleagues on the feasibility. I’d imagine we could create a function or webhook your booking system could use to add/delete codes, though a lot of that depends upon the capabilities of your system. And while we haven’t taken a single penny for any of our work, I can’t in good conscious ask my fellow devs to spend time on this without at least a small remuneration. If there were a “free” way of doing it now (there still might be) I’d certainly help you. We created this for our own personal usage and then to help the community. But let’s make sure you have the basics in place before we start seeing if this can be automated by your booking system.
FutureTense,
I would be wary of taking on any more scheduling functionality. Booking systems have a lot of edge cases to deal with, and I would be surprised if you could build something that would make everybody happy. The use case a few of us are talking about hits the intersection of people’s money, various laws, security, etc. I wouldn’t let it guide your design decisions because I’m pretty sure the 95% use case is one or two locks at someone’s house.
The most useful interim functionality would be the option to remove the scheduling functions that are in place, but I have no idea how difficult a task that would be. Frankly, your software most likely functions damn near perfect as is for almost everyone that uses it.
IMO, the complex scheduling should happen outside HA. There are plenty of ways to set the appropriate variables from outside HA right now. I use webhooks and the Remote HA integration right now, but I’m moving to MQTT just due to distributed nature and number of devices.
Relax, any of the customizations I might do for Lynn shouldn’t effect anyone else. They would simply be ways to program slots with webhooks.
Well what is complex scheduling? In KeyMaster a slot is either active or inactive based upon its slots settings and the environment. Like when the clock hits midnight, the date changes and a slot’s status may change because the environment changed. Heck, we could add a setting for the current temperature to be between 60 and 70 degrees if we wanted too. It’s immaterial though, as I think we have virtually every option one could need, and then some. Yes, one could create an external scheduling service and add/remove codes using this new proposed webhook. Both methods would work.
Manual interventions. Cancellations. Various back end anomalies. Multiple room bookings.
Booking today for yesterday. (Because they are made after midnight for immediate accommodation)
Here’s a fun one:
It’s easy to assume a booking starts (for example) 3pm and ends at 11am the next day, but when a guest decides to stay longer and books the room again for tomorrow, you’re probably going to lock them out of the room unexpectedly.
All I’m saying is that people are already using an external scheduling service. That’s what booking engines are. For example, the one I use sources reservations from 400 different channels, each with their own little quirks. (A single channel would be something like hotels.com, .or airbnb).
These outside systems know what the current state of all the doors should be… maybe. Lynn has an iCal feed. How this feed translates to door codes must be a custom thing because I’m pretty sure there’s no iCal standard for it. The booking engine I use only communicates in json feeds, and I have to impute what the codes are from there.
Long story short, translating any of this data into the scheduling variables inside keymaster seems like a waste of time when we can already easily set the codes with standard home assistant API calls with the existing variables. Calling the input_* services for the keymaster entities is trivial now as is and works fine.
I think its great if you want to add that in a more generalized way, but if it comes with a bunch of new entities it would compound the only complaint people ever have.
Either way, its your software, and its good software, do what you want. To me the kind of things the tiny minority of us are talking about seem way outside the scope of what I’d want to deal with.
Whie this is working great for my simple needs of ocasionally setting up a guest pin, I am thinking about removing it due to the amount of clutter it left in my automations and scriptds UI. Before I do is there a way to hide them?
I can only speculate how booking systems operate in conjunction with keycard systems. If they have the ability to activate/invalidate a specific keycard (or in our case a lock/slot combination) when a time-range is entered/exited then you wouldn’t need any of KeyMaster’s scheduling features. I suspect the booking system also generates new keycards, so it should also be responsible for generating lock/slot/PIN values.
So it (the booking system) might generate a “key” for room 1, slot 3 (R1S3) with PIN 1776 at the time of booking. And then when the occupancy period starts it enables R1S3. Likewise it would be responsible for disabling R1S3. If the booking system is sophisticated enough to trigger on start/end occupancy events, then by all means harness that.
I agree that the most useful feature to add for many folks would be an option for removal of some of the scheduling functions. For instance. I got the date range advanced schedule extended to support start and stop times (it didn’t originally) because I need it for my Rental Control integration that I’m working on. I don’t, however need all the custom weekdays schedules (at least for my use case). Having an option to have the advanced scheduling minus the custom weekdays would definitely reduce the number of entities in my instance(s)
Again, not in Keymaster, that’s why I’m working on a separate integration to drive getting codes into Keymaster without Keymaster having to worry about the logic of dealing with a rental and the silly things people do around extending their stay.
All of the systems I’ve dealt with that provide an iCal provide the following information (at a minimum): reservation identifier, start and end day (not even check-in / check-out time). Several of the ones I’ve gotten access to (thanks to beta testers) provide the last 4 digits of a phone number as well in the event description (which is useful for setting lock codes), otherwise we’ll be computing a lock code based up start / stop dates.
I don’t have access to any booking systems that provide only a JSON feed but I’m willing to work on that in the rental control system as well if people want to work with me (see the above announcement link which will get you to the GitHub repository where issues and PRs can be made).
Leave Keymaster to doing what it does well, managing locks. Move advanced meta-management logic elsewhere. This makes everything plugable, and tickles my fancy of the *nix way of development 
Thanks for the consideration.
All of our units are in different locations. I’d have to run individual HA networks installs in each place. I can’t imaging any other solution. So really what I’d be talking about is an install of KM that controls 1 lock on each HA host.
I may be a naive but I think there could be a fairly simple solution. Keep in mind this is being said by someone that isn’t a programmer, but I think it’s possible to come up with something without getting into the weeds on many of different external platforms/apps.
I use a channel manager (Guesty) plus AirBnB, VRBO, Bookings.com +. That said, I have a master calendar. That master calendar can be exported. (.ics for AirBnb, I’m not sure what for Guesty but I’d guess the same or similar)
In both cases, the calendars have the dates of the reservation, and the last 4 digits of the guest’s phone number (among other things). In my situation (and I think most reservations in this business) the check-in and check-out time is the same for every reservation. I’d use the dates, a default time (different for check-in and check-out), and then set the code to the last 4 digits of the guest’s phone number. Since it’s predictable, it’s easy to use the platform or channel manager to auto-generate a message for the guest the day before check-in with the access code.
Early check-in and late check-out could (and it our case would) be managed manually. We have to do that anyway because it requires coordination with the cleaning crews to ensure the unit is ready.
If you and anyone on your team does want to take this on, feel free to DM me.
+1 It is really a bother when I have to interact with any set of menus or views that has all these devices visible It would be great if all this scheduling stuff could be removed as entities or at least made as device attributes so the number of entities would be greatly reduced. I would venture that most people don’t need anywhere near this number of scheduling options, and if there are already booking systems that deal with it, maybe get rid of these functions and streamline (since that’s one goal for 2022 in HA) the entities created.
Why is that an objective? An RPI should be powerful enough that they aren’t causing any problems. Are you experiencing otherwise?
Oh, my RPi isn’t having any issues… I am when I look at the entities and automations lists! So many of the keymaster entities don’t prefix keymaster into their name so they’re mixed all over the place with my other entities and automations. Given that there isn’t a “not” filter it can make it really difficult to look through what’s in my system when I’m trying to do certain things.
Which is one of the things that folks really seem to be complaining about. The over abundance of entities and automations that for folks just using keymaster on their personal home may not need!
Personally, if I could select an option to not include the weekday advanced scheduling from generating I would. I would keep the date range scheduling, but I could see some folks not wanting even that.
Secondly, I would probably do some work to combine all the various automations. For instance there is a synchronize_code_slot_<door_name>_<code_slot_number> and a turn_on_access_limit_<door_name>_code_slot_number> for every code slot defined. The thing is, that in both of these cases it looks like something that is conceivable to bring down to a single automation that uses the triggering entity name to drive changes. This is already being done with many of the basic lock automations (changes codes, sending notifications, etc)
I should probably just go open an enhancement request about this…
I can give an example of where it causes problems.
When creating a new lovelace dashboard the default is to add every entity. Each and every keymaster variable shows up and makes it almost impossible to load.
It also makes the history tab on the ios phone app completely unloadable.
My rough guess is the tipping point for this is probably only five keymaster locks with with five codes each.
@FutureTense - Thank you for making Keymaster available to all of us! I use it for my 3 Schlage locks and it has been rock solid. While I admit I did not read the many posts above, I did see a few asking for the entities and automations / etc to be reduced and I have to +1 that as the amount of stuff Keymaster adds to HA is overwhelming and I do not need the majority of it. I would rather have a simple lock management system and a way to do all the scheduling, enable/disable stuff externally via Node Red. I’m not complaining though, as I appreciate your work, just sharing my point of view.
On another note, you likely already know this, but there are System log entries pointing to defaults missing on time templates related to Keymaster. Is that on your radar? They will likely stop working with the next release.
1 Like
You need to regenerate your templates to get this fixed. Just open up each of your lock configuration definitions via the integrations menu and hit save. That should resolve this issue.
1 Like
Here’s random thought:
With all this talk of iCal, and most of the extraneous entities being related to scheduling, replacing all the current scheduling variables with an iCal feed would solve everybody’s problem.