Nativer Matter Support oder andere Lösungen

[abeggled]

@serieger21 Hat die Variante Homebridge vorgeschlagen, @abeggled findet dies nicht zielführend da IMHO nur Homekit Anbindung.

[Micsi]

Ja, HomeKit ist Apple proprietär, aber weit verbreitet. Man könnte das überlegen, wenn es geeignete, offene Standards gibt. Glaub ich aber nicht… nur im Apple Universeum.
Matter ist ein offener Standard, aber zugegebenermaßen heftig. Über den würde die HomeKit-Integration m.M.n aber mitkommen - immerhin.

Unterscheidet Matter nicht nach Consumer und Server/Bridge? Was genau wollen wir werden?

[serieger21]

Vielleicht sollte ich meine Aussage etwas präzisieren. Mir geht es darum mein Haus über Apple Home möglichst gut steuern zu können. Der OBS sol dabei weiterhin das Backbone bleiben. Aber anstatt die Verbindung zu Apple Home in OBS zu implementieren macht es doch mehr Sinn Homebridge als Ausgabe Layer zu Apple Home zu nutzen. Anstatt das alles in OBS zu bauen.

Zum Thema Matter, seit kurzen hat Homebridge auch Matter Support:
https://stadt-bremerhaven.de/homebridge-2-0-matter-unterstuetzung-ist-endlich-da/

Aber auch hier ist es vermutlich besser nochmal darüber nach zu denken ob Matter nicht ein nativer OBS Adapter sein sollte um den OBS in seiner Rolle als Backbone und Single Point of Truth zu stärken.

[abeggled]

Open Bridge Server — Matter Integration Specification

Version: 0.1 (pre-implementation)
Lizenz: MIT
Teil von: Open Bridge Server (OBS) Monorepo (matter/)
Stand: 2026-05-05

---

1. Ziel

Dieses Dokument beschreibt die optionale Matter-Bridge-Integration für den Open Bridge Server (OBS). Sie ermöglicht es, OBS-Datenpunkte (Sensoren, Aktoren, Sollwerte) als native Matter-Geräte in Apple HomeKit, Samsung SmartThings, Google Home und Amazon Alexa sichtbar zu machen — lokal, ohne Cloud-Abhängigkeit, ohne proprietäre Hubs.

Die Matter-Bridge ist ein optionaler Sidecar-Service und kein Bestandteil des OBS-Kerns. Der OBS-Core bleibt protocol-agnostisch. Die Bridge wird via docker-compose aktiviert.

---

2. Architektur-Übersicht

KNX / Modbus / 1-Wire / weitere Protokolle
              ↓
   OBS Backend (Python / FastAPI)
              ↓  publish  (UUID-Topics + Alias-Topics)
       Mosquitto MQTT Broker
              ↓  subscribe
   Matterbridge + matterbridge-obs Plugin
              ↓  Matter over IP (Wi-Fi / Ethernet, mDNS)
   ┌────────────────────────────────────────┐
   │  Apple HomeKit  │  Samsung SmartThings │
   │  Google Home    │  Amazon Alexa        │
   └────────────────────────────────────────┘

Designprinzipien

• Entkopplung: Die Bridge kommuniziert ausschliesslich über den bestehenden Mosquitto-Broker — keine direkte Abhängigkeit zur OBS REST API im Normalbetrieb.
• Registry-Prinzip: Das Mapping Datenpunkt → Matter Device Type folgt dem OBS-eigenen Registry-Muster und ist zur Laufzeit via SQLite konfigurierbar.
• Sidecar-Pattern: Matterbridge läuft als separater Docker-Container, der im selben docker-compose-Stack optional aktiviert wird.
• Kein Neustart des OBS-Cores für Änderungen an der Matter-Konfiguration erforderlich.

---

3. Technologie-Entscheid: Matterbridge

Warum Matterbridge

Kriterium	Matterbridge	python-matter-server	CircuitMatter
Rolle	Device / Bridge ✓	Controller (liest Geräte)	Device (experimentell)
Basis	matter.js (Node.js)	offiz. C++ SDK (Python-Wrapper)	reines Python
Produktionsreife	Produktiv, aktiv entwickelt	Maintenance-Modus seit 2026	Alpha
MQTT-Support	Plugin-Ökosystem vorhanden	—	—
Docker	Offizielles Image	Offizielles Image	—
MIT/Apache	Apache-2.0	Apache-2.0	MIT
ARM Cortex-A72	✓ (läuft auf Pi 4)	✓	—

---

11. Implementierungs-Reihenfolge (empfohlen)

Phase M1 — Grundstruktur

1. matterbridge-obs npm-Package-Gerüst (TypeScript, Matterbridge-Plugin-Interface)
2. MQTT-Client-Verbindung zu Mosquitto
3. OBS REST API-Client (Datenpunkte laden)
4. DeviceTypeRegistry mit Standard-Mappings

Phase M2 — Erste Gerätetypen

5. TemperatureSensor — rein lesend, einfachster Fall
6. ContactSensor / OccupancySensor — Boolean, lesend
7. OnOffSwitch — Boolean, schreibend (erster Schreibpfad)
8. Docker-Compose-Integration, End-to-End-Test mit Apple Home

Phase M3 — Erweiterte Gerätetypen

9. DimmableLight (FLOAT 0–100%, schreibend)
10. Thermostat (Sollwert lesen/schreiben)
11. WindowCovering (Jalousie)
12. HumiditySensor, LightSensor

Phase M4 — OBS-Integration

13. SQLite-Tabelle matter_config + Migration
14. REST-Endpoints /api/v1/matter/*
15. MQTT-Steuerkanal für Live-Updates
16. Visu-Integration (Matter-Konfigurationsseite)

Phase M5 — Stabilisierung

17. Reconnect-Logik (MQTT + Matter Fabric)
18. Monitoring-Endpoint für OBS-Statusseite
19. Installationsdokumentation (Netzwerk-Anforderungen prominent)
20. Community-Plugin-Anleitung (eigene Device Type Mappings)

---

12. Abgrenzung

• Kein Thread Border Router: OBS exponiert Datenpunkte über Matter-over-IP (Wi-Fi/Ethernet). Thread als Transportprotokoll für angeschlossene Feldgeräte ist nicht vorgesehen.
• Keine Matter-Controller-Funktion: OBS steuert keine fremden Matter-Geräte — es ist rein ein Matter-Bridge (Device-Seite).
• Kein Cloud-Pairing: Ausschliesslich lokales Commissioning. QR-Code wird lokal in der Visu angezeigt.
• Keine Zertifizierung (Phase 1): Matterbridge läuft als nicht-zertifiziertes Gerät — alle grossen Controller akzeptieren dies mit einem einmaligen Warnhinweis beim Pairing. Für eine spätere offizielle Zertifizierung wäre eine CSA-Mitgliedschaft erforderlich.
• Alexa-Limit: Alexa unterstützt aktuell maximal 50 bridged devices pro Verbindung — bei grossen OBS-Installationen müssen Datenpunkte bewusst ausgewählt werden.

---

13. Offene Punkte

• Strategie bei >50 exponierten Datenpunkten für Alexa (mehrere Bridge-Instanzen?)
• Matter 1.4+ Device Types (Energy Reporting, EV Charging) — für industrielle OBS-Anwendungsfälle relevant
• Automatisches Mapping basierend auf KNX DPT-Typ (z.B. DPT 9.001 → TemperatureSensor)
• Gruppenbildung: Mehrere OBS-Datenpunkte als ein logisches Matter-Gerät (z.B. Heizkreis = Thermostat mit IST + SOLL + Pumpe)
• Visu-Pairing-Assistent mit Schritt-für-Schritt-Anleitung pro Ökosystem

[Micsi]

Ist das Projekt gemeint: https://matterbridge.io ? Also ein optionaler Docker-Container?

[abeggled]

genau, siehe oben:

• Sidecar-Pattern: Matterbridge läuft als separater Docker-Container, der im selben docker-compose-Stack optional aktiviert wird.
• Kein Neustart des OBS-Cores für Änderungen an der Matter-Konfiguration erforderlich.

[gbglace]

Das automatische Mapping nur via der KNX DPT Formatierung der GA zumachen würde den OBS darauf reduzieren das Du nur Temperatur via KNX gut automatisiert gemappt bekommst. Hier wurde ich dann eher wieder auf meinen PR des Metadatenmodells referenzieren. Wodurch jeder Datenpunkte eben auch eine semantische Zuordnung erhält. Darüber wäre dann auch eine 1-wire Temperatur direkt gemappt und nicht nur jene Temperaturen die irgendwie ein Binding zur KNX Welt haben. Bzw. Es ist nicht notwendig einen nicht KNX Datenpunkt Zwangsweise mit einem DPT zu versehen, da dies ja eine sehr KNX spezifische Typisierung ist.

[abeggled]

Im Objektsystem gibt es nur die Datentypen:

und "fast alle" Einheiten.

Das Dokument in der aktuellen Fassung (Version: 0.1 (pre-implementation)) soll nur zeigen, dass es "sinnvollere" Varianten als die Homebridge gibt, welche sich nur um Apple kümmert.

[Micsi]

@gblace , wo liest du, dass es nur KNX ga Mapping geben würde? Der OBS hat ein eigenes Objektsystem, bei dem es nicht mehr darauf ankommt, wo genau die Daten herkommen/hingehen.Außerdem ist das Dok wohl eher nur ein grober Plan, quasi der Weg zum MVP. Die Beschränkung auf 50 Werte scheint mir da eher ein Showstopper zu sein, oder? // Mail Müll gelöscht //

[abeggled]

Gut, wie viele Punkte hast du wirklich welche via Alexa gesteuert werden sollen? Soweit ich dies verstanden habe, sind da auch andere (Matter-)Lösungen betroffen. Ich denke wenn Verbreitung und somit der Druck steigt wird das hoffentlich angehoben.