Virtual integration

The Virtual integration allows users to set up "virtual" entities of different types. One of those entity types is locks.

The reason support for this integration was added is because it can be used to test Lock Code Manager functionality without affecting your main locks. Because Virtual locks don't have support for setting and clearing user codes, the way this works is that user codes are persisted to disk as you set them. If you remove a Virtual lock from your configuration, the file will be removed to keep your file system clean.

If you are curious about Lock Code Manager and don't want to impact any existing locks functionality, I would encourage you to try setting up Lock Code Manager with Virtual locks first!

PS - the way Virtual locks integrate with LCM is not set in stone. If you have ideas on how to make support for these locks better, please open an issue.

You no longer need one for a keypad-only setup

Before 5.3.0 a configuration required at least one lock, so the advice for checking codes from an external keypad with lock_code_manager.use_credential was to add a Virtual lock as a placeholder. That is no longer necessary — a configuration can now manage no locks at all. See External Keypads.

An existing entry set up that way keeps working. If its Virtual lock was only ever a placeholder, you can remove it from the entry; the stored codes for that lock are deleted with it.

A Virtual lock is still worth adding when you want somewhere concrete for uses to point at — a target that appears in your dashboard and carries the lock's name into notifications — or when you are trying Lock Code Manager out, which is what it was added for.