Neue Tabelle zum Speichern der „supported_options“ eines Features

Entwicklung
1

Hallo @contributors :waving_hand:

Ich füge gerade eine neue Tabelle zum Datenmodell hinzu und würde gerne eure Meinung hören, um sicherzustellen, dass es gut zu den Anforderungen passt, bevor ich weitergehe.

:light_bulb: Kontext

In einigen Integrationen müssen wir die von einer bestimmten Funktion unterstützten Werte speichern.

Einfaches Beispiel: Eine Klimaanlage mit einem „Betriebsmodus“.

  • Einige Modelle unterstützen: Warm / Kalt / Auto
  • Andere nur Kalt

Aktuell modellieren wir dieses Konzept der „Gerätefähigkeit“ nicht wirklich, was langsam zu Problemen führt.

Wir sehen das bereits bei Szenen / Zigbee2MQTT: Für Tasten wird eine recht große Liste möglicher Aktionen angezeigt (mehrere Dutzend), obwohl ein bestimmtes Gerät nur einen kleinen Teil davon unterstützt. Ergebnis: Unklare UX und Fehlerrisiko für den Benutzer.

:brick: Vorschlag

Ich schlage vor, eine Tabelle hinzuzufügen:

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

Sie würde es ermöglichen, für eine bestimmte Gerätefunktion die Liste der tatsächlich unterstützten Optionen zu speichern.

Der Label wird ein Wert in Englisch sein, der dann in den Übersetzungen übersetzt wird.

Falls der Label nicht existiert, wird als Fallback der Label auf Englisch angezeigt.

Auf der API-Ebene würde das in etwa so aussehen:

Bildschirmfoto 2026-06-19 um 18.59.43
Bildschirmfoto 2026-06-19 um 18.59.431048×748 67.6 KB

:red_question_mark: Warum jetzt?

Ich sehe diesen Bedarf immer häufiger, insbesondere:

  • mit Matter, wo einige Geräte (Roboterstaubsauger, Klimaanlagen) Cluster mit einer dynamischen Liste möglicher Optionen exponieren
  • mit Zigbee2MQTT, wo einige Funktionen (insbesondere Tasten / Aktionen) in der Anzahl der möglichen Optionen explodieren

Wir bewegen uns eindeutig auf ein Modell zu, bei dem wir uns nicht mehr mit einer globalen Liste von Optionen pro Funktion begnügen können.

Was denkt ihr? Seht ihr Fälle, in denen dieses Modell nicht funktionieren würde?

Danke für euer Feedback :slight_smile:

2

Völlig einverstanden, ich habe die Auswirkungen auf meiner Seite noch nicht gesehen, aber es ist klar, dass die Liste der Aktionen für die Tasten riesig wird.
Szenen damit zu erstellen, ist für diejenigen, die nicht wissen, wie man die Werte abruft, völlig verwirrend.

3

Der PR:

4

Das klingt für mich in Ordnung.

  • Müssen alle Werte immer irgendwo in Gladys abgebildet sein (wie heute)?
  • Wie wird das mit den bestehenden Geräten funktionieren?
5
  • Und wie werden die supported_options einer Funktion gefüllt?
6

Ja! Da ändert sich nichts.

Man kann ein Update für die Geräte hinzufügen, wie wir es tun, wenn sich eine Funktion weiterentwickelt :slight_smile:

Das wird von der Integration gefüllt, wenn es verfügbar/möglich ist!

Bei Matter gibt es zum Beispiel eine Tabelle, die vom Protokoll bereitgestellt wird, mit allen Werten, die das Gerät unterstützt.

7

Hallo @pierre-gilles,

Wo stehst du bei der Überlegung zu diesem Thema? Ist das etwas, das bald erscheinen wird?
Ich habe das « Problem » mit der Integration der Thermostat- und Klimaanlagen-Steuerungen in Tuya, an dem ich arbeite, also habe ich eine Guard programmiert, um Modi nicht zu senden, die von den betreffenden Geräten nicht unterstützt werden. Mit dieser Entwicklung werden wir das aber nicht mehr brauchen :wink:

8

Ja, das ist sogar schon fertig :smiley:

Ich habe gerade gemerged! Du kannst es in deinem PR verwenden :slight_smile:

9

Aaaaah super toll!! Danke dir ^^ :joy: :smiling_face_with_three_hearts:

10

Das funktioniert perfekt! In der Hoffnung, dass „man“ es richtig umgesetzt hat, musste ich es übernehmen, es war in etwas ultra Komplexes mit Wiederholungen verstrickt.
Gerät mit 4 Modi:

image
image298×381 10.1 KB

Gerät mit allen Modi:

image
image301×562 12.7 KB

11

Toll !!