Skip to content

husqvarna_automower_ble: Report mower not pairable just before connection#166002

Open
alistair23 wants to merge 1 commit intohome-assistant:devfrom
alistair23:alistair/pairable-fixup
Open

husqvarna_automower_ble: Report mower not pairable just before connection#166002
alistair23 wants to merge 1 commit intohome-assistant:devfrom
alistair23:alistair/pairable-fixup

Conversation

@alistair23
Copy link
Contributor

Proposed change

Only report that the mower isn't pairable just before we try to connect to it.

The mower needs to be in pairing mode for the initial connection to work. Every model does this a little differently, so there isn't one simple step. Confusingly if the mower isn't in pairing mode the BLE connection will still work and the mower will pair. BUT the communication won't, we just get an authentication error. So it isn't an obvious error for users.

For a range of mowers it's not a simple step to enter pairing mode. It involves rebooting the mower and then starting the connection quick enough to get the timing right. Users have trouble getting this right and there are numerous issues opened thinking that the integration isn't working, when in fact they just didn't have the mower in pairing mode.

So, the idea is to warn users that the mower isn't in pairing mode.

Here's the tricky part. The Mower provides this bool to indicate if the mower is in pairing mode. I don't have enough data to know if that bool is reliable for all models and all firmware versions. So I can't rely on the bool. Which means I don't want to abort the process if the mower reports that it isn't in pairing mode. Hence the log. The idea is that if it doesn't work users will check the log, see the message and try again, while not blocking anyone from trying if the bool is incorrect.

This is a re-open of #160426 as it was closed

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

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:

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 link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adjusts the Husqvarna Automower BLE config flow so the “not pairable / not in pairing mode” advisory is reported later in the flow, closer to the point where a connection attempt is made, to reduce confusion during setup.

Changes:

  • Move device support detection (_is_supported) into the config flow class and store the mower’s reported pairable flag on the flow instance.
  • Emit a log message in the Bluetooth confirm step when the mower reports it is not pairable.
Comments suppressed due to low confidence (1)

homeassistant/components/husqvarna_automower_ble/config_flow.py:131

  • This log is emitted as soon as the confirm step is displayed (when user_input is still None), which can create log spam and is earlier than “just before we try to connect” (per the PR description). Consider logging only when the user submits a valid PIN (right before check_mower()/connect), and use LOGGER.warning since this condition is advisory and does not indicate a failed operation.
        if not self.pairable:
            LOGGER.error(
                "The mower does not appear to be pairable. "
                "Ensure the mower is in pairing mode before continuing. "
                "If the mower isn't pariable you will receive authentication "
                "errors and be unable to connect"
            )

        if user_input is not None:
            if not _pin_valid(user_input[CONF_PIN]):
                errors["base"] = "invalid_pin"
            else:
                self.pin = user_input[CONF_PIN]
                return await self.check_mower(user_input)

…tion

Only report that the mower isn't pairable just before we try to connect
to it.

Resolves: home-assistant#156482
Signed-off-by: Alistair Francis <alistair@alistair23.me>
@alistair23 alistair23 force-pushed the alistair/pairable-fixup branch from 9c8c098 to aee7294 Compare March 19, 2026 12:12

# Some mowers only expose the serial number in the manufacturer data
# and not the product type, so we allow UNKNOWN here as well.
if product_type not in (ProductType.MOWER, ProductType.UNKNOWN):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to thus pull. But this is not reliable anymore (including unknown). AquaContours/Precise will get passed here and be discoverd as mowers.

They send the mfg data in multiple separate broadcasts, one is serial another is product type.

So when only serial, they will be seen as mowers.

In general we would need several packets to detect type. That is likely why unknown was needed in the first place.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ps. Problem is our flow will not restart of we reject unkown here and get correct data after.

errors: dict[str, str] = {}

if not self.pairable:
LOGGER.error(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not pop up a confirmation dialog instead? You need to grab a fresh mfg data when user actually start the flow to check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The mower does not appear to be pairable.

3 participants