The current reconnection handling to the HA server is more of a quick and dirty implementation than a proper solution.
With the new reconfiguration options there's a chance of a race condition, where suddenly two client connections are active. This interferes with heartbeat timeouts and can lead to constant reconnections. This has been seen in unfoldedcircle/feature-and-bug-tracker#243
The core already uses a state machine implementation for the WebSocket integration driver connections. This could probably be used as a starting point with some modifications (e.g. no authentication_error transition from the transient Connecting state, because of no header-based authentication):
Tasks:
[ ] analyze if we just need an additional "(re)-connection state-machine" (as shown above), or an overall state-machine which includes the current setup-flow state machine
[ ] design state machine(s)
[ ] replace current flag based reconnect with state machine implementation
The current reconnection handling to the HA server is more of a quick and dirty implementation than a proper solution. With the new reconfiguration options there's a chance of a race condition, where suddenly two client connections are active. This interferes with heartbeat timeouts and can lead to constant reconnections. This has been seen in unfoldedcircle/feature-and-bug-tracker#243
The core already uses a state machine implementation for the WebSocket integration driver connections. This could probably be used as a starting point with some modifications (e.g. no
authentication_errortransition from the transient Connecting state, because of no header-based authentication):Tasks: