From 3a3f894a93c7803dba42cb562f86b176a8e80505 Mon Sep 17 00:00:00 2001 From: "J. Nick Koston" Date: Sun, 7 Jan 2024 22:15:02 -1000 Subject: [PATCH] Remove restriction on bluetooth local name matcher length (#2031) --- docs/creating_integration_manifest.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/creating_integration_manifest.md b/docs/creating_integration_manifest.md index a19b7e95..bbbf49e7 100644 --- a/docs/creating_integration_manifest.md +++ b/docs/creating_integration_manifest.md @@ -161,7 +161,7 @@ The `loggers` field is a list of names that the integration's requirements use f 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. +Matches for `local_name` 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.