Zweck der Integration
Web Master liest den Zustand der Zentrale und der Leuchten über die lokale HTTP-API des EZ2-Adapters, Schema ges-v2. Diese Schnittstelle dient der Überwachung. Das Starten von Tests wird unter Modbus IP beschrieben.
Verbindung vorbereiten
- Zentrale und Integrationsrechner mit einem Netzwerk verbinden, in dem sie miteinander kommunizieren können.
- IP-Adresse der Zentrale notieren. Eine feste Adresse oder DHCP-Reservierung vorsehen.
- In den Einstellungen der lokalen API die Bereitstellung von Leuchtendaten aktivieren. Andernfalls liefern Leuchtenliste und Einzeldiagnose HTTP 403.
- Die Adresse der Zentrale im Browser öffnen. Danach
/data/systeminfo.phpund/lumlist.phpprüfen. - Im Web Master die EZ2-Integration wählen und die Adresse der Zentrale entsprechend der Web-Master-Konfiguration eintragen.
- Die Liste importieren, Geräteanzahl und Standorte mit der Zentrale vergleichen. Fehlerbeschreibungen aus
/data/errorcodes.phpin das Wörterbuch übernehmen.
192.168.1.50 ist nur eine Beispieladresse. Die Dienste gehören in ein vertrauenswürdiges Überwachungsnetz. Diese lokale Schnittstelle benötigt keinen Token; sie darf nicht direkt aus dem Internet erreichbar sein.
Abgerufene Daten
| GET-Anfrage | Format | Verwendung |
|---|---|---|
/data/systeminfo.php |
JSON | Anlagenzustand, Zähler und Datenschema |
/lumlist.php |
TSV, 10 Spalten | Bestand und Leuchtenzustände |
/data/errorcodes.php |
JSON | Fehlerwörterbuch |
/data/luminaire.php?id=196618 |
JSON | Einzelne Leuchte einschließlich NVG-Diagnose |
Vollständige Beispiele und HTTP-Fehlerbehandlung: EZF API.
Geräte eindeutig identifizieren
Die Leuchten-ID ist Kanal × 65536 + physische Adresse. Kanäle: 1 = BUS1, 2 = BUS2, 3 = AirBus. Die physische Adresse 10 ergibt 65546, 131082 beziehungsweise 196618. Das Feld adresse vollständig speichern und nicht auf 16 Bit begrenzen.
Nach einem Wechsel von einer älteren Integration mit reinen physischen Adressen den Bestand neu synchronisieren. Alte Datensätze nach dem Verfahren des Web Masters entfernen, damit keine Duplikate entstehen. Ein Kanalwechsel ändert die ID.
Spalten der Leuchtenliste
| Spalte | Bedeutung |
|---|---|
| adresse | Eindeutige Kanal-/Adress-ID |
| geraetetyp | AW, PIKTO, KOMBI, NVG oder UNKNOWN |
| gruppe | In der Zentrale gespeicherte Gruppennummer |
| ueberwachung | 1 = überwacht, 0 = einzeln von der Überwachung ausgeschlossen |
| schaltungsart | DS = Dauerschaltung, BS = Bereitschaftsschaltung; gegebenenfalls leer |
| betriebszeit | LTM_1H / LTM_2H / LTM_3H / LTM_8H; gegebenenfalls leer |
| letzte_testdauer | Leer, wenn keine gemessene Dauer des letzten Tests verfügbar ist |
| fehlercode | Vier hexadezimale Zeichen |
| ortstext | Standortbeschreibung |
| aktualisiert_am | Leer, wenn kein Zeitpunkt der letzten Aktualisierung verfügbar ist |
Leere Felder weder durch null noch durch das aktuelle Datum ersetzen. Die eingestellte Autonomiezeit ist kein gemessenes Ergebnis des letzten Tests. Bei NVG wird die Schaltungsart nur angegeben, wenn beide Ausgänge übereinstimmen. Bei Kommunikationsverlust bleiben Schaltungsart und Betriebszeit leer.
Prüfung vor der Abnahme
- Anzahl und IDs stimmen mit der Zentrale überein.
- Dieselbe physische Adresse auf BUS1, BUS2 und AirBus ergibt drei unterschiedliche Geräte.
- Gerätetyp und Standort sind erkennbar; Fxxx-Codes besitzen verständliche Beschreibungen.
- Simulierte LED-, Akku- und Kommunikationsfehler werden korrekt angezeigt.
- Fehlende HTTP-Antworten werden als fehlende aktuelle Daten dargestellt.
- Test, Sperre und Suche werden vom Zustand einer fehlerfreien Anlage unterschieden.
Der lokale Simulator unterstützt die Vorbereitung. Zur Abnahme gehören eine reale Zentrale und der vorgesehene Web Master. Siehe Programme und Downloads.