Falls du es einfacher machen möchtest und anderen Leuten ermöglichen, diese Integration zu nutzen, könntest du ein kleines Matterbridge-Plugin schreiben (mit Hilfe von KI, relativ einfach), sodass das Gerät zu Matter wird und damit mit Gladys kompatibel ist (aber nicht nur!).
Das Plugin ist einfach eine JS-Datei, in der du deine Magic Home LED-Befehle auf ein Matter-SDK abbildest, und dann musst du das Plugin nur noch in einem Git-Repo hosten, um es anschließend in Matterbridge zu installieren.
Matterbridge wird mit einem Klick in Gladys gestartet:
Ich gebe zu, ich hatte diese Möglichkeit bereits in Betracht gezogen. Aber ich bin auf einige Probleme gestoßen, als ich versucht habe, IPv6 in meinem Netzwerk zu aktivieren. Und ich habe auch professionelle Dienste, die bei mir laufen, also habe ich ein bisschen Angst, alles durcheinander zu bringen.
Aber es könnte interessant sein, das zu erkunden, denn selbst wenn das, was ich gemacht habe, funktioniert, ist es weit davon entfernt, perfekt zu sein. Es gibt Verzögerungen, und wenn man mehrere Dinge gleichzeitig ändern möchte, gibt es Probleme.
Eigentlich, wenn du Matterbridge einfach auf derselben Maschine wie Gladys laufen lässt, wird es nicht mal über dein Netzwerk gehen, also kannst du die Warnung, dass du eine IPv6-Schnittstelle brauchst, meiner Meinung nach ignorieren. Es wird wahrscheinlich trotzdem funktionieren (nicht zu 100% sicher, aber aus Erfahrung klappt es).
Ich habe ein benutzerdefiniertes Matterbridge-Plugin für meine Magic Home LED-Streifen (5 RGBWW-Controller, die als extendedColorLight exponiert sind) erstellt. Ein- und Ausschalten sowie die Helligkeit funktionieren perfekt, aber die Farben werden nie übertragen.
Fehler in den Gladys-Logs
ValidationDatatypeMismatchError/128: Expected number, got object.
at TlvNumberSchema.validate (/src/server/services/matter/node_modules/@matter/types/src/tlv/TlvNumber.ts:110:19)
at ObjectSchema.validate (…)
at Object.ClusterClient.commands. [as moveToHueAndSaturation]
at MatterHandler.setValue (/src/server/services/matter/lib/matter.setValue.js:160:24)
Identifizierte Ursache in matter.setValue.js Zeile ~160
await colorControl.moveToHueAndSaturation({
hue: matterHue,
saturation: matterSaturation,
transitionTime: null, // ← sollte 0 sein
optionsMask: { executeIfOff: true }, // ← Objekt statt einer Zahl (Bitmap)
optionsOverride: {}, // ← Objekt statt 0
});
Der optionsMask wird als JS-Objekt übergeben, aber ColorControl.moveToHueAndSaturation der Lib @matter/main erwartet eine Zahl (Bitmap). Dasselbe Muster funktioniert für LevelControl.moveToLevel, weil dieser Cluster Objekte akzeptiert, aber
ColorControl lehnt sie ab.
Vorgeschlagene Lösung
await colorControl.moveToHueAndSaturation({
hue: matterHue,
saturation: matterSaturation,
transitionTime: 0,
optionsMask: 1,
optionsOverride: 0,
});
Umgebung
- Gladys v4 (Image gladysassistant/gladys:v4)
- Matterbridge 3.6.1 (luligu/matterbridge:latest)
- Benutzerdefiniertes Matterbridge-Plugin matterbridge-magic-home mit Gerätetyp extendedColorLight
- NAS Synology DS1520+, Docker, --network=host
Ich könnte, aber ich denke, es wäre vielleicht besser, zu warten, bis das Farbsystem in Matter funktioniert, und dann veröffentliche ich das fertige Plugin.
Ich könnte mir eine PR anschauen, ja, aber ich habe das nur einmal gemacht, und das war anders, weil ich einfach nur einen Build für Windows für eine Anwendung vorgeschlagen habe.
