Home Assistant Bluetooth setup via REST and the tuya_ble HACS integration breakage

Bluetooth integration without a config entry

Observed September 2026: with a working adapter (hci0 up, kernel recognises it), no bluetooth config entry appeared in config_entries/get after Core and Supervisor restarts. Zero-config discovery does not always fire.

Completing it manually through the config flow REST API:

POST /api/config/config_entries/flow  {"handler": "bluetooth"}

The response is a single_adapter confirmation step with a flow_id and step_id. The adapter's name, MAC and model appear in description_placeholders. Submitting an empty {} to the flow's URL (/api/config/config_entries/flow/<flow_id>) returns a create_entry result.

tuya_ble (PlusPlus-ua/ha_tuya_ble) is broken on modern HA Core

The standard HACS tuya_ble custom integration imports these names from homeassistant.components.tuya.const: CONF_ACCESS_ID, CONF_ACCESS_SECRET, CONF_APP_TYPE, CONF_AUTH_TYPE, CONF_COUNTRY_CODE, SMARTLIFE_APP, TUYA_COUNTRIES, and others.

All were removed when Home Assistant's core Tuya integration moved from developer-credential (access ID/secret) cloud auth to a QR-code/user-code app-linking flow. The current tuya.const only has CONF_ENDPOINT, CONF_TERMINAL_ID, CONF_TOKEN_INFO and CONF_USER_CODE.

This is not a one-line fix. It would require vendoring the old constants, including a full country/endpoint table, from an older home-assistant/core release tag into the integration's own files. As of September 2026 the integration's default branch was stale; a maintained fork is worth looking for before attempting a patch.

Manifest edits need a Core restart

Editing a custom integration's manifest.json (for example relaxing a pinned requirement version) only takes effect after a Core restart. The parsed manifest is cached in memory, so retrying the same setup without restarting repeats the old error.