Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.29%. Comparing base (53a22a2) to head (a0a93a5).

@@            Coverage Diff             @@
##             main     #103      +/-   ##
==========================================
+ Coverage   88.92%   89.29%   +0.36%     
==========================================
  Files          20       21       +1     
  Lines        1219     1261      +42     
==========================================
+ Hits         1084     1126      +42     
  Misses        135      135              

@raman325 I got a chance to try this this morning.

I created a new LCM against a virtual lock I already had and got the following error in my logs after completing the setup:

2024-03-27 08:14:24.224 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/config/custom_components/lock_code_manager/__init__.py", line 389, in async_update_listener
    ][CONF_LOCKS][lock_entity_id] = async_create_lock_instance(
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/lock_code_manager/helpers.py", line 32, in async_create_lock_instance
    assert lock_config_entry
AssertionError

I still have my (non-functional) Zwave lock setup with slots 1 - 3 configured.

I setup my new LCM based virtual lock with exactly the same parameters (just a different name).

So configuration was basically:

3 slots starting at 1.

Slot 1 configuration:
Name: Slot 1
Code: 0101
Enabled

Slot 2 configuration:
Name: RC live test
Code: 0202
Calendar: calendar.rental_control_live_test

Slot 3 configuration:
Name: RC Manual test
Code: 0303
Calendar: calendar.rental_control_manual_test

thanks, I assumed that you would have a config entry given the docs for the virtual integration but maybe there was an incorrect assumption there

Virtual devices are created via YAML. That's all I know. I have the following in my configuration for my test system:

configuration.yaml:

# just showing the bits that are relevant
lock: !include locks.yaml

# Enable virtual components platform
virtual:

locks.yaml

- platform: virtual
  name: Test lock

This gives me a virtual lock that I can see in the LCM picker during configuration. This ends up giving me a device named Test Lock and an entity named Test Lock with entity_id of lock.virtual_test_lock

Of course, looking this over, maybe part of my problem is that I have two locks named Test Lock because my ZWave lock is also named that. Though it gets a different entity_id of course.

Let me try renaming my virtual lock.

:-/ weird, I updated updated my locks.yaml configuration to have a different name. Restarted, cleaned up the orphaned lock entity and no longer have a device related to the virtual lock, so it is no longer pickable in LCM. I'll debug that issue since I know you're looking for a device and not an entity. I'm not certain why it disappeared on me!

Ok, I don't know what's going on now 😢 I went and looked at the Virtual Components integration. I was using the latest release v0.8.0.1 and saw that there was an alpha version that might fix some issues. I switched to that, I get a device related to the virtual lock. The virtual also doesn't put virtual_ in the entity name anymore it just looks like a lock just with an interesting attribute (Persistent). In any case, it still doesn't show up in the pick list for some reason now after my having gone and fiddled with the name.

the name shouldn't matter. Check config/.storage/core.entity_registry and look up your lock. Does it say virtual for the platform?

Just pulled your latest changes to this PR, still not finding the virtual lock device. Yes, it does have virtual as the platform. The device is showing up with the following:

      {
        "aliases": [],
        "area_id": null,
        "capabilities": null,
        "config_entry_id": "354d708d84fcb64a5774c1a430b77cfb",
        "device_class": null,
        "device_id": "0de15f8388ec4bd4f127ee916c0e4439",
        "disabled_by": null,
        "entity_category": null,
        "entity_id": "lock.vtest_lock",
        "hidden_by": null,
        "icon": null,
        "id": "7bbed305a71397611017dfb7ed4e092b",
        "has_entity_name": false,
        "labels": [],
        "name": null,
        "options": {
          "conversation": {
            "should_expose": true
          }
        },
        "original_device_class": null,
        "original_icon": null,
        "original_name": "VTest Lock",
        "platform": "virtual",
        "supported_features": 0,
        "translation_key": null,
        "unique_id": "3aacdca6-c8bc-4aa2-ad4f-fe2b961ae465.virtual",
        "previous_unique_id": null,
        "unit_of_measurement": null
      }

@raman325 just updated to 2023.4.0 on my test system and the new virtual lock bits started working! Note: I'm still using the alpha release of the virtual component, but at least now I can actually do much better testing of things :)

I'll get it setup with more than one v-lock and see how well the multi-slot bits all work and then I can finally look at making this an optional lock driver for Rental Control

so is this good to merge?

EDIT: I think it is, but if you run into any issues open an issue so I can take a look