Hola a los @contributors 
Estoy añadiendo una nueva tabla al modelo de datos y me gustaría tener su opinión para asegurarme de que se ajuste bien a las necesidades antes de seguir adelante.
Contexto
En algunas integraciones, necesitamos almacenar los valores soportados por una característica dada.
Ejemplo simple: un aire acondicionado con un “modo de funcionamiento”.
- Algunos modelos soportan: Calor / Frío / Automático
- Otros: solo Frío
Actualmente, no modelamos realmente esta noción de “capacidad por dispositivo”, lo cual empieza a ser un problema.
Ya lo vemos en escenas / Zigbee2MQTT: para los botones, mostramos una lista de acciones posibles bastante amplia (varias decenas), cuando un dispositivo dado solo soporta una pequeña parte. Resultado: UX menos clara y riesgo de errores por parte del usuario.
Propuesta
Propongo añadir una tabla:
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
Esto permitiría almacenar, para una característica de un dispositivo dado, la lista de opciones realmente soportadas.
El label será un valor en inglés que luego será traducido en las traducciones.
Si el label no existe, el fallback será mostrar el label en inglés.
En la API, algo así:
¿Por qué ahora?
Veo que esta necesidad aparece cada vez más, especialmente:
- con Matter, donde algunos dispositivos (aspiradoras robóticas, aires acondicionados) exponen clusters con una lista dinámica de opciones posibles
- con Zigbee2MQTT, donde algunas características (especialmente los botones / acciones) explotan en número de opciones posibles
Nos dirigimos claramente hacia un modelo en el que ya no podemos conformarnos con una lista global de opciones por característica.
¿Qué opinan? ¿Ven algún caso en el que este modelo no funcione?
Gracias por su feedback 
