[blindlight86]

Summary

Fixes #6.

Replace the removed single-platform forwarding API with awaited hass.config_entries.async_forward_entry_setups(entry, PLATFORMS). The connection and initial state read now finish before platform forwarding, and forwarding finishes before entry setup returns.

• Bound the initial connection attempt with the existing 10-second timeout and raise ConfigEntryNotReady so Home Assistant schedules retries.
• Register connection cleanup with entry.async_on_unload and unload the switch platform before releasing the client.
• Run the driver's reconnect work through config-entry background tasks so Home Assistant cancels it on unload.
• Remove relay status callbacks when entities are removed and initialize entities from the state already read during connection setup.
• Move local_push metadata from the deprecated config-flow connection class to manifest.json.

The patch preserves configuration keys, YAML import, config-flow version, all 16 relay names, and entity unique IDs. It retains the existing boolean setup/unload return convention, which remains supported for custom integrations in Core 2026.11.

Based on current master at c1231928993a9ea4ad5ef492de3bef18003ed63f. The changes are limited to three integration files.

Official API confirmation

Home Assistant's migration guidance requires awaiting the plural forwarding method during entry setup. The replacement reported by Elwinmage in #6 remains valid in Core 2026.11.1. The earlier compatibility PR #7 was closed without merging.

• Platform forwarding migration
• Config entry unloading and cleanup
• Boolean return support for custom integrations

Simulation testing

Executed against real Home Assistant Core 2026.11.1 in an isolated Linux process with Python 3.14.10 and the unchanged usr-r16==0.0.4 dependency. A loopback TCP relay simulator supplied authorization replies and relay-state packets. The exercise used Home Assistant's config flows, entry lifecycle, entity registry, and switch service calls.

The simulation originally passed on 2026-11-10 and was rerun successfully on 2026-11-11 for this PR.

• YAML import creates the existing configuration shape and all 16 relay entities.
• User config flow, duplicate-device detection, initial state, and turn_on, turn_off, and toggle calls work.
• A live disconnect/reconnect retains one set of entities and status listeners.
• Entry setup waits for platform forwarding. Core rejects a concurrent unload during setup. Subsequent unload/reload preserves entity IDs and leaves a second entry working.
• Unloading an offline device cancels its active reconnect work. Restarting the simulated device produces no stale connection.
• A stalled initial handshake enters SETUP_RETRY, closes the partial connection, and recovers through Home Assistant's automatic retry when the simulator starts responding.
• An injected platform-unload failure retains the client and existing entities.
• An injected platform-forwarding exception closes the connection and clears the entry's runtime data.

Python compilation, manifest JSON parsing, git diff --check, and patch applicability to a clean master checkout also passed. The error logs in the last two scenarios are expected failure injections. This simulation suite ran locally.

Pending verification on a physical USR-R16

• Upgrade an existing Home Assistant installation with this patch and confirm existing relay entity IDs, custom names, and automation references remain usable.
• Confirm all 16 physical relay outputs and actual device state reports for on, off, and toggle operations.
• Power-cycle the device and interrupt the network to verify availability updates and recovery on the actual device firmware.
• Disconnect while a relay command is in flight and check recovery, command completion, and reported state.
• Reload, disable, and re-enable the integration in the deployed installation, including while the device is offline.

Physical-device results remain pending. The runtime checks above establish the tested Core/API and simulated lifecycle behavior.