Das ist wie bei Zigbee-, Z-Wave- und anderen Geräten: Nur weil das Protokoll das Gerät und dessen Funktionen kennt, bedeutet das nicht, dass Gladys diese ohne weitere Maßnahmen nutzen kann, wenn eine Integration existiert.
Man muss Gladys (also entwickeln) mitteilen, wie ein Schalter reagieren soll, wie ein Präsenzsensor Informationen sendet, welche Funktionen eine Lampe haben kann (Helligkeit, Farbe, Ein/Aus usw.).
Und das muss für jedes Protokoll gemacht werden.
Zigbee ist eine „alte“ Integration und hat daher viele bekannte generische Geräte (Schalter, Licht, Energieverbrauch und -leistung usw.), die bereits entwickelt wurden.
Wenn ein neues Gerät mit neuen Funktionen auf den Markt kommt und niemand aus dem Forum es kauft, wird die Entwicklung und das Testen schwierig und dauert lange.
Bei Z-Wave, einer jüngeren Integration als Zigbee, gibt es weniger Nutzer, daher werden auch weniger Geräte mit ihren Funktionen hinzugefügt. Ich komme von Jeedom und habe Geräte, die in Gladys implementiert wurden, nachdem ich die Informationen für die Integration bereitgestellt habe.
Bei Matter ist es ähnlich, und es ist noch jünger.
Alle Tests und Integrationen wurden (soweit ich weiß) mit matterbridge durchgeführt, das bestimmte Geräte im Demomodus bereitstellt.
In der Praxis fangen wir gerade erst an, daher gibt es noch Lücken, und wir können die Gerätebasis und die Funktionen dank der Personen erweitern, die Hardware kaufen.
Dort kann es kompliziert werden, weil die Hersteller von Matter-kompatiblen Geräten eine ältere Version von Matter integrieren können, die nicht der aktuellen entspricht, und bestimmte Funktionen nicht vom Gerät unterstützt werden (z. B. eine Rückmeldung), und das merkt man erst nach dem Kauf und bei Funktionsproblemen.
Und man sollte bedenken, dass sich die Funktionen der Geräte nicht von einer Integration zur anderen übertragen; leider sind das getrennte „Welten“.
Ich hoffe, meine Erklärung ist klar genug, ich habe mich nicht unbedingt gut durchgelesen 