SDK: expose all internal constants to Gladys

Feature requests
1

Hello,

I wonder why all of Gladys’ constants are not exposed by the SDK? This would avoid having to duplicate them in integrations and would limit errors. Example of a constant:

image
image880×855 73.2 KB

Thanks

2

Hi @Sescandell :slightly_smiling_face:

Thanks for the suggestion, the need is indeed real! Having to manually copy values like category: 'switch' or the codes for BUTTON_STATUS, with the risk of typos that cause device discovery to fail, is not a good developer experience.

However, I don’t think we’ll expose all internal constants. The core’s constants.js file mixes two things:

  • The public contract enums (categories/types/units of features, STATE, BUTTON_STATUS, weather conditions, transports…) → these, yes, it makes sense to expose them in the SDK, with TypeScript typings for autocompletion and compile-time errors :+1:
  • Implementation constants (internal events, WebSocket message types, timings…) → these will remain internal. Exposing them would turn them into a public API, and every internal renaming would become a breaking change for all integrations. The role of the SDK is precisely to encapsulate all of that.

So the idea we’re keeping: expose in the SDK the subset of constants that are part of the public contract (those that the API actually validates), with automatic CI checking to ensure they stay synchronized with the core.

One small clarification though: the reference for execution remains the version of Gladys installed at the user’s location. If a new category is added in a future version, it won’t be accepted by an older Gladys, even with an up-to-date SDK.

I’ll add it to the SDK roadmap!