,

Reolink Ereignisse

4,99 €

Die Kamera meldet, was sie sieht.

Bewegung, Person, Fahrzeug, Tier und Gesicht einer Reolink-Kamera als Schaltausgänge. Dazu Kamerastatus und freier Platz auf der SD-Karte.

In Entwicklung – noch nicht erhältlich. Du möchtest den Baustein vorab testen und uns Rückmeldung geben? Melde dich als Beta-Tester, wir schreiben dir, sobald eine Testversion bereitsteht.

Bald verfügbar

Artikelnummer: smo-reolink-ereignisse-smolabs Kategorien: , Schlagwort:

Beschreibung

Bewegung und KI-Erkennung (Person, Fahrzeug, Tier, Gesicht) und Status einer Reolink-Kamera abfragen.

Gerät
Gira X1
Version
1.0.0
Lizenz
Ein Schlüssel je X1 (MAC-Adresse), dauerhaft nutzbar
Thema
Sicherheit

Hinweis zur Schnittstelle: Der Baustein nutzt die Schnittstelle von Reolink. Ändert der Anbieter sie oder stellt sie ein, kann der Baustein eingeschränkt oder gar nicht mehr funktionieren, bis er angepasst ist. Wir passen ihn nach Möglichkeit an, einen Anspruch darauf gibt es nicht.

Anleitung

Gemeinsame Parameter

Parameter Bedeutung
IP-Adresse der Kamera z. B. 192.168.1.50, bei abweichendem Port 192.168.1.50:8080
Benutzer / Passwort Kamerabenutzer, Vorgabe admin. Empfohlen: eigener Benutzer mit eingeschränkten Rechten
Kanal (Kamera = 0) (ausgeblendet) 0 bei einer Kamera, bei einem NVR die Kanalnummer
HTTPS verwenden (ausgeblendet) Nur nötig, wenn die Kamera HTTP ablehnt. Das Zertifikat wird nicht geprüft (Kameras haben selbstsignierte Zertifikate).
Lizenzschlüssel Der Schlüssel für diesen X1 und diesen Baustein, siehe „Lizenz“

Die Anmeldung erfolgt bei jedem Abruf mit Benutzer und Passwort. Es gibt keine Sitzung, die ablaufen kann.

Ausgeblendete Ein- und Ausgänge und Parameter lassen sich im GPA (Gira Projekt Assistent) am Baustein einblenden.

Abgefragt wird immer dann, wenn der Eingang „Trigger“ den Wert 1 bekommt. Das Intervall bestimmt also das Logikblatt, z. B. mit einem Zyklus-Baustein.

Funktionen und Anschlüsse

Bewegung und KI-Erkennung abfragen, z. B. um Licht, Alarmanlage oder Benachrichtigungen auszulösen. Verwendete Befehle: GetMdState, GetAiState.

Eingänge: Trigger (Bool)

Parameter: IP-Adresse, Benutzer, Passwort, Kanal, HTTPS, Nachlaufzeit in Sekunden (ausgeblendet, Vorgabe 0), Lizenzschlüssel

Ausgänge: Bewegung, Person, Fahrzeug, Tier, Gesicht (ausgeblendet) (alle Bool), Lizenzstatus, Debug (ausgeblendet)

  • Empfohlenes Intervall: 1 bis 2 Sekunden.
  • Person, Fahrzeug, Tier und Gesicht liefern nur bei Kameras mit KI-Erkennung Werte. Bei anderen Kameras bleiben die Ausgänge 0 und „Debug“ zeigt den Grund.
  • Nachlaufzeit: Ein Ausgang bleibt nach der letzten erkannten Bewegung noch so viele Sekunden an, auch wenn die nächste Abfrage nichts mehr meldet. Erkennungen, die vollständig zwischen zwei Abfragen liegen, sieht der Baustein nicht. Dafür ein kurzes Intervall wählen.
  • Ist die Kamera nicht erreichbar, gehen Bewegung, Person, Fahrzeug, Tier und Gesicht auf 0 (nach Ablauf einer laufenden Nachlaufzeit) und „Debug“ nennt den Fehler. 0 heißt dann „keine Auskunft“, nicht „keine Bewegung“. Für Alarmanwendungen zusätzlich „Kamera erreichbar“ auswerten.

Kamerastatus (in beiden Bausteinen)

Beide Bausteine überwachen zusätzlich den Zustand der Kamera. Verwendete Befehle: GetDevInfo, GetHddInfo.

Eingang: Status-Trigger (Kamerastatus, empfohlen alle 5 bis 10 Minuten) (ausgeblendet, Bool). Bei 1 wird der Status abgefragt, unabhängig vom normalen Trigger.

Parameter: SD-Karte Warnschwelle freier Platz in % (ausgeblendet, Vorgabe 10)

Ausgänge (alle ausgeblendet): Kamera erreichbar (Bool), Name, Modell, Firmware (Text), SD-Karte frei in % (Zahl), SD-Karte Störung (fehlt, nicht lesbar oder fast voll) (Bool)

  • Empfohlenes Intervall: 5 bis 10 Minuten.
  • „SD-Karte Störung“ ist 1, wenn keine Karte eingebunden ist, die Kamera keine Kartengröße meldet oder der freie Platz unter der Warnschwelle liegt. Eine Kamera mit Überschreiben der ältesten Aufnahmen (Standard) zeigt trotzdem kaum freien Platz an, die Warnschwelle ist dann entsprechend niedrig zu wählen.
  • Ist die Kamera nicht erreichbar, geht „Kamera erreichbar“ auf 0. Name, Modell, Firmware und die SD-Werte bleiben auf dem letzten Stand.
  • Fehler der Statusabfrage erscheinen am Ausgang „Debug“. „Letzter Befehl erfolgreich“ der Steuerung bleibt den Steuerbefehlen vorbehalten.

Lizenz

Der Lizenzschlüssel wird im GPA im Parameter „Lizenzschlüssel“ eingetragen. Der Baustein prüft ihn beim Start auf dem X1, offline und gebunden an die MAC-Adresse des X1. Der Ausgang „Lizenzstatus“ zeigt das Ergebnis, bei einem Schlüssel für ein anderes Gerät auch die MAC-Adresse dieses X1. Ohne gültigen Schlüssel bleibt der Baustein untätig. In der Simulation des GPA am PC läuft er ohne Lizenzprüfung, damit sich Logikblätter testen lassen. Jeder der beiden Bausteine braucht einen eigenen Schlüssel.

Läuft eine Testlizenz ab, setzt „Reolink Ereignisse“ beim nächsten Trigger alle Ausgänge auf 0, „Reolink Steuerung“ sendet keine Befehle mehr. Beide bleiben bis zu einem neuen Schlüssel untätig. Den Schlüssel erhältst du beim Kauf über smolabs.de.

Changelog

Version 1.0.0
  • Erste Version.

Kompatibilität mit Gira X1 und Gira HomeServer

Die Funktion ist nur für die hier genannten Firmwarestände zugesichert. Vor einem Firmware-Update des Geräts bitte diese Tabelle prüfen.

Baustein-VersionGerät und FirmwareStatus
1.0.0Gira X1, Firmware 4.0.350Kompatibel
1.0.0Gira X1, Firmware 3.0.52Kompatibel
1.0.0Gira X1, Firmware 2.8.874Kompatibel
1.0.0Gira X1, Firmware 2.8.869Kompatibel
1.0.0Gira X1, Firmware 2.8.858Kompatibel
1.0.0Gira X1, Firmware 2.7.585Kompatibel

Rezensionen

Es gibt noch keine Rezensionen.

Schreibe die erste Rezension für „Reolink Ereignisse“

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen