# Intégration externe Spotify : avoir un selector unique

**URL:** <https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441>\
**Category:** Configuration\
**Tags:** integration-externe\
**Created:** [Août 3, 2026, 7:16 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441 "2026-08-03T19:16:29Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![spenceur](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/spenceur/32/1961_2.png) [@spenceur](https://community.gladysassistant.com/u/spenceur)\
**Post date:** [Août 3, 2026, 7:16 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441/1 "2026-08-03T19:16:29Z")

</div>

Hello c’est moi !!  
J’ai donc bien acces au plugin externe 🙂  
J’ai voulus intégré spotify :

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/a/6/a6bd75bee175dd359d882c28fd4aa12f78ff35ca.png)

Aucun moyen d’avoir un selecteur unique (uuid) ?

---

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [Août 3, 2026, 8:13 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441/2 "2026-08-03T20:13:43Z")

</div>

Je vais regarder

---

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [Août 3, 2026, 9:26 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441/3 "2026-08-03T21:26:56Z")

</div>

@pierre-gilles, Claude me dit que le problème vient du core voilà son analyse. Tu pourras regarder

```auto
Le diagnostic

Quand le front POST le device découvert sur /api/v1/device, il n'envoie pas de selector. Le core le génère alors dans un hook Sequelize beforeValidate :

server/utils/addSelector.js:11-17
function addSelector(item) {
  if (item.selector) {
    item.selector = slugify(item.selector);
  } else if (item.name) {
    item.selector = slugify(item.name); // <-- ici
  }
}

Donc selector = slugify(device.name), sans aucun dédoublonnage, alors que la colonne est unique: true (server/models/device.js:32-36). La contrainte UNIQUE saute, Sequelize lève un SequelizeUniqueConstraintError, et errorMiddleware.js:42-49 le transforme en 409 sur l'attribut selector — exactement ce que voit le membre du forum.

Son appareil Spotify Connect s'appelle « MacBook Pro de … » → selector macbook-pro-de-..., qui existe déjà chez lui (probablement un autre appareil du même nom : un Chromecast, un AirPlay, un device d'une autre intégration, ou un Spotify déjà ajouté puis renommé).

Ce que ça implique

Le problème n'est pas dans le plugin Spotify : nos external_id sont bien uniques (ext:<selector-integration>:spotify:<deviceId>), l'external_id du device Spotify n'entre jamais en collision. C'est bien une limite du core : le selector est dérivé du nom, et deux appareils portant le même nom sont impossibles à créer.

À noter que le core sait déjà faire mieux ailleurs — externalIntegration.buildSelector.js:25 boucle justement pour trouver un candidat libre :
while ((await db.Service.findOne({ where: { selector: candidate } })) !== null) {
Cette logique n'a simplement jamais été appliquée aux devices.

```

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 4, 2026, 6:03 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441/4 "2026-08-04T18:03:57Z")

</div>

@Will_71 Tu as raison, on devrait gérer ce cas 🙂 Je gère ça dans une PR

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 4, 2026, 6:26 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441/5 "2026-08-04T18:26:26Z")

</div>

C’est corrigé ici :

> <https://github.com/GladysAssistant/Gladys/pull/2772>
>
> \### Description
> 
> This PR resolves a critical issue where creating devices or fea…tures with duplicate names would fail due to selector collisions. The core now automatically generates unique selectors by appending numeric suffixes (e.g., \`-2\`, \`-3\`) or random characters when needed, ensuring that multiple devices or features can share the same name without conflicts.
> 
> \*\*Key changes:\*\*
> 
> 1. \*\*New \`buildUniqueSelector()\` function\*\* in \`addSelector.js\`: Generates unique selectors derived from a base name by:
> - First trying numeric suffixes (\`-2\` through \`-20\`) for readability
> - Falling back to random 4-character suffixes after 20 attempts
> - Checking both the database and a batch-local \`taken\` set to avoid collisions within a single creation pass
> 
> 2. \*\*Device creation\*\* (\`device.create.js\`): Now calls \`buildUniqueSelector()\` to ensure each device gets a unique selector, even when names collide.
> 
> 3. \*\*Feature creation\*\* (\`device.create.js\` and \`device.addFeature.js\`): Similarly ensures unique feature selectors across the entire table (not per-device), with batch-aware collision detection when creating multiple features at once.
> 
> 4. \*\*External integrations\*\* (\`externalIntegration.setDiscoveredDevices.js\`): Strips any selector published by integrations, since selectors are now derived and made unique by the core at creation time.
> 
> 5. \*\*Comprehensive test coverage\*\*: Added unit tests for \`buildUniqueSelector()\` and integration tests for device/feature creation with duplicate names.
> 
> This change maintains backward compatibility while fixing the user-facing issue where discovered devices with identical names (common in multi-device integrations like Zigbee2mqtt) would fail to create.
> 
> \### Checklist
> 
> \- \[x\] Tests pass: Added unit tests for \`buildUniqueSelector()\` and integration tests in \`device.create.test.js\` and \`device.addFeature.test.js\`
> \- \[x\] Linter and prettier pass
> \- \[x\] No breaking changes: The selector generation is now automatic and transparent to callers
> 
> https://claude.ai/code/session\_01ArC7FD5w9SwPhGnu3APxoV
> 
> 
> \## Summary by CodeRabbit
> 
> \* \*\*New Features\*\*
> \* Device and feature selectors are now generated uniquely during creation.
> \* Selectors remain unique across existing records and items created in the same batch.
> \* Discovered devices no longer accept integration-provided selectors; selectors are assigned automatically.
> 
> \* \*\*Bug Fixes\*\*
> \* Prevented selector conflicts when devices or features share names or requested selectors.
> 
> \* \*\*Tests\*\*
> \* Added coverage for selector conflicts, batch uniqueness, fallback generation, and discovered-device normalization.

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Août 4, 2026, 7:29 UTC](https://community.gladysassistant.com/t/integration-externe-spotify-avoir-un-selector-unique/10441/6 "2026-08-04T19:29:19Z")

</div>

Le correctif est live dans la 4.84.4 :

> [@Gladys Assistant 4.84.4: OAuth en HTTPS et sélecteur de valeurs dans les scènes](https://community.gladysassistant.com/t/gladys-assistant-4-84-4-oauth-en-https-et-selecteur-de-valeurs-dans-les-scenes/10450):
>
> Salut à tous ! Petite release du soir, suite directe aux retours d’hier : le vrai fix OAuth Spotify (via HTTPS), le bug d’alarme pendant l’armement, et quelques améliorations UX bien concrètes smileyIntégrations externes : OAuth2 via [my.gladysassistant.com](http://my.gladysassistant.com) Spotify (et les providers OAuth modernes en général) n’acceptent plus une redirect\_uri en HTTP sur une IP locale (http://192.168.x.x). Résultat : la plupart des installs auto-hébergées se prenaient un redirect\_uri: Not matching configura…