ein Vorschlag: Hast du vor, etwas im Bereich ONVIF zu machen, um Kameras ein- und auszuschalten?
Aktuell habe ich folgende Konfiguration:
Meine Kameras sind mit meinem Syno verbunden (ONVIF-Protokoll)
Ich habe ein Gladys-Modul erstellt, das sich mit der Synology-API für den Stream und die Grundsteuerung (Ein-/Ausschalten der Kameras) verbindet
Damit kann ich über Szenarien die Kameras einschalten, wenn ich das Haus verlasse, und sie ausschalten, wenn ich zurückkomme. Das erfüllt meinen Bedarf.
Aber ich stelle mir vor, dass es möglich sein muss, von Gladys aus über ONVIF mit den Kameras zu interagieren. Dadurch könnte jede Kamera nativ mit Gladys kompatibel gemacht werden. Was denkst du darüber?
Ich denke daran, weil du an den Stream-Feeds arbeitest, aber vielleicht ist es eher ein Service, der entwickelt werden muss, als eine native Funktion wie die, an der du gerade für die Feeds arbeitest.
@pierre-gilles: Die Idee von @link39 gefällt mir sehr, die Kamera bei unserer Anwesenheit zu aktivieren/deaktivieren. Ich würde diese Möglichkeit auch gerne haben Ich habe auch einen Synology.
Wenn du einen Synology hast, kannst du mein Modul verwenden: GitHub - link39/gladys-synology-camera: Control your synology surveillance station camera from gladys · GitHub
Damit kannst du die Kameras erkennen, die mit deiner Überwachungsstation verbunden sind, und sie aktivieren/deaktivieren. Für den Streaming-Betrieb benötigst du eine Überwachungsstation in Version 8.1, da die neueren Versionen den Stream nicht mehr unterstützen. Es gibt ein Thema im Forum, falls du mehr Informationen dazu möchtest.
Meine Idee für die V4 war eher etwas, das direkt mit ONVIF verbunden ist, was es ermöglichen würde, fast jede Kamera zu steuern
Derzeit ist es verzögert. Live-Updates sind möglich, aber dafür müssen wir mehr recherchieren und experimentieren, um sicherzustellen, dass die Hardware mitspielt und dass das Netzwerk bei allen funktioniert.
Das ist eine ganz andere Hausnummer, und ich bleibe bei der Philosophie von Gladys 4: „Wir machen weniger, aber was wir machen, machen wir gut“.
Derzeit habe ich ein Bild-Update alle 60 Sekunden eingestellt.
Man muss einen Kompromiss finden zwischen „zu altem Bild“ und „Überlastung der Hardware und der Benutzeroberfläche“.
Da es sich hier nur um ein Vorschaubild handelt, um einen Blick in den Raum zu geben, denke ich, dass 60 Sekunden weder zu häufig noch zu alt sind. Gebt mir eure Meinung dazu
Okay, eine Funktion, auf die ich ziemlich stolz bin: Man kann Gladys in Nachrichten nach einem Kamerabild fragen!
Vielleicht nicht ganz themenbezogen
Es wäre gut, den Namen des PUSH-Knopfes anpassen zu können
Statt „PUSH“ auf dem Knopf zu schreiben, könnte man die Funktion schreiben. Derzeit ist das in der v3 nicht möglich
Für mich ist das ein bisschen lang. Wäre es möglich, eine Standardfrequenz, z. B. 60, einzurichten und dem Benutzer die Möglichkeit zu geben, die Frequenz nach Bedarf anzupassen? Je nach Maschine, die Gladys ausführt, wird die Hardwareauslastung unterschiedlich sein.
Ich gebe zu, dass ich nicht begeistert davon bin, überall Parameter einzufügen. Das erhöht die Komplexität der App in Bezug auf die Benutzeroberfläche und das Verhalten. Der Benutzer sollte sich nicht mit solchen Implementierungsparametern auseinandersetzen müssen.
Zur Information arbeite ich heute an der Benutzeroberfläche von Z-Wave.
Ich würde mir gut ein Bild alle zwei Sekunden vorstellen. Ich weiß nicht, ob eine Pi das technisch unterstützen wird. Es ist kein Live-Stream, aber es ermöglicht ein Bild zu haben, das sich schnell genug ändert, um zu wissen, was zu Hause passiert, z. B. wer an der Tür klingelt.
Ich stimme zu, dass man keine Maschine mit so vielen Einstellungen haben sollte, dass man nicht mehr weiß, was man tun soll. Aber wenn die Aktualisierungsrate nicht passt und man sie nicht ändern kann, werden die Nutzer die Lösung nicht verwenden, oder sogar denken, dass sie nicht funktioniert, weil das Bild nicht schnell genug wechselt.
2 Sekunden erscheinen mir immer noch viel ^^ das macht 43.000 Aktualisierungen pro Tag Na gut, man kann diese Option immer noch in der Alpha-Version einbauen, um sie in der Praxis auf verschiedenen Geräten zu testen. Wenn sich herausstellt, dass es zu viel ist, entfernen wir die Option.
Ich bin mir nicht sicher, ob ich das richtig verstehe, wir sind uns doch einig, dass RTSP ein Echtzeit-Streaming-Stream ist, warum also eine Aktualisierungsverzögerung einfügen? Gibt es keine Möglichkeit, direkt zu streamen und Gladys einfach als eine Stream-Gateway zu nutzen?
Ein RTSP-Stream kann nicht von einem Browser gelesen werden, er muss zwangsläufig auf der Gladys-Server-Seite umgewandelt werden.
In Gladys 3 hatte @piznel ein Modul erstellt, das einen RTSP-Stream über WebSockets an einen Browser streamt. Das einzige Problem ist, dass es CPU-intensiv ist und wenn man nicht die richtigen Mechanismen implementiert, wird ständig konvertiert und der Raspberry Pi läuft die ganze Zeit, auch wenn der Browser nicht geöffnet ist.
Zusätzlich muss sichergestellt werden, dass die Implementierung auch funktioniert, wenn man über das Gateway geht.
Grundsätzlich ist es nicht so kompliziert, es gibt keine technischen Blockaden, aber die Philosophie der v4 ist „wir machen wenig, aber was wir machen, machen wir gut“.
Fangen wir mit statischen Inhalten an, und wenn wir mehr Erfahrung haben und mehr Tests auf verschiedenen Hardware- und Netzwerkkonfigurationen durchgeführt haben, können wir auf Live gehen.
Ich habe auch einen Synology.
Na gut, man kann diese Option immer noch in der Alpha-Version einbauen, um sie in der Praxis auf verschiedenen Geräten zu testen. Wenn sich herausstellt, dass es zu viel ist, entfernen wir die Option.