Hola,
Me pregunto por qué todas las constantes de Gladys no están expuestas por el SDK. Así se evitaría tener que duplicarlas en las integraciones y se reducirían los errores. Ejemplo de constante:
Gracias
¡Hola @Sescandell 
¡Gracias por la sugerencia, la necesidad es real! Tener que copiar a mano valores como category: 'switch' o los códigos de BUTTON_STATUS, con el riesgo de errores tipográficos que hacen fallar el descubrimiento de los dispositivos, no es una buena experiencia para el desarrollador.
Por otro lado, no creo que vayamos a exponer todas las constantes internas. El archivo constants.js del núcleo mezcla dos cosas:
- Los enums del contrato público (categorías/tipos/unidades de características,
STATE,BUTTON_STATUS, condiciones meteorológicas, transporte…) → estas sí, tiene sentido exponerlas en el SDK, con los tipos TypeScript para tener autocompletado y errores en la compilación
- Las constantes de implementación (eventos internos, tipos de mensajes WebSocket, temporizaciones…) → estas seguirán siendo internas. Exponerlas las convertiría en una API pública, y cada cambio de nombre interno se convertiría en un cambio de ruptura para todas las integraciones. El papel del SDK es precisamente encapsular todo esto.
Por lo tanto, la idea que retenemos: exponer en el SDK el subconjunto de constantes que forman parte del contrato público (aquellas que la API valida realmente), con una verificación automática en CI para garantizar que permanezcan sincronizadas con el núcleo.
Pequeña precisión: la referencia a la ejecución sigue siendo siempre la versión de Gladys instalada en el usuario. Si se añade una nueva categoría en una futura versión, no será aceptada por un Gladys más antiguo, incluso con un SDK actualizado.
¡Lo añado a la hoja de ruta del SDK!