Hallo seit dem letzten Update habe ich Probleme mit der Anzeige des Dashboards nur noch auf Gladys Plus.
Bin ich der Einzige?
Lokal gibt es dagegen keine Probleme 
Ich würde die Logs herausholen, wenn ich an einem PC bin ^^
@spenceur Ist das nicht das gleiche Uhrzeitproblem wie beim letzten Mal? Ich nehme den Fehler gerne, wenn du ihn hast, ja!
Ich habe keine besonderen Fehler bei Gladys Plus gesehen und bei mir funktioniert alles.
Bei mir gibt es keine Probleme mit der Anzeige.
Allerdings habe ich weiterhin Probleme mit Szenen, bei denen falsche Werte abgerufen werden, und das ist ziemlich zufällig.
Mein Haus scheint immer noch leer zu sein, Fake-Geräte mit Ein-/Ausschaltknöpfen geben keine Werte zurück (weder 0 noch 1), usw.
Ich werde alle Szenen überprüfen und an jeder Stufe eine Nachricht senden, um zu sehen, wo es hakt..
Also glaube ich nicht, dass das hier der Fall ist (ich habe das Problem auf dem Handy )
Manchmal aktualisiere ich und habe meine Schaltflächen, aber wenn ich ein Licht einschalte oder meinen Alarm deaktiviere, passiert nichts. Ich muss neu aktualisieren und erneut klicken.
Ich würde gerne die Ergebnisse deiner Untersuchung sehen 
Zögere nicht, ein spezifisches Thema zu erstellen, das wird vielleicht einfacher sein, um dir zu helfen!
Hast du den Fehler überall? Auf dem Handy und auf deinem Computer, sogar in verschiedenen Browsern?
Ich würde gerne die Browser-Logs sehen, ohne Informationen ist es schwer zu helfen
@pierre-gilles, ich habe vielleicht eine Spur entdeckt. Einige Szenen stoppten mitten im Ablauf ohne ersichtlichen Grund. Die Telegramm-Nachrichten in jeder Phase haben mir das bestätigt.
Ich habe eine Szene getestet, die einen Stecker über ewelink ein- und ausschalten sollte, aber es gab keine Reaktion.
Ich habe also den Schalter von « einfach » auf « berechnet » umgestellt, wobei ich den Wert beibehalten habe. Sie begann zu funktionieren. Als ich wieder in den einfachen Modus zurückkehrte, funktionierte es erneut.
Ich kann dir den Grund dafür nicht nennen.
Ich werde morgen früh sehen, ob meine Markisen-Szene mit diesem Trick auch behoben ist.
Ok, es gibt offensichtlich ein Problem mit der neuen Aktion „Gerät steuern“
Falls du noch weitere Infos hast, zögere nicht, das würde beim Debuggen sehr helfen
Das sieht sehr nach einem Bug aufgrund des Wechsels zum neuen Szenenformat mit Berechnung aus. Im neuen einfachen Modus gibt es wahrscheinlich eine Verarbeitung, die nur den als links in der Formel angesehenen Teil berücksichtigt und den rechts berechneten Teil ausschließt. Mit dem alten Format denke ich, dass die Fehlerbehandlung auf der leeren Seite fehlt. Beim Wechsel in den berechneten Modus gab es eine Speicherung im neuen Format, die das Problem löst, und beim Zurückwechseln in den einfachen Modus ist es dasselbe…zu überprüfen. Ich hätte es gerne gemacht, aber ich weiß nicht, welches Modul betroffen ist.
Ich bestätige, dass das mein Problem löst. Alle meine Rollläden haben sich heute Morgen wie gewohnt geöffnet.
Es betrifft tatsächlich die Ewelink-Schalter in „Gerät steuern“, aber auch Fake-Geräte, die in MQTT erstellt wurden:
Als ich auf „berechnet“ umstellte, war das Feld bei einigen davon leer. Ich habe also den Wert 0 angegeben und das scheint das Problem zu beheben.
Ich weiß nicht, wo ich weiter suchen soll, um das Problem zu identifizieren ..
In Bezug auf die Kameras, haben die Änderungen, die ich vorgenommen habe, die Latenz für alle verbessert? Ich bin offen für Feedback 
Ah, das ist tatsächlich ein bekannter Bug, der aber relativ schnell nach dem Release behoben wurde:
Was passiert sein muss, ist, dass du die Szene geöffnet hast, als der Bug noch vorhanden war, und du sie gespeichert hast, wodurch das Feld überschrieben wurde…
Ich sehe, dass du eine Nachricht hinterlassen hast, in der du sagst, dass du den Bug hattest:
Es ist also sehr wahrscheinlich, dass es das war
Ja, wahrscheinlich.
Das war in einem „Nur wenn“ leicht zu erkennen, da der Wert 0 nicht mehr angezeigt wurde, aber mit einer Gerätesteuerung sieht man nicht, dass die 0 fehlt, wenn der Schalter auf „Aus“ steht. Nur der Modus „Berechnet“ zeigt das an. 
Also nichts Ernstes dann ..
Bei mir zu Hause bufferisiert das Video heute Abend jedenfalls sehr oft. Egal, ob über Gladys Plus oder lokal.
Bei meiner Live-Kamera habe ich das Problem nicht.
Und bei Gladys Plus sehe ich keine Verbesserung der Verzögerung im Vergleich zum Live-Stream.
Eine andere Frage:
Meine Kamera bietet einen Stream über Websockets an, der reaktionsschneller und fast in Echtzeit im Vergleich zum RTSP-Stream ist. Wird das von der Bibliothek unterstützt, die du verwendest, oder nicht?
@lmilcent Okay, wir müssen Schritt für Schritt herausfinden, wo die Latenz herkommt!
Wenn du den RTSP-Stream über VLC abspielst, wie groß ist die Verzögerung? Wir müssen Schritt für Schritt vorgehen, wenn es lokal schon nicht gut ist, wird es über Gladys Plus sicherlich nicht besser
Ich denke, hier liegt das Problem lokal.
Wir verwenden ffmpeg zum Lesen der Streams (FFmpeg Protocols Documentation), die Liste der Protokolle scheint Websocket nicht zu enthalten, aber ehrlich gesagt lohnt es sich zu versuchen. Wie sieht die URL deines Streams aus?
Mein Kommentar zur Latenz steht auch in Verbindung mit dem Update-Versuch, um sie zu reduzieren.
Vor dem Update war es flüssig ohne Unterbrechungen, aber mit einer Verzögerung von etwa 20 Sekunden. Nach dem Update stoppt es ständig.
BERICHTIGUNG Die Verzögerungen schienen durch meine Kamera verursacht zu werden. Neuer Test am Sonntagmorgen, und kein Buffering mehr.
Kontext
Ich habe eine Kamera mit der Camera Pi 3 Wide und dem folgenden Open-Source-Projekt erstellt, das mir WebRTC-, RTSP- und MP4-Streams liefert:
https://github.com/bluenviron/mediamtx
Test 1: RTSP-Stream mit VLC
URL: rtsp://192.168.1.84:554/cam
Latenz: Zwischen 3 und 7 Sekunden Verzögerung festgestellt.
Test 2: HLS-Stream (m3u8-Datei und MP4-Format)
URL: https://192.168.1.84:8888/cam/ im Webbrowser und https://192.168.1.84:8888/cam/index.m3u8 auf Gladys.
Latenz: Zwischen 2 und 5 Sekunden festgestellt.
Die Browserkonsole zeigt mir etwa 2 MP4-Dateien pro Sekunde an. Ich weiß, dass die Konfiguration des Servers, der die Kamera verwaltet, auch auf meiner Seite angepasst werden kann, um die Größe dieser „Pakete“ und ihre Häufigkeit zu ändern.
Test 3: WebRTC-Stream
URL: http://192.168.1.84:8889/cam/. Die Konsole zeigt die Verwendung von WebSockets mit ws://192.168.1.84:8889/cam/ws an.
Latenz: fast keine.
Genial, danke für den Test Und kannst du dann welche Datenströme in Gladys nutzen?
Edit: Ich habe gerade gesehen, dass das auf Hackernews vorbeigekommen ist: WebRTC-Unterstützung in ffmpeg mit einer großen Verbesserung der Latenz!
Ich bin’s wieder @pierre-gilles 
Ich habe es erneut über Gladys Plus getestet und bestätige, dass die RTSP-Streams flüssig sind, während die gleichen HLS-Streams (.mp4) stark puffern.
Ich hatte auch diesen Fehler, ich denke, das ist damit verbunden:
Ok, super! Die Latenz in RTSP ist wirklich nicht schlecht
Stimmt, HLS über HLS zu machen, ergibt nicht viel Sinn und verursacht Pufferung. Der Fehler, den du siehst, ist tatsächlich ein Pufferungsfehler Bleib bei RTSP!
Ich habe einen kleinen Bug zu melden. Entweder ist es temporär oder der unvorhersehbare Bug 
Kontext: Meine Kamera ist ein Raspberry Pi 3, am Micro-USB-Port. Mein Sohn wollte sie verstecken, um zu spielen, und hat den Rpi für ein paar Sekunden zum Absturz gebracht.
Der Videostream ist gestoppt und nach einigen Sekunden wieder gestartet (kein Neustart).
Auf Gladys-Seite (Plus oder lokal) hat sich das Live-Video einige Sekunden vor der Trennung neu gestartet und dann endlos gepuffert.
- Seite neu laden ==> Gleiches Verhalten
- Live-Stopp und -Neustart ==> Gleiches Verhalten
- Manuell auf „Testen“ in der Kamera-Integration drücken ==> Nichts ändert sich
Erst nach mehreren Minuten hat sich das Live-Bild von selbst getrennt und schließlich die Verbindung wiederhergestellt.