FHEM Forum

HI!

Da diese Infos eher sehr mau sind dachte ich mal ich frage hier mal...

Gibt es schon irgendwelche Überlegungen MATTER (geht ja schon bald los) ins Fhem einzubinden? Falls es überhaupt möglich ist...

Wow :o bin etwas überrascht... Keine Antwort? Nix? Keine Info?

Woran liegts? Ist es geheim? Eine Überraschung? Oder einfach nur verpönt dieses Thema hier?  :o

Ich mein ja nur... Ich nutze Fhem als hauptsteuerzentrale für all meine Späschen hier und will es definitiv nicht mehr missen... Will mir nicht vorstellen was ich machen soll wenn das mal nicht mehr funktioniert... Dann stehe ich nämlich ganz schön blöd da...

Es wäre doch interessant und vielleicht auch klasse all die in Matter verfügbaren Geräte auch im FHEM darstellen und auslesen zu lassen und vielleicht auch noch anzusprechen mit all den Möglichkeiten von FHEM.

Wenn das hier nicht erwünscht ist, eine Info und ich entferne diesen Beitrag...

a) war es schon mal Thema: https://forum.fhem.de/index.php/topic,121182.0.html
b) sind 14 Stunden "erfolgloses Warten" schon ein Grund, den Weltuntergang zu befürchten...?!?
c) gibt es denn mehr wie Ankündigungen seitens der "alliance"?

Erfahrungsgemäß wird früher oder später so gut wie jeder verbreitete Standard in FHEM unterstützt (falls es nicht sowieso "nur" eine Erweiterung von was Bestehendem wie ZigBee ist)... Die Geräte müssen ja "irgendwie" miteinander kommunizieren ;) .

Also kein Grund für Panik 8) .

 ;D Naja Panik hatte ich nicht, aber nach 120x gelesen und noch keine Antwort hat es mir schon etwas Angst gemacht... ;D

Dann bin ich ja gespant... Dürfte ja noch ein Spannendes Jahr werden was das angeht...  ;)

https://matter-smarthome.de/ (https://matter-smarthome.de/)

Na ja , nur einen Knochen hinwerfen und erwarten dass man sich darauf stürzt,
für den einen oder anderen den Link als Info .

Wer selbst Projekte in Matter realisieren will,findet in
https://github.com/project-chip/connectedhomeip
eine offene SDK zu Matter.

Zu Matter:

Matter loest als Name den herstelleruebergreifenden Smart Home Standard
CHIP (Connected Home over IP) ab.

Der Standard wurde von Groessen wie Apple, Google, Amazon, Philips
ins Leben gerufen,
um Vereinheitlichung und Standard-Schnittstellen der ehemals
proprietaeren Schnittstellen zu realisieren.
Inzwischen haben sich 170 weitere Firmen angeschlossen.

Ziel ist es, auf Basis von Low Energy Bluetooth, Wi-Fi und Thread,
die Kompatibilitaet unter Produkten verschiedener Hersteller zu verbessern.
Diese drei Technologien spiegeln sich im Matter-Logo wider.

Durch die Unterstuetzung von Matter wird die Zusammenarbeit mit Geraeten anderer Hersteller vereinfacht. Matter wird voraussichtlich im vierten Quartal 2021 von der Connectivity Standards Alliance eingefuehrt. Quelle: smarthomeassistent.de

Damit ein Geraet das Matter-Logo tragen darf, muss es mit den Protokollen von Amazon Alexa, Apple Homekit und Weavo von Google kompatibel sein.

Anbindung mit Philips Hue[/b]:
https://www.smarthomeassistent.de/philips-hue-leuchten-werden-durch-bridge-update-mit-matter-kompatibel/

Message der Gruender:
"Dieser branchenweit einheitliche Standard ist ein Versprechen fuer zuverlaessige, sichere Konnektivitaet - ein Guetesiegel dafuer, dass Geraete heute und morgen nahtlos zusammenarbeiten werden. Matter schafft mehr Verbindungen zwischen mehr Objekten, vereinfacht die Entwicklung fuer Hersteller und erhoeht die Kompatibilitaet fuer Verbraucher. Dieser kollaborative Durchbruch basiert auf bewaehrten Technologien und wird von der Connectivity Standards Alliance (ehemals Zigbee Alliance) geleitet, deren Mitglieder aus verschiedenen Branchen zusammenkommen, um die Zukunft der Konnektivitaet zu veraendern.
"

Homepage von Matter:
https://buildwithmatter.com/

Wikipedia zu CHIP:
https://en.wikipedia.org/wiki/Connected_Home_over_IP

Das SDK basiert auf dem Entwicklungsbaukasten ninja (so was wie make),
unter Debian z. B. zu installieren mit sudo apt-get install ninja-build
Auf MACs mit brew install ninja

Das Matter SDK holt man sich mit git clone https://github.com/project-chip/connectedhomeip

Aus dem README des Matter SDK:

"Matter (formerly Project Connected Home over IP, or Project CHIP) is a new
Working Group within the Connectivity Standards Alliance (CSA, formerly Zigbee
Alliance). This Working Group plans to develop and promote the adoption of a
new, royalty-free connectivity standard to increase compatibility among smart
home products, with security as a fundamental design tenet.

The goal of the Matter project is to simplify development for manufacturers and increase compatibility for consumers. The project is built around a shared
belief that smart home devices should be secure, reliable, and seamless to use.
By building upon Internet Protocol (IP), the project aims to enable
communication across smart home devices, mobile apps, and cloud services and to
define a specific set of IP-based networking technologies for device
certification.

The CSA officially opened the Matter Working Group on January 17, 2020 and is inthe process of drafting the specification.

Visit [buildwithmatter.com](https://buildwithmatter.com) to learn more and read
the latest news and updates about the project.
"

Das ist erst einmal reines Marketing-Getrommel der beteiligten Firmen. Von Absichtserklärungen ist noch keine Umsetzung zu erwarten, und keiner der Beteiligten wird deswegen seine proprietären Protokolle aufgeben.

pah

P.S.: "Oberdatenrat", sieh mal an, ein Kollege... 8)

Nun ja, über Absichtserklärungen ist das Thema ja wohl lange hinaus, wenn man sich ansieht und anhört, was auf den Entwicklerkonferenzen (Google IO, Alexa, Apple WWDC, Samsung SDC etc.) zum Thema erzählt wird.

Die Treiber des Standards sind schon in der konkreten Umsetzung und zum Start im Herbst sollen rund 130 kompatible Produkte auf den Markt kommen. Das Thema scheint ziemlich disruptiv zu werden, wenn sich selbst professionelle Gebäudetechniker wie die Insta GmbH damit beschäftigen: https://matter-smarthome.de/interview/smarthome-programmierung-muss-so-einfach-gehen-wie-bei-einem-wecker/ (https://matter-smarthome.de/interview/smarthome-programmierung-muss-so-einfach-gehen-wie-bei-einem-wecker/)

Erst einmal ist das falsch zitiert - er spricht nicht von einem "Wecker". Zweitens lese ich in dem Interview nichts anderes, als in dem Marketing-Blabla der anderen Unternehmen.

Da ist noch nichts konkretes vorhanden.

LG

pah

Wie soll es denn auch konkrete Produkte geben, wenn der Standard noch nicht gelauncht ist? Denken Sie, dass Amazon, Apple, Google, Ikea, Bosch, Samsung und mehr als 200 weitere Firmen einen Standard ins Leben rufen, bereits konkrete Geräte ankündigen und es dann bei Marketing-Blabla belassen? Aber bleiben Sie ruhig bei Ihrer Meinung. Time will tell.

PS. Falls Sie irgendwann doch neugierig werden: Hier ein paar Links zu den Entwicklerseiten beteiligter Unternehmen, die zeigen, dass die Vorbereitungen tatsächlich laufen:
https://developers.home.google.com/matter (https://developers.home.google.com/matter)
https://developers.home.google.com/matter/overview (https://developers.home.google.com/matter/overview)
https://blog.smartthings.com/roundups/smartthings-tests-matter-compatible-products-in-anticipation-of-new-smart-home-standard/ (https://blog.smartthings.com/roundups/smartthings-tests-matter-compatible-products-in-anticipation-of-new-smart-home-standard/)
https://developer.amazon.com/en-US/blogs/alexa/device-makers/2022/01/ces-amazon-announces-new-matter-support-device-makers.html (https://developer.amazon.com/en-US/blogs/alexa/device-makers/2022/01/ces-amazon-announces-new-matter-support-device-makers.html)
https://developer.apple.com/forums/tags/matter (https://developer.apple.com/forums/tags/matter)

Offenbar postet hier jemand mit kommerziellen Interessen. Das benötigen wir nicht, um es zurückhaltend zu sagen.

pah

Noch so eine vorgefasste Meinung. Was sollen das für kommerzielle Interessen sein? Dass ich Werbung für Amazon, Apple und Google mache? Ich beschäftige mich gerade neu mit FHEM und habe es vor einigen Wochen auf meinem NAS eingerichtet um Erfahrungen zu sammeln. Auf Matter freue ich mich, weil ich hoffe, dass es künftig einiges erleichtern wird und vor allem die Einbindung beliebiger Sprachassistenten erleichtern dürfte. Aber ich sehe schon, hier bleibt man gerne unter sich und pflegt seine Vorurteile. Ich wünsche noch einen schönen Tag.

Hier eine, wie ich finde, gute Zusammefassung - wir werden sehen wie das wird. 

https://www.youtube.com/watch?v=zu_BPTw9bns

Und hier noch etwas, das ich ganz interessant finde: https://matter-smarthome.de/entwicklung/was-uns-die-ifa-2022-ueber-matter-gelehrt-hat/ (https://matter-smarthome.de/entwicklung/was-uns-die-ifa-2022-ueber-matter-gelehrt-hat/)

Neugierig bin ich ja schon. Aber wenn wir mal den Stand festhalten:

- Auf die Schnelle sehe ich jetzt kein real existierendes Gerät, das Matter über Wifi unterstützt. Die Eve-Komponenten basieren wohl auf Thread.
- Um wiederum Thread zu sprechen, bräuchte es idealerweise ein USB-Dongle wie den Conbee von dresden electronics. Da sehe ich jetzt aber erst einmal keine Aktivitäten. Bei Innovelec gibt es solche Dongles mit SDK.

Vielleicht könnte man damit versuchen, mal mit Thread-Geräten (von Eve?) einen ersten Kontakt aufzunehmen...

Arbeiten nicht die Leuchtmittel von Wiz mit WiFi? Da sind doch auch Updates angekündigt,zumindest für Lampen die seit letztem Jahr verkauft werden.

Ich habe gerade den Support von Eve gefragt, ob sie etwas als Matter-fähig empfehlen können. Da man ein Produkt auswählen musste, habe ich den Eve Energy, 3. Generation genommen.
Sehr schnelle, dafür nur mittelhilfreiche Antwort: "Nur die 4. Generation und nur nach einem Firmware-Update von uns."

Also wohl besser abwarten...

Hier gibt es eine Übersicht von Eve, welche Geräte Thread (und damit künftig auch Matter) unterstützen (sollen): https://www.evehome.com/de/identify-your-eve-accessory (https://www.evehome.com/de/identify-your-eve-accessory)

Die Antwort des Supports ("Update nötig") und auf der Webseite ("erfordert einen HomePod mini oder das neue Apple TV 4K") wirken jetzt nicht so, als ob "Thread im Sinne des Standard" unterstützt würde.

Ich denke doch, nur ist der Standard ja noch gar nicht "draußen" und dass bislang ein HomePod mini als Border Router für Thread benötigt wird, liegt wohl daran, dass bislang jeder mit Thread sein eigenes Süppchen gekocht hat (Apple, Google ...). Auch da wird erst mit Matter vereinheitlicht. Bei Thread-Geräten gibt es dafür wohl auch ein Softwareupdate: https://matter-smarthome.de/entwicklung/thread-protokoll-erhaelt-update-fuer-matter/ (https://matter-smarthome.de/entwicklung/thread-protokoll-erhaelt-update-fuer-matter/)

Zitat von: Prof. Dr. Peter Henning am 04 Juni 2022, 04:32:50
Offenbar postet hier jemand mit kommerziellen Interessen. Das benötigen wir nicht, um es zurückhaltend zu sagen.

pah

Ich habe auch soeben mal nach fhem und matter hier im Forum gesucht, nachdem ich auch das neue Video von Spiel und Zeug (wie durch mbruehl zuvor geposted) gesehen habe. Bin auch etwas erschrocken @Prof. Dr. Peter Henning, dass du so auf die Posts von homy reagierst. Zumal ich deine Arbeiten mehr als schätze und man doch auch bei diesem Thema ganz offen und konstruktiv diskutieren und sich austauschen sollte?! :o

Denn wie auch wie der angepriesene Standard matter, sollten sich alle Smart Home Interessierten und Geeks egal aus welcher Ecke sie kommen doch auch vernünftig austauschen dürfen. Am Ende sprechen wir ja doch alle die gleiche Sprache, irgendwie! ;-)

Anyway ich freue mich auch auf matter bzw. verfolge das Thema sehr interessiert, da es ja aus meiner Sicht auch für FHEM nur von Vorteil sein kann, wenn man nicht für jedes Gerät ein zusätzliches Modul braucht, sondern ggf. den Standard wie ZigBee und Co integriert und weiterentwickelt und somit zahlreiche Geräte wie bisher ja auch einbinden und standardisiert ansprechen kann.

Vielleicht kann sich FHEM dann auch anderweitig weiterentwickeln, wie z.B.: Benutzeroberfläche, Visualisierung oder oder?!

Also ich sehe da viel mehr als Marketing bla bla, sondern eine tolle Zukunft und vor allem einen Anfang in die richtige Richtung, dass alle irgendwie an einem Strang ziehen auch wenn natürlich die die proprietären Protokolle nicht von heute auf morgen ablösen wird und man weiterhin versuchen wird ein Alleinstellungsmerkmal zu generieren, wie auch immer das aussehen wird.

Für viele Neueinsteiger sicher einfacher bei der Geräteauswahl, da im worst case irgendwie doch alle Geräte miteinander kommunizieren könnten, ohne alles neu zu kaufen. FHEM wird dennoch eine tolle Plattform sein, die Dinge zu konsolidieren oder weiter zu personalisieren.

Das zumindest meine persönliche Meinung nach heutigem Wissenstand, der wie zuvor schon geschrieben ja noch recht mau ist.

Gruß
sTaN

 :o

Oha... So eine brutale Diskussion wollte ich überhaupt nicht entfachen...

Mir ging es eigentlich nur darum, wenn fhem irgendwie Matter unterstützt, erhoffe ich mir dadurch eine EINFACHE, Komfortable integration der vorhandenen Geräte in GoogleHome usw...
Denn momentan ist es alles andere als einfach und auf keinen Fall Komfortabel.

Eine einfache Anzeige der vorhandenen Geräte und die nutzung dieser... Ein, Aus, die Anzeige deren Status und schalten von Geräten anhand der GoogleHome Geolaokalisation... Automatismen bleiben schön im Fhem denn das ist einfach GEIL da!

Mehr wollte ich eigentlich nicht... ;D

Natürlich Hoffe ich das FHEM eigenständig bleibt und noch die Nächsten ca 60 Jahre am Start ist... Danach ist es mir egal... ;D :-X

Spannendes Thema. Mal sehen, wie das alles so weiter geht.

Ich hoffe bei dem Thema auch darauf, das es nicht sowas wie Zigbee/Hue wird, da haut zwar jeder Geräte raus wie es nur geht, aber wenn man alle Funktionen ordentlich uns sinnvoll nutzen will brauch man am Ende dann doch wieder das zum Hersteller passende Gateway, weil wieder irgendwas eingebaut wurde, was eben nicht Standard ist... so erlebt z.B. mit Conbee als Base, und Geräten von Lidl... das Zeug von Hue und Ikea ging bisher meist ganz gut.
Naja schauen wir mal was da kommt, grade bei heise.de hagelt es ja die letzten Tage News dazu...

Jo, es geht los:

Matter: Erste Firmware-Updates für Smart-Home-Zubehör noch vor Weihnachten | heise online

https://www.heise.de/news/Matter-Erste-Firmware-Updates-fuer-Smart-Home-Zubehoer-noch-vor-Weihnachten-7329315.html

Es gibt Neuigkeiten ..
https://www.heise.de/news/Matter-Erste-Firmware-Updates-fuer-Smart-Home-Zubehoer-noch-vor-Weihnachten-7329315.html (https://www.heise.de/news/Matter-Erste-Firmware-Updates-fuer-Smart-Home-Zubehoer-noch-vor-Weihnachten-7329315.html)

Kurzfassung:
- Erste Anbieter bilden schon Untergruppen, welche Inkompatibilitäten fördern können (Hatte ich s.o. nicht so etwas befürchtet)
- Es hört sich zwar nach viel an, aber eigentlich doch wenig Geräte

Zitat:

ZitatDass die federführenden Hersteller die Möglichkeiten der Zusammenarbeit nicht ausschöpfen und im Alleingang zusätzliche Partnerschaften schließen, nährt erste Zweifel, dass der Standard sich in der Praxis womöglich nicht als so universell erweist wie angekündigt

Schauen wir mal, was draus wird .....

Gibt es hier in der FHEM Gemeinde schon irgendwelche Bestrebungen oder überhaupt Auseinandersetzungen zu einer Matter und Thread Integration?

Thread Border Router Hardware gibt es bspw. hier:

https://www.kirale.com/products/

OpenThread gibt es hier:

https://openthread.io/

hier noch etwas interessantes:

https://software-dl.ti.com/simplelink/esd/simplelink_cc26x2_sdk/2.10.00.44/exports/docs/thread/html/thread-br/index.html

Home Assistant arbeitet bereits seit einiger Zeit an der Matter Integration und wird entsprechende Hardware bereitstellen:

https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

https://www.ifun.de/home-assistant-os-8-veroeffentlicht-matter-im-anmarsch-187962/

Home Assistant Yellow - Mini-Computer für matter:

https://matter-smarthome.de/produkte/home-assistant-yellow-mini-computer-fuer-matter/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

Ein USB-Stick ,,SkyConnect - Thread und ZigBee" befindet sich ebenfalls im Vorverkauf:

https://stadt-bremerhaven.de/skyconnect-thread-und-zigbee-fuer-den-home-assistant-vorbestellungen-starten/amp/

https://www.home-assistant.io/skyconnect/

Ich bin auf jeden Fall gespannt, wie das alles weitergeht und ob sich hier bei FHEM auch irgendwann eine (Entwickler) Gemeinde dafür findet.

Gruß Hoppel

Schaut mal, Sonoff hat auch einen USB-Stick mit dem Zigbee/Thread Chipsatz EFR32MG21 wie der Home Assistant SkyConnect:

Sonoff ZBDongle-E Zigbee 3.0 USB dongle

https://www.cnx-software.com/2022/08/05/sonoff-zbdongle-e-zigbee-3-0-usb-dongle-features-efr32mg21-mcu-with-20dbm-radio/?amp=1

Damit könnte man zumindest schonmal die Thread Geräte ,,einfangen".

Gruß Hoppel

der SLAE.SH Zigbee Stick den ich nutze, kann wohl auch OpenThread... https://slae.sh/projects/cc2652/#matter-support
Aber ob ich das will, ist ne andere Frage  :) Sicher: So fancy stuff, we gescheite Schalt- und Rolladenaktoren für Markenschalter (um das alte HM zu ersetzen - und HMIP ist keine Alternative!) wären toll, aber der Rest bei mir ist mittlerweile Zigbee und funktioniert einfach...

Ja, das stimmt bei mir funktioniert eigentlich auch alles mit dem alten Homematic Zeugs und Philips Hue (ZigBee). Aber ich habe Bock auf was neues. :)

Der SkyConnect Dongel wird wohl zukünftig beides parallel funken können (Thread/ZigBee). Da der SonOff Dongel den gleichen Chipsatz hat, müsste das damit eigentlich dann auch irgendwann möglich sein.

Habe gerade einen spannenden Artikel gefunden.

Momentan kocht wohl auch bei Thread mit den Border Routern jeder sein eigenes Süppchen. Das ist dann aber wohl mit der kommenden Thread Version 1.3.0 hinfällig und alles wird mit allem kompatibel, also auf der Thread Ebene... ;)

https://www.theverge.com/2022/7/19/23269460/thread-1-3-0-matter-border-routers-homepod-mini-echo-nest

Spannend, wie sich das alles weiterentwickelt.

Gruß Hoppel

Im Idealfall wäre es doch so, dass bestehende Thread-Border-Router auch mit allem sprechen kann. Die Philosophie hinter Matter ist ja genau das. Wie es jetzt mit Thread aussieht, was ja nur ein Funkstandard für die Sprache Matter ist, weiß ich nicht. Wenn FHEM (oder jede andere Home Assistant Software) mit meinen HomePods sprechen könnte um deren Thread-Funk zu nutzen, das wäre ja mal was. Für Home Assistant gibt es aber scheinbar einen eigenen Thread-Dongle.

Also muss man beide Sticks verwenden? Den -P für Zigbee und den -E für Matter? Und im -E Zigbee ausschalten?

Vielleicht reicht ja auch ein Stick:

https://www.heise.de/news/Smarthome-Matter-USB-Stick-SkyConnect-fuer-Home-Assistant-lieferbar-7445377.html

Zitat von: Amok am 02 Januar 2023, 20:41:50
Vielleicht reicht ja auch ein Stick:

https://www.heise.de/news/Smarthome-Matter-USB-Stick-SkyConnect-fuer-Home-Assistant-lieferbar-7445377.html

geht es mit dem auch, Sonoff plus V2(plus-E) oder ist der mit dem oben genannten nicht identisch ("und oder")  ?

Ich bin da grad nochmal drauf gestossen.
Der springende Punkt ist ja der: Jeder wird auf HomeKit oder so etwas "großes" umsteigen, sobald alle Aktoren und Sensoren durch Matter enabled devices ersetzt sind.
Fhem wird nur noch benötigt, wenn andere Geräte mit anderem Protokoll (z.B. CUL Stick, Sensoren, Homematic) im Einsatz bleiben.

Der ganze Sinn von fhem ist dann dahin... in Rente sozusagen. 

Zitat von: Frood42 am 24 Februar 2023, 12:57:51
Ich bin da grad nochmal drauf gestossen.
Der springende Punkt ist ja der: Jeder wird auf HomeKit oder so etwas "großes" umsteigen, sobald alle Aktoren und Sensoren durch Matter enabled devices ersetzt sind.
Fhem wird nur noch benötigt, wenn andere Geräte mit anderem Protokoll (z.B. CUL Stick, Sensoren, Homematic) im Einsatz bleiben.

Der ganze Sinn von fhem ist dann dahin... in Rente sozusagen.

Dann hast Du nicht verstanden worum es bei FHEM geht.

Cooltux hat es eigentlich schon ausreichend formuliert. Wer ein "großes" geschlossenes System haben möchte, kann das auch heute schon ohne Matter haben. Wer flexibel bleiben will, komplexere Automationen bauen will etc... braucht auch in Zukunft FHEM (oder ähnliches).

Servus,

ich muss auch mal meinen Senf dazu geben.
Da ich grundsätzlich ein Freund von Standards bin, sehe ich solche Vorhaben wie Matter eher positiv.
Nichts desto trotz sehe ich mittelfristig die Exsistenzberechtiging für Fhem, IObroker, HomeAssistant usw. zumindest für die Technikaffine Zielgruppen weiterhin gegeben.
Nicht jeder Hersteller wird auf Matter oder sonst einen Standard wechseln wollen, da sie lieber ihr eigenes Gedöhns verkaufen wollen und nicht jeder will die Cloud und einige wollen tatsächlich noch komplexere logische Verknüpfungen (Automatisierung) erstellen können. Gut die Zielgruppe für die letzten Punke wird von Jahr zu Jahr (gefühlt) geringer :D.

Also keine Angst vor neuen Standards :p

ZitatAlso keine Angst vor neuen Standards :p

wie definierst du standard?
jeden tag ein neuen standard, ist für mich kein wirklicher standard.  ;)

Zitat von: Frood42 am 24 Februar 2023, 12:57:51
Ich bin da grad nochmal drauf gestossen.
Der springende Punkt ist ja der: Jeder wird auf HomeKit oder so etwas "großes" umsteigen, sobald alle Aktoren und Sensoren durch Matter enabled devices ersetzt sind.
Fhem wird nur noch benötigt, wenn andere Geräte mit anderem Protokoll (z.B. CUL Stick, Sensoren, Homematic) im Einsatz bleiben.

Der ganze Sinn von fhem ist dann dahin... in Rente sozusagen.

Also ich habe ja nicht so die Ahnung von Fhem... Nutze es seit ca 5 Jahren und sicherlich nur zu max 10% was es eigentlich kann...

Aber wenn ich was weiß, dann das NICHTS, aber auch rein GAR NICHTS wird FHEM ersetzen können. Das kann ich behaupten, denn ca 80% von den 10% die ich mit FHEM mache, mache ich nur weil es nirgends geht. Kein Hersteller der Welt beschäftigt sich mit solchen dingen und das wird auch nie passieren.
Das sind so komplexe dinge das meistens Leute nicht mal wissen das sis sowas haben wollen!

Ein Beispiel:

Mein Gartentor geht auf und ich bin zu hause:
Mein Küchentablet, welches standardmäßig die FTUI Oberfläche anzeigt, schaltet auf die tinyCam app für 5 Minuten und zeigt mir alle Kameras rund ums Haus an. Zudem Schreit aus einem Lautsprecher welcher am Raspberry angeschlossen ist, das das Tor geöffnet wurde. Aus bestimmten Echogeräten kommt auch die Ansage das das Tor geöffnet wurde. Wenn es draußen über 10Grad Celsius sind, klingelt eine außenklingel. Wenn ich draußen Musik höre mit der Anlage wo ein Echo angeschlossen ist, stoppt er die musik, stellt etwas lauter und macht auch die Ansage das das Tor geöffnet wurde, macht wieder etwas leiser und spielt weiter Musik. Wenns Draußen dunkel ist geht ein Gartenfluter für 5 Minuten an.

Wenn ich nicht zu Hause bin passiert das meiste nicht, dann bekomme ich per Telegram eine Nachricht das das Tor geöffnet wurde und von bestimmten Cameras einen Snapshot.

Das ist nur ein kleines Beispiel... Ander würden den Rahmen Sprengen... ;D

Das soll mal einer nachmachen... ;D

Für mich wäre es interessant wenn Fhem mit Matter Arbeiten würde das man einfach und ohne wahnsinns Umwege und viel tüddelei theoretisch auf alle Aktoren im Fhem über die Home Apps von Google oder Apple zugreifen könnte.  Alles ander ist und bkleibt eh eingeschrenkte spielerei...

Aber wenn ich was weiß, dann das NICHTS, aber auch rein GAR NICHTS wird FHEM ersetzen können.

Gerade daher wäre es ja toll wenn FHEM auch Matter kann, so wäre es in Zukunft einfach machbar eine Komponente zu kaufen die Matter beherrscht und kann es dann in FHEM integrieren.

Stand heute muss man auch bei FHEM schauen ob eine Komponente geht (oder nicht geht).
Mit einem "Matter"-Siegel wäre ein User dann beim Kauf schon mal auf der sicheren Seite und so muss man ggfs nicht für zig verschiedene Hersteller Module bauen sondern hat ein "Matter"-Modul wo dann auch alle entsprechenden Komponenten anlernbar sind.

Ist Stand jetzt noch Wuschdenken (von mir und vielleicht auch von anderen) aber schauen wir mal was da bei FHEM noch kommen wird  ;)

Zitat"Matter"-Siegel

ich habe schon einige "Standards" kommen und gehen sehen. Da, wie schon erwähnt, die Hersteller Ihr eigenes "Gedöhns" verkaufen wollen, werden sie bestimmt Inkompatibilitäten finden. Es geht mit Matter, aber besser mit der "eigenen" Software in der "eingenen" Cloud mit ""Eigenen Monatlichen Gebühren" ... (O.K. letzteres ist Polemisch, aber ich bin Pessimist)

Es könnte sein, das Google und Apple hier als Regulierer einspringen ... dann möchten Sie aber auch, das es mit IHRER Cloud geht und FHEM (und andere Produkte) ist denen egal ..

Es könnte sein, das Google und Apple hier als Regulierer einspringen ... dann möchten Sie aber auch, das es mit IHRER Cloud geht und FHEM (und andere Produkte) ist denen egal ..

Könnte aber auch einfach sein dass Matter das ist was es sein soll:
Ein Standard der es Anbietern einfach macht Geräte entsprechend zu entwickeln die dann in allen Systemen gehen die Matter unterstützen.

Wir wissen es nicht in welche Richtung es sich entwickelt. Wäre es denn schlimm wenn man Matter in FHEM integriert bzw ein Modul für Matter entwickelt um die Matter-Geräte zukünftig in FHEM zu integrieren?

Nun. Es steht ja jedem frei, das zu tun.

Nun. Es steht ja jedem frei, das zu tun.

Das stimmt natürlich, die Chance hier sehe ich persönlich jedoch recht gering wenn ich mir den Thread so anschaue.  ;)
Hätte ich die Zeit und die Kenntnisse dann würde ich das machen aber mit fehlt Beides.  ;D

Zitat von: Cobra am 27 Februar 2023, 15:02:03
Das stimmt natürlich, die Chance hier sehe ich persönlich jedoch recht gering wenn ich mir den Thread so anschaue.  ;)
Hätte ich die Zeit und die Kenntnisse dann würde ich das machen aber mit fehlt Beides.  ;D

Meine Gute... Noch gibt es prakisch kein Interface und/oder keine Geräte, und schon wird "rumgeunkt"?!?
Das ganze ist im Ergebnis bestimmt auch nicht wesentlich komplexer/anders als z.B. HUEBridge/HUEDevice oder zigbee2mqtt, und es würde mich überhaupt nicht überraschen, wenn wir demnächst eine matter2mqtt Implementierung sehen würden, die man mit FHEM oder "whatever" zusammen sinnvoll nutzen kann. Muss ja nicht grade so "verquer" sein wie zwave2mqtt...

Zitat von: Beta-User am 27 Februar 2023, 16:27:15
Meine Gute... Noch gibt es prakisch kein Interface und/oder keine Geräte, und schon wird "rumgeunkt"?!?

Zitat von: misux am 24 Februar 2023, 20:59:04
Ein Beispiel:
Mein Gartentor geht auf und ich bin zu hause:

Die Geräte schlagen doch überall ein, sind nur noch zu teuer.
Von Eve gibt es stand heute fast alles, Matter Thread enabled. Alle Arten von Sensoren, Autoren, z.B auch ein Heizungsthermostat etc...

Und hat mal jemand HomeKit angeschaut?
Gegenfrage: Was kann man damit NICHT machen, was man mit Fhem machen kann?
Du hast dann wohl HomeKit nicht verstanden :-)
Die Beispiele mit dem Gartentor und den Kameras die misux genannt hat, sind jedenfalls nicht das Problem.
Darüberhinaus: HomeKit ist ja auch nur 1 von ehr sehr vielen "Zentralen" die man verwenden kann.
Klar kann jeder sein HomeAssi und ioBroker weiter verwenden, aber sind die auch so easy cloud enabled und auf allen Devices so schön verfügbar?

Und: Ganz sicher wird es ein Fhem Matter (Thread) Modul geben (müssen) - weil man Fhem sonst nicht mehr verwenden kann mit diesen, bald sehr günstigen Devices.

Zitat von: misux am 24 Februar 2023, 20:59:04
Für mich wäre es interessant wenn Fhem mit Matter Arbeiten würde das man einfach und ohne wahnsinns Umwege und viel tüddelei theoretisch auf alle Aktoren im Fhem über die Home Apps von Google oder Apple zugreifen könnte.  Alles ander ist und bkleibt eh eingeschrenkte spielerei...

Du lässt ja auch nicht auf Windows in einer VM Linux laufen und dann auf diesem Linux eine VM in der Windows läuft oder? Warum sollte man das machen?

Und mit Homebridge hast Du ja nur Einbußen und unnötige Komplexität und Redundanz.
Bsp: In Homekit definierst Du Deine eigenen Gruppen von Matter devices. Willst Du das dann in Homebridge, und in Fhem doppelt und dreifach machen?
Da verliert man doch ab 5 Devices komplett den Überblick 

Habs vielleicht nicht ganz rüber gebracht....

Ich würde meine kompletten Im Fhem konfigurierten Geräte einfach mit der Google Home App nutzen KÖNNEN! Es ist selten, sehr selten sogar...

Ich spreche von NUTZEN! AN, AUS, AUF, Zu Und anzeige verschiedener Sensoren... Nicht mehr. Denn die Cloud freie Lösung (Fhem) ist finde ich so stand alone perfekt! Fhem kümmert sich um alle automatismen, ob das Internet, Cloud oder sonstwas da ist oder nicht... Und ich kann sie auch schalten ohne das es eine Verbindung zum Internet haben MUSS!

Die Google Home Variante ist einfach nur n nettes Gimmick... Geht auch jetzt schon, nur sehr eingeschränkt und unheimlich kompliziert.

Und naja, ich habe noch keine 8fach Aktoren für 20€ gesehen außer HM... Und davon nutze ich allein 6... Dann 2 8fach Sensoren als Fenster/Tür Sensoren und einen als Tor, Heizungssensor... Sowas als nicht HM ist schwer machbar bis unbezahlbar.

Dann noch die Funktion das wenn vielleicht Fhem mal aussetzen sollte, sind manche wichtigen Komponenten miteinander gepairt und verrichten ihren Dienst IMMER.

CLOUD ist nur solange toll wenn sie da ist.... Wie kacke es ist weiß mann erst wenn sie mal nicht da ist...

Das ist doch der springende Punkt:
Wenn 90% der Heimbastler bald Matter Thread enabled devices nutzen, was passiert dann mit dem Preis?
Ein Heizungsthermostat für 9,99 Euro. Ein Schalter für 4,99 und eine Glühbirne für 1,99
Da konkurrieren alle Anbieter plötzlich - es gibt kein Homematic als Alleinstellungsmerkmal mehr.
Ganz im Gegenteil, wenn Homematic (ELV?) mit seinem IP nicht auch Matter (dann wohl leider kein Thread) unterstützt, sind sie weg vom Markt.

Das dauert noch locker 2-3 Jahre, aber wie es aussieht, wird es so kommen.

ZitatDas dauert noch locker 2-3 Jahre, aber wie es aussieht, wird es so kommen.

Da mir schon einige Standards mit dem gleichen Versprechen vorgestellt worden sind, wirst Du verstehen, das ich vorsichtig bin.

Es wird sich nicht das Technisch Sinnvolle durchsetzen, sondern das was von den meisten gekauft wird. Ob das Matter sein wird ... ist eine Möglichkeit.

Und das es dann billiger sein wird ...... das glaube ich erst, wenn ich es "sehe".

Bis dahin ist es aber auch nur eine "Glaskugelleserei" ... und die ist bei mir gerade eingestaubt ....

Oder auch: https://imgs.xkcd.com/comics/standards.png

Zitat von: Wernieman am 01 März 2023, 10:17:19
Da mir schon einige Standards mit dem gleichen Versprechen vorgestellt worden sind, wirst Du verstehen, das ich vorsichtig bin.

Es wird sich nicht das Technisch Sinnvolle durchsetzen, sondern das was von den meisten gekauft wird. Ob das Matter sein wird ... ist eine Möglichkeit.

Und das es dann billiger sein wird ...... das glaube ich erst, wenn ich es "sehe".

Bis dahin ist es aber auch nur eine "Glaskugelleserei" ... und die ist bei mir gerade eingestaubt ....

Es gab bisher noch keine Standards, die von Geräten wie HomePod, Alexa (Echo irgendwas) und Google Dings genutzt wurden. (nicht mal Zigbee)
Und die Geräte werden von jedem, auch ohne Technischen Verstand, genutzt. Selbst die Oma richtet bald mit einem HomePod die Lampen ein.
Und: Es ist ja eine Tatsache, dass diese Geräte stark verbreitet sind, das ist keine Glaskugel, die einem das sagt.
Das ist so, als wenn jeder eine Garage zu Hause hat, und dann für 9,99 einen Golf da reinstellen darf. Das wird natürlich fast jeder machen.

Ist das noch Meinung, oder schon Werbung?

Als Werbung würde ich es nicht deklarieren... Es ist eine Diskussion/Meinung die ich allerdings auch teile...

Wenn man sich etwas über Matter/Thread einliest merkt man schnell das dort definitiv die Größten Kollegen auf diesem Planeten MITEINANDER spielen! Und das gabs noch nie!

Wenn das klappt, was ich persönlich hoffe und auch glaube wäre das doch sehr schön!

Wenn alle auf diesem Planeten in bestimmten Dingen gemeinsame Sache mache würden und deren Knowhow und Reccourcen zusammentun würden, wären wir zu viel größerem fähig als manch einer denkt. Aber da alles gierige geldgeile aßgeier sind ist sowas leider selten machbar.

Das ist wie bei FHEM! Es gibt Alternativen die ein ähnliches Ziel verfolgen... Wenn sie diese Kollegen mal zusammen tun würden könnte ich mir gut vorstellen das da was großes entstehen würde.

Ich habe ganz oben schon einmal die Bedenken geäußert, dass hier offenbar auch aus kommerziellen Interessen gepostet wird.

LG

pah

P.S.: Ein Statement wie

ZitatDas ist so, als wenn jeder eine Garage zu Hause hat, und dann für 9,99 einen Golf da reinstellen darf

ist reichlich arrogant.

Ich finde Euren (Rudis und pahs) Vorwurf zu hart.
- dass Apple ohne EU/US-Verfahren von Inkompatibilität lässt, ist geradezu außergewöhnlich.
- Die Sprachassistenten waren ein gewisser Durchbruch für weitere Kreise von SmartHome (ohne, dass es in der Masse angekommen wäre), und nun sind alle 3 relevanten Hersteller nominell hinter einem Standard.
- Für HW-Hersteller ergibt sich damit die kostensparende Chance, geringere SW-Kosten zu haben (und das leidige Thema ist halt, dass viele - mich eingeschlossen - bei HW wenig Verständnis dafür haben, wenn sie wegen der SW doppelt so viel wie der Mitbewerber kostet.
- Matter hat mit Wifi *und* Thread (Zigbee) auf die richtige Kombination von Funkprotokollen gesetzt
- Offenkundige eigentliche Trivialitäten, wie, dass die Heizung die Heizkörperthermostate abfragt und je nach Ventilstand die HK-Pumpe ganz abschaltet, oder zumindest die VL-Temp senkt, wird es entweder nur geben, wenn die Kooperation - sagen wir - Viessmann / Tado - den Edelthermostaten für 120 € rausbringt, oder aber ein Standard da ist.

Die Zeichen stehen schon nicht schlecht. Ein Selbstläufer ist der Erfolg von Matter deswegen nicht.

Kommerzielle Interessen? Es steht doch jedem frei was er wählt, es wird hier nicht auf eine "Firma" verwiesen. Alle grossen machen mit, jeder kann sich einen aussuchen.

Allerdings hier mal was negatives, bei den HomePods steht nämlich zu Thread:

Beim Mini steht noch: "Nicht kompatibel mit Thread-Geräten, die HomeKit nicht unterstützen" - wäre also eine Limitierung auf das eigene Ökosystem.

Meine Meinung:
Wenn es keine Konkurrenz gibt gibt es auch keine neuen Innovationen.

Zitat von: neyzen am 02 März 2023, 10:28:28
Meine Meinung:
Wenn es keine Konkurrenz gibt gibt es auch keine neuen Innovationen.

Du willst Konkurrenz im Protokoll? Damit das kompakter wird, flexibler, oder warum genau?

Zitat von: Prof. Dr. Peter Henning am 01 März 2023, 22:16:00
Ich habe ganz oben schon einmal die Bedenken geäußert, dass hier offenbar auch aus kommerziellen Interessen gepostet wird.

LG

pah

P.S.: Ein Statement wie  ist reichlich arrogant.

Hier wird schrecklich viel dazu geschrieben, aber es ist ja auch eine bewegende Zeit. Auch für FHEM.

um es zu erklären: Jeder hat eine Alexa oder ein HomePod oder sowas zu Hause. Vielleicht 70% der Haushalte.
Also: Praktisch "jeder" hat einen Borderrouter!   
Und für 2,99 kann er (bald) Glühbirnen kaufen, die er mit seinem Handy steuern kann. Denn jeder hat ein Android oder iOS Smartphone. Sogar die Oma.
Ich finde das super, jeder kann im Supermarkt solche Birnen kaufen. Ich schätze 2,99 oder 1,99 das Stück. Die Heizkörpertherostate kosten dann nicht mehr 49,99 oder mehr wie die von Homematic. 

Was genau ist daran arrogant?

Und: Wer will das dann nicht machen?

Warum sollte ich Glühbirnen mit einem Handy schalten wollen? Das ist viel zu umständlich. Wir haben Schalter und Automation dafür. Kein Handy oder Sprachassistent nötig. Tatsächlich kosten viele unserer Birnen deutlich weniger, als 2,99 und sie sind trotzdem "smart" (wobei es tatsächlich nicht smart ist, wenn man für das Schalten solcher Leuchten ein Device raus holen muss, es ist genau das Gegenteil). Ich frage mich, was die Werbetexte sollen? Wer eine Integration von Matter möchte, sollte sich aktiv ran machen. Keiner hält euch auf!

Zitat von: Frood42 am 02 März 2023, 14:50:44
... es ist ja auch eine bewegende Zeit. ...
... Jeder hat eine Alexa oder ein HomePod oder sowas zu Hause. ...

ich hoffe mal du lebst nicht in russland, china, iran, korea, bangladesh, eritrea, ....

Zitat von: Prof. Dr. Peter Henning am 01 März 2023, 22:16:00
Ich habe ganz oben schon einmal die Bedenken geäußert, dass hier offenbar auch aus kommerziellen Interessen gepostet wird.

Mich würde ja schon mal interessieren, wie du konkret zu diesen Bedenken kommst. Hab ich einen Link oder so verpasst?

Zitat von: marvin78 am 02 März 2023, 14:56:04
Warum sollte ich Glühbirnen mit einem Handy schalten wollen?

Du bist offensichtlich nicht die Zielgruppe von "Ich klick mir eine Automatisierung in Homekit oder in der Alexa-App zusammmen". Passt schon, aber warum gehst du davon aus, dass es diese Zielgruppe sonst nicht gibt?

Ich denke dagegen schon, dass es auch Matter-Thread-Nutzer geben wird, die gerne FHEM einsetzen (wollen). Davon ab hast du natürlich Recht wenn du sagst: Mach halt. Es gibt ja keine Bestellungen hier. Zumindest führt es neue Leute ins Thema und damit eventuell auch zu FHEM.

...das war doch nur ein Beispiel. Natürlich geht das komfortabler, deswegen nur eine Frage:
Wie realisiert ihr es gerade mit FHEM und egal welchen Sensoren & Aktoren, dass das Licht im Haus genau dort an ist, wo ihr euch aufhaltet? Und das Licht und ggfs die Musik euch folgt.
(Falls ihr dabei Bewegungsmelder verwenden wollt - als Bewegungsmelder hab ich zur Zeit überall die von Homematic - ich hoffe aber es denkt jemand an andere Möglichkeiten, ich bin gespannt!)
Nur als ein Beispiel.
Und was kostet das?

Bitte um Antwort, dann antworte ich, wie das in Zukunft geht und was das kostet.

ZitatBitte um Antwort, dann antworte ich, wie das in Zukunft geht und was das kostet.

Du meinst, Du guckst in Deine Glaskugel, was es Deiner Meinung nach kosten würde?

Ich sage es dann wenn ihr sagt wie es stand heute mit fhem geht.
Ich verrate nur soviel: Falls es über zusätzliche Komponenten hinaus geht, also über das Beispiel mit Musikboxen, Player oder Lampen, dann wird es in jeden Fall teurer. in jedem. 
Ihr könnt das aber auch alles selber nachlesen. Ich verstehe nicht ganz warum hier einige die Informationen von Herstellern und aus dem Internet verweigern oder scheuen?! (Und von Glaskugeln reden)

Aber sagt bitte erst wie das mit Fhem geht. ich wüsste nämlich nicht ganz genau wie. 

Du biost retorisch geschult oder es Dir nicht bewust:

ZitatIch sage es dann wenn ihr sagt wie es stand heute mit fhem geht.

Das ist ein klassischer Marketing Trick. Weil mit den Daten kann man IMMER billiger (nicht besser) werden!

Und ja, da bis jetzt kein Gerätepark WIRKLICH auf dem Markt ist, ist es Glaskugelleserei.

Und ja, da bis jetzt kein Gerätepark WIRKLICH auf dem Markt ist, ist es Glaskugelleserei.
Na ja, Glaskugel-Leserei ist das jetzt nicht wirklich für den Anfang.
Der eine oder andere Hersteller hat ja schon Mattersupport angekündigt, ist in der Beta-Phase (FUT) oder rollt es gerade aus. Da auch bestehende Komponenten das teilweise bekommen werden und der Hersteller jetzt seine neuen Komponenten nicht günstiger anbieten wird hat man da zumindest schon mal ein Gefühl wo es erst mal bleiben wird.

Und da sind wir meilenweit davon entfernt dass die Teile unter 10€ kosten.
Weder bei Aqara, noch bei Eve oder Philips HUE bekommt man für den Preis eine Komponente. (sind so die ersten 3 die mir eingefallen sind)

Ob dann irgendwann einmal Anbieter auf dem Markt Matterfähige Komponenten für 5-10€ verschleudern? Ich glaub da weniger dran.....

Zitat von: Cobra am 03 März 2023, 11:01:20
Und da sind wir meilenweit davon entfernt dass die Teile unter 10€ kosten.
Weder bei Aqara, noch bei Eve oder Philips HUE bekommt man für den Preis eine Komponente. (sind so die ersten 3 die mir eingefallen sind)

Die Dinger kosten aktuell viel zu viel. Das wird aber automatisch passieren, dass man sie (irgendwann mal) von überall, auch aus China, hinterhergeworfen bekommt. (Was das dann genau mit Marketing und Daten zu tun hat, ist vollkommen unklar).
IKEA bringt "bestimmt" sehr bald Matter kompatible Leuchtmittel für 7,99 raus. 

Warum wird das so billig? Die Antwort ergibt sich aus der Gegenfrage: Warum kostet ein einziger meiner Bewegungsmelder von Homematic immer noch 59,90?

Was auch zur Antwort auf meine eigene Frage führt:
Wie macht ihr das heute mit Fhem? Oder: Habt ihr ein ordentliches Indoor GPS? Nein, also: Ihr bzw wir machen das GAR NICHT mit fhem. Es ist technisch beinahe unmöglich, ausser ihr bastelt euch einen BLE Beacon Park (einfach 10-20 ESP32 nehmen) zu Hause ein und programmiert die Ortung selber.
Alles was bisher geht ist, dass das Licht für 10 Minuten angeht, wo ich mich aufhalte und das für 59,90 pro Abschnitt. Das ist irre (teuer). Und wehe ich bewege mich nicht, oder ich habs mal wieder mit dem Code nicht gecheckt.

Und wie geht das in Zukunft? Eine Möglichkeit - die Technik ist bereits seit dieser Woche in allen Räumen hier - kurz und knapp:
U1-Chip.

Und das ist nur ein Beispiel.

Zitat von: Frood42 am 02 März 2023, 16:57:26
...das war doch nur ein Beispiel. Natürlich geht das komfortabler, deswegen nur eine Frage:
Wie realisiert ihr es gerade mit FHEM und egal welchen Sensoren & Aktoren, dass das Licht im Haus genau dort an ist, wo ihr euch aufhaltet? Und das Licht und ggfs die Musik euch folgt.
(Falls ihr dabei Bewegungsmelder verwenden wollt - als Bewegungsmelder hab ich zur Zeit überall die von Homematic - ich hoffe aber es denkt jemand an andere Möglichkeiten, ich bin gespannt!)
Nur als ein Beispiel.
Und was kostet das?

Bitte um Antwort, dann antworte ich, wie das in Zukunft geht und was das kostet.

https://wiki.fhem.de/wiki/PRESENCE#.C3.9Cberwachung_durch_verteilte_Agenten_in_der_Wohnung_.28presenced.2Flepresenced.2Fcollectord.29

Manchmal sieht man sogar als Mensch mit extrem guter Wahrnehmung den Partner auf dem Sofa nicht sofort. Oder den Hausgast unter dem Bett...

Idealerweise würde man sich - so wie die Katze - selbst einen Chip einsetzen lassen. Dann kann man das Smarthome richtig steuern, und Licht und Musik folgen einem korrekt. Alles andere ist fehleranfällig -

Hmmmm.  8)

Da war doch was mit Datenschutz oder so? Und die Verschwörungstheoretiker hatten doch irgendwelche Bedenken bei den Corona-Impfungen?

LG

pah

Hallo Frood42,

ZitatUnd wie geht das in Zukunft? Eine Möglichkeit - die Technik ist bereits seit dieser Woche in allen Räumen hier - kurz und knapp:
U1-Chip.

Meist Du das hier?
https://forum.fhem.de/index.php/topic,131278.msg1264489.html#msg1264489

Zitat von: Jamo am 04 März 2023, 10:33:31
Hallo Frood42,Meist Du das hier?
https://forum.fhem.de/index.php/topic,131278.msg1264489.html#msg1264489

:D ja mega oder?
Dass es daran lag, dass das nicht true wurde wenn das Licht angeht. Beinahe zu einfach um doch peinlich zu sein. zu heftig...
and [?Floor_Light_Sensor_Hue_2:lightlevel] < 12000)

Achso, das hat aber nichts mit einem neuen Chip zu tun. Das sind die schrottigen Hue Sensoren, die Homematic Bausätze sind halb fertig... und die Hue werden bald ersetzt. Aber wie gesagt... pro Abschnitt 49-69 EUR Kosten... für einen 1980er Bewegungsmelder... bisschen naja. 

Zitat von: Prof. Dr. Peter Henning am 04 März 2023, 09:57:03
Manchmal sieht man sogar als Mensch mit extrem guter Wahrnehmung den Partner auf dem Sofa nicht sofort. Oder den Hausgast unter dem Bett...

Idealerweise würde man sich - so wie die Katze - selbst einen Chip einsetzen lassen. Dann kann man das Smarthome richtig steuern, und Licht und Musik folgen einem korrekt. Alles andere ist fehleranfällig -

Hmmmm.  8)

Da war doch was mit Datenschutz oder so? Und die Verschwörungstheoretiker hatten doch irgendwelche Bedenken bei den Corona-Impfungen?

LG

pah

Kann aber auch am Alter liegen  ;)

In der Tat, müssten die IDs, die man irgendwo an sich trägt auch mit weiteren Sensoren kombiniert werden. Man könnte ja auch mal (Nachts) ohne unterwegs sein. Das ist nicht abwegig.
Ich bin gespannt was es da geben wird. und wenn es zusätzlich Bewegungssensoren (oder Wärme?) für 9,99 sind, auch noch ok.

Das sind die schrottigen Hue Sensoren, die Homematic Bausätze sind halb fertig... und die Hue werden bald ersetzt. Aber wie gesagt... pro Abschnitt 49-69 EUR Kosten... für einen 1980er Bewegungsmelder... bisschen naja.

Stimmt, die von dir erhofften 10€-Bewegunsgmelder die ja der absolute Durchbruch bei Matter sein werden die werden dann natürlich viiiiieeeeel besser sein und nicht so "schrottig" wie deiner Meinung nach (ja, es ist deine Meinung und keine Tatsache) die Homematic- und HUE-Melder sind.
*Kopfschüttel*

Ich hätte mal einen Vorschlag zur Güte:
Die Kategorien des Forums balancieren nicht unbedingt die Menge der Beiträge aus. Shelly ist irgendwo unter others.
Wenn man "Zigbee" in "Zigbee / Thread" umbenennt, unterstützt wenigstens schon einmal das FHEM-Forum Thread :-)

Wenn irgendjemand, der bitte schon einen FHEM-Entwicklungs-Trackrecord hat, übrigens Matter-Spielzeug haben möchte: Ich habe jetzt welches, rein zu Spielzwecken (HomePod mini, Eve-Wundertüte). Aber so schnell habe ich keine Zeit zum Spielen, kann es also regional gerne verleihen.

@Cobra was bei Matter passiert und ob dann tatsächlich viele Noname Marken auf den Zug aufspringen wird man sehen.

BESSERE Presence Erkennung durch MicroWave Sensoren sind ja aber gerade wirklich  ein Trend der groß und günstig durchstartet.

Mit so einem Sensor an der Schlafzimmerdecke bekommst du je nach Sensor und Abstand allein durch deine Atmung eine durchgängige Erkennung während du da liegst.

Nachteil ist halt, dass das nicht batteriebetrieben klappt.

Aber das eröffnet halt schon neue Möglichkeiten. Erkennung am Schreibtisch, am PC, im WC, im Schlafzimmer.

Bisher war das recht teuer, z.B. mit einem Aqara FP1 (Und der war schon günstig ggü. mancher führe verfügbarer Alternative).
Die Tuya waren dann schon nur noch halb so teuer (um die 20€).

Mit Miniboards wie z.B. dem LD2410B wird das ganze aber gerade plötzlich spottbillig.
Als ich das letzte mal geschaut hatte lagen die bei ca. 3€ das Stück.

Ist wegen der extremen Sensitivität auf kleinste Bewegungen auch nicht die Lösung für jedes Problem, aber für viele Anwendung ein Game-Changer.

Zitat von: Cobra am 04 März 2023, 15:27:00

Code Auswählen Erweitern

Das sind die schrottigen Hue Sensoren, die Homematic Bausätze sind halb fertig... und die Hue werden bald ersetzt. Aber wie gesagt... pro Abschnitt 49-69 EUR Kosten... für einen 1980er Bewegungsmelder... bisschen naja.

Stimmt, die von dir erhofften 10€-Bewegunsgmelder die ja der absolute Durchbruch bei Matter sein werden die werden dann natürlich viiiiieeeeel besser sein und nicht so "schrottig" wie deiner Meinung nach (ja, es ist deine Meinung und keine Tatsache) die Homematic- und HUE-Melder sind.
*Kopfschüttel*

Das klingt so als wärst Du da anderer Meinung?
Du meinst also eher, dass ein geschlossenes, propriertäres System wie Homematic, bessere Resultate erzielen kann als
https://github.com/project-chip/connectedhomeip

Kannst Du es vergleichen?

Oder geht man nicht eher davon aus, dass weit optimierte Protokolle als open source Projekte gepflegt - irgendwann viel besser in Hardware genutzt werden, welche dann gar dafür optimiert wurde?
Nein?
na dann... kein weiterer Kommentar.

Und: Mal im Ernst, wenn ein China Bewegngsmelder für 9,99 genausogut ist (gar nicht besser) wie der von Homematic (mit dem ich soweit zufrieden bin):  Dann schüttelst Du lieber den Kopf? Warum?

Und: Dir ist es egal ob die 17 Bewegungsmelder im Haus pro Stück 59,90 oder 9,99 Kosten?

Ihr vergesst bei dem ganzen BlaBla, dass ihr doch für Fhem AUCH Matter Support haben werdet. Ihr profitiert doch auch ALLE von den günstigen Aktoren und Sensoren. Jedem steht es frei weiter bei Fhem oder iOBroker oder so zu bleiben. gvzdus ist ja schon beinahe mittendrin. Ihr braucht dazu übringens nur die Leuchtmittel oder anderen kram von der Windertüte. Um Gottes Willen, bloss keine kommerztiellen Interessen vertreten und den Homepod nehmen (geht ja auch gar nicht, wenns ums FHEM modul geht))- sondern nur das CHIP Tool.

Zitathttps://openthread.io/codelabs/openthread-border-router#0

Und dann sowas:

Zitathttps://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app

Und hier:

Zitathttps://openthread.io/

Wer noch nicht mitbekommen hat, dass es da schon devices gibt, kann ja mal die 5 Seiten Produkte durchblättern. 

Was ich nur meinte: Die 30 MIllionen Neukunden (nur in DE) die mal einen Sensor, Schalter oder eine Glübirne vom Lidl ausprobieren wollen: Die haben bereits HEUTE eine Zentrale zu Hause stehen. Und manche Enthausiasten auch schon ein paaaaar mehr  ;D
Daraus resultiert? Keiner von denen wird an einen openHab, Fhem oder ioBroker rumbasteln. Können auch 98% von denen gar nicht.
Die großen, bösen, kommerziellen, alle ausspionierenden werden einen riesen stück vom Heimautomation Kuchen wegnehmen. Wobei der Kuchen dabei auch noch wächst.
Ich fande fhem über 10 Jahre super. Läuft RockSolid auf der NUC, speist alle geliebten Daten in meine interne DB. Der Code ist armbrechend aber macht flexibel.

Gedanklich bin ich aber schon weg.

Die 30 MIllionen Neukunden (nur in DE) die mal einen Sensor, Schalter oder eine Glübirne vom Lidl ausprobieren wollen

Das ist ja fast ein drittel der Deutschen Bevölkerung?  :o
Glaub ich eher nicht das das so viele ausprobieren wollen. Jedenfalls nicht jetzt. Irgendwann man vielleicht.

Zitat von: neyzen am 04 März 2023, 22:03:33

Code Auswählen Erweitern

Die 30 MIllionen Neukunden (nur in DE) die mal einen Sensor, Schalter oder eine Glübirne vom Lidl ausprobieren wollen

Das ist ja fast ein drittel der Deutschen Bevölkerung?  :o
Glaub ich eher nicht das das so viele ausprobieren wollen. Jedenfalls nicht jetzt. Irgendwann man vielleicht.

Na klar irgendwann mal. Erst dann wenns echt günstig wird.
Aber ich schätze mal gaaaanz grob dass es locker über 30 Millionen Zimmer in Deutschland gibt mit einem Matter Compatiblen Border Router dabei. Dabei zählt man ja viel mehr als Haushalte.

Sorry Leute, ich kann nicht anders - gerade auf der Suche nach ein paar Birnen, mal zum ausprobieren.
Aktueller Preis für E27 Leuchtmittel: 9,99 Wow. Ikea ist da nur wenig drunter, und die waren bisher echt gut.

Bei der Recherche auch hierauf gestossen. Das ist hier komplett das falsche Publikum, aber es gibt scheinbar so viele, die in dieser Richtung die Realität verweigern, deswegen sende ich es dennoch:

Zitathttps://www.computerbild.de/artikel/cb-News-Smart-Home-Matter-Thread-Standard-34110313.html#1552353123

Das wird immer schlimmer. Die Funk Steckdosen sind auch schon billiger als bei Homematic. Die LED Lichterketten auch.

Und bissl weiter oben sagte einer, dass es keine Hardware gäbe ?!?!?!?

Ich weiß ehrlich gesagt nicht so recht was hier diskutiert wird?

Ja, Matter kommt, und wird vermutlich auch ein bedeutender Standard werden.
D.h., er wird langfristig mögliche Alternativen verdrängen.
Aber das heißt doch nicht:

• dass die Zielgruppe spontan um ein Vielfaches wächst
• dass plötzlich alle ihre existierenden Geräte ersetzen
• dass FHEM, HomeAssitant, RedNode usw. plötzlich obsolet sind

Wenn jemand in Matter das nonplusultra des SmartHomes sieht, und mit der gebotenen Funktionalität all seine Bedürfnisse umsetzen kann, dann kann er das doch tun?
Und wer will, kann FHEM weiter als Zentrale benutzen.

Eingangs ging es wohl ob in Fhem bereits etwas für Matter geplant ist.

Und Naja, es werden sicherlich sehr viel mehr Omas die Lampen steuern, wenn sie (heute) schon eine Alexa zu Hause haben. Da kommen einige Millionen zusammen. Und die werden alle kein fhem, Homassi oder so verwenden.
Das heisst z.B. der Anteil der Fhem User wird immer kleiner.
Viel schlimmer wird es aber Homematic gehen...

Ihr müsst euch aber mal mehr reinlesen, z.B. auch sowas:

Zitathttps://stadt-bremerhaven.de/thread-kuenftig-arbeiten-alle-border-router-an-einem-thread-netzwerk-mit/

Das ist direkt wieder in Grund FÜR fhem, weil es sicher spezielle Sensoren / Autoren gibt, die es sobald nicht mit Matter Support geben wird. So gehts mir jedenfalls gerade - akut.

Wer komplexere Automatisierungen vornehmen will, sowie Geräte mit einbinden will die eben nicht 0815 Smart-Home sind (aber dennoch z.B. über eine HTTP API verfügen) wird auch weiter OpenSource SmartHome Systeme verwenden.
Denn auch abseits der Hürde, dass die Konkurrenzprodukte im Moment nicht mitspielen, sind die einzelnen offiziellen Lösungen ja doch eher begrenzt was die Möglichkeiten angeht.
Oft gewollt um die Komplexität zu beschränken und eine einfache Nutzerführung zu erlauben.

Ja: die allgemeine Zahl der Nutzer von SmartHome Produkten steigt.
(Würde sie auch ohne Matter, aber ein übergreifender Standard der Inkompatibilitäten minimiert, senkt natürlich die Einstiegshürde.)
Ja: der "Anteil" von Nutzern die statt einem fertigen Hub eine (OpenSource) SmartHome Lösung nutzen mag PROZENTUAL dadurch auch sinken.

Aber es werden durch den erleichterten Einstieg auch mehr angefixt werden "mehr" zu wollen.
Ich würde also zumindest den Systemen mit leichtem Einstieg in absoluten Zahlen eher einen starken Zulauf prognostizieren.

Fhem ist schon eher nerdy und man war sich hier ja auch nie sicher ob man jeden DAU wirklich an Bo(a)rd haben und jahrelang im Anfängerforum betreuen will.
Hier dürfte die Größe der Community daher eher weniger von solchen Entwicklungen beeinflusst werden.

Aber wenn ich mir z.B. HomeAssistant heute im Gegensatz zu vor 2-3 Jahren anschaue:

• Mittlerweile fast alles über GUI konfigurierbar, Module werden nach und nach von YAML Konfigurationsfiles darauf umgestellt. An sich braucht kein User mehr YAML zu Gesicht bekommen wenn er nicht will.
• Gerätetypen stark standardisiert, eine Kamera egal mit welchem Modul betrieben hat z.B. immer den selben Snapshot Befehl, Lampen haben die selben Standard-Entities(Readings) oder sie selben Parameter beim Einschalten wie Brightness, Duration für den Helligkeitsübergang und auch den selben Wertebereich (nicht 0..99 oder 0-100 oder 0-255 je nach Modul). Und dann eben zusätzliche Entities die evtl. speziell für diese Hardware sind.
• Einfache Automationen direkt in der UI zusammenklickbar
• Super Node-Red Anbindung mit eigenen Home-Assistant-Nodes die Geräteauswahl aus Dropdowns ermöglicht, Autovervollständigung, Device-Specific Parameteranzeige in der Node-Konfiguration, ... Das ganze als Addon, das aus HA automatisch installiert werden kann und fertig vorkonfiguriert ist. Hier kann man dann alle komplexeren Automatisierungen als "Low-Code" Lösung erledigen was auch ohne Programmiererfahrung schnell lernbar sein sollte.
• Fast alles was man an zusätzlicher Software brauchen könnte wie z.B. InfluxDB oder Grafana ist als Addon mit 1-2 Klicks aus Home Assistant heraus installierbar und dann schon vorkonfiguriert.
• Festes Entwickelteam das durch die freiwillige monetäre Unterstützung durch die Community auch die Zeit hat das Projekt voranzutreiben. Fester Releasezyklus mit Changelog, Breaking Changes Beschreibung usw.
• Modern wirkendes Frontend das über die UI zusammengeklickt und konfiguriert werden kann. Auch hier kein Code mehr nötig (für die Nerds aber natürlich weiterhin möglich).

Während ich früher Freunden / Bekannten zu FHEM geraten habe, allein weil ich da bei Fragen gut helfen kann,
rate ich mittlerweile jedem der es nicht ganz so nerdy braucht zu Home Assistant.

Für Homematic sehe ich aber auch keine rosige Zukunft.
Die Konfiguration war mir schon immer zu obskur.
Bei Manchem frage ich mich ob das absichtlich so kompliziert ist um den unbedarften User von der Nutzung abzuhalten. ;)
Der Erfolg lag sicher hauptsächlich daran, dass es zu der Zeit nicht so viele Alternativen gab und sie bei einigen Geräten einen guten Riecher hatten was Funktionalität anging.

Aber heute und erst recht zu dem Preis würde mir das nicht ins Haus kommen...

Lauter Kaffeesatzleser...

Homematic: Die Firmenoberen von eQ3 zeichnen sich bisher nicht durch gute Zusammenarbeit mit Enthusiasten aus. Schade, denn damit torpedieren sie ihr eigenes Geschäftsmodell. Wäre ich dort einer der Manager. würde ich schleunigst ein Expertengremium einrichten, das hilft, den Laden in die Zukunft zu bewegen. Und nein, damoit ist nicht gemeint, dass irgendjemand in der Firma gelegentlich mal über die Userforen drüber schaut.

Matter: Macht nur. Elon Musk hat auch gedacht, die Welt würde ihm folgen, wenn er Twitter kauft.

Der Trend in der Industrie ist noch viel zu uneinheitlich, um dort irgendetwas abzulesen. Sei es bei Matter, oder sonstwo. Die schlimmste Entwicklung ist derzeit, dass sich irgendwelche Marketing-Figuren in die technische Weiterentwicklung einmischen. Kann man sehr schön bei BSH verfolgen...

LG

pah

P.S.: Computerbild zitieren, soso. Das liegt aber nur wenig über der Bildzeitung...

Computerbild macht das auf extra niedrigem Niveau, wenig technisch, leicht verständlich, manchmal sogar mit richtigen Inhalten. So etwas für die einfach strukturiert denkenden.
Da stand halt auch etwas zur Vereinheitlichung eines Protokolls das bei Heimautomation-Komponenten und Zentralen verwendet wird.
Von Kaffee stand da jedoch nichts.
Und da wurde auch etwas dieser Trend von der Verwendung eines solchen Protokolls beschrieben.
Und welche Parteien daran beteiligt sind.

Das war echt nicht zu komplex dargestellt. Deswegen diese obskure Quellenangabe.
Was genau das mit irgendwelchen schrägen Vögeln und Twitter zu tun hat, stand da aber nicht.

Ich bin gespannt wann es hier etwas für Fhem geben wird - denn diese Devices sind sicher mindestens so verbreitet wie viele, für die es bereits fhem Module gibt.

Guten Tag!
Gibt es etwas Neues an der Matter / Thread Front?
Hierzulande ist inzwischen 50% der fhem Infrastruktur auf Matter / Thread umgestellt und die ,,zwei" koexistieren friedlich.
Was aber brutal fehlt ist das logging - es gibt viele matter Devices mit readings, die aber nirgends fortgeschrieben werden.
Auch die Steuerung ist wirklich einfach - einfach genug für Oma - aber zu einfach für fhem-ler.

Skurillerweise wollte ich dem fortschreiben der Daten - das erlangen einer Historie - nun mit homebridge begegnen. Was sich als Unsinn herausstellt.

Abhilfe würde ein OpenThread Border router schaffen, der als Teil vom Netz in die DB schreibt.
Alles was man dazu braucht ist ein nRF52840 Dongle für den Funk.
Da fhem eh bei den meisten auf Raspi oder NUC läuft bräuchte man nur ein OpenThread Modul für fhem und fertig.

https://openthread.io/guides/border-router

Das hätte auch den Vorteil, dass fhem nativ alle matter / thread devices supported. Home-assi und alternativen sind da seit Anfang des Jahres dran.

Grüße
Frood 

Moin,
Ich bin erstaunt, dass es noch gar nichts hier an der Matter-Front gibt.
Bin gerade über die neuen sonoff mini r4m gestolpert welche schön günstig sind und die ich gerne einbinden würde.
Gibt es schon Überlegungen matter zu integrieren?

Zitat von: Frood42 am 03 Dezember 2023, 22:30:44Abhilfe würde ein OpenThread Border router schaffen, der als Teil vom Netz in die DB schreibt.
Alles was man dazu braucht ist ein nRF52840 Dongle für den Funk.
Da fhem eh bei den meisten auf Raspi oder NUC läuft bräuchte man nur ein OpenThread Modul für fhem und fertig.

https://openthread.io/guides/border-router

Grüße
Frood 

Hallo,

Du schreibst: bräuchte man. Wer ist man? Fhem lebt auch vom selber machen und vom teilen. Die Gemeinschaft ist aber kein Dienstleister, dem man Aufträge erteilt und dann das Ergebnis geniest. Wenn Du also Matter in Fhem integriert haben möchtest, dann stellt sich niemand quer, wenn Du es selbst in Angriff nimmst. Und, hier ist jeder gerne bereit zu unterstützen, wenn man nicht weiter kommt.

Grüße Jörg

Es gibt auch eine Matter MQTT Bridge.
https://github.com/canonical/matter-mqtt-bridge
Damit sollte sich Matter mit ein wenig Arbeit von Fhem steuern lassen.

Kann nicht glauben, dass so wenig Interesse an Einbindung in FHEM besteht...

Die Bridge ist doch ein guter Weg. Einfach und für jeden individuell zugeschnitten.

Zitat von: -jato- am 23 März 2024, 19:24:36Kann nicht glauben, dass so wenig Interesse an Einbindung in FHEM besteht...

Und warum schreibst Du es dann nicht selber? (Oder versuchst es?)

Sorry aber nur so funktioniert OpenSource ....

So ist es. Es scheint, als gäbe es Interesse, von den Interessierten will es aber keiner machen. Alle anderen Einbindungen sind aber so entstanden: Jemand wollte es haben und hat es gemacht. Da sind auch oft Menschen dabei gewesen, die vorher noch keine Zeile Code in Perl geschrieben hatten. Sie haben sich dann Hilfe gesucht und hier im Forum dann in der Regel auch gefunden.

Zitat von: Wernieman am 24 März 2024, 10:27:34

Zitat von: -jato- am 23 März 2024, 19:24:36Kann nicht glauben, dass so wenig Interesse an Einbindung in FHEM besteht...

Und warum schreibst Du es dann nicht selber? (Oder versuchst es?)

Sorry aber nur so funktioniert OpenSource ....

Ich würde es sehr gerne machen, bin aber vom coden so weit weg wie unsere Nationalelf vom EM-Sieg im Sommer.

Ich wüsste gar nicht wo man da anfängt.

ZitatIch wüsste gar nicht wo man da anfängt.

Da kann man nichts machen, die 150+ FHEM Entwickler sind gluecklicherweise alle mit perl Kenntnissen auf die Welt gekommen.

Meiner Ansicht nach ist das Verstehen der Protokoll-Eigenheiten aufwendiger, als das reine programmieren eines FHEM-Moduls.
D.h. Doku besorgen und lesen, Hardware besorgen, evtl. bereits existierende Loesungen studieren, und dann mit kleinen Schritten anfangen.

Die, vermeintlichen, Vorteile und Argumente die die Welt verbessern scheinen etwas abzuflachen.

https://www.heise.de/news/Netatmo-verabschiedet-sich-von-Matter-Nanoleaf-wirft-Thread-raus-9957883.html (https://www.heise.de/news/Netatmo-verabschiedet-sich-von-Matter-Nanoleaf-wirft-Thread-raus-9957883.html)

Schade, dass es immer noch kein Matter gibt, da ist HA um Welten besser.
Ich werde mir mal die MQTT Bridge anschauen.

Was ich echt nicht leider kann (hier), ist immer das "dann mach es doch selber", oder noch schlimmer dieser Sarkasmus "Da kann man nichts machen, die 150+ FHEM Entwickler sind gluecklicherweise alle mit perl Kenntnissen auf die Welt gekommen."
Das muss doch nicht sein. Es gibt einfach Menschen, die haben damit nichts zu tun und haben aus Gründen keine Zeit/Weg/was auch immer, sich da rein zu denken.
Gerade in der heutige Zeit, aber lassen wir das....

Warum sollte sich jemand, den Matter nicht interessiert oder die Möglichkeiten nutzt, mit denen man Matter-Geräte auch heute sicher schon integriert bekommt, ohne etwas neues zu entwickeln, sich hinsetzen und für dich und eine kleine Minderheit etwas entwickeln? Da passen die Reaktionen hier schon ganz gut, weil 1. die Forderungen geradezu unverschämt sind und 2. sehr sehr viele der vorhandenen FHEM Intergrationen eben genau so entstanden sind: Jemand fand etwas toll, wollte es integrieren, hat sich angeeignet wie das geht und es gemacht. Das ist für jeden möglich. Tatsächlich ist dann Hilfe von anderen Entwicklern auch noch nie abgelehnt worden. Ein "macht doch mal, weil ich habe keine Lust" ist jedoch wenig hilfreich.

Das ist alles, was ich dazu zu sagen habe.

Zitat von: -jato- am 26 März 2024, 21:28:01Ich wüsste gar nicht wo man da anfängt.

Oh, da können wir sicher Tipps geben. Das geht nämlich heute viel einfacher, als zu der Zeit, in der wir angefangen haben.

Zitat von: Mitch am 23 Januar 2026, 11:42:15Es gibt einfach Menschen, die haben damit nichts zu tun und haben aus Gründen keine Zeit/Weg/was auch immer, sich da rein zu denken.

Dann sollen sich diese Menschen doch ein kommerzielles System kaufen und uns in Ruhe lassen.

pah

Zitat von: Mitch am 23 Januar 2026, 11:42:15Es gibt einfach Menschen, die haben damit nichts zu tun und haben aus Gründen keine Zeit/Weg/was auch immer, sich da rein zu denken.

Aber es sind doch genau die Menschen die eben doch was damit zu tun haben weil sie eben ein Modul für Matter haben möchten aber es dann nicht selbst versuchen wollen obwohl ihnen Hilfe angeboten wurde. Es ist ja eine Gruppe von mehreren Interessenten die einen Vorteil davon hätten. Man könnte sich arrangieren und gemeinsam was auf die Beine stellen.

Früher oder später wird es Matter für FHEM geben, da bin ich mir heute schon sicher. Das Protokoll nimmt zunehmend an Bedeutung zu. Es wird zu wichtig werden, um es nicht zu unterstützen ;)

Hallo,

für ioBroker gibt es eine Matter Adapter. Zusammen mit dem Fhem Adapter im ioBroker kann man da ganz viel machen.

Grüße Jörg

Natürlich kann man "viel machen". Allerdings gibt es - und aus irgendeinem Grund gehäuft hier im Thread - Menschen mit einer gewissen Anspruchshaltung an Software, für die sie nichts bezahlen müssen. Diese Kostenfreiheit ist aber noch nicht einmal der Kern von FLOSS, denn zu diesem Kern gehört vor allem die Freiheit der Entwickler. Und zwar auch die Freiheit zu sagen "wenn Du es willst, mach es halt selber". Mehrere der genannten Personen haben diesen Freiheitsbegriff noch nicht verstanden.

In den 43 Jahren, die ich Open Source Software veröffentliche, sind mir solche Personen immer wieder begegnet. Ich habe wenig Lust, auf meine eigenen Artikel zu dem Thema zu verweisen, aber den Hinweis auf Eric S.Raymonds grandiosen Artikel kann ich mir nicht verkneifen:
https://de.wikipedia.org/wiki/Die_Kathedrale_und_der_Basar

sollte jeder lesen, der die Aufgabe der Entwicklung eines Matter-Moduls bei "Anderen" sieht.

pah

typisch für unseren Gesellschaftswandel: "Die anderen" sollen leisten und man selbst leistungslos konsumieren und laut nach "Solidarität" schreien.

ZitatDas muss doch nicht sein. Es gibt einfach Menschen, die haben damit nichts zu tun und haben aus Gründen keine Zeit/Weg/was auch immer, sich da rein zu denken.

Die Alternative ist übrigens Menschen für Ihre Leistung zu bezahlen ! Genau das hat insbesondere der Mensch, auf dessen Beitrag Bezug genommen wurde, aber wohl nie mit FHEM im Sinn gehabt. Dann gäbe es FHEM vermutlich nicht.

Ergo: Fordert nicht einsatzlos, sondern bietet das zur Unterstützung an, was Ihr könnt: analysieren, codieren, testen, dokumentieren, vermarkten, erklären, ... JEDER kann etwas (beitragen).

Wer nur leistungslos konsumieren(nennt man glaube ich anderswo andere ausnutzen) möchte, sollte sich wenigstens zurückhaltender verhalten.

Schade, dass mein Satz hier so falsch verstanden wurde.
Es geht mir (ich habe nicht nach Matter Support gefragt), nicht darum, dass jemand etwas kostenlos möchte, und denjenigen als Schmarotzer hingestellt, wie das hier einige machen.
Es geht mit persönlich um die Art, wie auf solche Anfragen reagiert wird. Arrogant, beleidigend und mit Unterstellungen
z.B.

Zitat von: KölnSolar am 25 Januar 2026, 10:01:50typisch für unseren Gesellschaftswandel: "Die anderen" sollen leisten und man selbst leistungslos konsumieren und laut nach "Solidarität" schreien.

1. Keiner kennt den Fragenden persönlich.
2. könnte man auch einfach mit einem Dialog starten und seine Hilfe anbieten, damit sich Derjenige dahin entwickeln kann

Aber egal, ich will hier keine Grundsatzdiskussion starten, mir liegt halt gerade in der heutige Zeit viel an Miteinander und Hilfsbereitschaft. Sozial ist, wenn man die Schwächeren unterstützt.

Zitat von: Mitch am 26 Januar 2026, 16:51:57Sozial ist, wenn man die Schwächeren unterstützt.

Unwissenheit als "Schwäche" zu apostrophieren ist Unsinn.

Wenn man seine Unwissenheit erkennt, sollte man sie selbst beseitigen.

pah

Also Leute, es geht doch nicht darum dass hier "Schmarotzer" rumlaufen sondern ob überhaupt angedacht ist Fhem um Matter zu bereichern. Und jeder der danach fragt möchte ja nur eine Implantierung in Fhem, und jeder ist nicht Programmierer, aber es wäre schön wenn sich die Leute einbringen würden die davon Ahnung und Interesse haben. Ich glaube jeder würde sich in unserer Gemeinschaft dazu bereit erklären dieses zu testen und wenn fähig Unterstützung zu leisten. Also nicht gegeneinander sondern zusammen. Achso ICH bin nicht Programmierer aber wäre trotzdem für eine Integration, weil gerade das macht doch die Fhem-Bande aus!!

Zitat von: taskkill am 26 Januar 2026, 23:53:51jeder ist nicht Programmierer

>:(  >:(  Mal langsam, hier wird bitte niemand als "Programmierer" abqualifiziert, das gehört sich überhaupt nicht.

Wenn man für irgendeinen Anwendungsfall Software benötigt, kann man sie entweder kaufen (Möglichkeit A). Dann hat man, naiv gesehen, das Recht darauf, dass die zugesicherte Funktionalität auch erbracht wird. Viel Spaß dabei, dies bei Microsoft geltend zu machen. Oder bei Bose, die gerade dabei sind, ihre Server abzuschalten. Aus gutem Grund sind die so genannten Lizenzverträge in der Regel so ausgelegt, dass solche Ansprüche abgewehrt werden können.

Oder man benutzt FLOSS = Free and Libre Open Source Software (Möglichkeit B). In dem Fall gibt es zwei Untermöglichkeiten. Entweder, man nutzt sie so, wie sie ist und freut sich darüber, dass hier andere Menschen ihre Zeit und ihre Mühe aufgewendet haben (nennen wir das B.1)

Oder man arbeitet daran mit, Möglichkeit B.2.

Genau das fehlt allerdings in den genannten Fällen, stattdessen werden Ausreden vorgetragen.

Die Ausrede, dass man etwas "nicht könne", darf dabei gerne in dem Sinn gemeint sein, dass man etwas "noch nicht könne, aber gerne lernen will". Hier im Forum ist noch jedem geholfen worden, der dies vorgetragen hat. Es gibt sogar namentlich bekannte Beispiele dafür, dass dies absolute Anfänger im Selbststudium zu herausragenden und sehr kreativen Maintainern von FHEM-Modulen gemacht hat.

Wer diese Ausrede aber in dem Sinn verwendet, dass man etwas "nicht könne und es darum die anderen machen sollen", hat in einer Open Source Community nichts verloren. Auf der gleichen Stufe, nämlich ebenfalls mit dem Unwillen verbunden, an der eigenen Unwissenheit etwas ändern zu wollen, ist die Ausrede, dass man etwas "nicht sei".

pah

Zitat von: Prof. Dr. Peter Henning am 27 Januar 2026, 03:51:22

Zitat von: taskkill am 26 Januar 2026, 23:53:51jeder ist nicht Programmierer

>:(  >:(  Mal langsam, hier wird bitte niemand als "Programmierer" abqualifiziert, das gehört sich überhaupt nicht.

Wenn man für irgendeinen Anwendungsfall Software benötigt, kann man sie entweder kaufen (Möglichkeit A). Dann hat man, naiv gesehen, das Recht darauf, dass die zugesicherte Funktionalität auch erbracht wird. Viel Spaß dabei, dies bei Microsoft geltend zu machen. Oder bei Bose, die gerade dabei sind, ihre Server abzuschalten. Aus gutem Grund sind die so genannten Lizenzverträge in der Regel so ausgelegt, dass solche Ansprüche abgewehrt werden können.

Oder man benutzt FLOSS = Free and Open Source Software (Möglichkeit B). In dem Fall gibt es zwei Untermöglichkeiten. Entweder, man nutzt sie so, wie sie ist und freut sich darüber, dass hier andere Menschen ihre Zeit und ihre Mühe aufgewendet haben (nennen wir das B.1)

Oder man arbeitet daran mit, Möglichkeit B.2.

Genau das fehlt allerdings in den genannten Fällen, stattdessen werden Ausreden vorgetragen.

Die Ausrede, dass man etwas "nicht könne", darf dabei gerne in dem Sinn gemeint sein, dass man etwas "noch nicht könne, aber gerne lernen will". Hier im Forum ist noch jedem geholfen worden, der dies vorgetragen hat. Es gibt sogar namentlich bekannte Beispiele dafür, dass dies absolute Anfänger im Selbststudium zu herausragenden und sehr kreativen Maintainern von FHEM-Modulen gemacht hat.

Wer diese Ausrede aber in dem Sinn verwendet, dass man etwas "nicht könne und es darum die anderen machen sollen", hat in einer Open Source Community nichts verloren. Auf der gleichen Stufe, nämlich ebenfalls mit dem Unwillen verbunden, an der eigenen Unwissenheit etwas ändern zu wollen, ist die Ausrede, dass man etwas "nicht sei".

pah

Es war nicht abfällig oder abwertend gemeint.

Nachdem ich heute beim Schwedischen Möbelhaus war und feststellen musste das die Zigbee Produkte aus dem Programm genommen wurden und durch Matter / (Thread ?) Produkte ersetzt wurden frage ich mich nun auch, wie bekomme ich diese Gadgets in mein FHEM Smarthome. Also hier im Forum gesucht und nur diesen Post zum Thema gefunden. Oh ha, das hat mich doch sehr überrascht das es da noch nichts gibt.
Zum Glück hab ich mich noch mit Restbeständen der Zigbee Gadgets eingedeckt, das reicht mir ne Weile. Dann schau ich mal wie ich weitermache.

Zitat von: GeZi3560 am 27 Januar 2026, 17:35:09frage ich mich nun auch, wie bekomme ich diese Gadgets in mein FHEM Smarthome. Also hier im Forum gesucht und nur ...

Hallo,

habe ja schon geschrieben. Matter Adapter in ioBroker installieren und über den Fhem Adapter oder MQTT mit Fhem austauschen.

Es müssen nicht immer alle IT Lösungen alles können, solange sie eine gute Schnittstelle haben.

Grüße Jörg

Bei Matter wird es mittelfristig auf das hinauslaufen, was wir bereits bei ZigBee und HmIP sehen: FHEM kommuniziert mit einem dezidierten Server.
Dazu gibt es hier ein ganz interessantes Interview: https://matter-smarthome.de/interview/eine-alternative-zum-offiziellen-matter-sdk/, aus dem die Probleme ersichtlich sind: Viel proprietäres Gehabe bei den einzelnen Herstellern, somit ein gigantischer Gerätezoo.

Insofern ist der Vorschlag von JoWiemann vollkommen akzeptabel. Wer unbedingt jetzt Matter-Geräte haben will, kann diesen Weg gehen. Und, wenn irgendwann ein kompakter Nur-Matter-Server für einen Raspberry Pi erhältlich sein sollte, wird eben dieses Interface an Stelle eines ioBroker-Servers eingesetzt.

LG

pah

Du meinst also quasi ein Matter2MQTT? Würde ich nach meiner Recherche auch so sehen.

Wobei die iobrocker Lösung so etwas in "Groß" ist.

Erstens gibt es das Konzept im Matter-Universum schon, heißt dort "Border Router", siehe Grafik hier: https://www.st.com/en/wireless-connectivity/matter-products.html

Zweitens muss das nicht MQTT sein, den Overhead kann man sich sparen. Auch bei ZigBee und HmIP ist die Anbindung der "Zentrale" ja direkter und schlanker.

Drittens kann man sowohl bei ZigBee als auch bei HmIP sehen, was der Grund ist. Beide Netze leiten intern von Gerät zu Gerät, weiter eine "Zentrale" - wir sollten vlt. einfach den Begriff des "Border Routers" übernehmen, der trifft es ja - muss also in erheblichem Umfang die logische Netzwerkstruktur beherrschen und verwalten. Sonnenklar, dass eine Skriptsprache wie Perl damit vollkommen überfordert ist. In dem Interview, das ich in meinem vorigen Post zitiert habe, wird dasselbe auch über JavaScript gesagt.

Zitat von: Wernieman am 28 Januar 2026, 15:05:31Wobei die iobrocker Lösung so etwas in "Groß" ist.

Sicher. Geht aber als Zwischenlösung auf einem separaten Raspberry Pi problemlos. Das Ziel könnte also sein, ein solches System mal aufzusetzen - wirklich nur auf Matter fokussiert. Und dann als fertiges Image zur Verfügung zu stellen, das sich ein FHEM-User einfach auf einen Pi knallt und fertig.

LG

pah

Zum Thema Border Router:

https://matter-smarthome.de/wissen/was-ist-ein-thread-border-router/

Umgekehrt gibts das schon als Plugin für z2m: https://github.com/Luligu/matterbridge-zigbee2mqtt
Das ,,verwandelt" alle (?) Zigbee-Geräte in Matter...

Wir können auch den "python matter server" https://github.com/matter-js/python-matter-server über die API an fhem anbinden. Homeassistent nutzt den auch.

Perspektivisch ja. Aber erstens steht in dem Github-Projekt, dass noch viele Dinge fehlen. Und zweitens steht darin, dass das gerade auf Basis von matter.js "neu geschrieben" wird. In dem Interview, das ich unten verlinkt habe, äußert sich einer der Experten darüber etwas skeptisch.

Desweiteren steht in der Doku: "The server runs a Matter Controller and includes all logic for storing node information, interviews and subscriptions. To interact with this controller we've created a small Websockets API with an RPC-like interface. The library contains a client as reference implementation which in turn is used by Home Assistant. Splitting the server from the client allows the scenario where multiple consumers can communicate to the same Matter fabric and the Matter fabric can keep running while the consumer (e.g. Home Assistant is down)."

Nett, aber dieses "small API" ist nicht dokumentiert...

LG

pah

Zitat von: Prof. Dr. Peter Henning am 29 Januar 2026, 20:04:11Nett, aber dieses "small API" ist nicht dokumentiert..

Könne das das hier sein?
https://github.com/matter-js/python-matter-server/blob/main/docs/websockets_api.md

Diese Seite https://github.com/matter-js/python-matter-server/blob/main/DEVELOPMENT.md verweist darauf (ganz unten).

Zitat von: GeZi3560 am 27 Januar 2026, 17:35:09Nachdem ich heute beim Schwedischen Möbelhaus war und feststellen musste das die Zigbee Produkte aus dem Programm genommen wurden und durch Matter / (Thread ?) Produkte ersetzt wurden frage ich mich nun auch, wie bekomme ich diese Gadgets in mein FHEM Smarthome. Also hier im Forum gesucht und nur diesen Post zum Thema gefunden. Oh ha, das hat mich doch sehr überrascht das es da noch nichts gibt.
Zum Glück hab ich mich noch mit Restbeständen der Zigbee Gadgets eingedeckt, das reicht mir ne Weile. Dann schau ich mal wie ich weitermache.

Die Taster sind auf jeden fall Zigbee kompatibel,habe die beiden Bilresa in Zigbbe2MQTT anmelden können. Und die Lampen sollen es wohl auch sein.

Gruß Rolf

Hier (https://matter-smarthome.de/produkte/wie-ikea-die-kombination-von-thread-und-zigbee-meistert/) sind ein paar Infos dazu.

Ich war schon länger nicht mehr aktiv hier – nachdem mich vor Jahren ein Developer-Hero-Member niedergemacht hat, weil ich mich erdreistet hatte, nach Matter zu fragen.

Jetzt sehe ich, dass die Community wohl nicht viel weiter ist. Da wird sich gegenseitig unterstellt, man wäre ein Schmarotzer, es wird mit Sarkasmus und Belehrungen operiert.

Jede weitere Stunde ist verlorene Zeit. Ich bereue es nicht, zu Home Assistant gewechselt zu sein. Schaut euch mal an, welcher Ton dort im User-Forum herrscht. Nur so als freundliche Anregung.

Macht's gut mit FHEM

Komisch .. wie häufig ich schon bei diversen Projekten von "Umsteigern" solche Werbung gehört habe ....

warum bist Du dann auch wieder da?

(Sorry musste mal raus ... da schöne ist ja, das es verschiedene Arten gibt ein Problem zu lösen. Jedem das seine)

Zitat von: Wernieman am 09 Februar 2026, 17:56:57Komisch .. wie häufig ich schon bei diversen Projekten von "Umsteigern" solche Werbung gehört habe ....

warum bist Du dann auch wieder da?

(Sorry musste mal raus ... da schöne ist ja, das es verschiedene Arten gibt ein Problem zu lösen. Jedem das seine)

Sorry, und keine Sorge. Ich werde auch garantiert nicht wiederkommen.

Ein erster Schritt ist getan, ich habe einen IKEA Matter/ Thread Türkontakt mit einem Amazon Echo G4 verbunden.
Nur, wie bekomme ich den Echo als Border Router an FHEM?
Ich forsche weiter :-)

Ich habe heute mal versuchsweise einen Bilresa-Batterie-Dimmer (den mit dem physischen Drehrad) mitgenommen. Auf Schachtel und in der Doku ist ausschließlich von Matter die Rede. Wenn man den Pairing Button 10 Sekunden drückt, blinken zwar die drei LEDs, das aber dauerhaft, und in z2m wird nichts erkannt.
Habe dann im Internet (nein, nicht bei Harry Potter) gefunden, wie es geht: Pairing Button 10 s drücken. Dann 4 x schnell drücken. Dann 8 x schnell drücken (wird jeweils auch durch Änderung der LEDs angezeigt). Und - es funktioniert!
Mein z2m sagt zwar noch ,,unbekanntes Gerät", legt es aber an, und das Drehen des Rads sowie das Drücken werden auch als Events erkannt: brightness_move_to_level ## bzw. Toggle zwischen on/off.
Find ich prima, für schlappe 5 Euro so eine imo ergonomische Dimmer-Fernbedienung in fhem einbinden zu können, ohne irgendwelche Matter Hubs dazwischen schalten zu müssen.
Edit: Finde es auch gerade auf https://www.zigbee2mqtt.io/devices/E2490.html - muss wohl mal wieder updaten ;-)

Das hat dann doch aber nichts mit Matter zu tun, oder?

Dadurch

Zitat von: dadoc am 17 Februar 2026, 19:35:39Pairing Button 10 s drücken. Dann 4 x schnell drücken. Dann 8 x schnell drücken (wird jeweils auch durch Änderung der LEDs angezeigt).

wird doch letztlich vermutlich nur Zigbee aktiviert? (Was dann ja auch erst die Einbindung in Z2M erlaubt.)

Vielleicht verstehe ich aber auch etwas falsch.

Da hast Du prinzipiell recht. Außer man würde das Thread-Thema mental ergänzen zu ,,Matter[-Geräte] in fhem". Ich fand es halt nur merkwürdig, dass Ikea die fortgeführte Zigbee-Kompatibilität seiner Matter-Geräte derart geheim hält.
 Aber die Doppelstrategie ist für mich ja ganz ok. Aktuell fast perfekt über Zigbee/z2m in fhem einbinden (fast, da wohl nicht alle Funktionen auch im Zigbee-Modus gegeben sind, bei besagter Fernbedienung etwa fehlt der Event für das Drücken der ,,großen" Taste, die bei Matter vermutlich zwischen den drei kontrollierbaren Lampen umschaltet). Und wenn Matter dann irgendwann mal salonfähig geworden sein sollte, kann man einfach switchen, ohne alles neu kaufen zu müssen.

Hallo zusammen,
nach vielen Jahren mit FHEM stehe ich nun zum ersten Mal vor einer Herausforderung, für die ich (noch) keine direkte Lösung innerhalb meines Lieblingssystems gefunden habe.

Mit Blick auf die kommenden Entwicklungen – besonders im Bereich Energiemanagement und bei Hausgeräten – habe ich beschlossen, frühzeitig mit Matter zu starten. Um dies umzusetzen, habe ich mir parallel zu FHEM eine Home-Assistant-Instanz installiert. Über MQTT repliziere ich die Daten der neuen Geräte zurück in mein FHEM-System, was dank KI-Unterstützung glücklicherweise recht zügig machbar war.

Bisher habe ich meine Hardware immer strikt nach ihrer FHEM-Unterstützung ausgesucht. Angesichts der rasanten Entwicklung rund um Matter würde ich mich natürlich riesig freuen, perspektivisch eine native Integration oder ein Plugin in FHEM zu sehen. Die große Stärke von FHEM war für mich schon immer die enorme Vielfalt an Schnittstellen – seit ich damals meinen ersten Somfy-Rollladen eingebunden habe.

Meine Hausautomation ist mittlerweile zu einer stattlichen Landschaft angewachsen (EVCC, InfluxDB, SMA, Ellie, Max!, DuoFern etc.) und nun eben um Home Assistant und die erste Matter-Steckdose reicher. Es ist zu sehen, wie proprietäre Interfaces langsam verschwinden – mein alter FHEMduino liegt bereits als Andenken in der Bauteilkiste, und auch für 433MHz-Komponenten ist die Zeit bei mir abgelaufen.

Ich bin zwar selbst kein Entwickler – meine Stärke liegt eher im Konfigurieren und Systemdesign –, aber ich möchte an dieser Stelle einfach mal Danke sagen. Danke an diese großartige Gemeinschaft für eure unermüdliche Arbeit an FHEM, die mein Zuhause über Jahre so zuverlässig gesteuert hat.

Beste Grüße,
Stefan

Die Integration von Home Assistant (HA) in FHEM über MQTT Statestream ermöglicht es, Zustandsänderungen von HA-Entitäten automatisch als MQTT-Nachrichten zu veröffentlichen, die FHEM dann abgreifen kann.

1. Vorbereitung in Home Assistant
Zuerst muss die MQTT-Integration in HA aktiv sein und eine Verbindung zu einem MQTT-Broker (z. B. dem Mosquitto-Add-on) bestehen. Danach fügen Sie den Statestream in Ihre configuration.yaml ein:

# configuration.yaml
mqtt_statestream:
  base_topic: homeassistant
  publish_attributes: true
  publish_timesteps: true
  include:
    domains:
      - light
      - switch
      - sensor
2. Einrichtung in FHEM
defmod MQTT2_FHEM_Client MQTT2_CLIENT 192.168.178.150:1883
attr MQTT2_FHEM_Client autocreate complex
attr MQTT2_FHEM_Client group MQTT_CLIENT
attr MQTT2_FHEM_Client room MQTT2_DEVICE
attr MQTT2_FHEM_Client username mqtt-user
attr MQTT2_FHEM_Client verbose 1
In FHEM müssen Sie die einlaufenden Daten über ein MQTT2_DEVICE oder die MQTT_GENERIC_BRIDGE verarbeiten.
Schritt 1: MQTT-Verbindung prüfen
Stellen Sie sicher, dass FHEM mit demselben Broker wie HA verbunden ist (über MQTT2_CLIENT oder MQTT).
Schritt 2: Device anlegen
Sie können ein MQTT2_DEVICE manuell definieren oder autocreate nutzen, um die von HA gesendeten Topics (z. B. homeassistant/light/wohnzimmer/state) aufzufangen.
"Ich habe das autocreate nicht hinbekommen" Daher verbose des MQTT2_CLIENT auf 5 und die topics aus der fhemxxx*.log kopieren:

2026.04.10 07:31:28 5: MQTT2_FHEM_Client: received PUBLISH (0):homeassistant/sensor/spuelmaschine_verbrauch/friendly_name"Spuelmaschine Verbrauch"
2026.04.10 07:31:28 5: MQTT2_FHEM_Client: dispatch autocreate=complex\000MQTT2_FHEM_Client\000homeassistant/sensor/spuelmaschine_verbrauch/friendly_name\000"Spuelmaschine Verbrauch"
defmod MQTT2_Spuelmaschine MQTT2_DEVICE
attr MQTT2_Spuelmaschine IODev MQTT2_FHEM_Client
attr MQTT2_Spuelmaschine alias Spülmaschine
attr MQTT2_Spuelmaschine devStateIcon on:on:off off:off:on
attr MQTT2_Spuelmaschine group 2 HA Devices
attr MQTT2_Spuelmaschine icon scene_dishwasher
attr MQTT2_Spuelmaschine readingList homeassistant/switch/matter_over_wifi_smart_switch_2/state:.* state\
homeassistant/sensor/matter_over_wifi_smart_switch_leistung_2/state:.* leistung\
homeassistant/sensor/matter_over_wifi_smart_switch_spannung_2/state:.* spannung\
homeassistant/sensor/matter_over_wifi_smart_switch_wirkstrom_2/state:.* wirkstrom\
homeassistant/sensor/matter_over_wifi_smart_switch_eingespeiste_energie_2/state:.* energie_gesamt\
homeassistant/sensor/spuelmaschine_verbrauch/state:.* verbrauch
attr MQTT2_Spuelmaschine room MQTT2_DEVICE
attr MQTT2_Spuelmaschine stateFormat { sprintf("Status: %s | Leistung: %.1f W | Spannung: %.1f V", ReadingsVal($name,"state","?"), ReadingsVal($name,"leistung",0), ReadingsVal($name,"spannung",0)) }
Ein Learning hieraus ist, dass ich 2 HA Devices zu einem im FHEM kombinieren kann.
Ich habe mich bis jetzt aufs "mitlesen" konzentriert und noch keine Steuerung gemacht. Hier geht es mir um die Großverbraucher ins SolarFC zu integrieren.

Lohnt sich der Aufwand?

• Für das Spielkind in mir JA! :))
• Ich habe keine "vernünftige" MQTT PM Steckdose gefunden
• Daher meine Wahl SONOFF S61s Smart Steckdosen 16A/3840W

Fazit

• FHEM ist bei mir die graue Eminenz, die meine Homeautomation zusammen hält
• Home Assistant ist ganz nett, bleibt aber im Moment in der Matter Lücke

Gruß
Stefan

Sehr gut!

Das mit mqtt_statestream nutze ich auch so ähnlich für einzelne, über HA eingebundene Geräte.
Hatte das in dem anderen Thread zur Kopplung von FHEM und HA mal beschrieben:
https://forum.fhem.de/index.php?topic=115279.msg1319243#msg1319243

Zitat von: stefanne am 10 April 2026, 08:35:31Ich habe mich bis jetzt aufs "mitlesen" konzentriert und noch keine Steuerung gemacht.

In dem Post schreibe ich weiter unten auch über die Steuerung von HA-Geräten aus FHEM heraus mit MQTT.

Aktuell nutze ich da eine Automation pro Gerät (sind auch nur drei Geräte). Aber wenn man sich beim Programmieren der Automation schlau anstellt, kann man das bestimmt auch generisch machen. Dann hätte man idealerweise in HA nur eine Automation, mit der man sämtliche Geräte steuern kann (ggfs. gruppiert nach Gerätetypen). Am einfachsten ist es vermutlich, wenn man da mit JSON-Objekten arbeitet, z.B. so wie Zigbee2MQTT.

Danke für deinen Link  :)

Ich habe im Moment 2 Szenarien die Matter Steckdose für Großverbraucher und
die Sicherheitstechnik ( Eufy, Ring und LD2410 Bewegungsmelder). Hier fand ich die Einbindung in HA leichter. Der LD2410C wird auch über Bluetooth erkannt, nett aber in der Reichweite limitiert.
Mit Eufy habe ich die Sicherheitstechnik aus der Cloud raus.
Den LD2410 den ich mit ESPHome in HA programmiert. Diese Lösung ist ESPEasy überlegen, da die Kommunikation deutlich performanter ist als MQTT.
FHEM bekommt dann die Bewegung auf der Terasse  weiter gemeldet, um das Licht zu schalten und zu verhindern, dass der Rolladen runtergeht wenn wir noch draußen sitzen.

    entities:
      - switch.matter_over_wifi_smart_switch
      - sensor.prasenz_2aee08_entfernung_bewegung
      - binary_sensor.prasenz_2aee08_prasenz_erkannt
      - sensor.waschmaschine_verbrauch
      - sensor.kuehlschrank_verbrauch
      - sensor.spuelmaschine_verbrauch
      - sensor.trockner_trockner_verbrauch


Hallo zusammen,

spannendes Thema, ich wollte auch irgendwann mal mit Matter beginnen. Einfach nur um zu sehen, wie das geht. Da fhem bei mir Master ist und bleibt suchte ich auch nach einer Möglichkeit, eine Matter-welt mit fhem zu verbinden. Da ich weder Apple noch Alexa oder sonst was "cloudiges" nutze, scheint der Weg über homeassistant aktuell eine prima Lösung zu sein. Und wenn ich es recht überlege ist das ja auch nicht wirklich etwas anderes als z.B. Debmatic laufen zu lassen, um HomematicIP nutzen zu können.
Hier wurde ja schon viel berichtet wie das geht (danke dafür!), hier eine Kurzfassung von meinem Setup:
- homeassistanOS als VM unter Proxmox installieren (die Versionen von homeassistant, die in einem LXC laufen (core oder so) reichen nicht, da man dort die nötigen Zusätze nicht installieren kann)
- ein Sonoff Dongle-E per Webflasher zur Nutzung mit Thread geflashed und direkt in die VM durchgereicht (Es gibt auch Multiprotokoll für zigbee und thread, das wird aber im Moment wohl nicht empfohlen)
- homeassistant eingerichtet:
  - openthread boarder router: dieser erkennt dann den Sonoff-dongle
  - Companion-App auf dem Handy eingerichtet (um später Mattergeräte anlernen zu können, da dafür bluetooth verwendet wird)
  - Matter eingerichtet: erkennt das Thread-netzwerk

zusätzlich die Apps (hieß wohl mal Addon) MQTT und MQTT Statestream installiert und wie in diesem Thread schon beschrieben in der configuration.yaml eingerichtet.

Dann kam der erste Versuch: Ein IKEA Alpstuga Luftqualitätssensor angelernt (übers Handy mit QR-Code) und schon war er in Homeassistant und hat Daten geliefert.

Die Verbindung zu fhem mittels mqtt:
Der sensor liefert seine Daten alle über eigene Topics. Nun kommt es darauf an, was man in fhem haben möchte, entsprechend kann man den MQTT Statestream in der configuration.yaml einrichten. Wenn man nur mit include arbeitet, wird auch nur das gesendet, was hier eingetragen ist. Das ist mein Weg, den ich gewählt habe, da homeassistant aus meinem Netzwerk alle möglichen Fritzgeräte, shellys usw. gefunden hat und ich das alles nicht auch (dann gedoppelt) in fhem sehen möchte.
Die Topics sehen so aus:
- sensor.alpstuga_air_quality_monitor_air_quality
- sensor.alpstuga_air_quality_monitor_carbon_dioxide
- sensor.alpstuga_air_quality_monitor_pm2_5
- switch.alpstuga_air_quality_monitorman kann nun eine "domain" includen, das sind "sensor" oder "switch",
man kann entities includen, das wäre z.B. switch.alpstuga_air_quality_monitor (also der komplette Topic) oder
man kann entity_globs includen, das ist wohl so ein wenig Regex oder Wildcard, in meinem Fall habe ich sensor.alpstuga_air_quality_monitor_*
genommen, um die 3 ersten topics zu senden.
Im MQTT-Exporer sieht man dann schön die Daten kommen. Der Switch sendet über den Statestream seinen Zustand, genutzt kann er werden um das Display ein und auszuschalten.

Nun zu fhem: ich habe autocreate nicht verwendet sondern das MQTT2_Device selbst angelegt.
defmod air_quality_AZ MQTT2_DEVICE
attr air_quality_AZ comment Beachten: alle "Sensoren" senden "unavailable" wenn z.B. der Sensor ausgesteckt ist
attr air_quality_AZ devicetopic homeassistant/(sensor|switch)/alpstuga_air_quality
attr air_quality_AZ event-min-interval availability:1800
attr air_quality_AZ event-on-change-reading .*
attr air_quality_AZ group homeassistant
attr air_quality_AZ readingList $DEVICETOPIC_monitor_carbon_dioxide/state:.* co2\
$DEVICETOPIC_monitor_pm2_5/state:.* pm25\
$DEVICETOPIC_monitor_air_quality/state:.* air_quality\
$DEVICETOPIC_monitor/state:.* display
attr air_quality_AZ room MQTT2_DEVICE
attr air_quality_AZ setList on:noArg homeassistant/switch/alpstuga_air_quality_monitor/set on\
off:noArg homeassistant/switch/alpstuga_air_quality_monitor/set off
Im devicetopic habe ich den gemeinsamen Anfang der Topics und zwar für sensor und switch, in der ReadingList dann die jeweiligen enden dazu. Die Werte werden im Topic /state geliefert, da der Anfang des Topics aber unterschiedlich ist klappt das so.

Setlist schickt dann on oder off an homeassistant zurück, was dort per Automation ausgewertet wird (auch hier im Thread schon beschrieben)
die sieht folgendermaßen aus:
  alias: MQTT Global Switch Handler
  description: Empfängt Befehle von FHEM und schaltet die HA-Entitäten
  triggers:
  - topic: homeassistant/switch/+/set
    trigger: mqtt
  actions:
  - target:
      entity_id: switch.{{ trigger.topic.split('/')[2] }}
    action: switch.turn_{{ trigger.payload }}
  mode: parallel
  max: 10da hat mir eine befreundete KI geholfen um das generisch zu bekommen. Damit werden ALLE Kommandos von fhem die homeassistant/switch/irgendwas/set beinhalten an die entsprechenden Geräte mit der Payload weitergereicht. Das läßt sich bestimmt noch erweitern, habe aber bisher keine weiteren matter-Geräte, die ich dann auch noch von fhem aus bedienen können wollte.

Ich denke mal, das ist ein gangbarer Weg, um die Matter-welt an fhem zu koppeln. Mit Proxmox war das wirklich in kurzer Zeit erledigt.

Gruß

Sany

So oder so ähnlich hab ichs auch gemacht, mit Hilfe von Gemini für die HA Automationen, und dann mqtt explorer für die MQTT Topics ist das gut machbar.

HA ist relativ groß. Alternativ habe ich dies hier gefunden:
https://matterbridge.io/
Zusammen mit dem MQTT-Plugin liest sich das nach einer leichtgewichtigen Alternative.
Ich habe es - mangels Notwendigkeit - aber noch nicht selbst getestet.

Zitat von: m_schmid@posteo.de am 11 Juni 2026, 17:40:19HA ist relativ groß. Alternativ habe ich dies hier gefunden:
https://matterbridge.io/
Zusammen mit dem MQTT-Plugin liest sich das nach einer leichtgewichtigen Alternative.
Ich habe es - mangels Notwendigkeit - aber noch nicht selbst getestet.

fehlt aber doch noch etwas, was z.B. Thread-Geräte verbindet, der Thread-Border-Router. Das ist in meinem Fall eben HA mit einem Sonoff-dongle. Das für den Matter over thread part. Matter over Wifi kann HA dann natürlich auch. Und nur das, was man in fhem dann haben möchte, wird per MQTT an fhem angebunden. Ich sehe eigentlich keinen Unterschied im Aufwand wie z.B. HomematicIP an fhem anzubinden. Habe dazu einen Raspi mit Funkmodul und Debmatic. Und dann halt noch die HMCCU-Geschichte. Bei HA in einer VM auf dem Proxmox-Server ist das alles (bis auf den Sonoff-Dongle) in Software gemacht.
Vielleicht verstehe ich auch matterbridge nicht.


Aktuell ist das eh nur eine Spielwiese. Ich sehe aber z.B. bei IKEA den move von zigbee nach matter, und bisher gab es schon interessante Komponenten für eher kleines Geld. Wobei die Matter-Teile auch recht günstig sind. Jetzt müssen sie nur noch zeigen, dass sie auch so zuverlässing sind.


2ct by SANY

Zitat von: Sany am 19 Juni 2026, 18:43:35Vielleicht verstehe ich auch matterbridge nicht.

Ohne dass ich es mir jetzt im Detail angeschaut habe: Matterbridge übernimmt dieselbe Funktion wie HA, nur dass es eben leichtgewichtiger ist und eben nur Matter macht. Einen Thread-Border-Router brauchst du in beiden Fällen, darum geht es hier ja nicht.

Bei mir ist HA der Thread Border Router, dann kann es den Rest auch gleich mitmachen (Matter, MQTT)

Mir hat die Lösung über Home Assistant nicht wirklich gut gefallen, da ich nicht nur wegen Matter Home Assistant bei mir laufen haben wollte. Ich habe mir dann ein eigenes FHEM Device geschrieben, welches mit dem matterjs-server kommuniziert, den auch Home Assistant verwendet. matterjs-server kann man sich auch Stand-Alone ohne Home Assistant installieren. Mit meinen Devices kann ich jetzt zumindest meine Lampen aus FHEM direkt ansteuern. Der Link zu meinem Projekt https://gitlab.com/zeppelin1979/fhem-matter (https://gitlab.com/zeppelin1979/fhem-matter).
Gerne könnt ihr es ebenso nutzen und auch Vorschläge für Verbesserungen machen. Es handelt sich um ein reines Hobbyprojekt und selbst programmiere ich nicht wirklich in perl. Bitte verzeiht deswegen eventuell umständliche Wege im Code.

Hi,

@Zeppelin: Wie hast du deine Matter Geräte mit dem Matterjs-server verbunden. Ich habe den js-server als Proxmox LXC installiert und komme auch auf dessen Weboberfläche. Und dein Fhem Modul connected sich auch zu ihm. Aber ich hab es bis jetzt noch nicht hinbekommen, mein Matter-Device mit dem Server zu verbinden. Alles was ich bis jetzt gefunden habe, war dann wieder über die Home Assistant App und die will dann wieder eine HA Instanz haben, die ich ja gar nicht brauche.

Danke Dir

PS: Dein Tool ist soweit schon mal klasse - ich will nämlich auch kein HA extra nur für Matter. Daumen hoch

Hi @whirly85,

ich habe Lampen von Govee, da kann ich diese mit der Govee-App ins Netz holen. In der App kann ich mir dann einen Matter-Code für jedes Device holen. Da ich zu diesem Zeitpunkt noch Home Assistant am laufen hatte, habe ich diesen Code in die HA-Oberfläche eingegeben. Ich habe auch ein set matterServer commissionCode 35325335079 eingebaut aber nicht getestet, da meine Geräte schon eingebunden waren.
Prinzipiell würde auch die Möglichkeit bestehen, die Einbindung im Netzwerk auch über den MatterJs-Server zu machen, dann muss dieser aber Kontakt zum Device per Bluetooth haben.
Ein Doku findest du unter: Matter-js API Docu (https://github.com/matter-js/matterjs-server/blob/main/docs/websockets_api.md). Ich werde mal versuchen einen Bluetooth Stick in meinen Server zu stecken und mal das commissioning direkt zu machen. Eine App wie Home Assistant werde ich aber wahrscheinlich nicht angehen.
Als kurzfristigen Workaround kann man auch Home Assistant kurz starten und dort das Device ins Netzwerk holen. Danach kann man ihn ja wieder beenden.

Hi,

vielen Dank. Ich habe mein Device mit der SmartLife-App dort eingebunden und konnte dort dann den Code erzeugen. Hat dann jetzt sauber geklappt und ich kann das Device über FHEM steuern. Ich dachte, der Code, der auf dem Gerät selbst ist, ist der commission Code. Da war ich etwa auf dem Holzweg.

Saubere Arbeit - danke dir

Zitat von: Flachzange am 19 Juni 2026, 19:51:23

Zitat von: Sany am 19 Juni 2026, 18:43:35Vielleicht verstehe ich auch matterbridge nicht.

Ohne dass ich es mir jetzt im Detail angeschaut habe: Matterbridge übernimmt dieselbe Funktion wie HA, nur dass es eben leichtgewichtiger ist und eben nur Matter macht. Einen Thread-Border-Router brauchst du in beiden Fällen, darum geht es hier ja nicht.

Ich hab mir mal die Matterbridge angeschaut und die ist nicht in die Richtung gedacht - mit ihr kannst du z.B. Shellys oder MQTT Devices in die Matter-Welt bringen. Dort kannst du keine Matter Geräte einbinden. Es erzeugt nur einen Code von sich und lässt keine Eingabe von Commission Codes oder QR-Code zu. Aber da haben wir ja jetzt was dank Zeppelin  :)

Schön zu sehen, dass hier Bewegung drin ist — Zeppelins Modul (https://gitlab.com/zeppelin1979/fhem-matter) zusammen mit dem matterjs-server ist ein direkter Weg zu Matter in FHEM ohne Home Assistant, und whirly85 hat damit ja gerade erfolgreich ein Gerät eingebunden. Ich habe das Modul heute selbst gegen denselben matterjs-server laufen lassen: es verbindet sich auf Anhieb, legt pro Knoten und Endpunkt Geräte an und schaltet meine Testlampe zuverlässig (on, off, pct).

Zwei Dinge fehlen daneben trotzdem, und um die geht es mir hier. Erstens der Thread Border Router — weiter oben im Thread wurde schon festgehalten, dass der separat nötig bleibt, sobald Geräte Matter über Thread sprechen; die IKEA-Geräte, die ich hier verwendet habe, tun das. Zweitens Bluetooth: ein fabrikneues Thread-Gerät ist noch in keinem Netz, das erste Gespräch beim Anlernen läuft über Bluetooth LE. Zeppelins README nennt Commissioning via Bluetooth selbst als offenen Punkt, das Modul lernt derzeit übers Netz an (network_only) — was ausdrücklich keine Lücke des Moduls ist: der Bluetooth-Teil des Anlernens ist Sache des Matter-Servers, nicht des FHEM-Moduls.

Beides kommt bei dem, was ich gebaut habe, aus einem Guss: ein Stick, ein Container. Der Border Router läuft vollständig in der Firmware eines ESP32-C6; die Verbindung zum Rechner ist der USB-Port des Chips, host-seitig macht ein Docker-Container daraus ein Netzwerk-Interface, über das der Rechner die Thread-Geräte per IPv6 erreicht. Auf dem Rechner läuft kein otbr-agent, kein wpantund und kein RCP/Co-Prozessor. Und derselbe Stick leiht dem Matter-Server sein Bluetooth-Funkteil: der Server steuert Scan, Verbindung und Anlernvorgang, der Stick trägt sie über die Luft. Ein Server, NUC oder eine VM ohne eigenes Bluetooth kann damit ein fabrikneues Gerät direkt mit dem Code vom Karton anlernen — angestoßen auf der Web-Seite des Matter-Servers oder über dessen API. Meine Testlampe oben wurde über das Bluetooth des Sticks angelernt — bei mir über die API des Servers — und geschaltet habe ich sie danach mit Zeppelins Modul.

Voraussetzung ist ghcr.io/matter-js/matterjs-server mit der Option --ble-proxy; der python-matter-server (ghcr.io/home-assistant-libs/python-matter-server) meldet in seiner Begrüßung keine Proxy-Unterstützung und kann das nicht. Gemessen: nachdem der Stick eine größere ATT-MTU aushandelt (247 statt der anfänglichen 23), läuft ein Anlernvorgang in 22 Sekunden durch, der vorher im BTP-Handschlag stehenblieb.

Der ganze Weg bis dorthin ist als Anleitung aufgeschrieben: https://github.com/tostmann/THBR/blob/main/fhem/README.md — Stick in Betrieb nehmen, Matter-Server aufsetzen, dem Server einmalig die Thread-Zugangsdaten des Border Routers geben, anlernen; am Ende übergibt sie an Zeppelins Modul. Die Zugangsdaten sind eine Stolperstelle, die die Anleitung eigens behandelt: ohne sie läuft ein Anlernvorgang komplett durch Zertifikate und Fabric und scheitert erst ganz am Ende.

Zur Hardware: ein ESP32-C6 mit 4 MB Flash am nativen USB-Port. Ein ESP32-C5 läuft auch, mit halb so viel Speicherreserve — und bei den hier getesteten C5 setzte der native USB-Port gelegentlich aus, bis der Chip zurückgesetzt wurde. Der ESP32-H2 kann es nicht; Espressif liefert für ihn keine Border-Router-Bibliothek. Es gibt das Ganze als Home-Assistant-Add-on und als normales Docker-Image (docker pull tostmann/thbr); der Docker-Weg hat mit HA nichts zu tun. Projekt: https://github.com/tostmann/THBR — Lizenz PolyForm Noncommercial 1.0.0, privat und nichtkommerziell frei.

Mich würde interessieren: welche Matter-Geräte stehen bei euch an — Thread-basierte wie die IKEA-Geräte hier, oder WLAN-Geräte, die ohne Border Router auskommen? Und falls jemand schon einmal an einem fabrikneuen Thread-Gerät hängengeblieben ist: an welcher Stelle?

Cheers!

Das sind wirklich schön Entwicklungen hier. Vielen Dank @Zeppelin und @tostman.

@tostmann: Ich habe mir dein Projekt angeschaut. Einen ESP als OTBR finde ich gelungen. Jetzt ist es bei mir so, dass der Docker-Host bei mir im Keller im Serverschrank steht. Dort hilft mir der ESP nicht. Ich würde ihn gerne frei platzieren. Vor allem da platzieren, wo auch die Thread-Geräte laufen.

Du erwähnst im Quellcode ein ,,sibling project TBR" mit ESP32-C6 und W5500-Backbone. Ist das ein eigenes beziehungsweise öffentlich verfügbares Projekt, oder beziehst du dich dabei auf ein externes Projekt? Ich habe einen ESP32-C6-Bug mit Ethernet und PoE und würde den dann gerne einfach OTBR nutzen. Wenn es da schon etwas gibt, bräuchte ich nicht vorne anfangen.


Und zur Frage:

Für mich wird Matter inkl. Thread mit jedem Tag interessanter. Es scheint sich herauszukristallisieren, dass durch die Unterstützung der drei großen (Goole, Amazon, Apple) etwas geschaffen wurde, was die Kunden annehmen und daher mehr und mehr Produkte erscheinen. Allen voran Ikea, die natürlich mit ihrer Reichweite und Preisgestaltung zur Attraktivität beitragen können. Es ist ja schon verrückt, dass ein Matter-Leuchtmittel nur wenig mehr als ein Standard-Leuchtmittel kostet. Und ich finde es beispielsweise super spannend RGBW-LEDs dezentral anzusteuern. Mein erstes Matter-Gerät ist aber ein (teurer) WiFi-Aktor von Eltako, den ich mir aus Interesse zugelegt hatte (bei mir ist das meiste derzeit Eltako EnOcean).

Technisch finde ich Matter/Thread ebenfalls sehr spannend. Einzig das Commissioning mit QR Codes, Bluetooth und Co macht es für mich unnötig unkompliziert und ist ein Medienbruch.

@Flachzange: TBR ist kein öffentliches und kein fremdes Projekt — eigener Code für eigene Hardware (C6 + W5500 als Backbone), Stand "baut, aber nie auf Hardware getestet". THBR hat davon nur den Control-Flow geerbt. Zum Nachnutzen ist da nichts.

Dein Weg steht im ESP-IDF: examples/openthread/ot_br mit CONFIG_EXAMPLE_CONNECT_ETHERNET, das README führt den "Ethernet based Thread Border Router" als eigene Betriebsart. Anzupassen ist nur der Ethernet-Teil: der C6 hat keinen eingebauten Ethernet-MAC, Ethernet hängt dort immer über SPI dran (W5500 und Verwandte), der Treiber muss zu deinem Chip und Pinning passen.

Espressifs Abraten vom Border Router auf einem einzelnen C6 hat genau einen Grund: ein RF-Pfad, WiFi und 802.15.4 können nicht gleichzeitig empfangen. Bei kabelgebundenem Backbone entfällt der — bei dir Ethernet, bei THBR USB. Der 15.4-Funkteil gehört dann exklusiv Thread.

THBR bleibt beim USB-Weg: Ethernet-fähige C6-Hardware gibt es zur Genüge, du hast selbst ein Board mit PoE. Der Punkt des Projekts war die andere Frage — ob ein vollständiger Border Router auf einem nackten Fünf-Euro-ESP läuft, ohne Ethernet-IC und ohne Co-Prozessor. Einen Ethernet-Zweig wird es dort deshalb nicht geben.

Zum Keller: Thread ist ein Mesh, jedes netzbetriebene Thread-Gerät wird selbst Router und trägt weiter — es genügt, dass eines in Reichweite des Sticks steht. Und drei Meter USB-Verlängerung holen ihn aus jedem Schrank.

Zum Commissioning: der Code ist der Besitznachweis, das ist Matter und nicht FHEM. Der QR-Code ist nur eine Darstellungsform — dieselbe Zahl steht elfstellig auf Karton oder Gerät und wird in das Feld auf der Weboberfläche des Matter-Servers getippt, ohne Handy, Scanner oder Hersteller-App. Bluetooth braucht nur das allererste Gespräch mit einem fabrikneuen Thread-Gerät, und genau diesen Schritt nimmt der Stick einem Server ab, der kein eigenes Bluetooth hat. Lästig bleibt der Fall "schon woanders angelernt": dort gilt der Aufdruck-Code nicht mehr, der aktuelle Besitzer muss ein Commissioning-Fenster öffnen, das einen frischen erzeugt.

Dein Eltako-WLAN-Aktor braucht übrigens keinen Border Router — Matter over WiFi läuft ohne. Der wird erst für die IKEA-Fraktion gebraucht, die Thread spricht.

Zitat von: tostmann am 29 August 2026, 11:10:30@Flachzange: TBR ist kein öffentliches und kein fremdes Projekt — eigener Code für eigene Hardware (C6 + W5500 als Backbone), Stand "baut, aber nie auf Hardware getestet". THBR hat davon nur den Control-Flow geerbt. Zum Nachnutzen ist da nichts.

Dein Weg steht im ESP-IDF: examples/openthread/ot_br mit CONFIG_EXAMPLE_CONNECT_ETHERNET, das README führt den "Ethernet based Thread Border Router" als eigene Betriebsart. Anzupassen ist nur der Ethernet-Teil: der C6 hat keinen eingebauten Ethernet-MAC, Ethernet hängt dort immer über SPI dran (W5500 und Verwandte), der Treiber muss zu deinem Chip und Pinning passen.

Alles klar. Danke. Ich hatte mich halt gefragt, ob das nicht schon mal jemand irgendwo umgesetzt hat und die Kommentare deuteten draufhin. Ich nutze den gleichen ESP schon für ein anderes Projekt und habe dort die Ethernet-Unterstützung implementiert. Schaue mir das dann mal für den OTBR an.

Zitat von: tostmann am 29 August 2026, 11:10:30Espressifs Abraten vom Border Router auf einem einzelnen C6 hat genau einen Grund: ein RF-Pfad, WiFi und 802.15.4 können nicht gleichzeitig empfangen. Bei kabelgebundenem Backbone entfällt der — bei dir Ethernet, bei THBR USB. Der 15.4-Funkteil gehört dann exklusiv Thread.

ja, genau, deswegen ja auch mein Gedanke die Ethernet-Variante zu nutzen, um etwas flexibler zu sein

Zitat von: tostmann am 29 August 2026, 11:10:30THBR bleibt beim USB-Weg: Ethernet-fähige C6-Hardware gibt es zur Genüge, du hast selbst ein Board mit PoE. Der Punkt des Projekts war die andere Frage — ob ein vollständiger Border Router auf einem nackten Fünf-Euro-ESP läuft, ohne Ethernet-IC und ohne Co-Prozessor. Einen Ethernet-Zweig wird es dort deshalb nicht geben.

Alles okay, ich hatte ja auch nicht suggeriert, dass deine Lösung nicht ausreichend ist und verändert werden sollte. Im Gegenteil: Es ist vermutlich für viele genau das, was sie brauchen.

Zitat von: tostmann am 29 August 2026, 11:10:30Zum Keller: Thread ist ein Mesh, jedes netzbetriebene Thread-Gerät wird selbst Router und trägt weiter — es genügt, dass eines in Reichweite des Sticks steht. Und drei Meter USB-Verlängerung holen ihn aus jedem Schrank.

Klar, aber a) fange ich ja mit wenigen Geräten im Haus an einzelnen Stellen an und die Erfahrung bei mir sagt, dass das nicht gut funktioneren wird mit der Erreichbarkeit bis zum Keller. Mein aktuelles (kleines) Zwave-Netz läuft genauso: Stick am Server und dann Zwangsrouting über Funksteckdosen durchs Haus. Sub-Optimal. b) muss ich dann ja auch zum Commissioning in den Keller, sicher kein Showstopper, aber wenn es praktischer ginge...

Zitat von: tostmann am 29 August 2026, 11:10:30Zum Commissioning: der Code ist der Besitznachweis, das ist Matter und nicht FHEM. Der QR-Code ist nur eine Darstellungsform — dieselbe Zahl steht elfstellig auf Karton oder Gerät und wird in das Feld auf der Weboberfläche des Matter-Servers getippt, ohne Handy, Scanner oder Hersteller-App. Bluetooth braucht nur das allererste Gespräch mit einem fabrikneuen Thread-Gerät, und genau diesen Schritt nimmt der Stick einem Server ab, der kein eigenes Bluetooth hat. Lästig bleibt der Fall "schon woanders angelernt": dort gilt der Aufdruck-Code nicht mehr, der aktuelle Besitzer muss ein Commissioning-Fenster öffnen, das einen frischen erzeugt.

Mein Punkt war eher: Im Vergleich zu "ich drücke einen Learn Button am Gerät und das Gerät ist eingelernt", ist das bei Matter schon etwas anstrengender.

Zitat von: tostmann am 29 August 2026, 11:10:30Dein Eltako-WLAN-Aktor braucht übrigens keinen Border Router — Matter over WiFi läuft ohne. Der wird erst für die IKEA-Fraktion gebraucht, die Thread spricht.

Ja, ich hatte ihn auch schon testweise über Home Assistant in Betrieb.

@Flachzange: in den Keller musst du nicht, das Gerät aber schon — für den ersten Kontakt braucht es das Bluetooth des Sticks, alles andere läuft in der Weboberfläche des Matter-Servers. Praxis: fabrikneues Gerät neben den Stick, Code eintippen, anlernen, danach montieren. Über zwanzig Geräte gemessen: erfolgreich von -43 bis -80 dBm, gescheitert bei -95 dBm. Ein im Bluetooth-Teil gescheiterter Versuch kostet nichts, das Commissioning-Fenster bleibt offen; zurücksetzen muss nur, wer nach dem Thread-Beitritt scheitert.

Beim Mesh hast du recht: mit drei Geräten trägt das Argument nicht, vorher ist es ein Stern um den Stick und sein Standort entscheidet. Für deinen Aufbau ist Ethernet die richtige Antwort, nicht meine USB-Verlängerung.

Learn-Button: der Vergleich stimmt. Matter tauscht den Tastendruck gegen einen Code, weil ein Vertrauensverhältnis entsteht und nicht nur eine Funkbeziehung — bequemer wird es dadurch nicht.

Zur Info: seit heute ist Release 2026.8.41 mit Firmware 0.1.50 draußen. Behoben ist ein Fehler beim Wechsel des Thread-Netzes — der Border Router konnte danach auf seiner eigenen Adresse im Mesh verstummen, während jede Anzeige "läuft" sagte. Betrifft Erstinbetriebnahme, Stickwechsel und Migration; im stehenden Betrieb tritt es nicht auf. Add-on oder Container aktualisieren genügt, die Stick-Firmware wird bewusst nicht automatisch überschrieben — dafür der Knopf auf der Add-on-Seite.

Das ist ja alles sehr nett. Allerdings hat das unter "Anfängerfragen" nun wirklich nichts verloren.

Vorschlag: Neuer Forenbereich "Matter".

Außerdem sollten solche Beiträge wie der vom Tostmann ins Wiki, sonst sucht man sich später einen Wolf.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 29 August 2026, 18:46:04Vorschlag: Neuer Forenbereich "Matter".

Finde ich gut, bei wem müsste man das platzieren?

Ich habe einen neuen Forumsbereich erstellt, und dieses Thema dahin verschoben.

Danke Rudolf!

Und Dank Zeppelin und Tostmann habe ich jetzt auch meine ersten Matter-Devices (Thread +  Wifi) in FHEM und das komplett ohne HA. Vielen Dank für den Aufschlag. Den ESP habe ich aber wie schon geschrieben per Ethernet angebunden.

Ich kann jetzt neue Themen im neuen Subforum erstellen, aber nachvollziehbarer wäre es wohl, wenn die Erschaffer ihre Lösungen dort präsentieren würden.

Hallo zusammen
Ich bin gerade auf die Siegenia Fenstergriffe gestoßen, die ebenfalls matter-kompatibel sind. Mit einem Preis von 80-90 € eine gute Möglichkeit Fenster zu überwachen und, was viele andere Griffe nicht können, die Fenstergriffe können elektronisch verriegelt werden,

Ich werde jetzt ebenfalls in die Matterwelt einsteigen und meine Erkenntnisse und Erfahrungen gerne mit euch teilen.

Gruß Gerhard

Sind ja fast so "günstig", wie die EnOcean-Griffe von Hoppe  ;D

fhempy kann ab sofort auch Matter als auch MatterBridge  :)
Bugs bitte auf GitHub melden, nur so kann sie die KI schnell verarbeiten 😜

Willkommen zurück Dominik. Freue mich sehr von Dir zu hören.


Grüße
Marko

Hi, ich habe erfolgreich matter in mein FHEM integriert
Habe jetzt ein Problem, meine CC41 von der Firma Becker läuft noch im Beta-Modus, an der CC41 hängen meine Rolläden

Wenn ich versuche die CC41 mit meinem Matter in FHEM zu pairen kommt die Meldung:

failed: Commission failed: This device uses a test/development certificate. To commission it, enable the "Test DCL" option in the settings — only do this if you trust the vendor.. Check the code, put the device in pairing mode again and retry. IPv6 must be enabled in your network.

IPv6 ist aktiviert, aber wie bekomme ich in matter die option "Test DCL" enabled?

Danke für eure Hilfe und Grüße
Wolfgang

Du wirst irgendwie sagen müssen, mit welchen Modulen, du das in FHEM gemacht hast. Dieser Thread eignet sich dafür eher nicht.

Sorry, stimmt, da fehlen Infos

Matter ist über fhempy Version 2.10.1 reingekommen
Matter selber läuft in der Version 1.5.5

Das Ganze läuft auf einen Raspi5 unter Debian GNU/Linux 12

Gruß
Wolfgang

Zitat von: dominik am 16 Oktober 2026, 14:47:27fhempy kann ab sofort auch Matter als auch MatterBridge  :)
Bugs bitte auf GitHub melden, nur so kann sie die KI schnell verarbeiten 😜

Great, thanks for your work, It is really easy to install it.
I tried to find every information  about it (in english and german) but missing information.
It is not clear for me if Thread is supported. And how.
- I guess I just have to connect a Thread-Border-Router en fhempy will find it?
- Is it possible to use a ConbeeII flashed for Thread?
- Any preferred Thread-Border-Routers?


Mfg
Harry

Hi Harry,

thanks! Yes, Thread devices are supported, but fhempy doesn't talk Thread itself. The Matter server in fhempy reaches Thread devices over IPv6 through a Thread border router in your network, the same way Home Assistant does.

1. Just connect a border router and fhempy finds it? Almost. fhempy doesn't need to "find" the border router, there is nothing to configure in fhempy. The border router routes between your LAN and the Thread network, so a Thread device simply shows up as a normal IPv6 device. What you need:

IPv6 enabled in your router and on the FHEM machine.
The FHEM machine has to accept the route the border router announces. On a Raspberry Pi/Debian this is usually fine, if pairing a Thread device times out, run sudo sysctl -w net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=64 (use wlan0 instead of eth0 if you're on WiFi; to make it permanent, put it into /etc/sysctl.d/).
Pairing:

Easiest way: add the Thread device to Apple Home/Google Home/Alexa first (that also puts it into the Thread network of your border router), then choose "Turn on pairing mode"/"Linked Matter apps" in that app and use the new code with set matter pair <code>. The device keeps working in both.
Brand-new device directly from FHEM: attribute bluetooth_adapter 0, then set matter thread_dataset <active dataset hex> (from your border router's settings) and set matter pair_new_device <code>. Note that Apple and Google don't show you their dataset easily, so with those border routers the first way is much simpler.
2. ConBee II flashed for Thread? Not directly. fhempy doesn't include an OpenThread Border Router, so a USB stick alone isn't enough, you'd need to run an OTBR (e.g. the OpenThread Border Router docker image) yourself. Also I'm not aware of a working OpenThread RCP firmware for the ConBee II. If you want your own border router, a stick that is known to work with OTBR is the better choice (e.g. Home Assistant Connect ZBT-1/SkyConnect, Sonoff ZBDongle-E or a Nordic nRF52840 dongle).

3. Preferred border router? Any Matter-capable one works, fhempy doesn't care which. If you already have an Apple TV 4K/HomePod mini, a Google Nest Hub (2nd gen)/Nest Wifi Pro or an Echo 4th gen, just use that, it's the easiest setup. If you don't want a cloud ecosystem, OTBR with one of the sticks above works too, but needs more setup.

Feedback is very welcome, Thread hasn't been tested much yet!

Zitat von: wolfganghabenicht am 26 Oktober 2026, 14:17:03Sorry, stimmt, da fehlen Infos

Matter ist über fhempy Version 2.10.1 reingekommen
Matter selber läuft in der Version 1.5.5

Das Ganze läuft auf einen Raspi5 unter Debian GNU/Linux 12

Gruß
Wolfgang

Hallo Wolfgang,

danke für die Meldung! Bisher konnte man "Test DCL" im fhempy matter Modul leider nicht einschalten. Das kommt mit dem nächsten fhempy Update: Es gibt dann ein neues Attribut test_dcl am Matter Controller.

So geht's nach dem Update:

fhempy aktualisieren (set fhempy_local update) und warten, bis es neu gestartet ist.
Am Matter Controller das Attribut setzen: attr <dein_matter_device> test_dcl 1 Der Matter Server startet dadurch automatisch neu.
Die CC41 wieder in den Pairing-Modus bringen und erneut pairen.
Hinweis: Mit test_dcl 1 akzeptiert der Matter Server Geräte mit Test-/Entwicklungszertifikaten, wie sie Beta-Firmware oft hat. Das sollte man nur einschalten, wenn man dem Hersteller vertraut. Wenn die CC41 später eine finale Firmware bekommt, kannst du das Attribut wieder auf 0 setzen. Bereits gepairte Geräte bleiben dabei gepairt.

Gib gern Bescheid, ob es geklappt hat!

Moin

super, vielen Dank, hat prima geklappt

Viele Grüße
Wolfgang

Hallo zusammen,
ich habe gerade mal auf meinem Testsystem FHEMPY installiert...
Beim Start des Matter Server meckert dieser die Version von nodejs an.
Diese soll laut Matter Server mind. eine V22 sein.
Trixie (auf einem Raspberry 2B, leider nur 32 bit fähig) bringt nur v20.19.2  mit.
Die Installation empfiehlt folgendes:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo bash - && sudo apt install nodejs 
Was aber zu folgender Fehlermeldung führt:

2026-10-28 08:59:08 - Error: Unsupported architecture: armhf. Only amd64, arm64 are supported. Contact Nodesource for an extended support version https://nodesource.com/pages/contact-us.html. (Exit Code: 1)

Sieht für mich so aus, als ob der Matter Server von FHEMPY nicht (mehr) auf einem Raspberry Model 2b lauffähig ist, trotz aktueller Linux Distro.

Mit diesen Befehlen ist es mir gelungen, zumidest Nodejs V22.15 zu installieren:

sudo apt update && sudo apt install -y curl tar apt-transport-https ca-certificates gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://nodesource.com | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_22.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list
sudo apt install -y nodejs
Vermutlich bringt das nichts auf Dauer, da neue Versionen des Matter Servers auch neuere Nodejs Versionen erfordern, oder ?

Ich möchte keinen neuen Raspberry kaufen, da der "alte" für mich völlig ausreichend ist .

Gibt es andere Möglichkeiten ein neueres Nodejs zu installieren ?

Gruß Klaus

Antwort von Claude :)
Hallo Klaus,

danke für die ausführliche Beschreibung! Du hast recht: NodeSource baut seit einiger Zeit nur noch für amd64 und arm64, für 32-bit (armhf) gibt es dort nichts mehr. Der Hinweis in fhempy ist für den Pi 2B daher leider falsch, das passe ich an.

Zu deinem zweiten Weg: Der Schlüssel wurde von https://nodesource.com geladen, das ist aber die Webseite und kein GPG-Key (richtig wäre https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key). Außerdem hat die Repo für armhf keine Pakete. Schau bitte mal, woher dein Node 22.15 wirklich kommt:

which -a node
node -v
apt policy nodejs
Wenn apt update jetzt wegen der NodeSource-Quelle meckert, kannst du sie einfach wieder entfernen:

sudo rm /etc/apt/sources.list.d/nodesource.list /etc/apt/keyrings/nodesource.gpg
sudo apt update
Mein Vorschlag: offizielles Node 22 von nodejs.org. Für Node 22 gibt es auf nodejs.org weiterhin offizielle Binaries für armv7l (also auch den Pi 2B). Installation nach /usr/local, damit es auch der fhem-User findet:

cd /tmp
FILE=$(curl -fsSL https://nodejs.org/dist/latest-v22.x/ | grep -o 'node-v22[0-9.]*-linux-armv7l.tar.xz' | head -1)
curl -fsSLO https://nodejs.org/dist/latest-v22.x/$FILE
sudo tar -xJf $FILE -C /usr/local --strip-components=1 --exclude=CHANGELOG.md --exclude=README.md --exclude=LICENSE
hash -r
node -v
/usr/local/bin steht im PATH vor /usr/bin, das Debian-Node 20 darf also installiert bleiben. Für ein Update führst du die Befehle einfach nochmal aus. Danach fhempy neu starten, dann sollte der Matter Server starten.

nvm würde ich hier nicht nehmen: Es installiert Node nur ins Home-Verzeichnis des jeweiligen Users, fhempy läuft aber als fhem-User und sieht es dann nicht.

Zu deiner Frage "auf Dauer": Leider hast du recht. Node 22 bekommt noch bis Ende April 2027 Sicherheitsupdates. Ab Node 24 gibt es keine offiziellen 32-bit-ARM-Builds mehr, und auch die "unofficial builds" von Node.js bauen kein armv7l für Node 24. Der Matter Server braucht aktuell Node 22.13 oder neuer. Solange er nicht Node 24 verlangt, läuft es mit Node 22. Was danach kommt, kann ich heute nicht sagen.

Ein Tipp noch: Schau mal, welche Revision dein Pi 2B hat:

grep Revision /proc/cpuinfo
Steht dort a22042 (Pi 2B v1.2), dann hat dein Pi schon einen 64-bit-fähigen Chip (BCM2837, wie im Pi 3). Dann kannst du Raspberry Pi OS 64-bit (arm64) installieren und bekommst Node 22/24 ganz normal über NodeSource oder fhempy installiert es sogar selbst. Bei a01041 oder a21041 (v1.1) geht das leider nicht, dann bleibt nur der Weg über Node 22 oben.

Gruß Dominik

Hi Dominik,
danke für Deine Anleitung.
Habe jetzt node v22.23.4 am laufen  :)
Leider habe ich noch den Raspberry Model 2B V1.1, also nur 32 bit.

Kann jetzt schon mal via Matter over Wifi meine Govee Ambilight schalten ..
Als nächstes möchte ich ein IKEA Thread device mit dem SMLIGHT SLZB-06MU testen ..

Gruß Klaus

Hallo Dominik,

erstmal Danke für deine Arbeit.

Ich versuche gerade ein Smart Lock U200 von Aquara über Matter einzubinden. Der Aquara Hub M100 liess sich ohne Probleme pairen. Wenn ich das U200 über die App in den Pairingmodus versetze erkennt fhempy das ein neues Gerät im Netzwerk ist und ich kann den Pairing-Code eingeben. Dann passiert erstmal nichts und nach einiger Zeit taucht im Matter-Device die Fehlermeldung

failed: Commission failed: discovery of node with discriminator 1 failed: No device could be commissioned (1 of 1 started attempt(s) failed, 1 discovered). Check the code, put the device in pairing mode again and retry. IPv6 must be enabled in your network.
auf. Ich habe mal testweise test_dcl auf 1 gesetzt aber das ändert auch nichts.

Hast du eine Idee woran es liegen könnte?

Gruß
Jörg

List vom Matter-Device:

define matter fhempy matter
attr matter group matter
attr matter room Matter
attr matter test_dcl 1
#   DEF        matter
#   FHEMPYTYPE matter
#   FUUID      6ae2d4f3-f33f-47d8-8d05-10c69250291c6755
#   IODev      fhempy_local
#   NAME       matter
#   NR         107498
#   NTFY_ORDER 50-matter
#   PYTHONTYPE matter
#   STATE      connected
#   TYPE       fhempy
#   disableNotifyFn 1
#   eventCount 27
#   timeout    3000
#   READINGS:
#     2026-10-29 06:09:43   bluetooth       disabled
#     2026-10-29 06:09:43   fabric_id       1
#     2026-10-29 06:31:54   next_step       Ready. Pair more devices with 'set matter pair <code>'. Click 'Device specific help' for details.
#     2026-10-29 06:09:14   node_version    24.19
#     2026-10-29 06:31:54   nodes           1
#     2026-10-29 07:07:32   pairing         failed: Commission failed: discovery of node with discriminator 1 failed: No device could be commissioned (1 of 1 started attempt(s) failed, 1 discovered). Check the code, put the device in pairing mode again and retry. IPv6 must be enabled in your network.
#     2026-10-29 06:09:43   server_sdk      matter-server/1.4.0 (matter.js/0.17.9)
#     2026-10-29 06:09:38   server_version  1.4.0
#     2026-10-29 07:03:29   state           connected
#     2026-10-29 06:09:43   thread_dataset  not set
#     2026-10-29 06:09:43   wifi_credentials not set
#   args:
#     matter
#     fhempy
#     matter
#   argsh:
#   hmccu:
#



List vom funktionierenden M100:

define matter_1 fhempy matter matter 1
attr matter_1 alias Aqara Hub M100
attr matter_1 group matter
attr matter_1 icon mqtt_bridge_1
attr matter_1 room Matter
#   DEF        matter matter 1
#   FHEMPYTYPE matter
#   FUUID      6ae2da4a-f33f-47d8-a362-7c084e6a6f3c134d
#   IODev      fhempy_local
#   MATTER_CONTROLLER matter
#   MATTER_ID  1
#   MATTER_NODE 1
#   NAME       matter_1
#   NR         108367
#   NTFY_ORDER 50-matter_1
#   PYTHONTYPE matter
#   STATE      online
#   TYPE       fhempy
#   disableNotifyFn 1
#   eventCount 5
#   timeout    3000
#   READINGS:
#     2026-10-29 06:55:22   firmware        4.5.80
#     2026-10-29 06:31:54   label           Aqara Hub M100
#     2026-10-29 06:31:54   model           Aqara Hub M100
#     2026-10-29 07:03:29   state           online
#     2026-10-29 06:31:54   vendor          Aqara
#   args:
#     matter_1
#     fhempy
#     matter
#     matter
#     1
#   argsh:
#   hmccu:
#




Moin,
Kann jemand mal die Befehle und/oder Reihenfolge für eine parallele Installation von node hier aufschreiben.
Für RPi 3B+ /armv7l mit Bullseye und das Befehl für Befehl. Kann sein das fhempy auch schon seine eigne parallele Installation gemacht hatte, aber jetzt beim Modul matter sagt das list :

Internals:
   DEF        matter
   FHEMPYTYPE matter
   FUUID      6ae2f680-f33f-9a8d-d7f2-2caefc6f2b6efdce
   IODev      fhempy_local
   NAME       matter
   NR         385
   NTFY_ORDER 50-matter
   PYTHONTYPE matter
   STATE      Node.js 22.13 or newer needed
   TYPE       fhempy
   disableNotifyFn 1
   eventCount 4
   timeout    30000
   READINGS:
     2026-10-29 08:49:14   discovered      failed: Matter server is not connected, see state of matter
     2026-10-29 08:32:17   next_step       Install Node.js 22 or newer (https://nodejs.org or 'curl -fsSL https://deb.nodesource.com/setup_22.x | sudo bash - && sudo apt install nodejs') and restart fhempy.
     2026-10-29 09:15:09   node_version    found Node.js 20.19, 22.13 or newer needed
     2026-10-29 09:15:09   state           Node.js 22.13 or newer needed
   args:
     matter
     fhempy
     matter
   argsh:
Attributes:
   group      matter
   icon       control_building_control
   room       Matter
   verbose    5

Ich danke Euch schon mal, Reiner.

Hi Taskkill,
siehe Post #166:
cd /tmp
FILE=$(curl -fsSL https://nodejs.org/dist/latest-v22.x/ | grep -o 'node-v22[0-9.]*-linux-armv7l.tar.xz' | head -1)
curl -fsSLO https://nodejs.org/dist/latest-v22.x/$FILE
sudo tar -xJf $FILE -C /usr/local --strip-components=1 --exclude=CHANGELOG.md --exclude=README.md --exclude=LICENSE
hash -r
node -v

Besser wäre Du würdest dein RPI 3 mit ARM64 (trixie) neu installieren...  ;)

Zitat von: cetri am 29 Oktober 2026, 07:24:40Hallo Dominik,

erstmal Danke für deine Arbeit.

Ich versuche gerade ein Smart Lock U200 von Aquara über Matter einzubinden. Der Aquara Hub M100 liess sich ohne Probleme pairen. Wenn ich das U200 über die App in den Pairingmodus versetze erkennt fhempy das ein neues Gerät im Netzwerk ist und ich kann den Pairing-Code eingeben. Dann passiert erstmal nichts und nach einiger Zeit taucht im Matter-Device die Fehlermeldung

Code Auswählen Erweitern

failed: Commission failed: discovery of node with discriminator 1 failed: No device could be commissioned (1 of 1 started attempt(s) failed, 1 discovered). Check the code, put the device in pairing mode again and retry. IPv6 must be enabled in your network.
auf. Ich habe mal testweise test_dcl auf 1 gesetzt aber das ändert auch nichts.

Hast du eine Idee woran es liegen könnte?

Gruß
Jörg

List vom Matter-Device:

Code Auswählen Erweitern

define matter fhempy matter
attr matter group matter
attr matter room Matter
attr matter test_dcl 1
#  DEF        matter
#  FHEMPYTYPE matter
#  FUUID      6ae2d4f3-f33f-47d8-8d05-10c69250291c6755
#  IODev      fhempy_local
#  NAME      matter
#  NR        107498
#  NTFY_ORDER 50-matter
#  PYTHONTYPE matter
#  STATE      connected
#  TYPE      fhempy
#  disableNotifyFn 1
#  eventCount 27
#  timeout    3000
#  READINGS:
#    2026-10-29 06:09:43  bluetooth      disabled
#    2026-10-29 06:09:43  fabric_id      1
#    2026-10-29 06:31:54  next_step      Ready. Pair more devices with 'set matter pair <code>'. Click 'Device specific help' for details.
#    2026-10-29 06:09:14  node_version    24.19
#    2026-10-29 06:31:54  nodes          1
#    2026-10-29 07:07:32  pairing        failed: Commission failed: discovery of node with discriminator 1 failed: No device could be commissioned (1 of 1 started attempt(s) failed, 1 discovered). Check the code, put the device in pairing mode again and retry. IPv6 must be enabled in your network.
#    2026-10-29 06:09:43  server_sdk      matter-server/1.4.0 (matter.js/0.17.9)
#    2026-10-29 06:09:38  server_version  1.4.0
#    2026-10-29 07:03:29  state          connected
#    2026-10-29 06:09:43  thread_dataset  not set
#    2026-10-29 06:09:43  wifi_credentials not set
#  args:
#    matter
#    fhempy
#    matter
#  argsh:
#  hmccu:
#



List vom funktionierenden M100:

Code Auswählen Erweitern

define matter_1 fhempy matter matter 1
attr matter_1 alias Aqara Hub M100
attr matter_1 group matter
attr matter_1 icon mqtt_bridge_1
attr matter_1 room Matter
#  DEF        matter matter 1
#  FHEMPYTYPE matter
#  FUUID      6ae2da4a-f33f-47d8-a362-7c084e6a6f3c134d
#  IODev      fhempy_local
#  MATTER_CONTROLLER matter
#  MATTER_ID  1
#  MATTER_NODE 1
#  NAME      matter_1
#  NR        108367
#  NTFY_ORDER 50-matter_1
#  PYTHONTYPE matter
#  STATE      online
#  TYPE      fhempy
#  disableNotifyFn 1
#  eventCount 5
#  timeout    3000
#  READINGS:
#    2026-10-29 06:55:22  firmware        4.5.80
#    2026-10-29 06:31:54  label          Aqara Hub M100
#    2026-10-29 06:31:54  model          Aqara Hub M100
#    2026-10-29 07:03:29  state          online
#    2026-10-29 06:31:54  vendor          Aqara
#  args:
#    matter_1
#    fhempy
#    matter
#    matter
#    1
#  argsh:
#  hmccu:
#




Antwort von Claude :)

Hallo Jörg,
danke für die ausführlichen Infos, das hilft sehr.
Die Meldung "1 discovered" zeigt, dass fhempy das U200 im Netzwerk findet. Der Verbindungsaufbau zum Schloss klappt danach aber nicht. Ich vermute, das liegt an einer fehlenden IPv6-Route ins Thread-Netz.
Warum der M100 geht und das U200 nicht
Der M100 hängt direkt in deinem LAN, deshalb geht das Pairing ohne Probleme. Das U200 ist ein Thread-Gerät, das über den M100 als Thread Border Router funkt. Das Schloss hat eine IPv6-Adresse aus dem Thread-Netz (meist fdxx:...). Diese Adresse erreicht dein FHEM-Rechner nur, wenn er eine Route dorthin kennt. Der M100 kündigt diese Route per Router Advertisement an. Linux ignoriert solche Routen in der Standardeinstellung aber. Das Schloss wird also per mDNS gefunden, die Pakete von fhempy kommen beim Schloss aber nie an.
Prüfen
ip -6 route | grep -v fe80
Wenn dort keine Zeile wie fdxx:xxxx:xxxx:xxxx::/64 via fe80::... dev eth0 auftaucht, fehlt die Route. Du kannst auch set matter discover ausführen, während das U200 im Pairingmodus ist. Dann steht die Adresse im Reading discovered. Ein ping -6 <adresse> darauf sollte antworten.
Lösung (eth0 durch deine Schnittstelle ersetzen, z.B. wlan0)
sudo tee /etc/sysctl.d/60-matter-thread.conf <<'EOF'
net.ipv6.conf.eth0.accept_ra=1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=64
EOF
sudo sysctl --system
Falls auf dem Rechner IPv6-Forwarding aktiv ist (z.B. durch Docker), nimm accept_ra=2 statt 1. Danach ein paar Minuten warten, bis der M100 die nächste Ankündigung schickt, oder einfach neu starten. Dann mit ip -6 route prüfen, ob die fd-Route da ist. Danach das U200 in der Aqara App wieder in den Matter-Pairingmodus setzen und gleich danach set matter pair <code> ausführen. Der Code aus der App gilt nur ein paar Minuten.
Noch ein paar Hinweise:
test_dcl hat damit nichts zu tun, das kannst du wieder auf 0 setzen.
thread_dataset und Bluetooth brauchst du nicht. Die sind nur für ganz neue Geräte nötig, die noch in keinem Netz sind. Dein U200 ist schon über den M100 im Thread-Netz.
Wenn FHEM in Docker läuft, muss der Container mit network_mode: host laufen, und die sysctl-Einstellungen gehören auf den Host.
Das U200 schläft zwischendurch, um Batterie zu sparen. Wenn es trotz Route einmal nicht klappt, das Schloss kurz aufwecken (z.B. Tastenfeld berühren) und gleich noch einmal versuchen.
Gib gern Bescheid, ob es danach klappt. Falls nicht, schick mir bitte die Ausgabe von ip -6 route und das Reading discovered.
Gruß
Dominik

Zufällig den Faden gesehen...

@Dominik

WOW - fhempy  :o ist ja ganz schön "groß" geworden. Ich hatte mich von fhempy vor 1-2 Jahren verabschiedet, weil es leider immer wieder mal Zugangsproblem mit meinen Gerätschaften Netatmo / Tuya und Co. gab.

Da werd ich wohl mal bislang ungenutztes mein SLZB-MR4U rausholen müssen und mit fhempy irgendwie einbinden. ;D

Mal schauen und hoffen das ich dann damit mein Lamellendach von PERGOLUX irgendwie ins FHEM bekommen kann..... ;)

Zitat von: dominik am 29 Oktober 2026, 21:09:08Antwort von Claude :)

Hallo Jörg,
danke für die ausführlichen Infos, das hilft sehr.
Die Meldung "1 discovered" zeigt, dass fhempy das U200 im Netzwerk findet. Der Verbindungsaufbau zum Schloss klappt danach aber nicht. Ich vermute, das liegt an einer fehlenden IPv6-Route ins Thread-Netz......

Hallo Claude, :)

deine Vermutung war richtig. Die IPv6-Route hat gefehlt. Bei mir läuft FHEM in einem lxc unter Proxmox.

Mit

net.ipv6.conf.eth0.accept_ra=2
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=64
im lxc wird die Route korrekt angelegt und das U200 wurde gepairt.

Besten Dank und liebe Grüße

deine Gemini  ;D

Aktueller Status bei mir:

SLZB-MR4U ist in der Theorie komplett installiert und eingebunden - aber das notwendige "set matter pair xxxxxxxx" klappt trotz aller möglichen Anstrengungen (leider) noch nicht.

Mein Lamellendach von Pergolux ist da leider schon sehr sehr zimperlich mit der Einbindung bzw. dem Verbindungsaufbau.
In "Apple Home" habe ich es heute nur dadurch gepairt bekommen, das ich mit dem Handy "Wange an Wange" am Controller-Gerät / Aluprofil gestanden bin.
Mit einer App von PERGOLUX geht es auch nur im Umkreis von 2 Metern - nur die Fernbedienung (Funk) geht so bis zu 3-4 Meter Abstand.
Die Elektronik ist leider hinter einem Alu-Profil verschraubt, verdeckt und versteckt vor dem Wetter draußen.
Guter Wetterschutz - aber schlecht für die Verbindung.

Wenn ich es am WE nochmals (ohne den vielen Regen und etwas wärmer) wieder auf der Leiter schaffe, ganz nah mit dem SLZB-MR4U heranrücke, es erneut versuche und dann erfolgreich wäre ->> Juhuhuhuh ;)

Claude:

Hallo,
danke für den Zwischenstand. Die gute Nachricht: Für FHEM musst du sehr wahrscheinlich nicht noch einmal auf die Leiter.
Wichtig vorweg: Wer muss nah ans Dach?
Beim allerersten Einrichten läuft die Verbindung per Bluetooth. Deshalb musstest du mit dem Handy "Wange an Wange" stehen. Der SLZB-MR4U spielt dabei keine Rolle. Er ist nur der Thread Border Router und macht kein Bluetooth-Pairing. Wenn du ihn näher ans Dach bringst, hilft das beim Pairing also nicht.
set matter pair nutzt gar kein Bluetooth. Es erwartet, dass das Gerät schon im Netzwerk ist (WLAN oder Thread), und spricht es dann über IPv6 an. Ein frischer Code vom Typenschild bringt bei einem Gerät, das noch in keinem Netz ist, also nichts. Dafür gäbe es pair_new_device, das läuft über Bluetooth am FHEM-Rechner. Das hat bei dir aber dasselbe Reichweitenproblem.
Der einfache Weg: über Apple Home teilen
Das Dach ist ja schon in Apple Home und damit bereits in einem Netz. Matter erlaubt mehrere Steuerungen gleichzeitig (Multi-Admin). Du kannst es also aus Apple Home heraus an FHEM weitergeben, ganz ohne Bluetooth:
In der Home-App das Dach antippen und unten zu den Einstellungen scrollen.
"Kopplungsmodus einschalten" wählen. Du bekommst einen neuen 11-stelligen Code.
Gleich danach in FHEM set matter pair <code> ausführen. Der Code gilt nur ein paar Minuten.
Das Ergebnis steht im Reading pairing. Das Dach bleibt dabei weiter in Apple Home.
Das kannst du ganz bequem vom Sofa aus machen.
Falls das Dach per Thread angebunden ist
Wenn du in Apple Home gepairt hast, hängt das Dach jetzt im Thread-Netz deines Apple-Border-Routers (HomePod mini oder Apple TV). Das ist nicht unbedingt dasselbe Thread-Netz wie das vom SLZB-MR4U. Für den Weg oben ist das egal, solange dein FHEM-Rechner das Thread-Netz über IPv6 erreicht.
Genau da hakt es unter Linux oft. Der Border Router kündigt eine Route ins Thread-Netz an (Adressen wie fdxx:...), und Linux ignoriert diese Ankündigung in der Standardeinstellung. Das Gerät wird dann zwar gefunden, aber das Pairing schlägt fehl.
Prüfen:
ip -6 route | grep -v fe80
Dort sollte eine Zeile wie fdxx:xxxx:xxxx:xxxx::/64 via fe80::... dev eth0 auftauchen. Wenn sie fehlt (eth0 ggf. durch deine Schnittstelle ersetzen, z.B. wlan0):
sudo tee /etc/sysctl.d/60-matter-thread.conf <<'EOF'
net.ipv6.conf.eth0.accept_ra=1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=64
EOF
sudo sysctl --system
Falls IPv6-Forwarding aktiv ist (z.B. durch Docker), nimm accept_ra=2 statt 1. Danach ein paar Minuten warten oder neu starten und mit ip -6 route noch einmal prüfen. Läuft FHEM in Docker, braucht der Container network_mode: host, und die Einstellungen gehören auf den Host.
Zum Testen: set matter discover ausführen, während in Apple Home der Kopplungsmodus läuft. Die gefundenen Geräte stehen im Reading discovered. Taucht das Dach dort auf, sieht FHEM es schon. Dann liegt es fast immer an der Route.
Wenn es trotzdem nicht klappt
Schick mir bitte:
die Readings pairing und discovered (nach einem Versuch mit frischem Code),
die Ausgabe von ip -6 route,
die letzten Zeilen aus matter_server.log (meist unter /opt/fhem/.fhempy/matter_server/).
Damit sehe ich, ob das Dach gar nicht gefunden wird, ob die Verbindung nicht zustande kommt oder ob das Gerät etwas ablehnt.
Den SLZB-MR4U brauchst du für diesen Weg übrigens nicht. Er wird erst interessant, wenn du Thread-Geräte ganz ohne Apple einbinden willst. Dann reicht es, wenn er irgendwo in Funkreichweite anderer Thread-Geräte steht. Thread ist ein Mesh, die Geräte reichen die Pakete weiter.
Viel Erfolg am Wochenende, hoffentlich ganz ohne Leiter ;)
Gruß
Dominik

Kurzfassung:
Danke Dominik!

Ich habe keinen HomePod / kein Apple TV als Border Router. Mein einziges Thread-Gateway ist der SLZB-MR4U. Das Handy nutze ich nur als temporäre Bluetooth-Hilfe, um den Code zu erzeugen.



Langfassung:

Zitat von: dominik am 30 Oktober 2026, 23:05:52Der einfache Weg: über Apple Home teilen

Das wäre der allerletzte Plan....da müsste ein Applegerät dauerhaft im Hausnetz sein / bleiben.

Zitat von: dominik am 30 Oktober 2026, 23:05:52Wenn du in Apple Home gepairt hast, hängt das Dach jetzt im Thread-Netz deines Apple-Border-Routers (HomePod mini oder Apple TV). Das ist nicht unbedingt dasselbe Thread-Netz wie das vom SLZB-MR4U. Für den Weg oben ist das egal, solange dein FHEM-Rechner das Thread-Netz über IPv6 erreicht.

...und genau das ist bei mir der große Haken :
Das ist wie früher in der Kaffeewerbung " Isch habe gar kein Auto".... ;)

Ich habe kein Matter bei mir im Hausnetz - das möchte ich allein über den mein SLZB-MR4U realisieren.
Aber solange ich keine Kopplung mit diesem vornehmen kann......

Das sollte ?? m.A.n. ?? daher nur so (evtl.) funktionieren:
Wenn ich "Wange an Wange" mein Handy mit Apple Home bei Matterdevice bin und damit Kontakt habe...
Dann muss ich unten in / zu den Einstellungen meines dort einzigen Gerätes (PERGOLUX).
"Kopplungsmodus einschalten" und ich erhalte einen neuen 11-stelligen Code.
Handy in der Nähe des PEEGOLUX-Matter-Ddevice temporär ablegen / hinlegen.

Sofort / Eiligst in FHEM set matter pair <code> ausführen ->>> da der Code ja nur ein paar Minuten gilt ;)
Wenn das klappt, dann will ich wieder mit meinem Handy von dem PERGOLUX auf der Leiter wieder weg  :o

So war mein aktueller Plan mit dem näherbringen des SLZB-MR4U der in dem normalen Hausnetz per WLAN erreichbar ist (ein IP-Adressen-Kreis)
Oder ist das total daneben ?
Wie gesagt - Matter gar keine Ahnung / Erfahrung bislang....  :o  O:-)

Gruß
300P



NACHSATZ:

Dies schon mal im QNAP-Container ausgeführt....:


# sysctl -w net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.all.accept_ra = 2
# ip -6 route
2001:16b8:46:e100::/64 dev eth0 proto ra metric 1024 expires 6952sec pref medium
2001:16b8:46:e100::/56 via fe80::ec5:74ff:fed0:2aa3 dev eth0 proto ra metric 1024 expires 1552sec pref medium
fdd8:ddc8:bda5::/64 dev eth0 proto ra metric 1024 expires 6952sec pref medium
fdd8:ddc8:bda5::/64 via fe80::ec5:74ff:fed0:2aa3 dev eth0 proto ra metric 1024 expires 1552sec pref medium
fded:8dc0:e11e:1::/64 via fe80::eaf6:aff:feca:b868 dev eth0 proto ra metric 1024 expires 1645sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::ec5:74ff:fed0:2aa3 dev eth0 proto ra metric 1024 expires 1552sec mtu 1492 pref medium
#


# ip -6 route | grep -v fe80
2001:16b8:46:e100::/64 dev eth0 proto ra metric 1024 expires 6773sec pref medium
fdd8:ddc8:bda5::/64 dev eth0 proto ra metric 1024 expires 6773sec pref medium
#


Aber trotz aller Bemühungen (mit externer Unterstützung) heute leider keine Erfolg.


Hier noch das Log von Heute:

2026-10-31 16:06:36.492 INFO MatterServer File logging enabled: /opt/fhem/.fhempy/matter_server/matter_server.log
2026-10-31 16:06:36.499 INFO ConfigStorage Storage location: /opt/fhem/.fhempy/matter_server/data (Directory)
2026-10-31 16:06:36.615 INFO ConfigStorage Set config key fabricLabel to FHEM
2026-10-31 16:06:36.672 INFO ConfigStorage Set config key nextNodeId to 10
2026-10-31 16:06:36.685 INFO ConfigStorage Set config key wifiSsid to undefined
2026-10-31 16:06:36.690 INFO ConfigStorage Set config key wifiCredentials to <redacted>
2026-10-31 16:06:36.696 INFO ConfigStorage Set config key threadDataset to <redacted>
2026-10-31 16:06:36.704 INFO ServerIdResolver Found existing storage for server ID: server-1-fff1
2026-10-31 16:06:36.777 INFO DclCertificateService Initialize CertificateService prod: https://on.dcl.csa-iot.org test: https://on.test-net.dcl.csa-iot.org github: yes acceptTest
2026-10-31 16:06:36.787 INFO DclVendorInfoService Initialize VendorInfoService source: https://on.dcl.csa-iot.org interval: 24h
2026-10-31 16:06:36.797 INFO ControllerCommandHandler BLE is disabled
2026-10-31 16:06:36.813 NOTICE WebSocketControllerHandler Starting server: matter-server/1.4.0 (matter.js/0.17.9)
2026-10-31 16:06:37.039 INFO DclVendorInfoService Loaded 891 vendors from storage
2026-10-31 16:06:37.041 INFO DclVendorInfoService seed: skipping vendors ? storage has 891 entries >= seed expectedCount 891
2026-10-31 16:06:37.041 INFO DclVendorInfoService Fetching vendor information from DCL
2026-10-31 16:06:37.083 INFO DclCertificateService Loaded 181 certificates from storage
2026-10-31 16:06:37.209 INFO DclCertificateService seed: consumed 0 PAA certs from snapshot 2026-10-30T02:12:41.655Z
2026-10-31 16:06:37.218 INFO DclCertificateService seed: consumed 0 CDSigner certs from snapshot 2026-10-30T02:12:41.655Z
2026-10-31 16:06:37.230 INFO ServerNodeStore Opened server-1-fff1 storage location: /opt/fhem/.fhempy/matter_server/data/server-1-fff1 driver: wal
2026-10-31 16:06:37.742 INFO BaseEventStore Loaded volatile event store with next number 6001
2026-10-31 16:06:37.772 INFO Endpoint server-1-fff1 ready endpoint#: 0 type: RootNode (0x16, rev 4) behaviors: ?parts ?index ?accessControl ?basicInformation ?generalCommissioning ?generalDiagnostics ?administratorCommissioning ?operationalCredentials ?groupKeyManagement ?commissioning ?network ?productDescription ?subscriptions ?sessions ?events ?controller ?descriptor
2026-10-31 16:06:37.835 INFO DclOtaUpdateService Initialize OTAUpdateService prod: https://on.dcl.csa-iot.org test: https://on.test-net.dcl.csa-iot.org
2026-10-31 16:06:37.932 INFO Endpoint server-1-fff1.ota-provider ready endpoint#: 1 type: OtaProvider (0x14, rev 1) behaviors: ?otaSoftwareUpdateProvider ?descriptor ?softwareupdates
2026-10-31 16:06:37.937 INFO CertificateAuthority Loaded stored credentials with ID 0
2026-10-31 16:06:37.986 NOTICE FabricAuthority Rotated NOC for fabric 1
2026-10-31 16:06:38.022 WARN CommissioningController BLE is not enabled on this platform
2026-10-31 16:06:38.024 NOTICE Node server-1-fff1 going online
2026-10-31 16:06:38.036 INFO ServerNetworkRuntime TCP transport enabled (incoming=true, outgoing=true)
2026-10-31 16:06:38.075 INFO NetworkProfiles Configure profile fast exchanges: 200 additionalMrpDelay: 0
2026-10-31 16:06:38.077 NOTICE Node server-1-fff1 is online
2026-10-31 16:06:38.084 INFO FabricAccessControl ACL List updated privilege: 5 authMode: 2 subjects: 112233 targets: null fabricIndex: 1 privilege: 3 authMode: 2 subjects:  targets: { cluster: 41, endpoint: 1, deviceType: null } fabricIndex: 1 privilege: 3 authMode: 2 subjects:  targets: { cluster: 1364, endpoint: 2, deviceType: null } fabricIndex: 1
2026-10-31 16:06:38.136 INFO MdnsAdvertisement Publishing kind: operational service: mdns:41AB32C32A92CAB7-000000000001B669._matter._tcp.local
2026-10-31 16:06:38.139 INFO SoftwareUpdateManager Scheduling first OTA update check in 9m 29s
2026-10-31 16:06:38.167 NOTICE ControllerCommandHandler Matter Controller started
2026-10-31 16:06:38.169 INFO ControllerCommandHandler OTA event handlers registered
2026-10-31 16:06:38.181 INFO MatterController Registered Thread credentials from stored:default (xp=6A467D6BB0CE045D, network="ha-thread-dacb", ch=15, panId=0xDACB, mlPrefix=FD516863BBCDA731, activeTs=0000000000010000, pskc=set, networkKey=set, secPolicy=rotation672h/flags=0xF7F8, unknownTlvs=1)
2026-10-31 16:06:38.200 INFO WebRtcTransportRequestorServer WebRtcTransportRequestor initialized on endpoint=2 (id="camera-controller")
2026-10-31 16:06:38.207 INFO MatterController Enabled test OTA images (test-net DCL)
2026-10-31 16:06:38.233 INFO Endpoint server-1-fff1.camera-controller ready endpoint#: 2 type: CameraController (0x0147, rev 1) behaviors: ?webRtcTransportRequestor ?descriptor
2026-10-31 16:06:38.237 INFO ControllerCommandHandler WebRTC callback bridge wired
2026-10-31 16:06:38.237 INFO ControllerCommandHandler Found 0 nodes:
2026-10-31 16:06:38.238 INFO ControllerCommandHandler All 0 nodes initialized, starting connections
2026-10-31 16:06:38.249 NOTICE WebServer Webserver listening on http://127.0.0.1:5580
2026-10-31 16:06:39.383 INFO DclVendorInfoService Fetched 888 vendors from DCL
2026-10-31 16:06:39.413 INFO DclCertificateService Failed to fetch GitHub certificate Chip-Development-PAA-ML-DSA-44-Cert.der [certificate] DER certificate of 4080 bytes exceeds the 600 byte limit.
2026-10-31 16:06:39.476 INFO DclVendorInfoService Stored 892 vendors
2026-10-31 16:06:39.485 INFO DclCertificateService Failed to fetch GitHub certificate Chip-Development-PAA-ML-DSA-65-Cert.der [certificate] DER certificate of 5609 bytes exceeds the 600 byte limit.
2026-10-31 16:06:39.869 INFO DclCertificateService All certificates up to date (181 total)
2026-10-31 16:06:41.769 INFO WebSocketControllerHandler [0] WebSocket connection established
2026-10-31 16:06:41.786 INFO WebSocketControllerHandler WebSocket server start_listening
2026-10-31 16:06:41.787 INFO WebSocketControllerHandler WebSocket server start_listening. Returned 0 nodes
2026-10-31 16:16:07.149 INFO SoftwareUpdateManager No updatable nodes found
2026-10-31 16:19:05.932 INFO ConfigStorage Set config key nextNodeId to 11
2026-10-31 16:19:05.991 INFO Discovery Initiating discovery of node with discriminator 6
2026-10-31 16:19:54.518 INFO ConfigStorage Set config key nextNodeId to 12
2026-10-31 16:19:54.551 INFO Discovery Initiating discovery of node with discriminator 6
2026-10-31 16:22:06.017 ERROR WebSocketControllerHandler [0] WebSocket error response (commission_with_code) 3 Commission failed: discovery of node with discriminator 6 failed: No commissionable device was discovered
    at ServerError.nodeCommissionFailed (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/types/WebSocketMessageTypes.js:38:12)
    at ControllerCommandHandler.commissionNode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/controller/ControllerCommandHandler.js:959:25)
    at async #commissionWithRetry (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:786:39)
    at async #handleCommissionWithCode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:834:20)
    at async #handleWebSocketRequest (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:527:20)
  Caused by: [discovery] discovery of node with discriminator 6 failed: No commissionable device was discovered
    at CommissioningDiscovery.onComplete (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter/node/dist/esm/behavior/system/controller/discovery/ParallelPaseDiscovery.js:123:13)
2026-10-31 16:22:54.555 ERROR WebSocketControllerHandler [0] WebSocket error response (commission_with_code) 4 Commission failed: discovery of node with discriminator 6 failed: No commissionable device was discovered
    at ServerError.nodeCommissionFailed (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/types/WebSocketMessageTypes.js:38:12)
    at ControllerCommandHandler.commissionNode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/controller/ControllerCommandHandler.js:959:25)
    at async #commissionWithRetry (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:786:39)
    at async #handleCommissionWithCode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:834:20)
    at async #handleWebSocketRequest (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:527:20)
  Caused by: [discovery] discovery of node with discriminator 6 failed: No commissionable device was discovered
    at CommissioningDiscovery.onComplete (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter/node/dist/esm/behavior/system/controller/discovery/ParallelPaseDiscovery.js:123:13)
2026-10-31 16:25:08.233 INFO Discovery Initiating discovery of node discovery
2026-10-31 16:25:11.237 INFO ControllerCommandHandler Discovered result
2026-10-31 16:27:54.021 INFO ConfigStorage Set config key nextNodeId to 13
2026-10-31 16:27:54.051 INFO Discovery Initiating discovery of node with discriminator 6
2026-10-31 16:30:54.065 ERROR WebSocketControllerHandler [0] WebSocket error response (commission_with_code) 6 Commission failed: discovery of node with discriminator 6 failed: No commissionable device was discovered
    at ServerError.nodeCommissionFailed (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/types/WebSocketMessageTypes.js:38:12)
    at ControllerCommandHandler.commissionNode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/controller/ControllerCommandHandler.js:959:25)
    at async #commissionWithRetry (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:786:39)
    at async #handleCommissionWithCode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:834:20)
    at async #handleWebSocketRequest (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:527:20)
  Caused by: [discovery] discovery of node with discriminator 6 failed: No commissionable device was discovered
    at CommissioningDiscovery.onComplete (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter/node/dist/esm/behavior/system/controller/discovery/ParallelPaseDiscovery.js:123:13)
2026-10-31 16:42:41.422 INFO ConfigStorage Set config key nextNodeId to 14
2026-10-31 16:42:41.456 INFO Discovery Initiating discovery of node with discriminator 6
2026-10-31 16:45:41.470 ERROR WebSocketControllerHandler [0] WebSocket error response (commission_with_code) 7 Commission failed: discovery of node with discriminator 6 failed: No commissionable device was discovered
    at ServerError.nodeCommissionFailed (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/types/WebSocketMessageTypes.js:38:12)
    at ControllerCommandHandler.commissionNode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/controller/ControllerCommandHandler.js:959:25)
    at async #commissionWithRetry (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:786:39)
    at async #handleCommissionWithCode (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:834:20)
    at async #handleWebSocketRequest (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter-server/ws-controller/dist/esm/server/WebSocketControllerHandler.js:527:20)
  Caused by: [discovery] discovery of node with discriminator 6 failed: No commissionable device was discovered
    at CommissioningDiscovery.onComplete (file:///opt/fhem/.fhempy/matter_server/node_modules/@matter/node/dist/esm/behavior/system/controller/discovery/ParallelPaseDiscovery.js:123:13)



Hallo 300P,
danke für das Log und die Routen, damit kann ich jetzt viel mehr sagen. Und sorry, ich bin fälschlich davon ausgegangen, dass ein HomePod oder Apple TV im Haus ist.
Was das Log sagt
Jeder Versuch endet mit:
discovery of node with discriminator 6 failed: No commissionable device was discoveredfhempy hat also gar keine Verbindung zum Dach aufgebaut. Es hat das Dach im Netzwerk einfach nicht gefunden. Gesucht wird per mDNS im Hausnetz (Bluetooth ist im Container aus, siehe "BLE is disabled"). Code, Zertifikate usw. kamen noch gar nicht zum Zug.
Die Route ist übrigens schon da
Mein [tt]grep -v fe80[/tt] war ein schlechter Tipp von mir, der filtert genau die wichtige Zeile weg. In deiner vollen Ausgabe steht:
fded:8dc0:e11e:1::/64 via fe80::eaf6:aff:feca:b868 dev eth0 proto ra ...Das ist sehr wahrscheinlich das Thread-Netz deines SLZB-MR4U. Der IPv6-Teil passt also. Damit das nach einem Neustart bleibt, [tt]accept_ra=2[/tt] (und [tt]accept_ra_rt_info_max_plen=64[/tt]) bitte noch dauerhaft eintragen, [tt]sysctl -w[/tt] gilt nur bis zum Neustart.
Die eigentliche Frage: Ist das Dach WLAN oder Thread?
Ohne HomePod oder Apple TV hat Apple Home keinen eigenen Thread Border Router. Ein iPhone allein kann ein Thread-Gerät nicht in ein Thread-Netz bringen. Dass das Pairing in Apple Home trotzdem geklappt hat, spricht stark dafür, dass das Pergolux ein WLAN-Matter-Gerät ist. Das Handy hat ihm per Bluetooth nur die WLAN-Daten gegeben, seitdem hängt es in deinem WLAN.
Das kannst du leicht prüfen: Schau in deinem Router (z.B. FRITZ!Box unter Heimnetz) nach, ob seit dem Pairing ein neues WLAN-Gerät aufgetaucht ist. Und: Lässt sich das Dach in Apple Home auch vom Sofa aus steuern? Dann ist es im Netz.
Wenn es WLAN ist, heißt das:

• Den SLZB-MR4U brauchst du für das Dach gar nicht. Näher heranrücken bringt also nichts.
• Du musst auch nicht auf die Leiter. "Kopplungsmodus einschalten" schickt Apple Home über das WLAN ans Dach. Das Handy muss nur im Heimnetz sein, nicht neben dem Dach.
• Ein Apple-Gerät muss nicht dauerhaft bleiben. Das Handy braucht man nur dieses eine Mal als Helfer. Wenn das Dach in FHEM ist, kannst du es aus Apple Home wieder entfernen (vorher kurz prüfen, dass es in FHEM funktioniert).

Warum FHEM es trotzdem nicht findet
Ich vermute den Container auf der QNAP. mDNS läuft per Multicast, und das kommt bei Container Station im NAT-Modus nicht an. Bitte prüfen:

• Der Container sollte im Netzwerkmodus Host laufen (bei Container Station unter Netzwerk). Bridge mit eigener IP im LAN kann gehen, NAT geht nicht.
• Dann in Apple Home "Kopplungsmodus einschalten", gleich danach [tt]set matter discover[/tt] und das Reading [tt]discovered[/tt] ansehen. Taucht dort ein Gerät mit Discriminator passend zum Code auf, sieht FHEM das Dach. Erst dann [tt]set matter pair <code>[/tt].
• Falls [tt]avahi-browse[/tt] auf der QNAP oder im Container verfügbar ist: [tt]avahi-browse -rt _matterc._udp[/tt] während des Kopplungsmodus zeigt, ob das Dach sich überhaupt im Netz meldet. [tt]avahi-browse -rt _matter._tcp[/tt] zeigt alle Matter-Geräte, die schon gekoppelt sind. Das Dach sollte dort mit der Kennung von Apple auftauchen.

Falls es doch ein Thread-Gerät ist
Dann müsste das Dach im Thread-Netz des SLZB-MR4U hängen, und das geht nur, wenn das iPhone dessen Zugangsdaten kennt. Ohne Apple-Border-Router bleibt dann nur der Weg über Bluetooth direkt aus FHEM ([tt]pair_new_device[/tt] mit [tt]thread_dataset[/tt]). Dafür bräuchte der FHEM-Rechner einen Bluetooth-Adapter in Reichweite des Dachs, was bei einer QNAP im Container schwierig ist. Das würde ich erst angehen, wenn klar ist, dass es kein WLAN-Gerät ist.
Gib Bescheid, was der Router zeigt und was im Reading [tt]discovered[/tt] steht, dann sehen wir weiter.
Gruß
Dominik

Screenshot Borderrouting SLZ....: ->> Bildschirmfoto 2026-11-01 um 23.04.40.png

Den Rest schaue ich dann morgen nach.....😴🥱..war heute anstrengender Tag mit diversen Wphnungsübergaben für einen "schon langjährigen Rentner"... ;)


Nachsatz : das mit dem "Android hab ich wieder gelöscht - es war doch wieder der komisch Stick.....

Moin 300P,
mein SLZB hatte immer mal wieder unerwartet einen Softboot gemacht (das siehts Du oben rechts bei OTBR Betriebszeit). Erst ein Firmwareupdate mit der letzten stable Version update brachte Ruhe rein... (vorher war dev)

Ist es denn geplant, dass der Fhempy Matter Server auch mal einen BLE-Proxy unterstützt, also dass der Bluetooth Adapter des SLZB genutzt werden kann ?
Das attr bluetooth_adapter lässt aktuell nur 0 oder 1 zu, also für hci0 oder hci1, evtl. ble-porxy wäre vieleicht sinnvoll ?

Zitat von: Rampler am 02 November 2026, 07:34:33Erst ein Firmwareupdate mit der letzten stable Version update brachte Ruhe rein... (vorher war dev)

Moin !

Current firmware version: v3.4.5.dev0

Läuft bei mir ohne zu rerbooten durch....