Sporadische Programmverzögerung unerklärbar

[g55]

besten Dank @Black

btw., deinen UseCase hatte ich schon in meinem Beitrag verlinkt ... is wohl dort irgendwie nicht rüber gekommen

[schonwiederich]

Erst mal 1000 Dank für all eure Bemühungen und vor allem Geduld bei so einem unspezifischen Problem.
Das der Fehler nur sporadisch auftritt macht es um so schwieriger. Ich werde die Punkte die ihr vorschlagt mal Stück für Stück angehen. Dazu brauche ich etwas Zeit. Melde mich sobald ich weiter bin.
Danke

[schonwiederich]

Hallo zusammen,

ich komme weiter und weiter
Ein gesamtupdate kommt aber erst wenn ich noch mehr Daten sammeln konnte.

Ich habe eine Zwischenfrage. Ich komme mit dem Timeout und retry nicht zurecht.
Wenn ich es auf dieses wegt hier abändere funktioniert das skript nicht mehr.

Code: Alles auswählen

!Püft ob eine neue FW Version vorhanden ist
var url = "https://gitcdn.xyz/repo/jens-maus/RaspberryMatic/master/release/LATEST-VERSION.js";
! Firmwareupdate auslesen und reagieren (c) by Alchy
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /boot/VERSION");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
var sold = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex("=",1).Substr(0,16);
dom.GetObject("CUxD.CUX2801001:2.CMD_SETS").State("wget -q -T 2 -t 1 - '"#url#"'");
dom.GetObject("CUxD.CUX2801001:2.CMD_QUERY_RET").State(1);
var snew = dom.GetObject("CUxD.CUX2801001:2.CMD_RETS").State().StrValueByIndex("'",1);
if (sold.Find(snew) == 0)
{ dom.GetObject("CCUsysVar_Firmware_Betriebsstand").State(sold);
dom.GetObject("CCUsysVar_Firmware_verfuegbar").State(snew);
dom.GetObject("CCUsysVar_Firmware_Neue_Version_vorhanden").State(false);} 
else { dom.GetObject("CCUsysVar_Firmware_Betriebsstand").State(sold);
dom.GetObject("CCUsysVar_Firmware_verfuegbar").State(snew);
dom.GetObject("CCUsysVar_Firmware_Neue_Version_vorhanden").State(true); };

Lasse ich die wget Zeile auf

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:2.CMD_SETS").State("wget -q -O - '"#url#"'");

stehen funktioniert es.
Was mache ich falsch?

Danke

[Matthias K.]

"-O" fehlt im oberen Aufruf. "man wget" sollte helfen...

[Germa]

Ich lehne mich mal weit aus dem Fenster und behaupte, in 9,9 von 10 Fällen sind sporadische Verzögerungen auf hängende Scripte für externe Abfragen zurückzuführen. Es hilft eben nur, genau diese externen Kommunikationen abzuschalten und ggf. so zu gestalten, dass sie nicht zu Verzögerungen führen. Reine WebUI-Programme verursachen solche Hänger im Allgemeinen (und Speziellen) nicht. Es ist ausschließlich auf Scripting sowie URL-Aufrufe in CUxD-Geräten zurückzuführen. Nicht umsonst bin ich gegenüber exzessivem Scripting (gerade wenn es um externe Kommunikation geht oder dem "Ersatz" von dem System innewohnende Funktionalitäten) so kritisch.

Und die Ursachen für Verzögerungen sind fast immer gleich gelagert. Der angefragte Server ist nicht erreichbar.

ich lehne mich jetzt auch mal aus dem Fenster, dann kommt frische Luft in den Kopf
Ich habe jetzt seit dem Update auf die 3.61.5 am 22.11. und der anschließenden Rückkehr auf die 3.59.6 etliche Aufräumarbeiten getätigt, intensive Fehlersuche betrieben, Optimierungen durchgeführt, häufig getriggerte Programme geloggt (mit dem Skript von Michael N)

nächste Ausbaustufe

DC aufgezeichnet mit Alchys Skript

3. Möglichkeit - direkt per HM-Script - und das soll das eigentliche Thema dieses Threads sein.

ständig das Fehlerprotokoll ausgelesen und verdächtige Kanäle geloggt. Und nun auch noch die Skripte mit externen Abfragen gecheckt und zeitweise deaktiviert.
DAS IST ES ALLES NICHT.

Vor Weihnachten habe ich bei ELV ein Ticket erstellt, dann mein gesamtes Fehlerlog und ein vollständiges backup geschickt - Antwort: Sie benutzen Zusatz-Software, wir können Ihnen nicht helfen. Setzen Sie die CCU auf Werkszustand und richten Sie sie neu ein ..... Sind die besch...? Das würde mich hunderte von Stunden kosten, alles neu einzurichten. Und wird es dem Sachverstand des Herrn Maus gerecht, dass man die Schuld fehlerhafter Firmware auf seine Addons schiebt ......?!

Das, was mich dann wirklich absolut zweifeln lies, war folgendes Beispiel:
Einfaches Programm, Türklingel wird betätigt (Aktor wird ausgelöst)
DANN
Skript:

Code: Alles auswählen

! Bild von Netatmo Presence Kamera holen und auf CCU ablegen
dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("wget -O /usr/local/tmp/Presence.jpg http://192.168.178.29/123456789/live/snapshot_720.jpg");

mit 3 Sekunden Verzögerung zweites Skript (angelehnt an Alchys Skript)

Code: Alles auswählen

! Push mit Meldung und Bildanhang
!
var PUSH_CUXD_ID = "CUX2801002:1";
var USERKENNUNG = "xxxxxxxx";
var TOKEN = "yyyyyyyyy";
var USERDEVICE = "";
var TITEL = "Türklingel"; ! wenn leer wird Name der Applikation des Token mitgeschickt
string MESSAGE = "Es hat geklingelt";
var ATTACHMENT = "/usr/local/tmp/Presence.jpg"; ! Bildanhang MUSS vorhanden sein
var PRIO = "0";
var RETRY = "30"; !Wiederholungen des Alarm bei prio >1
var EXPIRE = "3600";
var SOUND = "pushover";
var HTML ="1"; ! 1 werden HTML Codes verwendet
! Erläuterungen
! userdevice: welches eingerichtete Gerät soll die Meldung bekommen? wenn leer = alle Geraete - sonst Namen komma separiert aneinanderreihen https://pushover.net/ einrichten
! Sounds: pushover, bike, bugle, cashregister, classical, cosmic, falling, gamelan, incoming, intermission, magic, mechanical, pianobar, siren, spacealarm, tugboat, alien, climb, persistent, echo, updown, none
! siehe "https://pushover.net/api#sounds"
!Prioritaeten: 0=Normal; 1=High (AudioVibration auch waehrend quiet hour); 2=Emergency (Meldung Muss bestätigt werden, solange sound/Vibration); -1=Low ; -2=Lowest
! Bei Prio 2: RETRY gibt an (in s), wie oft eine Nachricht vom Server geschickt wird (z.B. alle 30s)
! Bei Prio 2: EXPIRE gibt an (in S), wie lange Nachrichten geschickt werden sollen. Bestätigt der User, stoppt die Benachrichtigung. Beispiel: Alle 30s wird eine Nachricht geschickt, das passiert eine Stunde lang
if ( (dom.GetObject(ID_DATAPOINTS)).Get("CUxD."#PUSH_CUXD_ID#".CMD_EXEC")) { (dom.GetObject(ID_DATAPOINTS)).Get("CUxD."#PUSH_CUXD_ID#".CMD_EXEC").State("curl -s -k -F token='"#TOKEN#"' -F user='"#USERKENNUNG#"' -F device='"#USERDEVICE#"' -F title='"#TITEL.ToUTF8()#"' -F html='"#HTML#"' -F message='"#MESSAGE.ToUTF8()#"' -F attachment=@'"#ATTACHMENT#"' -F priority='"#PRIO#"' -F sound='"#SOUND#"' -F retry='"#RETRY#"' -F expire='"#EXPIRE#"' https://api.pushover.net/1/messages.json");

vor die Tür gestellt, geklingelt, Programm wird ausgeführt, nach über einer Minute kommt die Pushover mit einem Bild, auf dem keiner mehr drauf ist (der Klingelmann ist längst gegangen .....)
Programm über die WebUI ausgeführt (also ohne Klingelaktion), selbe Reaktionsträgheit.

Und jetzt kommts:!!!
Die beiden Skripte im Abstand von 3 Sekunden mit Blacks SDV ausgeführt.

Es geht weiter....
Aktuelles package SDV V4.08.04A hier auf Github

Bild wird ohne Verzögerung erstellt und Pushover direkt geschickt.

CCU neu gestartet, 20 Minuten "erholen" lassen, Programm über Klingel auslösen. Bild wird ohne Verzögerung erstellt und Pushover direkt geschickt.

Mein Fazit:
Das einzige, was wirklich hilft, ist ein Neustart der CCU alle paar Tage, denn sie wird anscheinend einfach laggy und träge!

Würde mich freuen, wenn jemand eine bessere Erklärung / Lösung hat ....

[schonwiederich]

Hallo zusammen,
ich wollte mich bei allen für die Hilfe zu diesem Problem bedanken.

Nach der ganzen Mühe und viel Testerei hab ich den Schuldigen gefunden und dank Euch ja auch das Werkzeug in der Hand wenn es wieder vorkommt.

Der Schuldige war ........................ Die Abfrage zur Firmwareversion die im CCU Script lief!

Was habe ich gemacht.
1. Alle verdächtigen Programme und Verbindungen deaktiviert.
2. Ein Programm auf der CCU erstellt das jede Minute 1 mal eine Variable schreibt.
3. Diese Aktualisierung dieser Variabel in einem IOBroker Script ausgewertet und geprüft ob der Abstand länger als 1 Minute (mit Toleranz 64 Sekunden) beträgt. Wenn ja, schreibe die Sekunden in eine IOBroker Variable, logge diese Variable und sende mir eine Whatsapp wenn Wert größer 64 Sekunden.
Damit wusste ich dann immer wenn es in der CCU zu Programmverzögerungen gekommen ist. Nachzulesen hier: https://forum.iobroker.net/topic/48406/ ... mblockaden
4. Die manuellen URL Response Tests und die Timeout Retry Änderungen in den Scripten durchgeführt wie von Euch Empfohlen.
5. Wann immer die Abfrage des Programms lief welches die Firmware / Update Version der CCU per URL abgefragt hat, kam die Verzögerung zustande.
6. Den Part des Skriptes dann von den anderen Bestandteilen getrennt und als separates Programm 1 mal Nachts ausführen lassen.
7. Siehe da, die Verzögerung kam nur noch zu dieser Zeit in der Nacht zustande.
8. Um diese Verzögerung und zu entfernen habe ich Firmware und Updateversionsprüfung auf den IOBroker ausgelagert und spiele die Inhalte der Variablen in die CCU aus dem IOB zurück. Nachzulesen hier: (Nicht meine Erfindung):https://forum.iobroker.net/topic/21170/ ... gedin=true
9. Keine Verzögerung mehr in meinem CCU Verzögerungstracking aus Punkt 3.
10. Programme wie Wetterdaten etc, wieder Stück für Stück aktiviert und Wochen gewartet. Keine Verzögerung.
11. Zum Schluss noch dem Hinweis von Shartelt gefolgt und die Lichtschalter für die Küche mit Langer und Kurzer Tastenbelegung so direkt verknüpft, dass die Programme nicht mehr nötig waren. (Durch diese Programme auf den Lichtschaltertastern hatte ich die Programmverzögerung ja erst bemerkt)

Fazit: Rundum Verzögerungsfrei und alles im Einsatz was ich brauche.
Zusätzlich kann ich jetzt Überwachen ob es zu neuen Verzögerungen kommt und habe die Werkzeuge um diese zu "bekämpfen"

Vielen Dank nochmal !!!!!!!

[MichaelN]

Der Hinweis auf Programme und skripte kam ja schon ganz am Anfang. Aber das durfte ja nicht sein.

Wie oft hast du denn die FW Version abgefragt?

[schonwiederich]

Zu Beginn alle 5 Minuten mit den Zustandsdaten der CCU.

Später dann 1 mal Täglich.

Und jetzt 1 mal Täglich per IOBROKER

[MichaelN]

Sowas habe ich befürchtet.
Man sollte generell überlegen welche Information wirklich zur Hausautomation benötigt und was nur technische Leistungsschau ist.

[schonwiederich]

Hi Michael,

im Grundsatz bin ich bei Dir.

Ich muss aber auch für die (dazu gehöre ich auch) sprechen, die aus der Leistungsschau eher Wartungs-/Alarmtätigkeiten ableiten.

= Neue Firmware Verfügbar = Update durchführen.

= Auslastung oder Speicher zu hoch = Nachschauen was los ist.

= etc.

Wenn man also die Hausautomationsanlage nicht nur zur "Automatisierung" einsetzt, sondern auch dazu die Technik an sich zu Überwachen und zu Warten, dann machen bestimmte dinge schon sinn, zumal man sie dann auch in einer grafischen Oberfläche darstellen kann.

Ich will keine Grundsatzdiskussion entfachen, sondern nur gegenseitiges Verständnis für verschiedene Ansätze fördern

VG