husqvarna_automower_ble: Report mower not pairable just before connection#166002
husqvarna_automower_ble: Report mower not pairable just before connection#166002alistair23 wants to merge 1 commit intohome-assistant:devfrom
Conversation
There was a problem hiding this comment.
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 reportedpairableflag 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_inputis stillNone), 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 beforecheck_mower()/connect), and useLOGGER.warningsince 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)
homeassistant/components/husqvarna_automower_ble/config_flow.py
Outdated
Show resolved
Hide resolved
…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>
9c8c098 to
aee7294
Compare
|
|
||
| # 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): |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
Why not pop up a confirmation dialog instead? You need to grab a fresh mfg data when user actually start the flow to check.
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
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: