mirror of
https://github.com/home-assistant/supervisor.git
synced 2026-08-13 00:12:57 +01:00
858630fb75
* Skip network re-activation on startup when settings are unchanged Since #3528 Supervisor re-applies its network defaults on every startup: it rewrites the NetworkManager connection profile of each enabled interface and re-activates the connection so the settings take effect. The re-activation runs unconditionally, so every Supervisor start causes a full connection cycle (routes torn down, DHCP re-negotiated, Wi-Fi reassociation) even when the profile did not change, which is the common case. Make NetworkSetting.update() report whether the profile actually changed by comparing NetworkManager's normalized view of the settings before and after the update call. Comparing Supervisor's generated payload against the current profile would not work here since NetworkManager omits properties at their default value from GetSettings. On the startup path, skip re-activation when the profile is unchanged and the connection is currently activated. Out-of-date profiles (e.g. after a change of Supervisor's defaults) are still rewritten and re-activated, and user-initiated updates via the API re-activate unconditionally as before. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Reapply changed network settings in place on startup When the startup profile update does change the NetworkManager connection profile (e.g. after a change of Supervisor's defaults), the settings were applied through a full re-activation cycle, briefly disrupting connectivity. Use NetworkManager's Device.Reapply() instead, which applies the updated profile to the active connection without disconnecting. Not all settings can be reapplied (e.g. wireless security changes), in which case NetworkManager raises an error and Supervisor falls back to the full re-activation as before. User-initiated updates via the API are unaffected and still re-activate the connection. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Log network connection activation and reapply at info level Activating or reapplying a connection affects host connectivity, but was only visible in debug logs. Log at info level when Supervisor activates a connection, reapplies changed settings in place, or creates a new connection, so the Supervisor log shows when and why the host network configuration was touched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Reapply changed settings in place for user-initiated updates too Extend the in-place reapply from the startup path to user-initiated network settings updates via the API. Changing e.g. IP or DNS configuration no longer drops connectivity, which also matters when the update is made remotely over the interface being reconfigured. Payloads containing a Wi-Fi PSK always re-activate the connection: secrets are excluded from GetSettings and ignored by NetworkManager's Reapply (the diff runs with NM_SETTING_COMPARE_FLAG_IGNORE_SECRETS), so an updated PSK would otherwise be written to the profile but never applied or validated. Unchanged settings also still re-activate on the user path, both to keep resubmitting settings working as a way to force a reconnect and to cover secret-only changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Clarify settings variable naming in NetworkSetting.update() The dict fetched from GetSettings was named new_settings and mutated by the merges into the payload sent to Update, so the name was only accurate for half of the function. Keep the fetched state pristine as current_settings, merge into a copy named new_settings, and compare current_settings against the normalized result. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Extract in-place settings application into a helper method Review feedback on #7043 noted the conditional block in apply_changes() had grown confusing with the added nesting. Move the decision whether updated settings are effective without a full re-activation cycle into a dedicated _apply_settings_in_place() method using early returns, so apply_changes() reads linearly: update settings, then activate unless they were applied in place. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>