ISSUE: 0.1.0 Migration Error

[alphaomega16]

Upgraded to 0.1.0. Upon restart of HomeAssistant received error "Migration error: Check the logs".

Upgraded HA from 2025.9 to 2025.10: did not resolve problem.

Attempted to reconfigure 'frontdoor' received error "Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble"

Selecting reconfigure for ADU lock (see screenshot below) works as expected.

• OS: Ubuntu
• Type of system that HA is running on: Dell R720
• Home Assistant version: 2025.10
• Docker
• Component version: 0.1.0
• Z-Wave integration name: zwave_js
• Lock make and model: 2 x Schlage BE469

Logs
Unexpected error fetching keymaster data

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 392, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/keymaster/coordinator.py", line 1733, in _async_update_data
await self._update_lock_data(keymaster_config_entry_id=keymaster_config_entry_id)
File "/config/custom_components/keymaster/coordinator.py", line 1766, in _update_lock_data
await self._connect_and_update_lock(kmlock=kmlock)
File "/config/custom_components/keymaster/coordinator.py", line 1621, in _connect_and_update_lock
client: ZwaveJSClient = zwave_entry.runtime_data.client
^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ConfigEntry' object has no attribute 'runtime_data'

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 392, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/keymaster/coordinator.py", line 1733, in _async_update_data
await self._update_lock_data(keymaster_config_entry_id=keymaster_config_entry_id)
File "/config/custom_components/keymaster/coordinator.py", line 1766, in _update_lock_data
await self._connect_and_update_lock(kmlock=kmlock)
File "/config/custom_components/keymaster/coordinator.py", line 1621, in _connect_and_update_lock
client: ZwaveJSClient = zwave_entry.runtime_data.client
^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ConfigEntry' object has no attribute 'runtime_data'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1110, in async_migrate
result = await component.async_migrate_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/keymaster/init.py", line 248, in async_migrate_entry
if not await migrate_2to3(hass=hass, config_entry=config_entry):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/keymaster/migrate.py", line 81, in migrate_2to3
raise ConfigEntryNotReady from coordinator.last_exception
homeassistant.exceptions.ConfigEntryNotReady: 'ConfigEntry' object has no attribute 'runtime_data'

[dcf1999]

I am having same issues across both my HA sites.

[firstof9]

The error means it's unable to locate your ZwaveJS configuration.

[dcf1999]

So I guess I’m curious how it can’t find it anymore? It’s been working for years at both my sites and now they are both down…. So something must have broke it. Was there an update that may have screwed it up?

I guess the next question is what the fix is? How do you make it locate the configuration?

[alphaomega16]

The error means it's unable to locate your ZwaveJS configuration.

Odd, I am still able to control the 'frontdoor' lock using the old lovelace page and the automation still work.
The 'adu' lock required updating the Lovelace page with the new configuration.

Along with dcf1999: Whats the next step to correct the error? How to re-run the migration script?

[firstof9]

Try hitting the 3 dots and hit "reload".

[alphaomega16]

Try hitting the 3 dots and hit "reload".

Selecting reconfigure results in: Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble
(See screenshot)

[firstof9]

See if you can reconfigure then.

[alphaomega16]

Reconfigure results in the message above. Reload is not an available option for the device with the error. Selecting Reload on working device has no change.

[dcf1999]

is alphaomega16 and I the only one with this issue? I guess I'm curious as to how it no longer can find the zwave configuration. Something must have happened in an update or something. Seems strange that were the only two people reporting this problem. Do we have any other ideas on a fix? I just rebooted HA and that didn't fix it. I might try removing one of my locks and re-adding it.

I can't remember everyone's code... is there a way to pull the current codes from the lock or is there a file in keymaster that has them listed?

[firstof9]

is there a way to pull the current codes from the lock or is there a file in keymaster that has them listed?

You can view the codes from ZwaveJS UI as long as your lock manufacturer followed the spec properly.

[dcf1999]

I restored my home assistant from a backup 20 days ago. That had the old Key Master integration in it and it works. I am updating everything now and when that's done, i will update key master to the newest version and see what happens. By restoring it to the old version of Key Master, I at least got to get the old codes in case I needed to start fresh with the updated Key Master.

is there a way to pull the current codes from the lock or is there a file in keymaster that has them listed?

You can view the codes from ZwaveJS UI as long as your lock manufacturer followed the spec properly.

Sorry, I just saw this now.

[dcf1999]

Updated to the newest version of Key Master and it seems to be doing better? On the integrations page, it still shows migration error but when I click on it, only 2 out of 6 locks show the error. The others are still "initalizing" I'm not sure how long that takes. But with only two locks bad, I can remove them and just re add them. My main "master" lock seems to be working (although still "initalizing"), so it can pull the codes and settings off that one for the failed ones.

On my lovelace page that has the locks shown, they seem to be displaying correctly, but all the locks are stuck "adding" under pin status.

I'll give it some time to see if it works itself out. If not, I'll restore my previous backup and try again. If that doesn't work, I'll just run the older version of Key master until a more stable version comes up with this fixed.

[dcf1999]

OK it's all messed up. I re-added one of the locks that didn't "migrate" and it added it however, when I added the script to the lovelace, it showed "configuration error" under all the code slots and "entity not found".

I'll try restoring this again.

Is there something that needed to be done before I update to the newest version of Key Master?

[dcf1999]

Fixed the issue! After spending 3 hours trying to get it to work, this is what worked:

1. Remove all locks from Key Master
2. Uninstall Key Master from Hacs
3. Re-install key Master from Hacs
4. Re-install Key Master into Home Assistant
5. Set up all user's and codes.

Maybe step 2 & 3 weren't necessary.... i just wanted to make sure all the old entities and scripts were removed.

Seriously thought... I spent way too much time trying to figure out why it wasn't working and it's easier to just start from scratch.

[alphaomega16]

Fixed: repair steps below:

Similar to dcf1999:
Removed affected lock and re-added. Lock was able to be recognized and could be partially controlled using old Lovelace configuration (lock/unlock worked, did not test code changes)..

Additional steps I needed to complete repair:
After completing above: I did notice the problematic lock had significantly less entities, ~half. This lack of entities is what causes the new Lovelace panel to not work. A lot of the entities it is expecting return 'null'. (didn't save an example)

Decided to completely remove and reset the problematic lock. After clearing the lock from the zwave network and re-adding. All 487 entities appeared on the lock and the generated lovelace panel worked.

Not sure when the problem began but I suspect it was long ago and originated at the lock. The upgrade just brought attention to the problem.

Thanks to both dcf1999 and firstof9 for your assistance.