Kampfspiel-Duell zwischen einem Standard-Roboter und einem Proprietär-Roboter, dazwischen ein Schiedsrichter mit der Frage 'Why not both?' — eine spielerische Sicht auf die Bluetooth-Mesh-Entscheidung.

Proprietäres vs. Standard-Bluetooth-Mesh: Eine Entscheidung, die Ihr Produkt über Jahre prägt

·MESHLE

Funktechnologie wählen: komplexer, als man denkt

Egal, ob man ein neues Produkt entwickelt oder ein bestehendes funkfähig machen will — eine Frage steht immer am Anfang: Welche Funktechnologie soll es sein? Bluetooth Mesh scheint die naheliegende Antwort. Weit verbreitet, energieeffizient, offline-first und durch einen Industriestandard abgesichert.

Doch sobald man tiefer einsteigt, wird das Bild unübersichtlich.

Denn Bluetooth Mesh ist nicht gleich Bluetooth Mesh. Auf dem Markt existieren mehrere Implementierungen nebeneinander — und die sind untereinander nicht zwangsläufig kompatibel. Mehrere Anbieter haben schon vor Jahren ihre eigenen proprietären Bluetooth-Mesh-Systeme entwickelt: geschlossene Ökosysteme, die unabhängig funktionieren und Funktionen bieten, die sich am tatsächlichen Marktbedarf orientieren. Daneben steht der offizielle Bluetooth-Mesh-Standard — vergleichsweise jung, normiert, aber im Funktionsumfang oft noch hinter dem zurück, was die etablierten proprietären Lösungen heute schon leisten.

Damit stehen Sie vor einer echten Wahl: Setzen Sie auf eine bestehende proprietäre Lösung, die genau die Funktionen mitbringt, die Ihr Markt jetzt verlangt, gehen schnell in Serie und bedienen diese Nachfrage? Oder entscheiden Sie sich für den Standard, nehmen in Kauf, dass er nicht alles abdeckt, was Sie brauchen, und setzen dafür auf langfristige Kompatibilität?

Klingt nach einem Entweder-oder. Aber stimmt das überhaupt?

Die eigentliche Frage lautet nämlich nicht, welcher Weg der richtige ist. Sondern: Gibt es noch andere Wege, mit dieser Entscheidung umzugehen — Kompromisse und hybride Ansätze, mit denen Sie das Beste aus beiden Welten bekommen, ohne sich die Nachteile beider einzuhandeln?

Wie alles begann: Die Geschichte von Bluetooth Mesh

Um zu verstehen, warum dieses Spannungsfeld überhaupt existiert, lohnt sich ein Blick auf seine Entstehung.

In den frühen Tagen entwickelten einige wenige Unternehmen ihre Bluetooth-Mesh-Protokolle unabhängig voneinander — jedes für sich ein komplett eigenständiges System. Casambi und MESHLE etwa wurden beide vor über zehn Jahren gegründet und bauten ihre eigenen proprietären Mesh-Stacks auf — zu einer Zeit, als es noch gar keine offizielle Bluetooth-Mesh-Spezifikation gab.

Casambi konzentrierte sich auf gewerbliche Beleuchtung und wurde dort zum First Mover. Der frühe Markteintritt und die breite Akzeptanz machten das Unternehmen zum dominierenden Player — für viele Lichtprofis ist der Name heute beinahe ein Synonym für drahtlose Mesh-Beleuchtung. Proprietär ist Casambi bis heute geblieben.

MESHLE schlug zunächst einen anderen Weg ein und fokussierte sich auf Smart-Home-Anwendungen, blieb dadurch im gewerblichen Lichtmarkt länger eher im Hintergrund. Genau dieser Fokus führte aber zu einem Funktionsumfang, der weit über die reine Lichtsteuerung hinausgeht: Schwarmlichtsteuerung, synchronisierte Farbanimationen (Mesh-Sync), motorisierte Rollladensteuerung mit Positionskalibrierung, Gastzugangsverwaltung, Heiz- und Temperatursteuerung sowie vielfältige Sensorintegrationen. Heute ist MESHLE ebenfalls im gewerblichen Lichtmarkt aktiv — und bringt diesen breiten Funktionsumfang gleich mit. Wie Casambi ist MESHLE im Kern proprietär geblieben — anders als Casambi kann MESHLE aber auch eine auf dem Bluetooth-SIG-Mesh-Standard basierende Alternative für Kunden bereitstellen, die sie benötigen.

Beide Unternehmen haben bewiesen, dass proprietäre Bluetooth-Mesh-Systeme erfolgreich sein können. Dann kam Silvair — mit einer anderen Strategie. Auch Silvair entwickelte eine eigene Mesh-Technologie, traf aber die strategische Entscheidung, sie in den Standardisierungsprozess einzubringen. Silvair wurde zu einem der führenden Mitwirkenden in der Mesh Working Group der Bluetooth SIG und baute das eigene Geschäft rund um den daraus entstandenen Standard auf — statt als rein proprietärer Anbieter zu konkurrieren.

So existieren heute drei unterschiedliche Wege im selben Markt nebeneinander: ein proprietärer First Mover mit enormer Marktdurchdringung, ein proprietärer Funktionsführer, der Smart Home und gewerbliche Beleuchtung verbindet, und ein Vorreiter der Standardisierung. Und damit sind wir beim ersten Dilemma: Entscheidet man sich für den Marktführer, weil die Verbreitung erprobt ist? Für den größten Funktionsumfang? Oder für die schmalste, aber „zukunftssicherste“ Variante — den Standard?

Was der Standard verspricht — und wo er an Grenzen stößt

Bluetooth Mesh — und die darauf aufbauenden Bluetooth-NLC-Profile (Networked Lighting Control) — ist wirklich gut durchdacht. NLC ist der erste durchgängige Standard für drahtlose Beleuchtung und deckt alles ab, von der Funkschicht bis hinauf zu den Geräteprofilen. Theoretisch sollte sich also jedes NLC-konforme Gerät beliebiger Hersteller in dasselbe Netzwerk einfügen.

Doch genau bei „theoretisch“ geht die Realität eigene Wege.

Die Grundlagen der Beleuchtung deckt der Standard solide ab: Dimmen, Farbtemperatur, Anwesenheitserkennung, tageslichtabhängige Steuerung, Energiemonitoring. Bewährte, belastbare Bausteine. Doch sobald ein Produktmanager mehr verlangt — Rollladen- und Jalousiesteuerung, mehrkanaliges RGB plus Tunable White, über viele Leuchten hinweg synchronisierte Lichteffekte, Gastzugangsverwaltung, Lichtsteuerung speziell für Horticulture —, spezifiziert der Standard das entweder noch gar nicht oder erst seit Kurzem. Die HVAC-Integration etwa fand erst vor Kurzem ihren Weg in die Bluetooth-NLC-Spezifikation. Wer vorher Beleuchtung mit der Klimatechnik koordinieren wollte, bewegte sich abseits des Standards.

Deckt der Standard nicht ab, was man braucht, bleiben zwei Möglichkeiten: auf die Standardisierung warten — was Jahre dauert und einen Konsens im Konsortium voraussetzt — oder selbst eigene Vendor-Modelle entwickeln. Und hier liegt der Haken: Ein solches Eigenmodell mag technisch innerhalb der Bluetooth-Mesh-Architektur leben, interoperabel ist es damit aber nicht mehr. Die eigene App muss es verstehen. Produkte anderer Hersteller wissen nicht automatisch, wie sie es ansteuern. Man hat damit faktisch eine proprietäre Erweiterung innerhalb eines Standardsystems gebaut.

Genau diese Lücke füllen proprietäre Systeme. Sie können Funktionen Monate oder Jahre früher ausliefern, als der Standard nachzieht — weil sie niemanden um Erlaubnis fragen müssen. Sie iterieren, liefern aus, sammeln Rückmeldungen, verbessern. Bis der Standard diese Funktionen formalisiert, ist die Marktnachfrage längst belegt — von den proprietären Anbietern.

Das Paradox proprietärer Systeme: Tempo gegen Lock-in

Proprietäre Systeme haben einen echten Vorteil: Sie sind schnell. Kein Konsensprozess, keine Arbeitsgruppen, kein Kompromiss zwischen mehreren Herstellern. Dieses Tempo zieht genau die Kunden an, die heute eine Lösung brauchen — und nicht irgendwann.

Die Geschichte des Marktes bestätigt das. Ein First Mover wie Casambi erreichte mit einem proprietären System breite Akzeptanz, weil es reale Probleme löste, bevor es überhaupt einen Standard gab — das ist keine Abschottung, das ist Markterfolg durch Tempo. MESHLE zeigt dasselbe Prinzip aus einer anderen Perspektive: Fähigkeiten wie die Schwarmlichtsteuerung oder die kalibrierte Rollladenpositionierung stehen heute in keinem Standard — und sind doch genau das, was bestimmte Projekte verlangen. Also greifen Unternehmen zur proprietären Lösung, die das liefert.

Doch proprietäre Systeme tragen ein Spannungsfeld in sich. Sobald man auf der Plattform eines Anbieters aufsetzt, werden die Wechselkosten real. Man hat in sein Ökosystem investiert, ist auf seine Werkzeuge geschult, hängt an seiner Roadmap. Das ist nicht böse Absicht — so funktionieren proprietäre Systeme nun einmal.

Weniger offensichtlich ist, dass sich standardbasierte Ökosysteme genauso verhalten können. Ein dokumentierter, reproduzierbarer Test zeigt es: Man nehme standardkonforme Bluetooth-Mesh-Firmware auf gängigen Chips wie dem Nordic nRF52840 oder dem ESP32. Provisioniert man diese Geräte mit Nordics offener App nRF Connect, treten sie dem Mesh-Netzwerk bei und funktionieren erwartungsgemäß, genau wie der Standard es verspricht. Versucht man nun, dieselben Geräte über die App von Silvair zu provisionieren, wird das Provisioning verweigert.

Dafür kann es legitime Gründe geben — Support-Umfang, Qualitätssicherung, Zertifizierungsanforderungen. Es spiegelt aber auch wider, wie die Geschäftsmodelle in der Bluetooth-Mesh-Welt typischerweise funktionieren: Da Bluetooth Mesh eine offline-first-Technologie ist, können Anbieter in der Regel nicht nachvollziehen, wie viele Geräte tatsächlich im Feld verbaut sind. Lizenziert wird deshalb meist im Voraus — pro Chip oder pro Firmware —, und das heißt: Der Anbieter muss von Anfang an wissen, welche Geräte „seine“ sind. Eine App, die beliebige Fremdhardware provisioniert, untergräbt dieses Modell — ob standardkonform oder nicht.

Die Lehre daraus: Standardkonformität auf Protokollebene verschafft einem nicht automatisch ein offenes Ökosystem auf Anwendungsebene. Womöglich muss man trotzdem seine eigene App, seine eigenen Inbetriebnahme-Werkzeuge, seine eigene Support-Infrastruktur aufbauen — also genau die Kosten tragen, die der Standard eigentlich ersparen sollte.

Offenheit hat mehrere Ebenen

An dieser Stelle schlagen viele Produktmanager den falschen Weg ein. Die Bewertung verengt sich allzu oft auf ein einziges Häkchen: Standard — ja oder nein? Wenn nein, kann es ja nur schlecht sein.

Doch Offenheit ist nicht schwarz oder weiß. Sie existiert auf verschiedenen Ebenen eines Systems:

Auf Funk- und Protokollebene kann ein System standardkonform oder proprietär sein. Auf Anwendungsebene können selbst Standardsysteme geschlossen sein, wie das Provisioning-Beispiel zeigt. Und auf Integrationsebene — Gateways und APIs — kann ein proprietäres System bemerkenswert offen sein.

Ein proprietärer Bluetooth-Mesh-Kern in Kombination mit einem Gateway, das Schnittstellen für BACnet™, REST, MQTT und Modbus bereitstellt, lässt sich in Gebäudeleittechnik, Monitoring-Plattformen und Drittanwendungen einbinden — über Protokolle, die seit Jahrzehnten offene Standards sind. Für viele Projekte ist genau das die Offenheit, auf die es wirklich ankommt: Kann mein BMS die Sensordaten lesen? Kann meine Facility-Software das Licht steuern? Sind meine Daten- und Steuerschnittstellen auch in zwanzig Jahren noch erreichbar?

Fragen Sie umgekehrt, was „Integration auf Bluetooth-Ebene“ für Ihr Unternehmen tatsächlich bedeuten würde. Eine eigene Mesh-Firmware entwickeln? Geräte verschiedener Hersteller mischen und darauf hoffen, dass jede benötigte Funktion von einem Standardmodell abgedeckt ist — obwohl man weiß, dass viele es nicht sind? In der Praxis würde man ohnehin eigene Modelle und bilaterale Absprachen schreiben und landet damit in einer quasi-proprietären Situation innerhalb einer Standardhülle.

Die richtige Frage lautet also nicht „Ist es ein Standard?“, sondern „Wo ist Offenheit für meinen Anwendungsfall entscheidend — und liefert mir dieser Anbieter sie genau dort?“

Der Kreislauf: Aus Innovation wird Standard

Hier zeigt sich ein historisches Muster, das man beim Namen nennen sollte: Standards entstehen selten aus dem Nichts. Neue Technologie beginnt proprietär, bewährt sich am Markt, gewinnt an Verbreitung — und wird dann standardisiert. Bluetooth Mesh selbst ging genau diesen Weg: Es entstand aus proprietärer Mesh-Arbeit, wobei Unternehmen wie Silvair ihre Technologie in den Standardisierungsprozess einbrachten.

Und der Standard nimmt weiter auf, was der Markt bereits validiert hat. Die kürzlich erfolgte Aufnahme der HVAC-Integration in Bluetooth NLC ist ein Paradebeispiel: eine Fähigkeit, die proprietäre Systeme zuerst boten und die nun formalisiert wurde, weil die Nachfrage erwiesen war. Schritt für Schritt schließt sich die Lücke — ganz geschlossen ist sie aber noch nicht.

Das rückt die Debatte „proprietär gegen Standard“ in ein neues Licht. Proprietär ist nicht das Gegenteil von Standardisierung — es ist oft deren Vorstufe. Die Funktionen, die proprietäre Anbieter heute ausliefern — fortgeschrittene Rollladensteuerung, synchronisierte Effekte, Horticulture-Lichtprofile, fein abgestufte Gastzugänge —, sind die Kandidaten für den Standard von morgen. Anbieter, die diesen Kreislauf verstehen, positionieren sich nicht gegen den Standard. Sie bauen, was der Markt jetzt braucht, bleiben kompatibel, wo es zählt, und bereiten sich darauf vor, beizutragen und mit dem reifenden Standard zusammenzuwachsen.

Das bedeutet zugleich: Die heutige Fragmentierung ist höchstwahrscheinlich ein Übergangszustand, kein Dauerzustand. Die spannende Frage für einen Einkäufer ist, welche Anbieter aufgestellt sind, diesen Übergang zu überstehen — und welche alles darauf verwetten, dass er ausbleibt.

Wie treffen Sie nun die Entscheidung?

Lässt man die Ideologie beiseite, läuft die Entscheidung auf eine Handvoll konkreter Fragen hinaus:

„Welche Funktionen brauchen Sie — heute?“ Wenn eine einfache Lichtsteuerung Ihren Anwendungsfall abdeckt und Sie mit dem aktuellen NLC-Umfang auskommen, ist der Standard eine sichere, vernünftige Wahl. Verlangt Ihr Produkt oder Projekt mehr, bewegen Sie sich abseits des Standards — ganz gleich, welchen Weg Sie wählen. Also nehmen Sie den Weg, auf dem diese Funktionen bereits existieren und im Feld erprobt sind.

„Wo ist Offenheit für Sie entscheidend?“ Interoperabilität auf Protokollebene klingt verlockend, doch für die meisten Projekte entscheidet die Offenheit auf Integrationsebene — BACnet™, REST, MQTT, Modbus am Gateway — darüber, ob Ihre Installation in zehn oder zwanzig Jahren noch beherrschbar ist.

„Wie positioniert sich der Anbieter zum Standard?“ Ein Anbieter, der Standardisierung rundweg ablehnt, wettet gegen den historischen Kreislauf. Ein Anbieter, der rein an den Standard gebunden ist, bleibt vom Tempo des Konsortiums abhängig. Nach beiden Seiten abgesichert sind Anbieter mit hybrider Strategie — proprietäre Funktionen heute, Standardunterstützung dort, wo sie gefragt ist, durchgängig offene Integrationsebenen. Genau hier steht MESHLE: Unser funktionsreiches proprietäres Protokoll ist die Kernplattform, und wo ein Projekt den offenen Standard verlangt, können wir über unsere Partnerhersteller eine auf dem Bluetooth-SIG-Mesh-Standard basierende Alternative bereitstellen. Unseren Ansatz haben wir ausführlich auf einer eigenen Seite zu unserer Unterstützung des Bluetooth-SIG-Mesh-Standards dargelegt.

„Wie sieht das Lizenzmodell aus?“ Eine Lizenzierung im Voraus pro Chip ist im offline-first-Bereich von Bluetooth Mesh die Regel. Verstehen Sie genau, worauf Sie sich festlegen, bevor es fest in Ihrer Stückliste verankert ist.

Eine universell richtige Antwort gibt es nicht. Casambis Verbreitung beweist, dass proprietäre Systeme Märkte gewinnen können. Silvairs Rolle beweist, dass Standards Bestand haben. Die Funktionsbreite von MESHLE beweist, dass es einen dritten Weg gibt. Ihre Aufgabe ist es nicht, die „korrekte“ Ideologie zu wählen — sondern das Modell an die tatsächlichen Anforderungen und die Lebensdauer Ihres Produkts anzupassen.

Häufige Fragen

Was passiert, wenn es meinen Anbieter in ein paar Jahren nicht mehr gibt?

Bei einem rein proprietären System ist eine eingestellte Plattform ein reales Risiko. Bei einem standardbasierten System hat man theoretisch Ersatzhardware anderer Hersteller zur Hand — doch wenn man für Funktionen, die der Standard nicht abdeckt, auf eigene Modelle gesetzt hat, lassen sich auch diese nicht übertragen. Der praktischste Schutz ist Offenheit auf Integrationsebene: Stellt Ihr Anbieter am Gateway BACnet™, REST, MQTT oder Modbus bereit, bleiben Ihre Gebäudesysteme, Daten und Steuerlogik selbst im schlimmsten Fall erreichbar und migrierbar.

Kann ich später von einem proprietären System auf den Standard wechseln — oder umgekehrt?

Nicht nahtlos. Mesh-Netzwerke werden pro System in Betrieb genommen; Firmware, Steuermodelle und Apps unterscheiden sich. Eine Migration bedeutet in der Regel, die Hardware neu in Betrieb zu nehmen und die Konfigurationen neu aufzubauen. Einige Anbieter arbeiten an hybriden Ansätzen, die ihren proprietären Stack und Standard-Bluetooth-Mesh auf derselben Hardware unterstützen — das kann den Wechsel abmildern. Ansprechen sollte man das aber bereits im allerersten Gespräch mit einem Anbieter, nicht erst nach dem Rollout.

Reicht der Bluetooth-Mesh-Standard für mein Projekt „aus“?

Für die Kernfunktionen gewerblicher Beleuchtung — Dimmen, Anwesenheit, tageslichtabhängige Steuerung, Energiemonitoring — zunehmend ja, und NLC wird weiter ausgebaut (die HVAC-Integration ist eine der jüngsten Ergänzungen). Für alles darüber hinaus — Rollläden, mehrkanalige Farbe, synchronisierte Effekte, Horticulture-Steuerung, Gastverwaltung — prüft man die Spezifikation am besten genau. Übersteigen die Anforderungen sie, braucht man ohnehin eigene Modelle oder eine proprietäre Plattform.

Was ist der reale Unterschied zwischen „proprietär mit offenen APIs“ und „Standard mit eigenen Modellen“?

Geringer, als man denkt. Beide liefern Funktionen, die der Standard nicht abdeckt, und beide erzeugen eine gewisse Anbieterabhängigkeit. Die praktischen Unterschiede liegen im Tempo (proprietär liefert schneller) und darin, wo die Offenheit angesiedelt ist (Gateway-APIs gegenüber teilweiser Protokoll-Interoperabilität). Bewerten sollte man beides an den tatsächlichen Integrationsanforderungen — nicht am Etikett.

Garantiert mir die Wahl des Standards, dass meine Geräte in jeder standardkonformen App funktionieren?

Nein — und das überrascht viele Teams. Standardkonforme Firmware lässt sich mit offenen Werkzeugen wie Nordics nRF Connect verifizieren, doch die Apps einzelner Anbieter verweigern womöglich trotzdem das Provisioning von Fremdhardware — aus geschäftlichen oder Support-Gründen. Protokollkonformität und Ökosystem-Zugang sind zwei verschiedene Dinge; prüfen sollte man Letzteren ausdrücklich.

Weiterlesen

Wir sind MESHLE, und dieser Artikel ist aus den Fragen entstanden, die Produktmanager uns täglich stellen. Wir geben uns nicht als neutraler Beobachter aus — aber wir reden ehrlich mit Ihnen. Wir glauben an offene Standards, ohne daraus eine Ideologie zu machen, und wir sind lieber der Partner, der sowohl den proprietären als auch den standardbasierten Weg bedienen kann, als Sie in ein Entweder-oder zu drängen. Das heißt: die Funktionsbreite unseres proprietären Protokolls als Kernplattform und dazu eine auf dem Bluetooth-SIG-Mesh-Standard basierende Alternative für die Projekte, die sie verlangen — damit Ihre Wahl nicht proprietär gegen Standard lautet, sondern: was zu Ihrem Produkt passt, jetzt und während der Standard reift.

Sprechen Sie mit unserem Team