Startup race: keymaster polls zwave_js before config entry finishes setup, causing false 'Not Connected' errors

[DieterMartin]

Describe the bug

On every Home Assistant restart, the Z-Wave JS provider throws repeated AttributeError while trying to access runtime_data on the zwave_js config entry, because keymaster's coordinator starts polling before the zwave_js integration has finished its own async_setup_entry. All keymaster-managed locks briefly report "Not Connected" until the coordinator's built-in retry/backoff eventually succeeds a couple of minutes later.

The locks themselves are unaffected (verified by calling lock.lock/lock.unlock directly on the underlying Z-Wave lock entities during the affected window), so this is purely a noisy/misleading startup log issue rather than a functional one — but the ERROR-level logging and multi-minute "Not Connected" status could be confusing during troubleshooting.

To Reproduce

Steps to reproduce the behavior:

1. Restart Home Assistant with keymaster and zwave_js both configured (zwave_js listed in keymaster's after_dependencies).
2. Watch the log during startup.
3. Observe repeated errors from custom_components.keymaster.providers.zwave_js and custom_components.keymaster.coordinator until zwave_js's config entry finishes setup.

Expected behavior

Since after_dependencies only affects component load order, not whether a given config entry has completed async_setup_entry, keymaster's first connection attempt to zwave_js probably shouldn't be logged at ERROR level (or attempted at all) until the zwave_js config entry's state is ConfigEntryState.LOADED. Something like awaiting hass.config_entries.async_wait_component(zwave_entry) before the first async_connect() call would avoid the false-alarm errors on every restart without disabling the existing retry logic.

Log output

2026-08-19 02:42:22.667 ERROR (MainThread) [custom_components.keymaster.providers.zwave_js] [ZWaveJSProvider] Can't access Z-Wave JS client: AttributeError: 'ConfigEntry' object has no attribute 'runtime_data'
2026-08-19 02:43:22.667 ERROR (MainThread) [custom_components.keymaster.coordinator] [Coordinator] Front Door Lock: Not Connected
2026-08-19 02:43:22.667 ERROR (MainThread) [custom_components.keymaster.coordinator] [Coordinator] Side Door Lock: Not Connected
2026-08-19 02:44:22.668 ERROR (MainThread) [custom_components.keymaster.coordinator] [Coordinator] Front Door Lock: Provider failed to connect
2026-08-19 02:45:22.666 ERROR (MainThread) [custom_components.keymaster.coordinator] [Coordinator] Side Door Lock: Not Connected

(Recovers on its own ~3 minutes after startup, once the zwave_js config entry finishes loading.)

Environment

• keymaster version: v0.5.3 (latest release)
• Home Assistant Core: 2026.8.2
• Z-Wave JS installed as a separate config entry, zwave_js listed in keymaster's after_dependencies

[firstof9]

Thanks for reporting this and providing detailed logs!

We have submitted #709 to address this startup race condition. It adds checks to ensure that the provider config entry has reached ConfigEntryState.LOADED and that runtime_data is initialized before attempting connection, while also downgrading initial connection attempts during Home Assistant startup to DEBUG to eliminate the false-alarm error logs on boot.