Try to fix RFLink tests broken by Python 3.14.3 asyncio changes

[javicalle]

Breaking change

Proposed change

This makes #169074 obsolete by fixing the tests rather than disable them.

During the code tests another bug has been detected and fixed.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes Fix rflink tests broken by Python 3.14.3 asyncio changes #169075
• This PR is related to issue: Bump base image to 2026.02.0 with Python 3.14.3, use 3.14.3 in CI #162263
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[Copilot]

Pull request overview

This PR aims to restore stability of the rflink test suite under Python 3.14.3 by adjusting the RFLink connection mock’s failure sequencing and ensuring setup-related tasks have fully settled before assertions.

Changes:

• Change the RFLink test connection mock to consume failures in left-to-right order.
• Update binary_sensor and sensor availability tests to use the new failure sequence and add an extra async_block_till_done() after setup.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
tests/components/rflink/test_sensor.py	Tweaks availability test’s mocked connection failure sequence and waits for setup tasks to settle.
tests/components/rflink/test_init.py	Changes mock connection failure consumption order to match “sequence” semantics.
tests/components/rflink/test_binary_sensor.py	Tweaks availability test’s mocked connection failure sequence and waits for setup tasks to settle.

[Copilot]

Pull request overview

This PR updates the RFLink test suite to be resilient to Python 3.14.3 asyncio scheduling changes by making connection/reconnect behavior deterministic and ensuring the event loop is fully drained before assertions.

Changes:

• Replace the temporary xfail markers by fixing the underlying timing/race in availability tests.
• Adjust RFLink connection failure sequencing in the test mock to use left-to-right ordering.
• Avoid mutating the shared CONFIG dict in availability tests and explicitly set reconnect_interval under the rflink config key.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
tests/components/rflink/test_sensor.py	Makes availability test deterministic via config copy, controlled reconnect failure sequence, and additional loop draining.
tests/components/rflink/test_binary_sensor.py	Mirrors the sensor availability test fix for binary sensors (config copy + deterministic reconnect behavior).
tests/components/rflink/test_init.py	Changes mock connection failure sequencing to consume failures in call order (pop(0)), matching test expectations.

[joostlek]

Why is it now False True?

[javicalle]

The short answer is because is how tests must work.
failures is to mock the create_rflink_connection method called during initialization and reconnections:
https://github.com/javicalle/home-assistant/blob/60cd4a999116b3967215481eab5fb1f1fa40d037/tests/components/rflink/test_init.py#L65-L66
In that tests, during the RFLink initialization the connection must be fine (failure=False) and must create the configured entities but state would be unknown.
After the disconnect_callback call, RFLink will try to reconnect but will fail (failure=True) and should make entities unavailable

Not sure how has been working until now this way. That part of tests has been this way for years. It's possible that the accumulation of errors caused the test to work, because after adding the await hass.async_block_till_done() sentence, 3 bugs has been detected:

• the fail = failures.pop(0) # removes from left to right (maybe not a bug but very confuse at least)
• the failures = [False, True] to manage failures (probably failures = [False, True, False] would be better to make explicit the second await hass.async_block_till_done() in tests)
• the config[CONF_RECONNECT_INTERVAL] = 60 was wrong and must be config['rflink'][CONF_RECONNECT_INTERVAL] = 60 (fixed in new code)

I hope this answers your questions.

[joostlek]

Awesome, thanks

[joostlek]

So hey, there are 3 other things.

1. We added a radio frequency platform, so if this device has the possibility to just send raw commands, we could add that platform
2. We introduced the serialx library, which can be used in combination with the serial port selector (which is used in a config flow) and that essentially allows you to hook up your serial device to ESPHome and you can put it anywhere in house.
3. We now have config sub entries, so it would be possible to add some form of discovery for devices

[javicalle]

@joostlek Thanks for your comments, I appreciate it a lot.

1. I'm aware of the new radio_frequency entity platform and I'm following it with some interest, but unfortunately, the RFLink library used for the integration doesn't allow sending raw commands in the current version, and it's unlikely the library will be updated.
2. I wasn't aware of the potential use of serialx. It seems like a good use case for the integration and a type of functionality that some RFLink users might find useful. Could you tell me about a use case that utilizes it?
3. I'm quite interested in the config sub-entries for handling the automatic detection of new entities. I'm going to look into how it could be integrated.

In any case, any of these changes should arrive after #161822.

I must say that RFLink usually receives very little attention, making it very difficult to implement changes.