DE102022210455A1

DE102022210455A1 - System zur beleuchtungssteuerung

Info

Publication number: DE102022210455A1
Application number: DE102022210455.2A
Authority: DE
Inventors: Arnulf Rupp
Original assignee: Inventronics GmbH
Current assignee: Inventronics De GmbH
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2024-04-04
Also published as: WO2024068673A1

Abstract

Ein System (1) zur Beleuchtungssteuerung umfasst wenigstens ein Eingabegerät (2), das dazu eingerichtet ist, dem System zur Beleuchtungssteuerung eine vom Nutzer bereitgestellte, eine Status- und/oder eine Umgebungsinformation in Erwiderung auf einen Abfragebefehl (10a) zu übermitteln, und/oder wenigstens ein Betriebsgerät (3), das dazu eingerichtet ist, einer oder mehreren Lichtquellen Leistung zuzuführen und dem System zur Beleuchtungssteuerung Statusinformationen in Erwiderung auf einen Abfragebefehl (10a) zu übermitteln. Ferner umfasst es ein Anwendungssteuergerät (4), das eingerichtet ist, die vom Nutzer bereitgestellten, Status- und/oder Umgebungsinformationen zu empfangen, und dazu eingerichtet ist, einen Abfragebefehl (10a) auszugeben, um die Information zu erhalten, oder diesen abhängig von der Information auszugeben. Ferner ist eine Reverse Bridge (5) bereitgestellt, die dazu eingerichtet ist, mit dem Anwendungssteuergerät (4) über einen drahtgebundenen Netzwerkbus (6) zu kommunizieren, der unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird, das mit IEC 62386-101 übereinstimmen kann. Die Reverse Bridge ist ferner dazu eingerichtet ist, mit dem wenigstens einen Eingabe- (2) und/oder Betriebsgerät (3) über ein Netzwerk (7) zu kommunizieren, das unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird und mit IEC 62386-104 übereinstimmen kann. Die Reverse Bridge (5) ist zur bidirektionalen Kommunikation zwischen dem Anwendungssteuergerät (4) und dem wenigstens einen Eingabe- (2) und/oder Betriebsgerät (3) eingerichtet.

Description

Technisches Gebiet
Verschiedene Aspekte und Ausführungsbeispiele betreffen ein System zur Beleuchtungssteuerung, das ein Netzwerk einschließt, mit welchem die von einem Anwendungssteuergerät gesteuerten Eingabe- und Betriebsgeräte verbunden sind. Solche Aspekte und Ausführungsbeispiele beziehen sich insbesondere auf ein System zur Beleuchtungssteuerung, das einen drahtgebundenen Netzwerkbus aufweist und durch einen asynchron betrieben Netzwerkteil vermittels einer Bridge (deutsch eigentlich: Brücke - hier wird der in der Fachsprache allgemein verwendete englische Begriff verwendet) erweitert ist, die die mit dem asynchron betriebenen Netzwerkteil in Zusammenhang stehenden Eingabe- und Betriebsgeräte mit dem drahtgebundenen Netzwerkbus verbindet, an welchem das Anwendungssteuergerät angeordnet ist. Bei diesem Aufbau wird die Bridge als Reverse Bridge bezeichnet.
Technischer Hintergrund
Im Bereich der Gebäudeautomation werden digitale Bussysteme zunehmend verwendet, beispielsweise um eine große Anzahl von Beleuchtungssystemen, die Leuchten und Sensoren umfassen, zentral oder dezentral zu steuern. Einen entsprechenden Standard bietet beispielsweise ein Protokoll, das als DALI (DALI: „Digital Addressable Lighting Interface“) bezeichnet wird. Dieses Protokoll ist u.a. in der IEC-Normenfamilie IEC 62386 definiert. Es basiert auf dem früheren DSI-Standard (Digital Signal Interface) und schließt die Lücke zwischen herkömmlichen analogen 1-10-V-Schnittstellen und komplexen digitalen Bussystemen wie KNX/EIB (European Installation Bus) oder LON (Local Operating Network) etc., die über die Beleuchtung hinaus auch die Vernetzung und Steuerung anderer Haushaltsgeräte umfassen.
Mit dem Kommunikationsstandard IEC 62386 („DALI“) (Weiterentwicklungen und Erweiterungen werden nach aktuellem Stand weiter diskutiert) können jeweils bis zu maximal 64 Betriebsgeräte (engl. control gear devices) für die Beleuchtung und Eingabegeräte über entsprechende Schnittstellen an den Bus angeschlossen werden, die von einem oder mehreren Anwendungssteuergeräten (engl. application controller) gesteuert oder überwacht werden. Solche Anwendungssteuergeräte dienen als Master im DALI-Netzwerk und sind als Entscheidungsinstanz ausgelegt. Eine größere Anzahl beteiligter Betriebs- oder Eingabegeräte kann durch die Einrichtung von DALI-Gateways erfolgen, die benachbarte Steuernetzwerke verbinden. Bei den Betriebsgeräten kann es sich um elektronische Vorschaltgeräte und insbesondere um LED-Treiber, Dimmer oder Aktoren handeln. Bei den Eingabegeräten kann es sich um Sensoren, Schalter oder andere Bedienelemente usw. handeln. Die jeweiligen Schnittstellen können einen Controller und einen Speicher umfassen, in dem Parameter wie bis zu 16 programmierte Szenenwerte oder bis zu 16 Gruppenadressen (unter denen Nummern von Steuer- und Eingabegeräten gruppiert sind) gespeichert sind. Jede Schnittstelle wird einzeln adressiert. Der Bus verfügt über eine 2-Draht-Leitung, über die alle Betriebs- und Eingabegeräte im bidirektionalen Datenaustausch grundsätzlich das gleiche Signal empfangen, wobei nur das im Signal-Frame (dt. eigentlich „Rahmen“, auch hier wird der allg. im Fachgebiet verwendete englische Begriff verwendet) adressierte Betriebsgerät (z.B. LED-Treiber) oder Eingabegerät für den Empfang und die Verarbeitung des Signals konfiguriert ist, es sei denn, das System zur Beleuchtungssteuerung arbeitet im sogenannten Broadcast-Modus.
Der DALI-Kommunikationsstandard sieht vor, dass der Bus mit etwa 16 Volt Gleichspannung versorgt wird. Der Bus ist sowohl eine Signalleitung als auch - wenn auch in geringerem Maße - eine Stromversorgungsleitung. Die Signale werden von einer übertragenden Schnittstelle durch gepulste Kurzschlüsse zwischen den beiden Adern erzeugt. Die jeweilige Folge von Spannungsabfällen von 16 Volt auf 0 Volt wird von den anderen am DALI-Bus angeschlossenen Schnittstellen erkannt und ausgewertet. Der Standard erlaubt die Einhaltung bestimmter Toleranzbereiche der Spannungswerte sowohl für das sendende als auch für das empfangende Gerät. Die übertragenen Informationen werden in Transaktionen zusammengefasst, die jeweils aus einem oder mehreren Befehls-Frames bestehen können.
Nach dem derzeitigen DALI-Standard können Signale mit einer Rate von 1.200 Bit pro Sekunde übertragen werden, was 833,3 µs für ein Bit entspricht. Ein Toleranzbereich von ± 10 % ist allgemein akzeptiert. Befehle oder Abfragen, die von einem Anwendungssteuergerät oder einem anderen Betriebsgerät erteilt und übertragen werden, sind vorwärts gerichtete Frames mit einer Nutzdatenlänge von 16, 24 oder 32 Bit. Es wird von dem empfangenden Gerät (z. B. ein Betriebsgerät oder ein Eingabegerät) erwarte, eine Antwort auf den Befehl oder die Abfrage in Form eines rückwärts gerichteten Frames mit einer Nutzdatenlänge von 8 Bit auszugeben und zu senden. Dabei werden jeweils ein führendes Startbit und eine vorgegebene Anzahl von abschließenden Stoppbits hinzugefügt. Eine Antwort ist zeitlich begrenzt nach Ablauf des letzten Stoppbits des Vorwärts-Frames zu auszugeben und zu übertragen: Das Startbit des Rückwärts-Frames muss innerhalb einer Zeitspanne von 5,5 ms bis 10,5 ms nach jenem Ablauf ausgegeben werden. Ein neuer Vorwärts-Frame darf erst nach Ablauf von 10,5 ms ausgegeben werden.
Die obigen Definitionen machen den drahtgebundenen DALI-Bus zu einem Netzwerk, das im Halbduplex-Modus mit synchroner Datenübertragung betrieben wird. Dies gilt jedoch nur für DALI-Netzwerke, wie sie in IEC 62386 Teil 101 (System), IEC 62386 Teil 102 (Betriebsgeräte) und IEC 62386 Teil 103 (Eingabegeräte) beschrieben sind.
In der vorliegenden Beschreibung wird ein Netzwerk, das unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird, im Allgemeinen durch eine Kommunikation zwischen Geräten definiert, bei der eine Antwort eines Geräts auf eine von einem anderen Gerät ausgegebene Benachrichtigung (Befehl) in einer zeitlich begrenzten Weise erwartet wird und von keinem weiteren Gerät, das die Kommunikation abhört, erwartet wird, dass es innerhalb dieser reservierten Zeitspanne eine weitere Benachrichtigung auf demselben Medium (verdrahteter Bus) ausgibt. Die Norm IEC 62386 Teil 101 entspricht dieser Definition. Im Gegensatz dazu ist ein Netzwerk, das mit einem asynchronen Netzwerkprotokoll betrieben wird, definiert, um das Problem zu lösen, eine auf eine Benachrichtigung (Befehl) hin gesendete Antwort mit dieser Benachrichtigung auf andere Weise zu verknüpfen (z. B. durch Anhängen weiterer Adressen, Tags usw. an das gesendete Paket). IP-basierte Protokolle können im Allgemeinen asynchron sein.
In jüngerer Zeit wurden DALI+-Netzwerke in der Norm IEC 62386 Teil 104 (Allgemeine Anforderungen - Drahtlose und alternative drahtgebundene Systemkomponenten) eingeführt. Hierbei kommunizieren DALI+-Geräte (Anwendungssteuergeräte, Betriebsgeräte und Eingabegeräte) miteinander unter Verwendung bestehender DALI-Transaktions-, Befehls- und Antwortsätze wie oben beschrieben. Diese werden jedoch über ein drahtloses und/oder IP-basiertes Medium übertragen und nicht über ein dediziertes Kabelpaar, wie es von DALI-Netzwerken verwendet wird (oder DALI-2, das ein Zertifizierungsprogramm für die beteiligten Geräte vorsieht; oder D4i, eine Erweiterung von DALI-2, bei der LED-Treiber mit einem obligatorischen Satz von Merkmalen in Bezug auf Stromversorgungsanforderungen und Smart-Data-Fähigkeiten ausgestattet sind). Darüber hinaus können Bridges implementiert werden, um Geräte in konventionellen, drahtgebundenen DALI-Netzen mit dem/den Anwendungssteuergerät(en) im drahtlosen und/oder IP-basierten DALI+-Netz zu verbinden (im Folgenden auch als „Teil-104-Netz“ bezeichnet, im Gegensatz zum konventionellen „Teil-101-Netz“). Da es sich um ein drahtloses und/oder IP-basiertes Protokoll handelt, erfolgt die Datenübertragung im Teil-104-Netzwerk asynchron.
Wie bereits erwähnt, sieht die Norm IEC 62386 Teil 104 die Möglichkeit vor, dass ein Anwendungssteuergerät im Teil-104-Netz angeordnet ist und Betriebsgeräte oder Eingabegeräte im herkömmlichen Teil-101-Netz ansprechen kann. Eine so genannte Reverse-Bridge, d. h. eine Bridge, die so eingerichtet ist, dass sie die von einem Anwendungssteuergerät im Teil-101-Netz ausgehende Kommunikation in das Teil-104-Netz übersetzt, wird zwar erwähnt, aber darin als „außerhalb des Anwendungsbereichs“ der Norm liegend betrachtet.
Es hat sich jedoch gezeigt, dass es möglich ist, herkömmliche DALI-Bussysteme mit drahtloser Kommunikation über Anwendungs-Gateways zu kombinieren, die zwischen DALI und dem jeweiligen drahtlosen Netzwerkprotokoll der Wahl übersetzen. Allerdings gibt es dafür noch keinen Standard. Daraus ergibt sich die Schwierigkeit, Geräte von verschiedenen Herstellern zu implementieren.
Darüber hinaus verwenden bestehende Implementierungen, in denen ein auf Teil-101 basierendes Anwendungssteuergerät mit DALI-Geräten in einem auf Teil-104 basierenden Netzwerk verbunden ist, regelmäßig eine Simulation von DALI-Geräten in einem entsprechenden DALI-Gateway. Genauer gesagt werden die Steuergeräte wie etwa Betriebsgeräte (z. B. LED-Treiber) vom Gateway nur simuliert, um auf Anfragen (oder Befehle) innerhalb des oben genannten begrenzten Zeitrahmens zu reagieren, der durch die DALI-Teil-1 01 -Spezifikation vorgegeben ist - unter Verwendung ihrer aktuellen simulierten Zustandsinformationen. Die Zustandsinformationen selbst werden im DALI-Gateway asynchron über das Gerät im asynchron betriebenen Netzwerk als Datenquelle ständig aktualisiert. Es erfolgt jedoch keine direkte Rückmeldung vom jeweiligen part 104-basierten Steuergerät an das Teil-101-basierte Anwendungssteuergerät.
Ein Beispiel für ein DALI-Gateway mit ähnlichen Eigenschaften ist der Bluetooth-steuerbare DALI-Controller CBU-DCS von Casambi Technologies Oy, Espoo, Finnland (Datenblatt „CBU-DCS Bluetooth controllable DALI controller“, September 2021, heruntergeladen von
https://f.hubspotusercontent40.net/hubfs/7177595/Data%20sheets/English/CBU_DCS_Data-Sheet_EU_EN_2_0_24092021.pdf
am 28. September 2022). Der CBU-DCS kann mit kabelgebundenen DALI-Controllern verbunden werden und fungiert als drahtloses DALI-Gateway in einem Casambi-Netzwerk, entweder im DALI-Broadcast-Modus oder zur Steuerung einzelner adressierter DALI-Geräte.
Die Druckschrift DE 10 2018 202 965 A1 offenbart ein System zur Beleuchtungssteuerung, bei dem eine Zentraleinheit über einen DALI-Bus mit Steuergeräten (Betriebsgeräten) kommuniziert. Jedes der Steuergeräte verfügt sowohl über eine DALI-Schnittstelle („DALI-Controller“) als auch über eine Bluetooth-Schnittstelle. Ein mobiles Gerät kommuniziert über Bluetooth mit jedem der Steuergeräte, um auf einen Speicher der Steuergeräte zuzugreifen. Eine cloudbasierte Zentraleinheit kommuniziert mit den Steuergeräten entweder über das mobile Gerät (Bluetooth) oder über den DALI-Bus.
In Anbetracht des oben erläuterten Netzwerksaufaus muss eine Reverse Bridge, die auf der Simulation von Statusinformationen basiert, anstatt die Informationen zeitlich zu übersetzen und weiterzuleiten, genaue Kenntnisse über das zu simulierende Gerät haben. Wie bereits erwähnt, treten Probleme auf, wenn das tatsächliche Gerät von einem anderen Hersteller stammt und wenn der kontinuierliche Aktualisierungsprozess des simulierten Geräts Diskrepanzen aufweist, die nicht mit dem tatsächlichen Gerät synchronisiert sind. Insbesondere der Umgang mit plötzlichen Fehlern, die auf der Seite des betroffenen Geräts auftreten, muss sorgfältig behandelt werden.
Darstellung der Erfindung
Es ist daher eine Aufgabe, ein System zur Beleuchtungssteuerung bereitzustellen, das aus einem drahtgebundenen Busnetzwerk, das mit synchronem Datentransfer betrieben wird, und einem asynchron betriebenen Netzwerk, das mit asynchronem Datentransfer betrieben wird, besteht, wobei beide Netzwerke unter Verwendung einer Reverse Bridge kommunizieren, wobei ein Anwendungssteuergerät auf der Seite des synchronen Busnetzwerks vorgesehen ist, wobei das System zur Beleuchtungssteuerung solche sogenannten Out-of-Sync-Situationen vermeidet und wobei die Reverse Bridge nicht kontinuierlich Statusinformationen der Geräte auf der Seite des asynchron betriebenen Netzwerks sammeln und speichern muss.
Eine weitere Aufgabe besteht darin, die Flexibilität solcher kombinierten Netzwerke zu erhöhen, indem Geräte verschiedener Hersteller unabhängig vom Typ der Reverse Bridge integriert werden können. Eine weitere Aufgabe ist es, die Integration von IP-basierten DALI+-Netzwerken in bestehende konventionelle DALI-Teil-101 -Netzwerke zu ermöglichen.
Verschiedene Aspekte und Ausführungsbeispiele gehen von einem System zur Beleuchtungssteuerung aus, das mindestens ein Eingabegerät, das so konfiguriert ist, dass es dem System zur Beleuchtungssteuerung als Reaktion auf einen Abfragebefehl oder eine Ereignismeldung vom Benutzer abgeleitete, Status- und/oder Umgebungsinformationen übermittelt, und/oder ein Betriebsgerät umfasst, das so konfiguriert ist, dass es eine oder mehrere Lichtquellen mit Strom versorgt und dem System zur Beleuchtungssteuerung als Reaktion auf einen Abfragebefehl Statusinformationen liefert. Im Allgemeinen sind beide Typen von Geräten in einem System zur Beleuchtungssteuerung präsent. Das System zur Beleuchtungssteuerung weist ferner ein Anwendungssteuergerät auf, das eingerichtet ist, die vom Benutzer ermittelten und/oder die Umgebung betreffenden Informationen oder die Statusinformationen zu empfangen, und eingerichtet ist, einen Abfragebefehl zu auszugeben oder Ereignismeldungen zu empfangen, um die Informationen zu erhalten, oder in Abhängigkeit von den erhaltenen Informationen auszugeben und zu empfangen.
Des Weiteren ist eine Reverse Bridge bereitgestellt, die eingerichtet ist, mit dem Anwendungssteuergerät über einen drahtgebundenen Netzwerkbus zu kommunizieren, der unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird, und die eingerichtet ist mit dem wenigstens einen Eingabegerät und/oder Betriebsgerät über ein Netzwerk zu kommunizieren, das unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird. Das solchermaßen bereitgestellte System zur Beleuchtungssteuerung ist mit einen erweitertes und mit IEC 62386 (DALI) Teil-104 kombiniertes IEC 62386 (DALI) Teil-101 Netzwerk kompatibel, die beide über die Reverse Bridge verbunden sind, die zwischen einem asynchronen Netzwerkprotokoll und einem synchronen Netzwerkprotokoll übersetzt und vermittelt. Jedoch sind die Aspekte und Ausführungsbeispiele nicht notwendig auf DALI-Anwendungen beschränkt, und das hierin vorgeschlagene System zur Beleuchtungssteuerung kann ebenso kompatibel mit anderen Standards oder proprietären Protokollen sein.
Bei dem vorerwähnten System zur Beleuchtungssteuerung ist die Reverse Bridge für die vollständige bidirektionale Kommunikation zwischen dem Anwendungssteuergerät und dem wenigstens einen Eingabegerät und/oder Betriebsgerät eingerichtet. Dies bedeutet, dass Befehle oder Abfragen („Abfragebefehle“, die eine Antwort erwarten), die von dem Anwendungssteuergerät auf der Seite des drahtgebundenen Netzwerks ausgegeben werden, durch die Reverse Bridge hindurch geführt und zum Eingabe- oder Betriebsgerät weitergeleitet werden, wo dann eine Antwort vorbereitet und zurück zur Reverse Bridge übermittelt wird.
Die Reverse Bridge braucht nicht Statusinformationen zu sammeln und zu speichern, nur um von jedem Gerät auf der Seite des asnychron betriebenen Netzwerks eine aktualisierte Statusliste zu erhalten. Die Reverse Bridge kann vielmehr einfach die Informationen empfangen und verarbeiten, die sie mit der Antwort empfangen hat, um diese an das Anwendungssteuergerät über den drahtgebundenen Netzwerkbus weiterzuleiten. Verschiedene Alternativen können als weitergehende Ausführungsbeispiele implementiert werden, um die erforderliche Übersetzung in das zeitgebundene Antwortschema des synchron betriebenen Netzwerks mit verdrahtetem Bus zu erzielen, oder im Fall von DALI: des Teil-1 01 -basierten Netzwerks.
Als eine Konsequenz der vollständig bidirektionalen Kommunikation ist die Reverse Bridge davon entlastet, Simulationsmittel bereitzustellen. Somit können etwaig mögliche Inkonsistenzen zwischen den Statusinformationen, die von der Reverse Bridge an das Anwendungssteuergerät geliefert werden, und den aktuellen Informationen entsprechend den tatsächlichen Eingabe- oder Betriebsgeräten wirksam vermieden werden. Dadurch wird die Stabilität und Zuverlässigkeit des Systems zur Beleuchtungssteuerung erhöht.
Außerdem kann aufgrund der Entlastung der Reverse Bridge von den Aufgaben einer Simulation das Anwendungssteuergerät einfacher aufgebaut sein. Es ist keine Steuerung oder Handhabung einer komplexen Datenbankstruktur notwendig, und es brauchen keine Abfrageaufgaben durch die Bridge mehr implementiert zu werden, um neue oder laufende Statusinformationen zu erhalten. Infolgedessen sind die Anforderungen an die interne Steuerung der Reverse Bridge deutlich relaxiert und Speicherplatz kann eingespart werden. Außerdem brauchen die asynchron betriebenen Netzwerk-(DALI+)-Geräte nicht wiederholt mit der Aufgabe befasst sein, Statusinformationen bereitzustellen, die über die Erfordernisse des jeweils verwendeten Netzwerkprotokolls, wie etwa DALI, hinausgehen.
Während des Weiteren die Reverse Bridge aus Sicht des Anwendungssteuergeräts transparent wird, wenn sie die Informationen von den Eingabe- und Steuergeräten (Betriebsgeräten) einfach durchleitet, werden die Anforderungen an diese Eingabe- und Steuergeräte ebenfalls weiter relaxiert, so dass basierend auf einem einheitlichen Standard wie etwa DALI die Geräte verschiedener Hersteller in einem kombinierten Netzwerk implementiert werden können.
Gemäß einem besonders vorteilhaften alternativen Aspekt ist die Reverse Bridge so konfiguriert, dass sie einen Vorwärts-Transaktions-Frame, der mit dem von dem Anwendungssteuergerät empfangenen Abfragebefehl verknüpft ist, an das Eingabegerät und/oder Betriebsgerät übermittelt.
Die Reverse Bridge ist ferner so konfiguriert, dass sie an das Anwendungssteuergerät einen Befehl ausgibt, der mit einem entsprechenden Antwort-Frame verbunden ist, den sie von der Eingabevorrichtung und/oder dem Betriebsgerät als Reaktion auf den Vorwärts-Transaktions-Frame empfangen hat. Hierbei ist es das Ziel eines solchen Befehls, wirksam Antwortwerte auf eine Abfrage hin dann zu liefern, wenn die Antwort von der Seite des asynchron betriebenen Netzwerks (im Fall von DALI die Teil-104-Seite) tatsächlich vorliegt.
Folglich kann, wenn z.B. ein DALI-Netzwerk betroffen ist, die Bridge übereinstimmend mit dem Standardprotokoll ihren eigenen Befehl initiieren - anstelle einer Antwort auf den ersten Befehl des Anwendungssteuergerät - um die von dem Anwendungssteuergerät benötigte Information zu übermitteln. Einem Ausführungsbeispiel zufolge ist die Reverse Bridge eingerichtet, den als Vorwärts-Frame ausgebildeten Befehl auszugeben und darin die Antwort als Nutzdaten des Befehls aufzunehmen. Hierbei kann entweder ein neuer Typ von Befehls-Frame verwendet werden, beispielsweise ein Frame mit verschiedenen Bitlängen im Vergleich zu den gegenwärtig festgelegten Befehlen oder Vorwärts-Frames, oder ein existierender (DALI-)Befehl (mit z.B. 24 Bits) wird wiederverwendet, um die Antwortinformationen zu liefern.
Gemäß einem alternativen vorteilhaften Aspekt kann die Reverse Bridge so konfiguriert sein, dass sie einen Vorwärts-Transaktions-Frame, der mit dem von dem Anwendungssteuergerät empfangenen Abfragebefehl verbunden ist, zu dem Eingabe- und/oder Betriebsgerät transportiert, ähnlich wie bei dem obigen Aspekt. Abweichend von dem obigen Aspekt ist die Reverse Bridge jedoch weiterhin dazu eingerichtet, als Reaktion auf den Vorwärts-Transaktions-Frame eine mit einem entsprechenden von dem Eingabe- und/oder Betriebsgerät empfangenen Antwort-Frame verbundene Antwort zu dem Anwendungssteuergerät zu transportieren. Hierbei ergibt sich der Vorteil, dass die Antwort des Eingabe- bzw. des Betriebsgeräts wieder in eine Antwort umgewandelt wird. In einer weiteren Ausführungsform kann, etwa im Fall von DALI, daher der Transaktionstyp gleichbleiben.
Hierbei kann, gemäß einem Ausführungsbeispiel, mit dem Ziel, die begrenzte Zeitspanne des synchron betriebenen, drahtgebundenen Netzwerkbusses einzuhalten, die Reverse Bridge einen weiteren nachfolgenden Befehl, der von dem Anwendungssteuergerät ausgegeben wird, abwarten, um die Bereitstellung der Antwort innerhalb der vorgegebenen (z.B. DALI-) Zeitspanne zu ermöglichen (bei synchronem Datentransfer auf dem drahtgebundenen Netzwerkbus). Das Anwendungssteuergerät kann optional so eingerichtet werden, dass es die Reverse Bridge abfragt, bis die gewünschte Antwort gesendet wird. Der (die) wiederholte(n) Befehl(e), der (die) vom Anwendungssteuergerät an die Reverse Bridge gesendet wird (werden), kann (können) Zähler (engl. Counter) und/oder Flags enthalten, die sich auf den ursprünglichen ersten Befehl beziehen und es der Reverse Bridge ermöglichen, den richtigen Befehl zu identifizieren, auf den sie antworten soll. Dementsprechend kann das Anwendungssteuergerät so konfiguriert sein, dass es einen zweiten Befehl ausgibt, der auf den zuvor ausgegebenen ersten Befehl folgt, und die Reverse Bridge kann so konfiguriert sein, dass sie die Antwort als Reaktion auf den vom Anwendungssteuergerät ausgegebenen zweiten Befehl übermittelt.
Darüber hinaus kann die von der Reverse Bridge transportierte Antwort, wie oben angegeben, im Wesentlichen identisch sein mit dem von der Reverse Bridge von dem Eingabe- und/oder Betriebsgerät empfangenen Rückwärts-Antwort-Frame.
In einem weiteren Ausführungsbeispiel, die sich auf diesen Aspekt bezieht, kann die Reverse Bridge einen als sog. Memory Page ausgebildeten Speicher umfassen, in dem die Antwort vorübergehend gespeichert wird, wenn sie ausgehend von dem Eingabegerät und/oder dem Betriebsgerät empfangen wird. Die Reverse Bridge kann dabei weiter so konfiguriert sein, dass sie die Antwort aus der Memory Page ausliest, wenn sie den zweiten Befehl von dem Anwendungssteuergerät über den drahtgebundenen Netzwerkbus empfängt. Die Reverse Bridge kann dann den zuvor empfangenen und gespeicherten Antwort-Frame als Antwort an das Anwendungssteuergerät übermitteln. Anders als bei dem oben mit Bezug auf den Stand der Technik beschriebenen Speichermanagement, bei welchem die Statusinformationen für alle Teil-104-seitigen Geräte in dem DALI-Gateway-Datenbankspeicher gehalten werden, wird hier vorübergehend nur die bloße Antwort gespeichert, bis der zweite Befehl ausgegeben wird. Die gespeicherte Information wird dann nicht länger benötigt. Die Reverse Bridge verbleibt somit passiv und braucht sich nicht mit dem Aktualisieren von Informationen zu befassen.
Gemäß einem weiteren Aspekt des Systems zur Beleuchtungssteuerung weist die Reverse Bridge einen Speicher ähnlich wie in den vorher beschriebenen Aspekt auf, wobei dieser nun eingerichtet ist, Informationen zur Inbetriebnahme eines neuen Eingabegeräts und/oder eines neuen Betriebsgeräts in dem Speicher zu speichern, das in das System zur Beleuchtungssteuerung zu integrieren ist. Das Anwendungssteuergerät ist ferner dazu eingerichtet, über die Reverse Bridge eine Inbetriebnahme mit dem neuen Eingabegerät und/oder Betriebsgerät einzuleiten. Dieser Aspekt hat den Vorteil, dass die Inbetriebnahme über die Reverse Bridge erfolgen kann. Die Inbetriebnahme wird dadurch vereinfacht, da die Reverse Bridge die Informationen mit den neuen Geräten in ihrem Netzwerk einfach synchronisieren kann.
Das Anwendungssteuergerät kann so konfiguriert sein, dass es über den synchronen drahtgebundenen Netzwerkbus mindestens einen Befehl ausgibt, der die Inbetriebnahmeinformationen des neuen Eingabegeräts und/oder neuen Betriebsgeräts enthält. Dabei kann das Anwendungssteuergerät eingerichtet sein, die Inbetriebnahmeinformationen von einer Benutzeroberfläche, wie z. B. einer Inbetriebnahme-App, die vorzugsweise auf einem mobilen Gerät ausgeführt wird, über eine drahtlose Datenübertragung zu erhalten. Ferner kann die Reverse Bridge dazu eingerichtet sein, den Befehl zu empfangen und die Inbetriebnahmeinformationen zu speichern. Diese Variante ist besonders bevorzugt, da das Anwendungssteuergerät ohnehin für die Kontrolle der Gesamtkonfiguration zuständig ist und die Reverse Bridge von weiteren Konfigurationsaufgaben und der Notwendigkeit einer eigenen Benutzeroberfläche zum Empfang von Inbetriebnahmeinformationen entlastet wird.
Hier wird die Reverse Bridge in einer transparenten, aber passiven Konfiguration betrieben, die nur in dem Maße Funktionen und Daten speichert, wie sie benötigt werden.
Gemäß einem weiteren Aspekt der Erfindung wird ein System zur Beleuchtungssteuerung vorgeschlagen, das, ähnlich dem obigen Aspekt, mindestens ein Betriebsgerät umfasst, das so konfiguriert ist, dass es eine oder mehrere Lichtquellen mit Strom versorgt und dem System zur Beleuchtungssteuerung als Reaktion auf einen Abfragebefehl Statusinformationen bereitstellt. Außerdem umfasst das System zur Beleuchtungssteuerung ein Anwendungssteuergerät, das eingerichtet ist, die Statusinformationen zu empfangen, und ferner eingerichtet ist, einen Abfragebefehl auszugeben, um die Informationen zu erhalten, oder in Abhängigkeit von den erhaltenen Informationen auszugeben. Ferner umfasst das System zur Beleuchtungssteuerung, ebenfalls ähnlich den obigen Aspekten und Ausführungsbeispielen, eine Reverse Bridge, die eingerichtet ist, mit dem Anwendungssteuergerät über einen drahtgebundenen Netzwerkbus zu kommunizieren, der unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird, und welches eingerichtet ist, Mit dem wenigstens einen Betriebsgerät über ein Netzwerk zu kommunizieren, dass unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird. Wie eingangs beschrieben ist ein solcher Aufbau kompatibel mit einem erweiterten DALI-Teil-101 Netzwerk, das mit einem DALI-Teil-104 Netzwerk kombiniert ist, die beide miteinander über eine Reverse Bridge verbunden sind.
Das solchermaßen bereitgestellte System zur Beleuchtungssteuerung umfasst ferner, zusätzlich zu dem einen von der Seite des asynchron betriebenen Netzwerks aus kommunizierenden Betriebsgerät (z.B. von der Seite eines DALI-Teil-104 Netzwerks aus), eine anderes Betriebsgerät, das von der Seite des drahtgebundenen Netzwerkbusses aus kommuniziert (z.B. von der Seite des DALI-Teil-101 Netzwerks aus). Die Reverse Bridge transportiert Befehle von dem drahtgebundenen Netzwerkbus zu dem einen Betriebsgerät.
Um dies zu erreichen kann die Reverse Bridge hierbei eingerichtet sein:

(a) Einstellungen des anderen Betriebsgeräts, das eingerichtet ist, von der Seite des drahtgebundenen Netzwerkbusses aus zu kommunizieren, zu einem Zeitpunkt der Installation zu dem einen Betriebsgerät zu kopieren, das eingerichtet ist, von der Seite des asynchron betriebenen Netzwerks aus zu kommunizieren.

Gemäß diesem Aspekt bewirkt die Reverse Bridge, dass ein auf der Seite des asynchronen betriebenen Netzwerks bereitgestelltes Betriebsgerät einfach einem konkreten „realen“ Betriebsgerät auf der Seite des drahtgebundenen Netzwerkbusses „folgt“, anders als bei einem simulierten Betriebsgerät, wie es im Stand der Technik zu finden ist. Das konkrete Betriebsgerät auf der Seite des drahtgebundenen Netzwerks braucht dabei nicht beeinträchtigt zu werden, und braucht auch nicht zu „erkennen“, dass ein anderes Gerät seine Eigenschaften imitiert oder kopiert. Weil in der Richtung des einen Betriebsgeräts, das auf der Seite des synchronbetriebenen Netzwerks bereitgestellt ist, übertragene Befehle anders als die Antworten nicht durch die Zeitgrenzen beeinträchtigt sind, Können diese auf der anderen Seite in einfacher Weise durch die Reverse Bridge zum Zweck der Ausführung durch geleitet werden.
Gemäß einem Ausführungsbeispiel kann die Reverse Bridge des Weiteren eingerichtet sein:

(b) einen von dem Anwendungssteuer ausgegebenen Befehl zu empfangen und wahlweise zu einer Adresse eines anderen Betriebsgeräts durchzuleiten, das so angeordnet ist, dass es von der Seite des synchron betriebenen Netzwerks aus kommuniziert;
(c) den empfangenen und durchgeleiteten Befehl zu einer Adresse des einen Betriebsgeräts weiterzuleiten, das so angeordnet ist, dass es von der Seite des asynchron betriebenen Netzwerks aus kommuniziert.

Um weitere in dem Netzwerk auftretende Kommunikation zu berücksichtigen, kann die Reverse Bridge außerdem eingerichtet sein:

(d) einen von dem Anwendungssteuergerät an eine Adresse eines dritten Betriebsgeräts ausgegebenen Befehl auszufiltern, das so angeordnet ist, dass es von der Seite des synchron betriebenen Netzwerkbusses aus kommuniziert, und den Befehl daran zu hindern zu dem einen Betriebsgerät durch geleitet zu werden, das so angeordnet ist, dass es von der Seite des asynchron betriebenen Netzwerks aus kommuniziert; und/oder
(e) eine beliebige von dem Anwendungssteuergerät an eine Adresse eines Betriebsgeräts oder eines Steuergeräts ausgegebene Abfrage herauszufiltern, die so angeordnet sind, dass sie von der Seite des drahtgebundenen Netzwerkbusses aus kommunizieren, und den Befehl daran zu hindern, zu dem einen Betriebsgerät durchgeleitet zu werden, das so angeordnet ist, dass es von der Seite des asynchronen betriebenen Netzwerks aus kommuniziert.

Der vorgeschlagene „Folge-Modus“ (engl. „follow mode“) besitzt den Vorteil, dass eine Realisierung ziemlich einfach ist und kaum die Konfiguration auf der Seite des drahtgebundenen Netzwerkbusses beeinträchtigt. Dies bezieht sich insbesondere auf DALI-implementierungen mit kombinierten drahtgebundenen/drahtlosen Netzwerken.
Weitere Aspekte und Ausführungsbeispiele der Erfindung beziehen sich auf die konkrete Ausgestaltung der Netzwerke, wie sie in den vorhergehenden Aspekten verwendet wurden. Beispielsweise ist in dem System zur Beleuchtungssteuerung der vorangegangenen Aspekte das asynchron betriebene Netzwerk, das mit einem asynchronen Netzwerkprotokoll betrieben wird, ein drahtloses Netzwerk, wobei ein Netzwerkprotokoll auf der Transportschicht vorzugsweise Thread, Zigbee, Wifi oder Bluetooth/BLE ist. Es wird darauf hingewiesen, dass die DALI-Teil-104-Spezifikation eine Reihe von Transportalternativen zum herkömmlichen drahtgebundenen DALI-Bussystem vorsieht, die sowohl drahtlos als auch drahtgebunden sein können. Eines der zugrundeliegenden Kommunikationsprotokolle in der DALI-Teil-104-Spezifikation ist das User Datagram Protocol (UDP), das mit dem Internet Protocol (IP) verwandt ist. UDP ermöglicht drahtgebundene (z.B. Ethernet) oder drahtlose (z.B. Thread, WiFi) Optionen. Die neue Spezifikation unterstützt DALI mit Thread, das ein drahtloses, IP-basiertes Protokoll ist. Dennoch können in Zukunft auch andere Protokolle wie die oben genannten unterstützt werden, so dass die oben beschriebenen Aspekte der Erfindung in keiner Weise auf DALI-Teil-104-basierte Netzwerke beschränkt sind, die lediglich auf Thread gründen.
Nichtsdestoweniger ist anzumerken, dass die obigen Aspekte besonders vorteilhaft warden, wenn das Eingabegerät und/oder das Betriebsgerät auf der einen Seite und das Anwendungssteuergerät auf der anderen Seite eingerichtet sind, miteinander über die Reverse Bridge unter Verwendung eines DALI Protokolls (IEC 62386) zu kommunizieren, wobei der drahtgebundene Netzwerkbus ein DALI-Bus ist und Das Eingabegerät und/oder das Betriebsgerät, das Anwendungssteuer gerät und die reverse Bridge jeweils mit einer entsprechenden DALI-Netzwerkschnittstelle ausgestattet sind (wobei die Reverse Bridge optional mit zwei oder mehr Schnittstellen ausgestattet ist - wenigstens eine auf jeder Seite).
Ferner können das Anwendungssteuergerät und die Reverse Bridge dazu eingerichtet sein, Miteinander unter Verwendung des Teils-101 des DALI-Protokolls (IEC 62386-101) zu kommunizieren, und/oder das Eingabegerät und/oder das Betriebsgerät und die Reverse Bridge dazu eingerichtet sein, miteinander unter Verwendung des Teils-104 des DALI-Protokolls (IEC 62386-104) zu kommunizieren.
Weitere Vorteile, Merkmale und Einzelheiten der verschiedenen Aspekte ergeben sich aus den Ansprüchen, aus der folgenden Beschreibung bevorzugter Ausführungsbeispiele und aus den Zeichnungen. In den Zeichnungen bezeichnen die gleichen Bezugszeichen die gleichen Merkmale und Funktionen.
Kurze Beschreibung der Zeichnungen
Darin zeigen:

1 in einer schematischen Ansicht ein System zur Beleuchtungssteuerung gemäß einem ersten Ausführungsbeispiel;
2 in einer schematischen Ansicht ein System zur Beleuchtungssteuerung gemäß einem zweiten Ausführungsbeispiel;
3 in einer schematischen Ansicht ein System zur Beleuchtungssteuerung gemäß einem dritten Ausführungsbeispiel;
4 in einer schematischen Ansicht ein System zur Beleuchtungssteuerung gemäß einem vierten Ausführungsbeispiel.

Detaillierte Beschreibung bevorzugter Ausführungsbeispiele
Bei der folgenden Beschreibung der bevorzugten Ausführungsbeispiele ist zu beachten, dass sich die vorliegende Offenbarung der verschiedenen Aspekte nicht auf die Einzelheiten der Konstruktion und Anordnung der Komponenten beschränkt, wie sie in der folgenden Beschreibung und den Zeichnungen dargestellt sind. Die Ausführungsbeispiele können auf verschiedene Weise in die Praxis umgesetzt oder ausgeführt werden. Es sollte auch beachtet werden, dass die hier verwendeten Ausdrücke und Begriffe nur der spezifischen Beschreibung dienen und vom Fachmann nicht als einschränkend aufgefasst werden sollten. Darüber hinaus bezeichnen in der folgenden Beschreibung dieselben Bezugszeichen in den verschiedenen Ausführungsbeispielen oder Figuren dieselben oder ähnliche Merkmale oder Gegenstände, so dass in einigen Fällen eine wiederholte detaillierte Beschreibung derselben weggelassen wird, um die Kompaktheit und Klarheit der Darstellung zu wahren.
Nachfolgend werden vier Ausführungsbeispiele in größerem Detail erläutert, wobei jedes der vier Ausführungsbeispiele auf einer Kombination eines DALI Teil-101 - Netzwerks und eines DALI Teil-104-Netzwerks beruht. Wie bereits erwähnt, können die in Bezug auf diese Ausführungsbeispiele entwickelten Grundsätze auch für andere Normen oder sogar für proprietäre Systeme gelten, und sie können auch für fortgeschrittene DALI-Systeme gelten, die in der Zukunft entwickelt werden, aber auf den vorliegenden Definitionen basieren. Es wird darauf hingewiesen, dass sich der Name von DALI in solchen Weiterentwicklungen oder Standardversionen (z. B. „D4i“) ändern kann, während die nachstehend beschriebenen Ausführungsformen weiterhin mit einem solchen erweiterten DALI-Standard kompatibel sein können.
Darüber hinaus wird das in den Zeichnungen gezeigte, auf Teil-104 basierende Netzwerk durch Thread als zugrunde liegendes IP-Protokoll unterstützt. Es versteht sich jedoch von selbst, dass auch andere zugrundeliegende Protokolle in ähnlicher Weise eingesetzt werden können, selbst wenn es sich nicht um ein drahtloses, wie Thread, sondern um ein kabelgebundenes, wie Ethernet, handelt. Der Standard DALI+ (einschließlich eines auf Teil-1 04 basierenden Netzwerks), wie er unter anderem in den Ausführungsbeispielen und Zeichnungen verwendet wird, umfasst eine Systemadresse, die die Anzahl der möglichen Geräte mit 255 multipliziert, und wenn ein IP-basierter Träger wie Thread verwendet wird, geht diese Erweiterung noch weiter und bietet eine nahezu unbegrenzte Adressierungsmöglichkeit. Dementsprechend kann die Anzahl der Geräte auf der Teil-104-Netzwerkseite, wie sie in den Ausführungsbeispielen gezeigt ist, ebenfalls je nach Bedarf auf eine beliebige Anzahl erhöht werden. Die Anzahl der Geräte auf der Teil-101 -Netzseite kann entsprechend der Norm auf jeweils 64 für Eingabegeräte und Betriebsgeräte begrenzt werden.
Die zwei ersten, in den 1 und 2 gezeigten Ausführungsbeispiele illustrieren ein DALI-System zur Beleuchtungssteuerung umfassend ein Anwendungssteuergerät 4, das (über eine DALI-Schnittstelle) mit einem 2-adrigen (klassischen) DALI-Teil-101 basierten, drahtgebundenen Netzwerkbus 6, einer Reverse Bridge 5 mit einer 2-adrigen DALI-Schnittstelle und einer Teil-104-basierten (hierin drahtlos) Schnittstelle. Ferner ist jeweils eine Vielzahl von Betriebsgeräten 3, 3i, ... Eingabegeräten 2, 2i, ... bereitgestellt, die eine Teil-104-basierte (hierin drahtlos) Schnittstelle umfassen. Es ist anzumerken, dass die genannten DALI-Schnittstellen - seien diese Teil-101-basiert oder Teil-104-basiert - zum Zweck der Übersichtlichkeit nicht in den Figuren gezeigt sind. Das Bezugszeichen 7 bezeichnet ein DALI-Teil-104 basiertes, drahtloses, asynchron betriebenes Netzwerk.
Das erste Ausführungsbeispiel ist in 1 illustriert und kann das am meisten bevorzugte sein. Das Anwendungssteuergerät 4 und die Reverse Bridge können so angepasst und konfiguriert werden, dass sie spezifische Befehle austauschen, die eine vollständige bidirektionale Kommunikation zwischen der Anwendungssteuerung 4 und den Betriebsgeräten 3, 3i und Eingabegeräten 2, 2i ohne Simulation von Statusinformationen usw. ermöglichen. Ein Kommunikationsprozess beginnt zunächst damit, dass das Anwendungssteuergerät 4 einen Abfragebefehl 10a an die Reverse Bridge 5 sendet. Der Abfragebefehl kann Teil einer Transaktion sein, die einen oder mehrere Befehle enthält, die ein Betriebsgerät anweisen, die Beleuchtungsbedingungen anzupassen (z. B. die Stromversorgung zu ändern), oder eine einfache Abfrage, um Statusinformationen zu erhalten oder Einstellungen zu ändern. In beiden Fällen kann das Anwendungssteuergerät 4 eine Bestätigung oder Informationen erwarten, die in einem oder mehreren Frames über eine Antwort zurück an das Anwendungssteuergerät gesendet werden.
Das Anwendungssteuergerät 4 und die Reverse Bridge können angepasst und eingerichtet sein, spezielle Befehle auszutauschen, die eine vollständige bidirektionale Kommunikation zwischen dem Anwendungssteuergerät 4 und den Betriebsgeräten 3, 3i und Eingabegeräten 2, 2i erlauben, ohne eine Simulation von Statusinformationen, etc. Als erstes startet ein Kommunikationsprozess damit, dass das Anwendungssteuergerät 4 einen Abfragebefehl 10a an die Reverse Bridge 5 sendet. Der Abfragebefehl kann Teil einer Transaktion sein, die einen oder mehrere Befehle enthält, mit denen ein Betriebsgerät angewiesen wird, Beleuchtungseinstellungen anzupassen (beispielsweise die Leistungsversorgung zu ändern), oder mit denen eine Statusinformation abgefragt oder die Änderung von Grundeinstellungen angefordert werden. In beiden Fällen kann das Anwendungssteuergerät 4 eine Bestätigung oder Informationen erwarten, die in einen oder mehreren Frames über eine Antwort zurück an das Anwendungssteuergerät geschickt werden.
Die Reverse Bridge 5 ist dazu eingerichtet, den Abfragebefehl 10a über den DALI-Teil-101-basierten, drahtgebundenen Netzwerkbus 6 an seiner entsprechenden DALI-Teil-101- Schnittstelle zu empfangen und ihn in das DALI-Teil-104-basierte, drahtlose, asynchrone betriebene Netzwerk 7 über seine entsprechende andere Schnittstelle zu übersetzen bzw. zu transportieren. Der Abfragebefehl wird dabei verkapselt in einem Teil-104-basierten Vorwärts-Transaktions-Frame 10b über das drahtlose Netzwerk weitergeleitet und von dem Betriebsgerät 3 oder dem Eingabegerät 2 empfangen, abhängig von der Kurzadresse, die in dem Vorwärts-Transaktions-Frame enthalten ist.
Das Betriebsgerät 3 oder das Eingabegerät 2 (was auch immer hier anwendbar ist) antwortet mit einem Antwort-Frame 10c an die Reverse Bridge 5, wobei der Antwort-Frame die Bestätigung oder andere angeforderte Informationen enthält. Die Reverse Bridge 5 gibt dann einen Befehl 20a aus, um schließlich den durch den ursprünglichen Abfragebefehl 10a angeforderten Antwortwert an das Anwendungssteuergerät 4 als Teil der Nutzdaten des Befehls 20a (z.B. DALI-Datentransferregister 2 (DTR2)) zu liefern.
Wie bereits erwähnt, können Frames in der Kommunikation aus einem oder mehreren Befehlen bestehen (z. B. einer Kombination aus dem Setzen eines DTR0-Registers und einem Befehl, der DTR0 verwendet), und ein oder mehrere Frames können eine Transaktion bilden, die, wenn sie über den drahtgebundenen Bus übertragen wird, ein spezielles zeitgebundenes Schema für die Übertragung ihrer Bestandteile erfordert.
Dieser Befehl 20a entsprechend dem Ausführungsbeispiel kann gemäß verschiedenen Alternativen in die Praxis umgesetzt werden. Der Zweck des Befehls 20a ist es, auf effiziente Weise Antwortwerte auf den vorherigen Abfragebefehl 10a vom Anwendungssteuergerät 4 zu übermitteln, und zwar genau dann, wenn die Antwort von der Teil-104-Seite in der Reverse Bridge 5 vorliegt. Dabei kann der Abfragebefehl 10a eine einzelne Abfrage oder eine Transaktion sein, die mehrere Befehle und Abfragen enthält, wie es gemäß dem DALI-Standard im Teil-101 vorgesehen ist. In den oben beschriebenen, nicht beschränkenden, speziellen Ausführungsbeispielen können bis zu 7 Abfragen pro Transaktion durch den Befehl gemeinsam adressiert werden, der durch die Reverse Bridge 5 vorbereitet wird.
Gemäß einer speziellen Option kann ein neuer Typ von Befehls-Frame spezifiziert und ausgenutzt werden. Der neue Typ von Befehls-Frame kann beispielsweise 20-bit Frames aufweisen. Die Frame-Bits können wie folgend angeordnet warden: SSSS XXXXXXXX YYYYYYYY. Durch Verwendung einer solchen Bit-Anordnung können bis zu vier Frames erforderlich sein, um alle Antwortwerte (Informationen oder Bestätigung) zu liefern. In der obigen Bit-Anordnung bezeichnet S Sequenznummer, die für jede Transaktion 10a inkrementiert wird, X bezeichnet eine Bitmaske mit Antwort-Flags (innerhalb des ersten Frames) oder nachfolgende Antwortwerte 2, 4, 6, und Y bezeichnet Antwortwerte 1, 3, 5, 7.
Gemäß einer anderen speziellen Option kann ein DALI-Befehl aus einem bereits bestehenden Befehlssatz wiederverwendet werden, um die Antwortwerte zu liefern.
Hierbei sind die speziellen 24-bit-Befehle DTR1:DTR0 oder DTR2:DTR1 bevorzugt, weil zwei Bytes an Nutzdaten mit einem einzelnen 24-bit-Befehl möglich sind. Die Anordnung von Bits innerhalb des Frames lautet dann AAAAAAAAXXXXXXXX YYYYYYYY, Wieder mit bis zu vier Frames, die erforderlich sind um alle Antwortwerte zu liefern. In der obigen Bit-Anordnung bezeichnet A das Adress-Byte 0xC7 oder 0xC9 entsprechend für die Befehle DTR1:DTR0 und DTR2:DTR1, X bezeichnet eine Bitmaske mit Antwort-Flags (innerhalb des ersten Frames) oder nachfolgende Antwortwerte 2, 4, 6, und Y bezeichnet Antwortwerte 1, 3, 5, 7.
In der bevorzugten Implementierung des Vorwärts-Befehls 20a, wie in 1 gezeigt, wird die Bitmaske mit Flags wie folgend beschrieben vorbereitet. Wie bereits erwähnt, werden bis zu 4 Frames (20- oder 24-Bit-Frames wie oben beschrieben) benötigt, um die bis zu 7 Antwortwerte zu liefern. Die 4 Frames können in einer Transaktion auf dem Teil-101-Bus 6 von der Reverse Bridge 5 an das Anwendungssteuergerät 4 gesendet werden, um Unterbrechungen zu vermeiden. Im Allgemeinen kann das Anwendungssteuergerät 4 lediglich solche Frames von der Reverse Bridge erwarten. Hierbei wird davon ausgegangen, dass keine weiteren Anwendungssteuergeräte, die Vorwärts-Frames senden, Teil des Systems sind.
Um die Anzahl der erforderlichen Befehle zu optimieren, ist es nützlich, lediglich für jene Abfragebefehle 10a innerhalb der Gesamttransaktion aus entsprechenden Abfragebefehlen 10a Werte bereitzustellen, die auch in einem Antwortwert auf der Seite des asynchronen betriebenen Teil-104-Netzwerks 7 resultieren. Die Bitmaske (z.B. die X-Bits in dem ersten Frame) kann wirksam anzeigen, welcher der Abfragebefehle tatsächlich zu einer Antwort geführt hat. In einem Beispiel ist im ersten Frame die Bitmaske folgendermaßen gesetzt: XXXXXXXX → CFFFFFFF, wobei C anzeigt, ob eine beliebige der Abfragen zu mehrfachen Antworten auf der Teil-104-Seite geführt hat, und F bezeichnet die Bitmaske mit einem Bit für jeweils bis zu 7 Abfragen in der Gesamttransaktion, wobei das Bit anzeigt, ob von der Teil-104-Seite eine Antwort erhalten wurde (zum Beispiel =1), oder ob keine Antwort erhalten wurde (zum Beispiel =0). Z.B. beginnend mit dem niedrigstwertigen Bit, das für die erste Befehlsabfrage innerhalb der Gesamttransaktion steht, wobei nicht abgefragte Befehle in der Gesamttransaktion aus der Bitdarstellung verworfen werden.
Dabei dürfen nur die Antwortwerte für die Abfragebefehle, die in der Bitmaske eine „1“ haben, als Y-Bits und nachfolgende X-Bits hinzugefügt werden, wodurch die Übertragung ungenutzter Bits für Abfragen ohne Antwort effektiv vermieden wird. Ferner wird das C-Bit in der obigen Bitmaske gesetzt, wenn mehrere Geräte auf mindestens eine der Abfragen geantwortet haben. In diesem Fall kann die Abfrage, die zu mehreren Antworten führt, den Wert 0xFF mit der Angabe MASK enthalten.
Nachstehend sind einige Beispiele aufgeführt:

(a) Transaktion mit 1 Abfragebefehl, der eine Antwort generiert:
- Abfrage: 0x0190 → QUERY STATUS wird an die Kurzadresse 0 des Betriebsgeräts (3) gesendet
- Antwort: DTR2:DTR1 (0x01, 0x04) → führt zu genau einer gültigen Antwort mit Wert 0x04 (→ 0x090104).
(b) Transaktion mit 2 Abfragebefehlen, und nach Erhalt der Befehle wird genau eine Antwort generiert:
- Abfrage: 0x0391 0x0103 0x0190 → QUERY CONTROL GEAR PRESENT (addr:1), STEP UP (addr:0), QUERY STATUS (addr:0)
- Antwort: DTR2:DTR1 (0x02, 0x0B) → genau eine gültige Antwort 0x0B (d.h., der dritte Befehls-Frame entspricht dem zweiten Abfragebefehl).
(c) Transaktion mit 7 Abfragebefehlen, alle antworten:
- Abfrage: 0x01C5, 0x01C5, 0x01C5, ... → 7 mal READ MEMORY LOCATION (DTR1, DTR0)
- Antwort: DTR2:DTR1 (0x7F, 0x01), DTR2:DTR1 (0x02, 0x03), DTR2:DTR1 (0x04, 0x05), DTR2:DTR1(0x06, 0x07) → führt zu 7 Antwortwerten (1,2,3,4,5,6,7)

Ein zweites Ausführungsbeispiel ist in 2 gezeigt. Wie oben mit Bezug auf 1 beschrieben beginnt eine Transaktion damit, dass das Anwendungssteuergerät 4 einen Abfragebefehl 10a an die Reverse Bridge 5 übermittelt. Der Abfragebefehl kann ein Befehl sein, mit welchem ein Betriebsgerät angewiesen wird, die Beleuchtungseinstellungen anzupassen (beispielsweise die Leistungsversorgung zu ändern), oder eine einfache Abfrage, um Statusinformationen zu erhalten oder Grundeinstellungen zu ändern.
Die Reverse Bridge 5 ist dazu eingerichtet, den Abfragebefehl 10a über den DALI-Teil-101-basierten, drahtgebundenen Netzwerkbus 6 an seiner entsprechenden DALI Teil-101-Schnittstelle zu empfangen und transportiert bzw. übersetzt ihn auf das DALI-Teil-104-basierte drahtlose, asynchron betriebene Netzwerk 7 über seine entsprechende andere Schnittstelle. Der Abfragebefehl wird dabei als ein verkapselnder Teil-104-basierter Vorwärts-Transaktions-Frame 10b über das drahtlose Netzwerk übertragen und durch das Betriebsgerät 3 oder das Eingabegerät 2 abhängig von der im Vorwärts-Abfrage-Frame enthaltenen Kurzadresse empfangen.
Das Betriebsgerät 3 oder das Eingabegerät 2 (was auch immer hier anwendbar ist) antwortet mit dem Antwort-Frame 10c an die Reverse Bridge 5, einschließlich der Bestätigung oder der anderen Information, die angefordert wurde. Die Reverse Bridge 5 speichert dann die Information in dem Speicher 8 (MEM) und wartet einen weiteren Abfragebefahl 30a vom Anwendungssteuergerät ab. Wenn dieser Abfragebefehl ausgegeben wird, liest die Reverse Bridge 5 die Information (den Antwortwert) aus dem Speicher 8 aus und fügt sie in einen Frame der Antwort 30b ein und sendet sie an das Anwendungssteuergerät 4.
Ein drittes Ausführungsbeispiel ist in Fig.. 3 dargestellt. Hier überträgt das Anwendungssteuergerät 4 eine Vielzahl von Befehlen 40a, um Werte im Speicher 8 (in entsprechende Memory Pages; MEM) zu setzen, einschließlich Inbetriebnahmeinformationen wie den EUI64 (64-Bit Extended Unique Identifier; bezeichnet ein von IEEE standardisiertes MAC-Adressformat zur Identifizierung von Netzwerkgeräten) und ein Inbetriebnahmegeheimnis PSKd des Thread-basierten Teil-104-Geräts (Betriebsgerät 3 oder Eingabegerät 2). Nach dem Vervollständigen des Datentransfers in den Speicher 8 initiiert die Reverse Bridge 5 den Inbetriebnahmeprozess anhand eines dem Netzwerk neu hinzugefügten Geräts unter Verwendung der Information, die nun aus dem Speicher 8 ausgelesen wurde.

Eine bevorzugte Implementierung einer Memory Page im Speicher 8 sieht wie folgt aus. Die Memory Page enthält Informationen über die Geräte (Betriebsgeräte 3, Eingabegeräte 2), die auf der Seite des asynchron betriebenen Netzes 7 des Teil-1 04-Netzwerks vorhanden sind, über Antworten, die für die Abfrage verfügbar sind, und Beitrittsgeheimnisse für Geräte, die dem Netz beitreten sollen (wobei die Reverse Bridge 5 als Inbetriebnahmeinstanz für Thread fungiert. Ein Beispiel einer Memory Page ist in Tabelle 1 gezeigt. Tabelle 1:

Adresse	Beschreibung	Standardwert	RESET-Wert	Speichertyp
0x00	Adresse der letzten zugänglichen Speicherposition		Keine Änderung	ROM
0x01	Indikator-Byte	beliebig	beliebig	beliebig
0x02	Sperr-Byte	0xFF	0xFF	RAM
0x03	Kurzadresse des Anwendungssteuergeräts, das über Änderungen zu informieren ist	0xFF	Keine Änderung	NVM
0x04	Flags: CFFFFFFF	0x00	0x00	RAM
0x05.. 0x0B	Antwortwerte für alle Abfragen für F=1 in den Flag-Bytes (address 0x04)	0x00	0x00	RAM
0x0B.. 0x13	EUI-64 für das Thread beitretende Gerät	0x00	0x00	RAM
0x14.. 0x23	PSKd für das Thread beitretende Gerät	0x00	0x00	RAM
0x24.. 0x2 B	Bitmaske (64-bit), die anzeigt, welche Kurzadressen von Betriebsgeräten auf der Teil-104-Seite erfasst wurden	0x00	0x00	RAM
0x2C.. 0x34	Bitmaske (64-bit), die anzeigt, welche Kurzadressen von Steuergeräten auf der Teil-104-Seite erfasst wurden	0x00	0x00	RAM
0x35	Betriebs- / Status-Byte (xxxxAEJD)	0x00	0x00	RAM

Genauer gesagt hält der Speicher 8 die Antwortwerte für die Abfrage bereit (als Alternative zu den Befehlen 20a, die die Antworten im ersten Ausführungsbeispiel senden). Weiter zeigt die Kurzadresse des Anwendungssteuergeräts 4 zeigt an, ob ein Anwendungssteuergerät 2 erwartet, Hinweise auf Antwortwerte zu erhalten. 0xFF (MASK) deaktiviert die Benachrichtigungen. Alternative Befehlsformate können die Kurzadresse verwenden, um Informationen an das Anwendungssteuergerät 4 zu senden.
Des Weiteren sind EUI-64 und PSKd Geheimnisse der neu hinzuzufügenden Geräte, die spezifisch für das Thread-Protokoll sind (als ein Beispiel für eine Teil-104-Netzwerk-Technologie). Ist erst einmal das letzte Byte des Geheimnisses PSKd hinterlegt, so beginnt die Reverse Bridge 5 damit, als eine Inbetriebnahmeinstanz für Thread zu agieren und fügt das Gerät (das Eingabegerät 2 oder das Betriebsgerät 3) mit einer vergebenen EUI-64 (welches wie oben beschrieben der MAC-Adresse entspricht) der Liste der Geräte hinzu, bei denen davon ausgegangen wird, dass sie dem Netzwerk hinzugefügt werden. Jeglicher Erfolg oder Fehler kann dabei beobachtet werden, indem das Status-Byte ausgelesen wird (address 0x36). Der Prozess startet, wenn das J-Bit in dem Betriebs-/ Status-Byte gesetzt wird und wird gestoppt, wenn das J-Bit The process starts when the J-bit is set in the Operation / Status Byte and terminates when the J-bit geleert ist (beim Lesen). Ds E-Bit kann dabei anzeigen, wenn ein Fehler aufgetreten ist.
Die Bitmasken bei der Adresse 0x24..0x2B und der Adresse 0x2C..0x34 zeigen an, welche Kurzadresse auf der Seite des asynchron betriebenen Teil-104-Netzwerks 7 der der Reverse Bridge 5 verwendet wird. Die Identifikation von bereits verwendeten Kurzadressen beginnt, wenn das D-Bit im Betriebs-/ Status-Byte gesetzt ist, und stoppt, wenn das D-Bit geleert ist (beim Lesen). Die Reverse Bridge 5 ist dazu eingerichtet, automatisch Kurzadressen für das Gerät (Betriebsgerät 3 und/oder Eingabegerät 2) auf der Seite des Teil-104-Netzwerks zuzuweisen (z.B. unter Verwendung der von konvetionellen DALI bekannten Adresssuche), wenn das A-Bit in dem Betriebs- / Status-Byte gesetzt ist.
Ein viertes Ausführungsbeispiel ist in 4 gezeigt. Hierbei wird, anstelle einer Simulation eines DALI-Geräts, das im asynchron betriebenen Teil-104-Netzwerk 7 vorhanden ist, ein reales DALI-2-Gerät („ein anderes“ Betriebsgerät 3b) auf der Seite des drahtgebundenen Teil-101-Netzwerkbusses 6 implementiert, und die Reverse Bridge 5 ist dazu eingerichtet, ein oder mehrere Geräte in dem asynchron betriebenen Teil-104-Netzwerk dazu u bringen, diesem Gerät „zu folgen“. Genauer gesagt ist die Reverse Bridge 5 dazu eingerichtet:

- Einstellungen (70) des anderen Betriebsgeräts 3b, welches so angeordnet ist, dass es von der Seite des drahtgebundenen Netzwerkbusses 6 aus kommuniziert, zu dem anderen Betriebsgerät 3 zum Zeitpunkt der Installation zu kopieren, welches so angeordnet ist, dass es von der Seite des asynchron betriebenen Netzwerks 7 aus kommuniziert.

Des Weiteren kann die Reverse Bridge 5 dazu eingerichtet sein:

- einen Befehl (60a) zu empfangen und wahlweise durchzuleiten, der durch das Anwendungssteuergerät 4 an eine Adresse des anderen betriebsgeräts 3b ausgegeben wurde, welches so angeordnet ist, dass es von der Seite des drahtgebundenen Netzwerkbusses 6 aus kommunizier; und
- den empfangenen und durchgeleiteten Befehl (60b) an eine Adresse des einen Betriebsgeräts 3 weiterzuleiten, welches auf der Seite des asynchron betriebenen Netzwerks 6 angeordnet ist.

Um darüber hinaus mit anderen Befehlen und/oder Abfragen umgehen zu können, ist die Reverse Bridge 5 ferner dazu eingerichtet:

- einen von dem Anwendungssteuergerät 4 an eine Adresse eines dritten Betriebsgeräts, welches so angeordnet ist, dass es von der Seite des drahtgebundenen Netzwerkbusses 6 aus kommuniziert, ausgegebenen Befehl auszufiltern und diesen Befehl daran zu hindern, zu dem einen Betriebsgerät 3 durchgeleitet zu werden, welches so angeordnet ist, dass es von der Seite des asynchron betriebenen Netzwerks 7 aus kommuniziert; und/oder
- eine beliebige von dem Anwendungssteuergerät 4 an eine Adresse eines Betriebsgeräts oder eines Steuergeräts, welches so angeordnet ist, dass es von der Seite des drahtgebundenen Netzwerkbusses 6 aus kommuniziert, ausgegebene Abfrage auszufiltern, und die Abfrage daran zu hindern, zu dem einen Betriebsgerät 3 durchgeleitet zu werden, welches so angeordnet ist, dass es von der Seite des asynchron betriebenen Netzwerks 7 aus kommuniziert.

BEZUGSZEICHENLISTE:

1: System zur Beleuchtungssteuerung
2: Eingabegerät (z.B., Sensor, Schalter)
2a: neues Eingabegerät (zur Inbetriebnahme)
3: Betriebsgerät (z.B. LED-Treiber)
3a: neues Betriebsgerät (zur Inbetriebnahme)
3b: „anderes“ Betriebsgerät: verbunden innerhalb des drahtgebundenen Netzwerkbusses
4: Anwendungssteuergerät
5: Reverse Bridge
6: synchron betriebenes Netzwerk (drahtgebundener Netzwerkbus)
7: asynchron betriebenes Netzwerk (z.B., drahtloses Netzwerk (Thread) oder Ethernet)
8: Speicher
9: Nutzerschnittstelle (Inbetriebnahme-App)
10a: Abfragebefehl
10b: Vorwärts-Transaktions-Frame
10c: Antwort-Frame
20a: Befehl
30a: zweiter Befehl
30b: Antwort, bereitgestellt in Erwiderung auf Abfragebefehl 30a
40a: Inbetriebnahme Start-Befehl
50: Nachrichten zwischen Bridge und dem einen Betriebsgerät oder Steuergerät in dem asynchronen Netzwerk
60a: Befehl (keine Abfrage)
60b: forward frame following command

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102018202965 A1 [0013]

Zitierte Nicht-Patentliteratur

https://f.hubspotusercontent40.net/hubfs/7177595/Data%20sheets/English/CBU_DCS_Data-Sheet_EU_EN_2_0_24092021.pdf [0012]

Claims

System (1) zur Beleuchtungssteuerung, umfassend: wenigstens ein Eingabegerät (2), das dazu eingerichtet ist, dem System zur Beleuchtungssteuerung eine vom Nutzer bereitgestellte, eine Status- und/oder eine Umgebungsinformation in Erwiderung auf einen Abfragebefehl (10a) zu übermitteln; und/oder wenigstens ein Betriebsgerät (3), das dazu eingerichtet ist, einer oder mehreren Lichtquellen Leistung zuzuführen und dem System zur Beleuchtungssteuerung Statusinformationen in Erwiderung auf einen Abfragebefehl (10a) zu übermitteln; ein Anwendungssteuergerät (4), das eingerichtet ist, die vom Nutzer bereitgestellten, Status- und/oder Umgebungsinformationen zu empfangen, und dazu eingerichtet ist, einen Abfragebefehl (10a) auszugeben, um die Information zu erhalten, oder diesen abhängig von der Information auszugeben; eine Reverse Bridge (5), die dazu eingerichtet ist, mit dem Anwendungssteuergerät (4) über einen drahtgebundenen Netzwerkbus (6) zu kommunizieren, der unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird, und welche dazu eingerichtet ist, mit dem wenigstens einen Eingabe- (2) und/oder Betriebsgerät (3) über ein Netzwerk (7) zu kommunizieren, das unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird; wobei die Reverse Bridge (5) zur bidirektionalen Kommunikation zwischen dem Anwendungssteuergerät (4) und dem wenigstens einen Eingabe- (2) und/oder Betriebsgerät (3) eingerichtet ist.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 1, wobei die Reverse Bridge (5) dazu eingerichtet ist, wenigstens einen Vorwärts-Transaktions-Frame (10b) zu dem Eingabe- (2) und/oder Betriebsgerät (3) gerät transportieren, der mit dem Abfragebefehl (10a) verknüpft ist, den sie von dem Anwendungssteuergerät (4) empfangen hat, und an das Anwendungssteuergerät (4) einen Befehl (20a) auszugeben, der mit einem entsprechenden Antwort-Frame (10c) verknüpft ist, den sie von dem Eingabe- (2) und/oder Betriebsgerät (3) in Erwiderung auf den wenigstens einen Vorwärts-Transaktions-Frame (10b) erhalten hat.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 1, wobei die Reverse Bridge (5) dazu eingerichtet ist, einen als Vorwärts-Frame ausgebildeten Befehl (20a) auszugeben, der die Antwort (11c) als Teil der Nutzdaten des Befehls (20a) umfasst.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 1, wobei die Reverse Bridge (5) dazu eingerichtet ist, an das Eingabe- (2) und/oder Betriebsgerät (3) einen mit dem Abfrage-Befehl (10a), den sie von dem Anwendungssteuergerät (4) empfangen hat, verknüpften Vorwärts-Abfrage-Frame (10b) zu transportieren, und an das Anwendungssteuergerät (4) eine mit einem entsprechenden Antwort-Frame (10c) verknüpfte Antwort (30b) zu transportieren, den sie von dem Eingabe- (2) und/oder Betriebsgerät (3) in Erwiderung auf den wenigstens einen Vorwärts-Transaktions-Frame (10b) erhalten hat.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 4, wobei das Anwendungssteuergerät (2) dazu eingerichtet ist, auf den vorherigen ersten Befehl (10a) folgend einen zweiten Befehl (30a) auszugeben; und die Reverse Bridge (5) dazu eingerichtet ist, die Antwort (30a) in Erwiderung auf den zweiten Befehl (30a) zu transportieren, der von dem Anwendungssteuergerät (4) ausgegeben wurde.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 5, wobei die Reverse Bridge (5) einen Speicher (8) umfasst, in welchem der/die Antwortwert(e) von dem Antwort-Frame (10c) vorübergehend gespeichert wird/werden, wenn diese(s) von dem Eingabe- (2) und/oder Betriebsgerät (3) ausgehend empfangen wird/werden; und die Reverse Bridge (5) dazu eingerichtet ist, die Antwort (10c) aus dem Speicher (8) auszulesen, wenn sie den zweiten Befehl (30a) empfängt, und den/die Antwortwert(e) aus dem Antwort-Frame (10c) als die Antwort (30b) an das Anwendungssteuergerät (4) zu übermitteln.
System (1) zur Beleuchtungssteuerung gemäß einem der Ansprüche 1 bis 6, wobei die Reverse Bridge (5) einen (oder den) Speicher (8) aufweist und dazu eingerichtet ist, Inbetriebnahmeinformationen eines neuen Eingabegeräts (2a) und/oder eines neuen Betriebsgeräts (3a) in dem Speicher (8) zu speichern, die dem System (1) zur Beleuchtungssteuerung hinzugefügt werden sollen; und die Reverse Bridge (5) dazu eingerichtet ist, einen Inbetriebnahmeprozess mit dem neuen Eingabe- (2a) und/oder Betriebsgerät (3a) zu starten.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 7, wobei das Anwendungssteuergerät (4) dazu eingerichtet ist, wenigstens einen Befehl (40a) über den drahtgebundenen Netzwerkbus (6) auszugeben, der das synchrone Netzwerkprotokoll verwendet, wobei der Befehl (40a) die Inbetriebnahmeinformation des neuen Eingabegeräts (2) und/oder des neuen Betriebsgeräts (3) enthält; und die Reverse Bridge (5) dazu eingerichtet ist, den Befehl (40a) zu empfangen und die Inbetriebnahmeinformation in dem Speicher (8) zu speichern; wobei das Anwendungssteuergerät (4) vorzugsweise dazu eingerichtet ist, die Inbetriebnahmeinformation direkt von einer Nutzerschnittstelle zu erhalten (9), vorzugsweise ausgeführt auf einem Mobilgerät über drahtlosen Datentransfer.
System (1) zur Beleuchtungssteuerung, umfassend: wenigstens ein Betriebsgerät (3), das dazu eingerichtet ist, einer oder mehreren Lichtquellen Leistung zuzuführen und dem System zur Beleuchtungssteuerung Statusinformationen in Erwiderung auf einen Abfragebefehl (10a) zu übermitteln; ein Anwendungssteuergerät (4), das eingerichtet ist, Statusinformationen zu empfangen, und dazu eingerichtet ist, einen Abfragebefehl (10a) auszugeben; eine Reverse Bridge (5), welche dazu eingerichtet ist, mit dem Anwendungssteuergerät (4) über einen drahtgebundenen Netzwerkbus (6) zu kommunizieren, der unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird, und mit dem wenigstens einen Betriebsgerät (3) über ein Netzwerk (7) zu kommunizieren, das unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird; das System zur Beleuchtungssteuerung zusätzlich zu dem einen Betriebsgerät (3), das mit der Reverse Bridge auf der Seite des Netzwerks (7) kommuniziert, das unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird, ferner ein anderes Betriebsgerät (3b) umfasst, das von der Seite des drahtgebundenen Netzwerkbusses (6) kommuniziert, der unter Verwendung eines synchronen Netzwerkprotokolls betrieben wird; wobei die Reverse Bridge (5) dazu eingerichtet ist: - Einstellungen des anderen Betriebsgeräts (3b), das eingerichtet ist, von der Seite des drahtgebundenen Netzwerkbusses (6) aus zu kommunizieren, zu dem einen Betriebsgerät (3) zum Zeitpunkt der Installation zu kopieren, welches dazu eingerichtet ist, auf der Seite des asynchron betriebenen Netzwerks (7) zu kommunizieren.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 9, wobei die Reverse Bridge (5) des Weiteren dazu eingerichtet ist: - einen von Anwendungssteuergerät (4) ausgegebenen Befehl zu empfangen und wahlweise an eine Adresse des anderen Betriebsgeräts (3b) durchzuleiten, welches angeordnet ist, so dass es von der Seite des drahtgebundenen Netzwerkbusses (6) aus kommuniziert; - den empfangenen und durchgeleiteten Befehl an eine Adresse des einen Betriebsgeräts (3) weiterzuleiten, welches angeordnet ist, so dass es von der Seite des asynchron betriebenen Netzwerks (7) aus kommuniziert; wobei die Reverse Bridge (5) vorzugsweise weiter dazu eingerichtet ist: - einen vom Anwendungssteuergerät (4) an eine Adresse eines dritten Betriebsgeräts ausgegebenen Befehl auszufiltern, das angeordnet ist, so dass es von der Seite des drahtgebundenen Netzwerkbusses (6) aus kommuniziert, und den Befehl daran zu hindern, zu dem einen Betriebsgerät (3) durchgeleitet zu werden, welches angeordnet ist, so dass es von der Seite des asynchron betriebenen Netzwerks (7) aus kommuniziert; und/oder - eine beliebige von dem Anwendungssteuergerät (4) an eine Adresse eines Betriebsgeräts oder Steuergeräts ausgegebene Abfrage auszufiltern, welches angeordnet ist, so dass es von der Seite des drahtgebundenen Netzwerkbusses (6) aus kommuniziert, und die Abfrage daran zu hindern, zu dem einen Betriebsgerät (3) durchgeleitet zu werden, welches angeordnet ist, so dass es von der Seite des asynchron betriebenen Netzwerks (7) aus kommuniziert.
System (1) zur Beleuchtungssteuerung gemäß einem der Ansprüche 1 bis 10, wobei das Netzwerk (7), das unter Verwendung eines asynchronen Netzwerkprotokolls betrieben wird, ein drahtloses Netzwerk ist, wobei ein Netzwerkprotokoll auf der Transportschicht vorzugsweise Thread, Zigbee, Wifi oder Bluetooth/BLE st.
System (1) zur Beleuchtungssteuerung gemäß einem der Ansprüche 1 bis 11, wobei das Eingabegerät (2) und/oder das Betriebsgerät (3) auf der einen Seite, und das Anwendungssteuergerät (4) auf der anderen Seite dazu eingerichtet sind, miteinander über die Reverse Bridge (5) unter Verwendung eines DALI-Protokolls (IEC 62386) zu kommunizieren, wobei der drahtgebundene Netzwerkbus (6) unter Verwendung eines synchronen Protokolls ein DALI-Bus ist und das Eingabegerät (2) und/oder das Betriebsgerät (3), das Anwendungssteuergerät (4) und die Reverse Bridge (5) jeweils mit einer DALI-Netzwerkschnittstelle ausgestattet sind.
System (1) zur Beleuchtungssteuerung gemäß Anspruch 12, wobei das Anwendungssteuergerät (4) und die Reverse Bridge (5) eingerichtet sind, miteinander unter Verwendung von Teil-101 des DALI-Protokolls (IEC 62386-101) zu kommunizieren; und das Eingabegerät (2) und/oder das Betriebsgerät (3) und die Reverse Bridge (5) miteinander unter Verwendung von Teil-104 des DALI-Protokolls (IEC 62386-104) kommunizieren.