Es como con los dispositivos Zigbee, Z-Wave y otros, no es porque el protocolo conozca el dispositivo y sus funciones que Gladys pueda explotarlos sin hacer nada si existe una integración.
Hay que decirle a Gladys (por lo tanto, desarrollar) que un interruptor debe reaccionar así, un sensor de presencia envía información de esta manera, una luz puede tener una función de luminosidad, color, encendido/apagado, etc.
Y eso hay que hacerlo para cada protocolo.
Zigbee es una integración « antigua » y, por lo tanto, tiene muchos dispositivos genéricos conocidos (conmutador, luz, consumo y potencia energética, etc.) que han sido desarrollados.
Si sale al mercado un nuevo dispositivo con nuevas funciones y nadie del foro lo compra, será difícil desarrollar y probar, y llevará tiempo.
Para Z-Wave, una integración más joven que Zigbee, hay poca gente que lo use, por lo que hay pocos dispositivos añadidos con sus funciones. Vengo de Jeedom y tengo dispositivos que se han implementado en Gladys después de que proporcioné la información para la integración.
Para Matter es lo mismo, y es aún más joven.
Todas las pruebas e integraciones se han realizado (a menos que me equivoque) gracias a matterbridge, que expone ciertos dispositivos en modo demo.
En la práctica, acabamos de empezar, por lo que aún hay agujeros y podremos enriquecer la base de dispositivos y funciones gracias a las personas que compran material.
Donde puede complicarse es que los fabricantes de dispositivos compatibles con Matter integran una versión de Matter que puede ser más antigua que la vigente y algunas funciones no son soportadas por el dispositivo (por ejemplo, una retroalimentación de información), y eso no lo descubres hasta después de tu compra y los problemas de funcionamiento.
Y hay que tener en cuenta que las funciones de los dispositivos no se transmiten de una integración a otra, son, desafortunadamente, « mundos » separados.
Espero que mi explicación sea lo suficientemente clara, no me he releído del todo bien 