Salut les @contributors 
Je suis en train d’ajouter une nouvelle table au data model et j’aimerais avoir votre avis pour être sûr que ça colle bien aux besoins avant d’aller plus loin.
Contexte
Dans certaines intégrations, on a besoin de stocker les valeurs supportées par une feature donnée.
Exemple simple : une climatisation avec un “mode de fonctionnement”.
- Certains modèles supportent : Chaud / Froid / Auto
- D’autres : uniquement Froid
Aujourd’hui, on ne modélise pas vraiment cette notion de “capacité par device”, ce qui commence à poser problème.
On le voit déjà côté scènes / Zigbee2MQTT : pour les boutons, on affiche une liste d’actions possible assez large (plusieurs dizaines), alors qu’un device donné n’en supporte qu’une petite partie. Résultat : UX moins claire et risque d’erreurs côté utilisateur.
Proposition
Je propose d’ajouter une table :
t_device_feature_supported_option :
- `id` UUID PK
- `device_feature_id` UUID FK → `t_device_feature`
- `value` INTEGER NOT NULL
- `label` STRING NOT NULL
- `sort_order` INTEGER NOT NULL DEFAULT 0
Elle permettrait de stocker, pour une feature d’un device donné, la liste des options réellement supportées.
Le label sera une valeur en anglais qui ensuite sera traduite dans les traductions.
Si le label n’existe pas, le fallback sera d’afficher le label en anglais.
Côté API, ça donnerait quelque chose de ce genre :
Pourquoi maintenant ?
Je vois ce besoin revenir de plus en plus souvent, notamment :
- avec Matter, où certains appareils (aspirateurs robots, climatisations) exposent des clusters avec une liste dynamique d’options possibles
- avec Zigbee2MQTT, où certaines features (notamment les boutons / actions) explosent en nombre d’options possibles
On va clairement vers un modèle où on ne peut plus se contenter d’une liste globale d’options par feature.
Vous en pensez quoi ? Est-ce que vous voyez des cas où ce modèle ne fonctionnerait pas ?
Merci pour votre retour 
