[Feature Request] Move automations, scripts and helper entities to internal integration functions

[Snuffy2]

From @raman325 https://github.com/FutureTense/keymaster/issues/334#issuecomment-1566588123:

You are right that keymaster has some unnecessary complexity/surface area, but by comparing it to this script you are ignoring a lot of what keymaster does. Ultimately, I'd like keymaster to be more modular because a lot of people don't need all of the features that keymaster offers, but that's a significant rewrite and would not be made simpler by moving to pyscript or App Daemon. If this is something you feel that confidently about, feel free to submit a PR for this or a fork.

There is no design flaw. At the time that keymaster was originally created, the implementation was the only solution given what was available. There's a path to a better solution but that's only been made available recently, and that path does not involve pyscript or App Daemon.

Great - have at it and please share once it's built!

I'm wondering if there would be interest in a rewrite of sorts moving away from automations, scripts, and helpers? I've started thinking about how best to do it and I am interested in giving it a try if there would be interest from the repo maintainers in this.

I'm very open to feedback but my approach would be:

• Create a device for each lock in keymaster with all of the keymaster entities for it
  • For child locks, set the via_device property to the parent lock
• Expand the KeymasterLock class to store all of the properties of the lock and utilize the device_ids to link parent/child locks
• Utilize a coordinator to hold all the locks so that each lock can access and change the properties of its parent/child locks
• Move automations/scripts to internal integration functions
• Move from helper entities to integration entities

Helper Entity	Integration Entity
input_text	text
input_boolean	switch
input_number	number
input_datetime	date, datetime, or time

Obviously this would not be a single, small PR.

Before I go further down this rabbit-hole, please let me know if there's interest. If not, no worries.

[firstof9]

Sounds good to me.

[bergethan]

I'd love to see this! Because of how the automations are generated, I cannot categorize them using Home Assistant's new categorization features, so I have to scroll endlessly to find anything else I'm looking for. It's not sustainable long-term.

[firstof9]

@Snuffy2 give me a ping when you're ready for those to be merged into that beta branch.

[tykeal]

Looks like I'm going to have to install a beta version on my test system to make sure that Rental Control still works with all of this! Wee!

I'll note that all of those PRs are currently failing the py312 tests and that really should be fixed before they're merged anywhere.

Linting is also failing, but I suspect that's symptomatic of the entire code base. I haven't checked the current code base against the linters ;)

[firstof9]

I'll note that all of those PRs are currently failing the py312 tests and that really should be fixed before they're merged anywhere.

The tests are broken due to internal changes in HA. They need reworking, I just don't have the time for such the endeavor.

[Snuffy2]

@firstof9 I think this is now ready for beta testing.

It utilizes all internal code to manage keymaster with the exception that it will continue to send notices to keymaster_<doorname>_manual_notify if it exists. I tried to reproduce the same logic as before but I'm sure there are some differences. Let me know and I'll try to refine it I've tested it locally but it really needs some more extensive testing, hence the beta

Prior to release, I'll remove a lot of the logging and remove the actual PIN/Usercodes from the logs.

Functionality not yet implemented

• A best effort migration function to convert from the helper entities to internal entities
• Remove prior keymaster package files and entities in the migration
• Lovelace code generator
• HA actions/scripts
• Add button entity to reset (lock and each code slot)

Features

• Coordinator redesigned to manage the status of all keymaster locks and the link to the physical locks
  • Entities now get their value/state from the Coordinator
• Expand the KeymasterLock class to hold all of the necessary lock properties
• Standardize the code of entities using a KeymasterEntity base class
• Converted existing Sensor and Binary Sensors
• Added Text entities replacing input_text helper entities
• Create a device for each lock in keymaster with all of the keymaster entities for it
  • For child locks, set the via_device property to link the parent lock to the child lock
• Move input_boolean helper entities to switch entities
• Move input_number to number entities
• Move input_datetime to datetime or time entities
• Store coordinator data to disk and restore on HA restart
• Build Code Slot active logic
• Move applicable automations and scripts to listeners
• Add boltchecked/retry lock function
• Add auto-lock timer function
• Ensure new and change configurations work properly

[firstof9]

Now we just need to fix tests.

[Snuffy2]

Now we just need to fix tests.

Not something I have a lot of experience with but I'll give it a try. Any assistance would be greatly appreciated.

[firstof9]

I'll have to see what I can do when time permits.

[tykeal]

@Snuffy2 I've cleaned up my old keymaster install on my test system and have installed the beta branch to walk through some stuff.

First up, I saved off one of the slot config boxes from my previous install and am working through re-attaching the different entities.

There are two entities that I have yet to find a replacement for yet. The connected sensor and the active sensor. What are the new entities that I should be pointing at for this?

Second: setting the PIN doesn't seem to actually cause my lock to get programmed, or deprogrammed. Flipping enabled / disabled doesn't seem to be doing it either, all it seems to do is set the PIN to unknown when it goes from disabled -> enabled.

Third: if the slot is not enabled it is impossible to program any of the entities which is a major problem for when I update Rental Control to be able to use this. Rental Control programs the name, the pin, the start / stop daterange and that it should be using the date range all before enabling the slot. That way the slot doesn't try push a code out when it isn't supposed to.

If the logic is to enable the slot, then program the advanced options, and then program the name and PIN I can do that but it's a reworking of logic from how keymaster currently works.

[Snuffy2]

Thanks for testing it out.

1. I have not recreated the code slot sensor called sensor.connected_<lockname>_<#>. With the new setup, I was hoping that it wouldn't be needed but I can add it in if necessary.

• For Active per Code Slot: There should be a binary_sensor called something like binary_sensor.<lock_name>_code_slot_<#>_active.
• For Lock Connected: There should be a binary sensor called something like: binary_sensor.<lockname>_network.

2. Could you enable debug logging and either post them or email them to me ([email protected]). Note: that the logs currently contain PIN/usercodes in them while testing/in beta. Feel free to de-identify but note if they are discrepant between keymaster and the lock please.

3. Yes, that is how I built it as that seemed to make sense. But I can change it to function how it used to work since there is a valid reason/use case as to why you'd want to set a pin even when disabled.

[tykeal]

I'll turn on debugging to get some output, On the topic of the connected and active sensors. The connected sensor is the most critical as that has been my way of knowing if the PIN has actually hit the lock without having to go inspect it directly in ZWave-JS UI. We need some sort of indicator that the PIN has been properly programmed or if there is a problem with it. The active sensor just lets you know what state that the PIN should be in. It allows you to know when Keymaster should be programming or deprogramming. But in reality the connected sensor tells you all of that with the states that it has of Disconnected, Adding, Connected, and Deleting.

Having at least the connected sensor is rather vital as a piece of knowledge as to what the integration is doing. I have one lock that fairly consistently runs into that Adding hang that is all over the issue tracker here and I just go fix the given code slot in JWave-JS UI and make sure it's properly programmed and then it shows as Connected in Keymaster. I don't have that issue with the many, many other locks I have in use but they do all sometimes run into it and it's useful for me to know what Keymaster is thinking.

------ A little while later -----

Ok, I enabled debugging and here's what I've found:

1. I initially setup the new configuration to work on the first 10 slots of my test lock. I had codes programmed into slot 1 and 3 with 0101 and 0303 respectively.

2. The logs are showing me both of those values.

3. I later went and changed the configuration to only work on the first slot.

4. Restarts of the system still show the coordinator with 10 slots, even after a full restart of HA

5. Complete removal of current configuration + restart + adding it again still has it showing up with 10 slots

6. Slot programming was not working correctly until I manually set the PIN in ZWave-JS UI on the first test slot. Since then it's been doing the correct thing with programming / deprogramming the slot. I see that there is a binary_sensor.<lock_name_code_slot_<#>_active that seems to be effectively doing what I expected the end state status of the connected sensor to do. It does not, however tell me if Keymaster is trying to program / deprogram the slot. Granted, the lock I'm testing with rarely has had the hung bug that seems so prevalent so I don't know if it matters here.

7. Slot 3 is an issue though. I deprogrammed the slot manually via ZWave-JS UI and I still see it showing up in the log with the PIN that it had long previously detected when I had it doing 10 slots.

8. Removing a PIN code (setting it to empty) throws the following error:

2024-11-26 08:14:17.355 DEBUG (MainThread) [custom_components.keymaster.text] [Text async_set_value] test_lock Code Slot 1: PIN: config_entry_id: 01JDMEKFV57AHZSSG3GDD6YH3Q, value:
2024-11-26 08:14:17.355 DEBUG (MainThread) [custom_components.keymaster.coordinator] [set_pin_on_lock] test_lock: Code Slot 1: Setting PIN to
2024-11-26 08:14:17.355 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140006301334496] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 245, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2802, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2845, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1007, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1079, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/text/__init__.py", line 81, in _async_set_value
    await entity.async_set_value(value)
  File "/config/custom_components/keymaster/text.py", line 119, in async_set_value
    await self.coordinator.set_pin_on_lock(
  File "/config/custom_components/keymaster/coordinator.py", line 1282, in set_pin_on_lock
    await set_usercode(kmlock.zwave_js_lock_node, code_slot, pin)
  File "/usr/local/lib/python3.12/site-packages/zwave_js_server/util/lock.py", line 146, in set_usercode
    raise ValueError("User code must be at least 4 digits")
ValueError: User code must be at least 4 digits

There should be a way to fully clear the code outside of just disabling it. Again, this comes back to not being able to program the code while the slot is disabled. Changing out a code needs to happen without an old code hitting the lock temporarily.

9. Adding a new configuration after removing an old one ends up requiring a reload of the integration or restart of HA to get it to configure the entities, they all end up as Unavailable without doing this and the following gets dumped in the log:

2024-11-26 08:30:56.622 DEBUG (MainThread) [custom_components.keymaster.coordinator] [add_lock] test_lock
2024-11-26 08:30:56.622 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_door_and_lock_state] Running
2024-11-26 08:30:56.622 DEBUG (MainThread) [custom_components.keymaster.coordinator] [unsubscribe_listeners] test_lock: Removing all listeners
2024-11-26 08:30:56.622 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_listeners] test_lock: Calling create_listeners now
2024-11-26 08:30:56.622 DEBUG (MainThread) [custom_components.keymaster.coordinator] [create_listeners] test_lock: Creating handle_zwave_js_lock_event listener
2024-11-26 08:30:56.623 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.624 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.625 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.625 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.626 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.627 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.627 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.631 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.633 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.633 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.633 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.634 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.634 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.634 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.635 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.635 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.635 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.635 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.636 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.637 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.638 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.639 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.639 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.640 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.641 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.641 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.641 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.642 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.647 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.647 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.648 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.648 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.649 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.649 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.650 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.650 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.651 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.651 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.654 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.655 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.656 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.656 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.657 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.657 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.657 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.658 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.658 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.658 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.658 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.659 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.661 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.661 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.661 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.
2024-11-26 08:30:56.661 DEBUG (MainThread) [custom_components.keymaster.coordinator] Debouncer call ignored as shutdown has been requested.

While not exactly common, if someone messes up and wants to restart their config from scratch this is likely something that they would end up doing.

[Snuffy2]

@tykeal, hopefully this will work a bit better now.

• #404 should fix numbers 1-3, 6-8.
• I added a Sync Status sensor and updated a lot of the surrounding logic and logging
• You can now change the code slot settings on disabled code slots
• I'm not able to reproduce the issues you noted in numbers 4 & 5. It consistently only shows the number of slots I select. Let me know if you're still seeing this and anything of note you see in the debug logs.
• Number 9, I see on occasion when there's another error in the logs. I'm not quite clear on how to address the Debouncer issues directly but fixing the issue that caused the error makes it so the Debouncer issues don't appear. Let me know if you're still seeing it and if there's a keymaster error higher up in the logs

So once #404 gets merged, if you could test again I'd really appreciate it. Also, there is now an upgrade/merge function added that should keep the settings from the previous version and delete the old entities when you upgrade from the current version to the beta.

[firstof9]

#404 is merged.

[Snuffy2]

I've updated the Wiki based on the changes currently in the beta for when this gets fully released. https://github.com/Snuffy2/keymaster-wiki/wiki https://github.com/Snuffy2/keymaster-wiki.wiki.git

[tykeal]

I'll try and get some testing done soon. I was away for Thanksgiving and have a busy weekend currently in front of me.

As a point of clarification, I should note that when I say "Restarts of the system still show the coordinator with 10 slots, even after a full restart of HA" I mean that it is informing me of information about slot states, not actually creating entities for 10 slots. I haven't pushed the latest beta update but I did finally notice this log line:

2024-11-26 08:33:15.748 DEBUG (SyncWorker_5) [custom_components.keymaster.coordinator] [Coordinator] No changes to kmlocks. Not updating JSON file

which made me go searching for a json file, I was originally thinking it would have been in ~/config/.storage with all the HA configuration but it isn't, and I think I realize what is happening. Modifications to the configuration are not clearing out old slots from the config/custom_components/keymaster/json_kmlocks/keymaster_kmlocks.json file. Given the number of times I've added and removed the lock while doing some testing I now have 5 blocks in the file.

The first block is my initial just install it over the old Keymaster without removing configuration and see what happens. I had that KM configured to do slots 10 - 14. When that didn't work very well, I did a complete removal of any configuration and built new that had slots 1 - 10. Since that was too much clutter while I was trying to figure out the updated entities for the dashboard I modified the configuration to only be slot 1. I have since removed all configuration, restarted HA and added configuration for only 1 slot 2 other times.

This tells me that on removal you are not clearing your data blocks at all. On a reconfiguration, you're leaving the data block behind and creating a new one instead of updating the old one. And finally, data from all blocks seem to be getting reported on the regular check cycle which is what is was confusing me. I will try purging that file completely after removing all of my configurations and giving HA a restart to see if that fixes my problem.

[tykeal]

Ok, after some further testing with the latest beta branch and having purged the json file things are definitely looking a lot better! I like the sync status entity. Especially when I just remove the PIN (thanks for cleaning up the error that was thrown). Since it goes to Out of Sync that's really good :)

I have also loaded up the generated dashboard and that looks good. Even better than the previously generated one since all the advanced features are truly hidden unless enabled. That's a good touch :) I will note, however, that you've moved the location of the generated dashboard. The documentation will need to be updated or you should take a look at how Lock Code Manager by @raman325 does an autogenerated dashboard. I don't really understand how it works, but it's pretty slick when all you have to do is add a dashboard and include a single custom card and all the locks and everything just auto-populate!

A reset button is still needed however, that will make it significantly easier for someone to clear out slot along with all of the advanced configuration. I use this feature of the current release with my Rental Control integration so that I don't have to explicitly clear the name, pin, enabled status and date range when a code slot needs to be cleared.

[tykeal]

@Snuffy2 I haven't dug into the code to see what is going on, but when I'm using my programmed code to unlock the lock, it's firing a keymaster_lock_state_changed event (like it should) but it's throwing it as code_slot: 0 with code_slot_name: "" instead of the actual slot information

Since I only have one slot currently defined, it should be throwing it as code_slot: 1 with code_slot_name: "foo" Admittedly, it could actually be the lock. I had pulled this one from one of my properties because it was regularly having issues... I do not presently have a verified good lock to test with :rofl:

[Snuffy2]

@tykeal

• Deleting locks should already be working better, but I also made some further improvements with #409
• Reset lock and code slots added with #408
• Updated documentation has been started for whenever this gets released: https://github.com/Snuffy2/keymaster-wiki/wiki
• I'll look into the notifications. It isn't something I tested very thoroughly yet, so I'm not shocked if it isn't working right.
• Interesting approach to the dashboard with Lock Code Manager. Not sure I plan to deploy anything similar right now, but an approach to consider for this (or other integrations) in the future

@tykeal, @firstof9 do you think this is in a good enough state where we can try to get some more users to test it out? Any ideas how to recruit some users?

[tykeal]

I'll do some more testing when I can get a chance either this evening or in the morning.

As for more users testing, it could go out as a beta 1.0 this is a major breaking change and I would posit closer to what a 1.0 really should be than what we've had before.

[bergethan]

@Snuffy2, I have a setup with several Yale locks. Since the work you’re doing is something I’ve specifically asked for (and I’m REALLY looking forward to), I’m happy to test it out.

By the way, in case nobody has said it yet, thank you!

On Dec 1, 2024, at 19:13, Snuffy2 @.***> wrote:

@tykeal https://github.com/tykeal Deleting locks should already be working better, but I also made some further improvements with #409 https://github.com/FutureTense/keymaster/pull/409 Reset lock and code slots added with #408 https://github.com/FutureTense/keymaster/pull/408 I'll look into the notifications. It isn't something I tested very thoroughly yet, so I'm not shocked if it isn't working right. Interesting approach to the dashboard with Lock Code Manager. Not sure I plan to deploy anything similar right now, but an approach to consider for this (or other integrations) in the future @tykeal https://github.com/tykeal, @firstof9 https://github.com/firstof9 do you think this is in a good enough state where we can try to get some more users to test it out? Any ideas how to recruit some users?

— Reply to this email directly, view it on GitHub https://github.com/FutureTense/keymaster/issues/393#issuecomment-2510323498, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIKRAH2WOROVP5FQNBSH2T2DOQ3DAVCNFSM6AAAAABRSEPI22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJQGMZDGNBZHA. You are receiving this because you commented.

[tykeal]

Heya, just touching base. I know I said I would do some more testing, but I haven't had a chance to (life has intruded). I'll try as soon as I can!

[Snuffy2]

@firstof9 I have the changes to pass mypy just about done and I have one other change regarding the notifications to do but otherwise that's it.

I've tried getting pytest working, but I'm out of my depth in how to do it properly with the coordinator and zwave, sorry.

What are next steps to get this to a wider beta audience?

[firstof9]

I'll check in on the pytest to see what's going on, likely just needs some tweaking for the changes to zwave_js that have been done in the past few years.

[Snuffy2]

With #428, I am now "done". Without any further testing by others, I'm don't anticipate finding any other issues.

@firstof9, please let me know what next steps are to get this further tested and hopefully released.

[CJOWood]

With #428, I am now "done". Without any further testing by others, I'm don't anticipate finding any other issues.

@firstof9, please let me know what next steps are to get this further tested and hopefully released.

I'm curious if you can explain some of the changes more clearly between this and the original. As far as I understand it's putting some of the logic being scripts rather than in helpers?

[Snuffy2]

It uses all internal functions. It doesn't use the packages, helpers, automations, scripts that the current version uses. The only script/action it will optionally use is a custom notification script/action. I believe it has all of the options and functionality of the current version.

[tykeal]

@Snuffy2 this changes entity names as well too doesn't it? I should finally have the breathing space to do more testing with it today. Sorry, from Thanksgiving until after the New Year is always extremely full in my family so I haven't been able to do the needed testing.

[VACIndustries]

What's the best way to test this out without nuking the existing? I would assume fork it and install it that way? Would love to also verify functionality with my 4 (1 leader, 3 follower) Schlage locks

Also down to just test out upgrade from my current keymaster instance if migration is present now

[firstof9]

What's the best way to test this out without nuking the existing?

I spin up a 2nd HA container with a minimal config and do it that way.