Document local_name matching restrictions (#1449)

This commit is contained in:
J. Nick Koston 2022-08-27 15:06:45 -05:00 committed by GitHub
parent 377ba9ef34
commit a406ef9888
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -162,6 +162,8 @@ Result:
If your integration supports discovery via bluetooth, you can add a matcher to your manifest. If the user has the `bluetooth` integration loaded, it will load the `bluetooth` step of your integration's config flow when it is discovered. We support listening for Bluetooth discovery by matching on `connectable` `local_name`, `service_uuid`, `service_data_uuid`, `manufacturer_id`, and `manufacturer_data_start`. The `manufacturer_data_start` field expects a list of bytes encoded as integer values from 0-255. The manifest value is a list of matcher dictionaries. Your integration is discovered if all items of any of the specified matchers are found in the Bluetooth data. It's up to your config flow to filter out duplicates.
Matches for `local_name` must be at least three (3) characters long and may not contain any patterns in the first three (3) characters.
If the device only needs advertisement data, setting `connectable` to `false` will opt-in to receive discovery from Bluetooth controllers that do not have support for making connections such as remote ESPHome devices.
The following example will match Nespresso Prodigio machines: