Fix: MQTT reconfiguration reverts to old settings on save

[PWhite-Eng]

Problem

When reconfiguring the integration via the "MQTT Broker" option, changes to the connection details (e.g., updating the Broker IP or port) were not being saved. After submitting the new details, the configuration would revert to the previous values.

Cause

The async_step_configure_serial_port method was calling self.get_options() at the start of the step. This caused self.options to be reloaded from the stored config entry, overwriting the new values that had just been set in the preceding async_step_mqtt_config step.

Fix

Removed the redundant self.get_options() call in custom_components/ramses_cc/config_flow.py. The self.options dictionary is already correctly populated by the previous step, so reloading it is unnecessary and destructive in this context.

Verification

• Confirmed that changing the MQTT connection string (e.g., IP address) via the config flow now correctly persists the new value.

[PWhite-Eng]

Fix: CI failure due to pycares 5.0.0 breaking changes

I encountered a CI build failure during the testing phase with the error AttributeError: module 'pycares' has no attribute 'ares_query_a_result'.

The Issue

The pycares library recently released version 5.0.0, which introduced breaking API changes (specifically removing ares_query_a_result). The testing dependency chain (pytest-homeassistant-custom-component -> aiohttp -> aiodns) relies on pycares, but aiodns is not yet compatible with version 5.0.0.

Because the development requirements were not pinned to exclude this new version, the CI environment automatically installed the incompatible 5.0.0 release, causing the test suite to crash.

The Fix

I have updated requirements/requirements_dev.txt to explicitly pin the version:

Plaintext

pycares<5.0.0

[PWhite-Eng]

I am seeing persistent CI failures related to a dependency update, and I could use some guidance on how to resolve this in this repo's environment.

The tests are failing with AttributeError: module 'pycares' has no attribute 'ares_query_a_result'. This is caused by pycares releasing version 5.0.0 recently, which introduced breaking changes that are incompatible with the current version of aiodns used in the test suite.

I attempted to fix this by adding pycares<5.0.0 to requirements/requirements_dev.txt in this PR. However, the GitHub Actions runner appears to be ignoring this change or using a cached version of the requirements file. The CI logs show it skipping the new line and still installing pycares-5.0.0:

Plaintext

Collecting pyserial-asyncio-fast>=0.16 (from -r ... requirements_dev.txt (line 9))
Collecting ramses-rf==0.52.4 (from -r ... requirements_dev.txt (line 10))
...
Downloading pycares-5.0.0-cp313-cp313-manylinux_2_26_x86_64.manylinux_2_28_x86_64.whl

Since the runner isn't picking up the constraint despite it being present in my branch, I am struggling to get the tests to pass. Could you advise if there is a specific workflow for updating dependencies here, or if this pin needs to be applied upstream?

[silverailscolo]

You can take the dependency change out of your PR. Thanks for identifying the cause. I copied it to PR #371 but run into the same problem.
It's being worked on in aiodns, so it seems most efficient for us to wait for PR aio-libs/aiodns#218 to be merged.

[github-actions]

Package	Line Rate	Health
.	60%	❌
tests_new	99%	✔
tests_old	94%	✔
virtual_rf	66%	➖
Summary	69% (2232 / 3221)	➖

Minimum allowed line rate is 60%