Apologies for the delay, but finally got through the vibe code experience and have what I think is a decent solution addressing all of the major outstanding concerns. Upgrade and let me know if you continue to see issues.
For integration issues (PINs not syncing, states mismatch, locks unavailable, etc.), please set log level to debug for custom_components.lock_code_manager, reproduce the issue, and then share the debug logs I can go through what happened step by step
For frontend issues (mainly dashboard generation issues, errors, etc.), capture the error/behavior as experienced in the HA UI (complementary screenshots appreciated) but also go to your browserâs Developer Tools, click on the Console tab, and include the error message that is displayed there, which usually gives additional helpful context beyond what you see in HA.
It can definitely be tested, and while I canât confidently say itâs bulletproof, I think I covered a lot of the edge case scenarios. But I of course wonât know until this is in the wild and I get feedback.
BTW - when you mentioing a warning in the first point, what are you referring to? Are you talking about the disclaimer in the README or something else?
EDIT: I see what you mean now, thanks for the heads up I will remove it
I installed the integration, and it all seemed to work correctly. I was impressed with how simple it worked. Unfortunately, I noticed it was repeatedly syncing my 3 slots over and over without end. Iâm guessing that would kill my battery quickly, so I disable it (hopefully temporarily).
One thing I noticed: When it synced a code slot, the pin sensor would show *******, but shortly afterward it would change to the unhidden (ârawâ) pin number. Could it be cycling the synce because of the ****** does not match the raw pin code? In other words, the obfuscation characters cause the sync to fail, which triggers another sync?
FYI, my lock is a somewhat older z-wave Schlage BE469.
Damn I put in some fixes specifically to prevent that behavior but I guess itâs not working for all scenarios⌠can you set the log level for the LCM integration and zwave js integration to debug, enable the integration again and watch it flap a bit, then disable again and send me the logs? Thatâll help me track down the race condition thatâs occurring. Thanks!
Works great now! Thanks for the update. I appreciate this integration. Itâs more intuitive and simple to install compared to KeyMaster which is perfect for many users.
OK well I added a configuration option in 0.9.7 to disable it through the dashboard strategy. Set show_per_configuration_lock_cards to false (set show_all_lock_cards_view to false to disable that final view that shows all the lock cards for all config entries)
Hi, thanks for all the recent updates on this, itâs working pretty nicely for me. I have noticed, though, that my two Yale Keyless locks (with the z-wave module fitted) are guzzling batteries. Should the recent update 0.9.7 have fixed that or is there something else I can check/report back on? I do have a number of empty and unmanaged slots. Looking at the activity logs for each lock, there are frequent (every 7-8 seconds) changes to each slot coming from LCM.
are you still seeing this behavior on the latest release 1.0.0? If so, set log levels to debug for the integration, restart it, let it run for a bit, then share your logs!
sorry what is add a user view? This adds a final view to the dashboard that shows all locks managed across all LCM entries and their codes. You can also show them directly on the view for a specific LCM entry. This is for people who are managing multiple locks in different entries, although I suppose by default it may be overkill.
