Hallo Ralf,
vielen Dank für den Tipp. Ich habe hier nur eine MQTT-Instanz mit dem Tasmato-Modul von KaiS laufen. Die sieht aber unauffällig aus…
Gibt es eine Anleitung zur Installation der oben genannten Tools auf einem Raspberry Pi?
Joachim
Ist das Problem eigentlich auch über den Connect-Dienst nachstellbar? Könnte ich also mich von hier aus auf dein System Konsole + WebFront einloggen und das Verhalten auch sofort sehen? Oder dauert es ein wenig bis dies passiert?
paresy
Hallo Paresy,
hab es gerade noch mal getestet: Wenn ich irgendein Skript aufrufe dauert es bei der ersten Ausführung sehr lange, danach geht es bei jeder Ausführung gefühlt etwas schneller, ab der vierten Ausführung geht es super schnell…
Ich weiß aber nicht ob Du es über den Connect-Dienst sehen kannst…
Joachim
Hallo Leute,
seit einigen Tagen reagiert auch mein IP Symcon 6.1 testing auf einem Raspberry 4 mit 4 GB in einigen Bereichen sehr langsam.
Schalten über das Webfront läuft verzögerungsfrei. Über Alexa ebenfalls.
Die Ausführung von Skripten dauert teilweise mehrere Minuten.
Bei den PHP Informationen finde ich zeitweise nur 1-4 laufende Skripte die rot hinterlegt sind (ich habe max. 50 Skripte zeitgleich zugelassen).
Im Meldungsfenster werden dann auch keine Meldungen mehr angezeigt.
Das Debug-Fenster von dem Homematic Socket bleibt leer, auch wenn ich z.B. die Stehlampe per Alexa schalte und diese auch sofort reagiert. Schalte ich dagegen die Küchenlampe mit einem Homematic 6-fach Taster, wird diese Betätigung in IP Symcon überhaupt nicht erkannt, obwohl die Betätigung auf der Homematic Weboberfläche sofort erkannt wird.
Ein Neustart des Dienstes behebt das Problem nur für einige Minuten.
Hat jemand eine Idee?
Grüße aus dem Norden
Axel
Hallo Axel,
da bin ich ja ein Stück weit beruhigt das ich nicht der Einzige bin…
Prinzipiell läuft alles, aber die teilweise massive zeitliche Verzögerung bei der Ausführung eines Skriptes ist schon nervig. Mittlerweile starte ich mindestens einmal am Tag neu.
Eine typische Szene:Receiver auf „FireTV“, hört man sofort durch leises klicken, das Skript das dabei die Ansicht im Webfront verändert dauert so lange das man schon andere Wege sucht, Beamer ein, regiert sofort, die Leinwand - die automatisch herunterfahren soll wenn der Beamer „An“ meldet wird oft gar nicht mehr ausgeführt. Mehrmals „Stop“, „Öffnen“, „Schließen“ - irgendwann läuft es…manchmal Stop der gestartet Timer dann aber nicht automatisch und die Leinwand fährt so lange herunter bis nichts mehr auf der Rolle ist - der WAF sinkt dabei schneller als der DAX am Black Friday…
Joachim
Dieses Tool ist nicht mehr relevant, da die Metriken des Prometheus Moduls diese ab IP-Symcon 6.1 integriert haben!
Da ich gerade für diese Problemstellung ein kleines Tool entwickelt habe, wollte ich es allen anderen nicht vorenthalten:
Damit kann man recht gut analysieren, was auf dem WebSocket Rückkanal so passiert und wer ggf. der Übeltäter ist.
paresy
@Hallo Paresy,
gibt es das Modul auch für Windows?
Das sollte prinzipiell unabhängig vom Betriebssystem sein, du brauchst allerdings Node.js (https://nodejs.org)
hast du eine Idee dazu was wir hier in dem Screenshot von der WebSocket Aufzeichnung erkennen können ?
Kannst du das bitte erklären.
Danke
Hi! Kannst du mir noch kurz sagen, ob das ein Screenshot von deinem Live-System ist? Denn laut Grafana solltest du eher 200 Nachrichten pro Sek. empfangen? Oder stimmt nur die msg/s Berechnung nicht?
paresy
Hi,
ja das ist vom LiveSystem.
Aber nochmal die Frage, warum tauchen dort so viele selbe IDs auf ?
Gruß
Die größten Nachrichten (1. Block) können ja auch alle von der selben ID kommen. Somit können dort mehrfach die selben IDs vorkommen.
Der 2. + 3. Block sind die Anzahl der Nachrichten je nach Nachrichten Typ und dann je nach SenderID.
Bleibt es bei dir immer bei den 5 msg/s? Oder ist das grad nur Zufall?
paresy
Hi,
das verstehe ich nicht so ganz. Wie könnte von der Selben ID zur gleichen Zeit Daten aktualisiert werden?
Womit hängt das zusammen ? Das würde doch heißen das mehrere Verbindungen bestehen ?
Ja, die Anzahl der Nachrichten bleiben relativ so in diesem Bereich.
Gruß
Ich verstehe deine Schlussfolgerung nicht. Die größten Nachrichten ist einfach eine Sammlung. Die sind nicht gleichzeitig gekommen, sondern irgendwann während der gesamten Laufzeit dieses Tools.
paresy
Ahhh ok, das war mir nicht bewusst.
Aber ich verstehe immer noch nicht wie du denn auf die Ansammlung kommst.
Ich verstehe das so, das doch geschaut werden soll welche Variablen über den WebSocket immer aktualisiert werden sollen. Daher sieht das für mich so aus als würden mehrere Variablen Aktualisierungen über den WebSocket laufen.
Also den Sinn von dem Hilfsscript ist mir gerade überhaupt nicht klar.
Gruß
Es laufen sogar alle Aktualisierungen über den Socket. Das Tool ist für diverse Zwecke Interessant. Für dich ist wahrscheinlich die „Busy IDs“ Sektion die relevante. Du möchtest ja sehen, wer die meisten Nachrichten versendet.
Kannst du mir ggf. mal deine Zugangsdaten für den Fernzugriff per PM zusenden? Ich würde dann das Tool einfach ebenfalls mal laufen lassen und schauen, ob dort mit den Nachrichten pro Sekunde etwas nicht stimmt - denn irgendwie gibt es ja eine Abweichung zu den Statistiken die in Grafana zu sehen sind.
paresy
PS: Ich bin aktuell dabei eine Erweiterung des MessageQueueWatch Spezialschalters zu entwicklen, woman man tracken kann, welche Instanzen genau am meisten Zeit bei der Verarbeitung benötigen. Das sollte für deine Verzögerungen ebenfalls helfen eine Analyse durchzuführen.
Hallo Paresy,
ich habe nun alle meine Module durchforstet und hinsichtlich der SetReceiveDataFilter und der SetStatus überarbeitet.
Das System läuft jetzt sehr viel besser und reagiert deutlich schneller!
Eine Auffälligkeit habe ich noch gesehen und zwar sehr viele „VM_CHANGEPROFILEACTION“. Das rührt wahrscheinlich hieraus:
If ($State == false) {
$this->EnableAction("State");
}
else {
$this->DisableAction("State");
}
Um das nicht immer wieder „unnütz“ zu machen (im Modul würde das so mehrmals pro Sekunde geschehen) habe ich mir folgendes Konstrukt überlegt:
If (HasAction($this->GetIDForIdent("State")) <> !$State)
If ($State == false) {
$this->EnableAction("State");
}
else {
$this->DisableAction("State");
}
}
Sieht nicht besonders „schön“ aus, geht es auch besser?
Aktuell sieht die Auswertung so aus:
Joachim
Eine Randbemerkung:
HasAction prüft nicht ob die Standardaktion vorhanden ist oder nicht.
Vielmehr wird zusätzlich auch eine vom User eingetragene ‚Eigene Aktion‘ mit berücksichtigt.
Somit könnte deine Prüfung mit HasAction nicht in deinem Sinn sein.
Besser wäre es dann vielleicht eine Prüfung mit IPS_GetVariable?
https://www.symcon.de/service/dokumentation/befehlsreferenz/variablenverwaltung/ips-getvariable/
if (IPS_GetVaribale($this->GetIDForIdent("State"))['VariableAction'] == 0) //keine Standardaktion aktiv
Michael
Der Vorschlag von Michael sieht noch schlechter aus, ist aber die korrekte Variante 
Ansonsten sieht es bei dir in den Grafana Charts sehr gut aus. Um 16:00 gab es einen sehr großen Ausreißer. Evtl. hast du da ja was gemacht
paresy
Hallo Paresy,
das Ganze hat schon eine Menge gebracht.
Ein Punkt habe ich noch wo ich aktuell etwas ratlos bin:
Ich habe ja diverse Instanzen die über einen Software-Client-Socket mit PiGPIO kommunizieren (das macht es mir deutlich einfacher Kommando und dazugehörige Antwort „beisammen“ zu halten). Da ich auf eine Kommando eine genau definierte Anzahl von Zeichen erwarte ist dieser entsprechend aufgebaut. Um sicherzustellen dass jedes Kommando einzeln abgearbeitet wird habe ich in dieser Funktion ein Semaphore gesetzt, dieses war eine gefühlte Ewigkeit auf 300ms gestellt, was nie zu Problemen geführt hat. Im Zuge der aktuellen Fehlersuche bin ich irgendwann darauf gestossen, dass dieses - aus mir unerfindlichen Gründen - jetzt viel zu kurz war und habe es testweise auf 3000ms hochgestellt. Jetzt laufen die meisten Dinge - u.a. auch die eingangs erwähnte Leinwand - wieder.
Ich habe testweise auch auf einem der diversen Raspberry Pi die ich dafür benutze auf eine frühere Version von PiGPIO zurückgestellt - ohne sichtbaren Erfolg.
Kann es sein dass sich hinsichtlich des PHP-Client-Sockets irgendetwas signifikant geändert hat? Warum dauert das jetzt solange?
Joachim