🚀 Matter & Gladys Assistant: ¡Comenzamos!

No uso su plugin matterbridge-example-dynamic-platform, ¡es realmente práctico! Genera decenas de dispositivos de todos los tipos existentes, lo que permite probar muchos dispositivos.

He subido una imagen para corregir un pequeño error, en algunos casos tenía dispositivos con deviceData vacío, lo que rompía la integración :slight_smile:

Por otro lado, puedo controlar los enchufes en Matterbridge, ¡así que buena noticia, todo funciona!

Solo el dispositivo « CookTop » no puedo controlarlo, pero me pregunto si no será solo un sensor…

Ah, creo que lo he entendido:

Como son placas de cocción, solo se pueden controlar para apagarlas, no para encenderlas (lo cual sería muy peligroso). Esto permite apagarlas a distancia :slight_smile:

Bueno, algo nuevo que implementar, pero bueno, no creo que haya muchos dispositivos en el mercado para esto, así que no es mi prioridad.

Esta mañana, añado el control de 2 funciones indispensables: gestión de la luminosidad y el color de las bombillas conectadas :rocket:

Lo pruebo todo en la práctica con la excelente bombilla Nanoleaft Matter Thread E27:

Acabo de publicar una nueva imagen con gestión de colores y luminosidad de las bombillas :slight_smile:

Acabo de publicar una nueva imagen con la gestión de los sensores de humedad :droplet:

Acabo de publicar una nueva imagen con la gestión de los termostatos (calentamiento + aire acondicionado). Por ahora, gestiono la temperatura objetivo así como el encendido/apagado :fire:

¡No hay quien te pare! :grinning_face:

una máquina nuestro @pierre-gilles :grin:

Algunos comentarios de prueba

¡Una excelente función! Veo los números de los Endpoint en los nombres de los dispositivos a agregar y los agregados.

Sin embargo, acabo de eliminar el plugin somfy en matterbridge y los dispositivos emparejados aún están presentes :thinking:
Luego, reinstalé el plugin y me encontré con nuevos números de Endpoint, PERO Gladys conservó los números antiguos para los dispositivos emparejados.
Probé el alto/bajo y no funciona.

Descomisioné este matterbridge y los dispositivos somfy emparejados desaparecieron correctamente.

Añadí el matterbidge y los dispositivos somfy reaparecieron con sus nuevos Endpoint, y mis dispositivos de respaldo ya no están conectados a nada :(, obligación de eliminarlos y volver a hacer todo.

De lo que he podido ver (con el plugin somfy), los Endpoint cambian con cada reinstalación como dices, pero los serialNumber y uniqueId son idénticos cada vez. No sé si esto puede ser una pista.

También debería haber un spinner cuando se descomisiona un dispositivo, ya que descomisionar un matterbridge puede tardar y no se sabe si está en proceso o no.

Sí, los dispositivos emparejados no desaparecen aunque los elimines en Matterbridge, así es como funciona Matter.

De la misma manera, si mi enchufe conectado Eve Energy es inalcanzable, sigue siendo visible en todas partes (por ejemplo, en mi iPhone, sigue en Homekit).

En este caso, este comportamiento proviene de Matter y no de Gladys.

Sí, desafortunadamente, como el plugin cambia los números de endpoint, no podemos hacer coincidir los antiguos con los nuevos.

Sin embargo, podríamos mostrar un « Sin respuesta » en el antiguo, como hace iOS, por ejemplo:

No es suficiente, desafortunadamente, el uniqueId es propio del dispositivo « padre » Matter, pero en este dispositivo puedo tener varios « child_device » cada uno con una lista de características.

No hay ningún identificador debajo que no varíe.

Me encantaría ver qué pasa en otro controlador Matter, ¿podrías probar el mismo comportamiento en iOS o en Google Home?

¡Buena observación! Lo voy a añadir :slight_smile:

He hecho varios intentos pasando por Matterbridge de « bridge » a « childbridge » y sí, por supuesto, el endpoint cambia, pero los endpoints de las características siempre están en el mismo orden, es decir, el endpoint del dispositivo + 1, etc. Por lo tanto, en teoría, deberías poder reaparearlos juntos, pero probando de otra manera.
Para mí, sigo pensando que:

  • el node_id es un parámetro => que puede cambiar
  • el endpoint es un parámetro => que puede cambiar.

Si para el external_id tomas:

  • dispositivo => el número de serie si está disponible, o el unique_id si está disponible, o cualquier otra cosa… (si no hay nada más disponible, entonces avisas de que los datos históricos se perderán en caso de reapareamiento)
  • características => external_id del dispositivo + « -1 » para el primer endpoint del dispositivo, « -2 » para el segundo, etc.

Normalmente no hay ninguna razón por la que no puedas reaparearlos y actualizas los parámetros « node_id » y « endpoint » para cada uno de los dispositivos…

Te basas en el uso de Matterbridge, ellos hacen su propia implementación interna, pero esto no es representativo del protocolo Matter en su conjunto, no es suficiente para sacar conclusiones :slight_smile:

No creo que el enfoque que propones sea conforme al estándar Matter, y aún no he visto ninguna otra implementación en el ecosistema Matter que funcione de esta manera.

Dicho esto, tienes razón en un punto: podríamos considerar permitir al usuario vincular un nuevo dispositivo a uno antiguo, siempre que ambos tengan exactamente las mismas funcionalidades en el mismo orden.

Pero esto no siempre es posible, porque:

  • Un dispositivo físico puede recibir actualizaciones y exponer nuevas funcionalidades a medida que el protocolo evoluciona.
  • En el caso de Matterbridge, el software en sí puede evolucionar y agregar funcionalidades a dispositivos ya integrados.

Aun así, voy a profundizar en el tema para ver cómo Apple o Google manejan este caso. Mi objetivo sigue siendo seguir el estándar Matter de la manera más rigurosa posible.

@Terdious he probado un enfoque de coincidencia (para reemplazar los dispositivos) basado en el par único_id + posición, pero bueno, el riesgo es realmente fusionar un dispositivo con otro dispositivo. No he visto nada en la especificación que garantice este funcionamiento.

Mientras sea solo una coincidencia de reemplazo, me molesta menos. En cuanto a external_id, mantenemos el enfoque actual que es el enfoque oficial.

¡Sería genial tener la información en « directo »!

Una idea al pasar: ¿y si tuviéramos un botón que permitiera descomisionar y reaparear automáticamente el dispositivo, crees que sería viable?
Esto permitiría un refresco de los dispositivos emparejados. Podría estar disponible solo en Matterbridge, no necesariamente en dispositivos unitarios como los tuyos actualmente (porque no veo el interés).

No, no realmente, porque en este caso no hay un identificador único a este nivel.

(Ya os veo venir, no, « VendorID » y « ProductID » no son identificadores únicos :stuck_out_tongue: )

En el caso de Matterbridge, el identificador único está a nivel del dispositivo hijo que representa un aparato, por lo que puedo proponer al usuario un emparejamiento a este nivel. Creo que no funcionará perfectamente, pero será mejor que nada…

Aprovecho para recordarte esto :slight_smile:

Añadir un spinner durante el desmantelamiento:

Añadir un distintivo a los nodos desconectados:

¿Y con un ping6, crees que funcionaría mejor para las pruebas en lugar de verificar el inet6 de la interfaz de red?
Cuando desactivo ipv6 en el syno, efectivamente inet6 desaparece al ejecutar ifconfig en el syno (no en el terminal de docker gladys, no puedo verificar porque no hay comandos de red instalados).

Entonces, realmente hay cosas que ya no entiendo :frowning: y que superan mis competencias en docker/red.
En mi syno, he activado la IPV6 en la red:


mis dockers (incluyendo Gladys) están en modo host y la ipv6 parece no estar activa:

y sin embargo matterbridge detecta ipv6 y es la ipv6 del propio syno (normal porque host) :thinking:

@Terdious @pierre-gilles ¿docker en PC/MAC o NAS?

¡Bien hecho!! (aunque no tengo un Google Home)

Así que acabo de probar en iOS:

  • creación de un hogar en la aplicación Casa
  • emparejamiento con Matterbridge a través de código QR: OK
  • detección automática de los dispositivos Somfy y su adición a Casa en diferentes habitaciones y creación de una escena abrir/cerrar
  • pruebas de subida/bajada: OK (aunque no me parece muy buena la gestión de los deslizadores)
  • prueba de la escena: OK
  • desactivación del plugin Somfy en Matterbridge: TODOS los dispositivos (guardados, por lo tanto) desaparecen de Casa, así como la escena asociada
  • reactivación del plugin: TODOS los dispositivos Somfy reaparecen y se colocan todos en una sola habitación por defecto (garaje), pero la escena no ha vuelto
  • prueba de abrir/cerrar: OK
  • eliminación del plugin Somfy en Matterbridge: TODOS los dispositivos (guardados, por lo tanto) desaparecen de Casa
  • reinstalación del plugin Somfy (por lo tanto, nuevo Endpoint): TODOS los dispositivos Somfy reaparecen y se colocan todos en una sola habitación por defecto (garaje)
  • prueba de abrir/cerrar: OK

Algo interesante, el plugin matterbridge-somfy ha « encontrado » los antiguos Endpoint y parece hacerlos coincidir con los nuevos:


Descomisiono y vuelvo a añadir Matterbridge en Gladys: los nombres conservan los antiguos Endpoint, pero parece que se ha producido una sincronización, ya que mi persiana de prueba (Salón PF) me vuelve a pedir una habitación para guardar, aunque había puesto « casa ». Sin embargo, la función de abrir/cerrar no funciona.
Descomisiono y vuelvo a añadir de nuevo… bueno, lo intento, pero ya no funciona :frowning:
image

No utilizo exactamente ifconfig, utilizo en Node.js el módulo core os:

Hago:

const interfaces = os.networkInterfaces()

Lo que me devuelve algo así:

{
  lo: [
    {
      address: '127.0.0.1',
      netmask: '255.0.0.0',
      family: 'IPv4',
      mac: '00:00:00:00:00:00',
      internal: true,
      cidr: '127.0.0.1/8'
    },
    {
      address: '::1',
      netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
      family: 'IPv6',
      mac: '00:00:00:00:00:00',
      scopeid: 0,
      internal: true,
      cidr: '::1/128'
    }
  ],
  eth0: [
    {
      address: '192.168.1.108',
      netmask: '255.255.255.0',
      family: 'IPv4',
      mac: '01:02:03:0a:0b:0c',
      internal: false,
      cidr: '192.168.1.108/24'
    },
    {
      address: 'fe80::a00:27ff:fe4e:66a1',
      netmask: 'ffff:ffff:ffff:ffff::',
      family: 'IPv6',
      mac: '01:02:03:0a:0b:0c',
      scopeid: 1,
      internal: false,
      cidr: 'fe80::a00:27ff:fe4e:66a1/64'
    }
  ]
} 

Luego, miro si hay direcciones « IPv6 » disponibles :slight_smile:

Normalmente, si ya no tienes interfaces ipv6, también debería desaparecer en Gladys.

Si quieres ver el resultado del comando en tu caso, puedes abrir el inspector de tu navegador y seleccionar esta solicitud:

No estoy seguro de entender la pregunta. Desarrolle en Mac y mi Gladys funciona en un Beelink mini S12 Pro :slight_smile:

¡Gracias por la prueba! :slight_smile:

Vale, lo sospechaba, iOS no guarda ningún rastro de los dispositivos, y por lo tanto no tiene que hacer coincidir lo antiguo con lo nuevo, lo elimina todo. Me parece violento :sweat_smile: Después, por ahora en estas plataformas, no hay historiales (no hay vista gráfica), así que les importa poco el legado, lo cual no es nuestro caso.

Para informar, aún no había empujado mis mejoras de esta mañana, por lo que probaste la versión del sábado por la noche :stuck_out_tongue:

Acabo de empujar un nuevo build Docker con esta vez el emparejamiento automático basado en la pareja « UNIQUE_ID + posición » (solución imperfecta lo recuerdo, pero « good enough »)

Sin embargo, ¿todavía lo ves en la lista en « configuración » no? El decommissioning no ha funcionado