Iâm adding a new table to the data model and would like your input to ensure it aligns well with the needs before moving forward.
Context
In some integrations, we need to store the values supported by a given feature.
Simple example: an air conditioner with an âoperating modeâ.
- Some models support: Hot / Cold / Auto
- Others: only Cold
Currently, we donât really model this notion of âcapability per device,â which is starting to cause issues.
We already see this with scenes / Zigbee2MQTT: for buttons, we display a quite extensive list of possible actions (several dozen), while a given device only supports a small part of them. Result: less clear UX and risk of user errors.
Proposal
I propose adding a 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
This would allow us to store, for a given device feature, the list of actually supported options.
The label will be an English value that will then be translated in the translations.
If the label doesnât exist, the fallback will be to display the English label.
On the API side, it would look something like this:
Why now?
I see this need becoming more and more frequent, especially:
- with Matter, where some devices (robot vacuums, air conditioners) expose clusters with a dynamic list of possible options
- with Zigbee2MQTT, where some features (especially buttons / actions) are exploding in the number of possible options
We are clearly moving towards a model where we can no longer settle for a global list of options per feature.
What do you think? Do you see any cases where this model wouldnât work?
Thanks for your feedback ![]()
