Hallo zusammen,
da kürzlich die Matter-Unterstützung über fhempy vorgestellt wurde, möchte ich auf eine bereits länger bestehende Alternative aufmerksam machen.
Die native, Perl-basierte Matter-Integration für FHEM wurde ursprünglich von Zeppelin1979 entwickelt, noch bevor die entsprechende Unterstützung in fhempy verfügbar war (siehe anderer Thread dazu)
Ich nutze diese Integration inzwischen produktiv in meiner eigenen FHEM-Installation. Dabei habe ich verschiedene Funktionen getestet, Fehler analysiert und mich mit einzelnen Erweiterungen und Fehlerbehebungen an der Weiterentwicklung beteiligt.
Wichtig ist mir dabei die Zuordnung: Die ursprüngliche Entwicklung und die Hauptarbeit an den FHEM-Modulen stammen von Zeppelin1979. Ich bin in erster Linie Anwender und Mitwirkender, nicht der Hauptentwickler, aber de kürzliche fhempy-Vorstellung verdrängt kommunikativ diesen Weg gerade ;)
Warum eine andere Matter-Integration?
Was mir an diesem Ansatz gefällt, ist die vergleichsweise schlanke Architektur mit klar getrennten Verantwortlichkeiten. Ich bin nicht so ein Freund von hochintegrierten eierlegenden Wollmilchsäuen...sorry ;)
Die beiden Module 97_MATTER.pm und 97_MATTERDevice.pm sind klassische Perl-Module, die direkt in FHEM eingebunden werden. Sie kommunizieren über WebSocket mit einem separat betriebenen matterjs-server und bilden die unterstützten Matter-Geräte, Endpunkte und Cluster auf FHEM-Readings und Befehle ab.
Damit benötigt die FHEM-Anbindung selbst weder eine zusätzliche Python-Laufzeit noch die BindingsIo-Infrastruktur.
Das bedeutet ausdrücklich nicht, dass hier eine eigene Matter-Protokollimplementierung existiert. Die eigentliche Matter-Kommunikation übernimmt matterjs-server.
Auch fhempy kann einen externen Matter-Server verwenden. Der wesentliche Unterschied liegt daher nicht im Matter-Controller, sondern in der FHEM-seitigen Implementierung: klassische Perl-Module einerseits, Python-basierte Integration über fhempy andererseits. fhempy bietet inzwischen einen umfangreicheren Funktionsumfang und zusätzliche Komfortfunktionen. Der Ansatz von Zeppelin1979 ist dagegen eine direkte, vergleichsweise schlanke Anbindung an den Matter-Server.
Welche Architektur man bevorzugt, hängt letztlich von den eigenen Anforderungen und Vorlieben ab.
1. FHEM-Matter-Module von Zeppelin1979
Die Module ermöglichen die Einbindung von Matter-Geräten einschließlich ihrer Endpunkte und unterstützten Cluster in FHEM.
Die Unterstützung der unterschiedlichen Matter-Cluster und Gerätetypen ist noch nicht vollständig, für meine bisher eingesetzten Geräte funktioniert die Integration jedoch bereits produktiv.
Ich pflege einen eigenen Entwicklungsfork mit ergänzenden Änderungen und Fehlerbehebungen. Die ursprüngliche Entwicklung bleibt dabei das Projekt von Zeppelin1979.
Originalprojekt:
https://gitlab.com/zeppelin1979/fhem-matter
Mein Entwicklungsfork:
https://github.com/Flachzange/fhem-matter-fork
2. Eigenständiger matterjs-server
Als Matter-Controller verwende ich den unabhängig von FHEM betriebenen matterjs-server.
Dieser übernimmt Commissioning, Gerätemanagement und die eigentliche Matter-Kommunikation. FHEM verbindet sich über die WebSocket-Schnittstelle mit dem Server.
Damit bleiben die Verantwortlichkeiten klar getrennt: Matter-Protokoll und Gerätemanagement auf der einen Seite, Integration und Automatisierung in FHEM auf der anderen.
Projekt:
https://github.com/matter-js/matterjs-server
3. Eigenständiger Thread Border Router mit Ethernet und PoE
Für Matter-over-Thread setze ich zusätzlich auf das THBR-Projekt von tostmann.
THBR führt den vollständigen OpenThread Border Router direkt auf einem ESP32-C6 aus. Das ursprüngliche Projekt verwendet dafür eine USB-basierte Backbone-Anbindung.
Für meine Installation habe ich einen Fork entwickelt, der den W5500-SPI-Ethernet-Controller als zusätzlichen Backbone-Transport unterstützt.
Die Hardware besteht aus einem ESP32-C6-Bug mit Eth-Bug-PoE-Erweiterung. Der Border Router arbeitet damit eigenständig über physisches Ethernet und wird über PoE versorgt. Ein dauerhaft angeschlossener USB-Host, Docker oder Home Assistant sind für diese Betriebsart nicht erforderlich.
Der Fork enthält inzwischen auch sämtliche Upstream-Änderungen bis THBR 2026.10.46. Die W5500-Erweiterungen sind im Hauptbranch main integriert.
Originalprojekt von tostmann:
https://github.com/tostmann/THBR
Mein Ethernet-Fork:
https://github.com/Flachzange/THBR-ETH
Dieser Border Router ist natürlich keine Voraussetzung für die FHEM-Matter-Integration. Andere Thread Border Router können ebenso verwendet werden. Matter-over-Wi-Fi benötigt ohnehin keinen Thread Border Router. Was man aber immer braucht ist ein Commissioning Device. Auch dafür wird der ESP mit THBR verwendet.
Mit diesem Beitrag möchte ich vor allem auf die Arbeit von Zeppelin1979 und tostmann aufmerksam machen und meine Erfahrungen mit der Kombination aus FHEM, matterjs-server und einem eigenständigen Thread Border Router teilen.
Mich würde interessieren, ob andere FHEM-Anwender diesen Ansatz ebenfalls verwenden oder daran interessiert sind.
Über Erfahrungen, Rückmeldungen und Beiträge zur Weiterentwicklung würde ich mich freuen.
Bin noch nicht soooo tief in matter eingestiegen. Habe mir testweise Ikea-Teile zugelegt, um zu testen, wie sie noch in zigbee einbindbar sind.
Was mir an diesem Ansatz gefällt, ist die vergleichsweise schlanke Architektur mit klar getrennten Verantwortlichkeiten. Ich bin nicht so ein Freund von hochintegrierten eierlegenden Wollmilchsäuen...sorry ;)Der wesentliche Unterschied liegt daher nicht im Matter-Controller, sondern in der FHEM-seitigen Implementierung: klassische Perl-Module einerseits, Python-basierte Integration über fhempy andererseits. fhempy bietet inzwischen einen umfangreicheren Funktionsumfang und zusätzliche Komfortfunktionen. Sehe ich genauso.
Früher oder später werde ich mich an Deinem Projekt versuchen....
Grüße
Markus