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.
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
Bueno, algo nuevo que implementar, pero bueno, no creo que haya muchos dispositivos en el mercado para esto, así que no es mi prioridad.
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
¡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
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?
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
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.
¡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 )
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…
¿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 y que superan mis competencias en docker/red.
En mi syno, he activado la IPV6 en la red:
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
No estoy seguro de entender la pregunta. Desarrolle en Mac y mi Gladys funciona en un Beelink mini S12 Pro
¡Gracias por la prueba!
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 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
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