He seguido tus intercambios en GitHub con la fábrica de plugins, en particular este comentario:
Por favor, encuentra otra solución para asegurarte de que esos dispositivos “nuevos” sean en realidad los mismos que los anteriores guardados en Gladys.
En realidad, no es el plugin el que gestiona esta parte, por lo que Claude Code no podrá mejorar realmente nada en cuanto al mecanismo de emparejamiento.
Si tienes dificultades con Matterbridge en tu ciclo de desarrollo y pruebas, lo más pertinente sería abrir un issue en el repositorio principal de Matterbridge para explicar con precisión qué no funciona y ver con su desarrollador si es posible mejorar el flujo de trabajo.
Por otro lado, si iniciamos esta discusión, es mejor llegar con casos reproducibles y, si es posible, ejemplos de plugins ya utilizados en producción. Esto permitirá demostrar que se trata de una limitación general de Matterbridge y no de un caso específico del plugin.
cc @prohand: Creo que también te concierne en tus pruebas
sí, esta IA empieza a irritarme en este desarrollo
Matterbridge no es el problema para mí.
Hay un número de serie para los climas Mitsubishi que tienen 36 caracteres: no sé quién los genera, sabiendo que Matterbridge solo envía 32 a Gladys.
Por lo tanto, cuando hay una parada del plugin y un reinicio, tenemos nuevos endpoints con los mismos números de serie en Matterbridge, pero no en Gladys, de ahí los nuevos dispositivos en lugar de una simple actualización.
Por lo tanto, le pedí a la IA que encontrara una solución para tener un número de serie más corto.
Y esta tonta de IA (lo siento, es la mostaza…) me modifica el código (ya dos veces) y genera un número de serie aún más largo.
En resumen, si no funciona con mi último comentario, lo dejo porque no sé cómo hablarle como es debido (pero bueno, empezó con los inicios de Siri en su momento y aún no sé cómo hablarle).
De mi experiencia, Claude Opus 4.8 está realmente al nivel de un buen desarrollador. Por lo tanto, si la experiencia es frustrante, el problema probablemente proviene de algo más que de la “inteligencia” de Claude
Alcance confuso: aquí en realidad le estás pidiendo que gestione “2 plugins en uno”. Esto aumenta considerablemente la complejidad y dificulta el comportamiento, especialmente si luego solo pruebas una de las dos ramas. Creo que valdría la pena recrear un ticket más simple: un solo plugin, una sola API, un solo caso de uso. Esto hace que el desarrollo y, sobre todo, la validación sean mucho más simples.
Falta de retroalimentación de la IA: la fábrica podría mejorar la experiencia devolviendo sistemáticamente una respuesta en el issue de GitHub. Por ejemplo, una frase simple como: “he modificado X / no he encontrado nada que cambiar / no hay suficiente información”. Hoy en día, tenemos la impresión de trabajar “en el vacío”, lo cual es frustrante del lado de la prueba, porque ni siquiera sabemos si la IA ha tenido realmente algo que hacer o si ha concluido que no había nada que modificar.
El SERIAL_NUMBER mostrado en Gladys es puramente informativo: no se utiliza para reconciliar dos dispositivos con diferentes NodeID.
Para la deduplicación / actualización de un dispositivo existente, si no existe ningún dispositivo con el mismo NodeId, Gladys se basa en el uniqueId proporcionado por Matter, ¡y no en el número de serie!
Entiendo, y eso seguramente alimenta mi frustración y volver a empezar desde cero lo aumenta aún más… en fin, ya veré cuándo me sienta mejor.
Para el último parche de la fábrica, manejó muy bien los envíos de los números de serie y ID únicas de matterbridge a Gladys, y son estrictamente idénticos.
Mi pregunta es, ¿quién gestiona/genera los NodeID?
¿Cómo puedo encontrarlo?
En toda lógica y siguiendo lo que describes como comportamiento, Gladys debería ver que el Unique ID es idéntico, ¿no? Y, por lo tanto, hacer una actualización en lugar de una adición?
Ahora creo que el problema viene de Gladys y no de la fábrica, ¿tengo razón?
Me informé, en el caso de Matterbridge, el NodeId se genera/asigna durante el emparejamiento de la instancia con el fabricante Matter (por lo tanto Gladys aquí).
Luego, cada dispositivo está en modo « ChildBridge » bajo Matterbridge y se identifica por su número de endpoint.
Por lo tanto, aquí tendrás un solo Node ID, es realmente un caso particular de Matter el caso Matterbridge.
En Gladys, puedes encontrar esta estructura directamente en la configuración de la integración Matter: allí verás el NodeId de la instancia Matterbridge, luego los endpoints asociados a cada dispositivo.
Te pongo el pastebin de mi discusión con la IA en el repositorio matterbridge que me ayudó a entender todo esto
No necesariamente estoy de acuerdo con lo que está escrito, pero bueno.
Por ejemplo, he probado y vuelto a probar el plugin oficial de somfy de matterbridge: añadiendo todas mis persianas en Gladys, desinstalando el plugin, reinstalando y por lo tanto nuevos endpoints → ningún nuevo dispositivo que añadir en Gladys, todo era reconocido y funcional.
Comportamiento totalmente idéntico con solo un disable plugin y enable plugin.
Por eso no entiendo por qué, por ahora, hay tal diferencia de comportamiento.
