Hello,
Je me pose la question de pourquoi toutes les constantes de Gladys ne sont pas exposées par le SDK ? Ca éviterait dans les intégrations de devoir les dupliquer et limiterait les erreurs. Exemple de const :
Merci
Salut @Sescandell 
Merci pour la suggestion, le besoin est bien réel ! Devoir recopier à la main des valeurs comme category: 'switch' ou les codes de BUTTON_STATUS, avec le risque de typo qui fait échouer la découverte des appareils, ce n’est pas une bonne expérience développeur.
Par contre, je ne pense pas qu’on exposera toutes les constantes internes. Le fichier constants.js du core mélange deux choses :
- Les enums du contrat public (catégories/types/unités de features,
STATE,BUTTON_STATUS, conditions météo, transports…) → celles-là, oui, ça a du sens de les exposer dans le SDK, avec les typings TypeScript pour avoir l’autocomplétion et les erreurs à la compilation
- Les constantes d’implémentation (événements internes, types de messages WebSocket, timings…) → celles-là resteront internes. Les exposer les transformerait en API publique, et chaque renommage interne deviendrait un breaking change pour toutes les intégrations. Le rôle du SDK est justement d’encapsuler tout ça.
Donc l’idée qu’on retient : exposer dans le SDK le sous-ensemble des constantes qui font partie du contrat public (celles que l’API valide réellement), avec une vérification automatique en CI pour garantir qu’elles restent synchronisées avec le core.
Petite précision quand même : la référence à l’exécution reste toujours la version de Gladys installée chez l’utilisateur. Si une nouvelle catégorie est ajoutée dans une future version, elle ne sera pas acceptée par un Gladys plus ancien, même avec un SDK à jour.
Je l’ajoute à la roadmap du SDK !