IPS-Console / Fehler - Der Bereich der Nachricht ist größer als der Nachrichtenpuffer

Hi!

Wenn ich das Meldungen-Fenster zu lange offen lasse (Mittelungen Limit = default = 1000) und zu viele (oder eine bestimmte!?) Skript-Ausgabe (vmtl. HTMLBox) mit zuviel Text kommt, dann fängt die IPS-Console erst an zu hängen, zeigt immer wieder „Keine Rückmeldung“ - manchmal erholt sich die IPS-Console wieder, manchmal aber nicht und diese Meldung kommt und ich muss die IPS-Console neu öffnen.

ips-console_nachrichtenpuffer.jpg

Könnt ihr das irgendwie abfangen/verhindern? Wenn man schaut, ob Probleme/Fehler im Log auftauchen und dem Meldungen-Fenster zuschaut, dann passiert mir das regelmäßig im Abstand von wenigen bis einigen Minuten.

Danke und Grüße,
Chris

Abfangen nicht wirklich. Es wäre eher Spannend was passiert, dass die Konsole „blockiert“. Und wenn ich das löse, würde das andere Problem mitgelöst.

paresy

Ich vermuuute, dass es an der kompletten Ausgabe von HTMLBoxen hängt?! Bei der alten IPS 3.4 Console musste man so lange Texte ja immer extra anklicken, damit man alles sieht. Bei der neuen IPS 4 Console wird teilweise über mehrere Seiten eine Ausgabe gemacht im Meldungen-Fenster und das scheint das Problem zu sein.
Kann es aber bisher nicht konkret nachstellen.

Ich habe ein Skript, damit kann ich zumindest das extreme hängen nachstellen. Und wenn davon ein paar laufen oder da mal mehr drin ist, dann gibt es vmtl. den Crash. Leider ist die Seite die ich da Abfrage mit Anmeldung, sonst könnte ich dir das Skript geben.

Man braucht eine Seite mit viel Inhalt, damit im Meldungen-Fenster min. 1 oder mehr Seiten mit dem einen Log Eintrag gefüllt werden und dann passiert das. Finde nur leider spontan keine andere Seite mit so viel Inhalt…

Edit: Oder einfach mal eine Webseite auslesen und den Skript x-Mal nacheinander hängen mit einer Schleife und in eine Variable schreiben :smiley: Probier ich gleich mal aus…

Grüße,
Chris

Soooo…zumindest die Hänger kann man damit nachstellen…

<?
$test = file_get_contents('http://www.welt.de');

for($i=0; $i<1; $i++)
{
	$test .= $test;
}

SetValue(12345, $test);  // Hier die ID von einer STRING-Variable eintragen
?>

Wenn ich das manuell ausführe und ins Meldungen-Fenster wechseln will, dann hängt die Console schon mit „Keine Rückmeldung“, hat sich aber dann wieder gefangen. Aber denke das ist das Grund-Problem und wenn das zu viel wird, dann crasht die Console…

Kann ich beliebig oft nachstellen mit diesem Skript.

Grüße,
Chris

Hm. Ist natürlich unschön, aber ich kann eher schwer was dagegen zu tun. Es betrifft ja zum Glück nicht Dienst. Der sollte ohne jegliche „Pausen“ weiterarbeiten.

paresy

Früher wurde die Ausgabe doch auch auf eine bestimmte Länge verkürzt und mit „…“ beendet.

Das sollte in der Console doch reichen. Details kann man sich bei Bedarf doch im Logfile direkt ansehen.

Aber auch früher konnte ich diese Meldung der Console schon ‚geplant‘ provozieren.
Ist also nix neues :smiley:
Michael

Eine crashende Console finde ich jetzt auch eher unschön :smiley:

Mir würde es auch absolut ausreichen, wenn in der Console irgendwann abgeschnitten wird und wenn man mehr sehen will, dann schaut man ins Log. Ich brauche keine Ausgabe von einem Skript über 1 oder 2 Seite von einer HTMLBox-Variable :smiley: Eine halbe Seite oder so reicht völlig :slight_smile:

Grüße,
Chris

Hallo Leute,

ich habe diese Meldung auch gerade, aber im Webfront.
Wollte das neue Heating-Modul ausprobieren. Zuerst die PHP-Componenten konfiguriert und dann ins Webfront übernommen. Die Solltemperatur stand auf 17°C. Als ich diese über den Pfeil nach rechts hochstellen wollte kommt die Meldung. Anschließend startet das Webfront neu und hört nicht mehr auf, ohne dass ich irgend etwas anklicke. Ich kann das Webfront auch kurzzeitig bedienen, aber es startet ständig neu. Werd jetz mal den Dienst beenden.

Man, das war ganz schön hart. :mad:
Ich konnte das gesamte System nicht mehr bedienen. Nach dem Start der Console schmierte diese ebenfalls nach einigen Sekunden ab.
Hab dann durch mehrmaliges neu starten des Dienstes und daktivieren sämtlicher Spezialschalter das Heating-Control wieder gelöscht.
Jetzt läuft alles wie immer.

Was kann das denn sein? Hab mal das log angesehen. Da gibt es 1000de Zeilen

22:51:52 | 53960 | DEBUG   | VariableManager      | [Scripte\Heizungssteuerung\Heating Control Küche\Vorrang] = false
22:51:52 | 38692 | DEBUG   | VariableManager      | [Scripte\Heizungssteuerung\Heating Control Küche\Absenkung] = false
22:51:52 | 53960 | DEBUG   | VariableManager      | [Scripte\Heizungssteuerung\Heating Control Küche\Vorrang] = false
22:51:52 | 38692 | DEBUG   | VariableManager      | [Scripte\Heizungssteuerung\Heating Control Küche\Absenkung] = false

Irgendwas scheint dort endlos schalten zu wollen. Weißt du noch, was du im Heating Control eingestellt hat?

paresy

Ich habe die Isttemperatur, welche durch ein HMS Gerät zur Verfügung gestellt wird, angegeben,
Als Sendinstanz ein HM Schalter invertiert, Hysterese 0,4, Absektemp 5.
Dann habe ich die Solltemperatur gesucht und diese als Variable außerhalb des Formulars im Objektbaum gefunden aber auf 0 stehen lassen.
Die gesamte Instanz habe ich dann als Link ins Webfront übernommen. Die Solltemp. stand auf 17°C.
Nach der Veränderung dieser über das Webfront gingen die Probleme los.
Vorrang- und Absenk-Variablen hatte ich glaube ich noch nicht gesetzt. Sollte ja ein erster Test sein. :wink:

Hallo Zusammen,

habe leider die gleiche Fehlermeldung in meiner Verwaltungskonsole:

„Der Bereich der Nachricht ist größer als der Nachrichtenpuffer“

Das Verhalten ist momentan so, dass die Konsole immer träger wird. Rechtsklick Menü öffnet erst nach 20 Sekunden.
Wenn die Konsole neugestartet wird, klappt es ca 5 Minuten lang, anschließend fängt das Träge wieder an.

  • Habe jetzt in den Spezialschaltern mal das Überwachen für Variablen usw deaktiviert. Nachrichtenpuffer auf 16384 testweise gestellt.
  • Lokale Logs gelöscht und neu erstellen lassen (unter 1MB groß)
  • Teamvierer QuickConnect Ausnahme für ips_console.exe hinzugefügt

Momentan ist es mir nicht mehr möglich über die Konsole zu arbeiten. Fehler tritt wie oben beschrieben sehr schnell auf.

Hier noch ein paar Daten zu meinem System:

  • Win10
  • IPS 4.10
  • 1099 Variablen
  • IPS Datenbank 1MB
  • Skripte 78

Hoffe auf Hilfe, da ich wie gesagt, die IPS Konsole nicht mehr nutzen kann aktuell.

Edit: Hab grad gesehen, dass es wohl an hoher CPU Last liegt.
Siehe Thema: Lokale Console mit hoher CPU Last Thread.

Verfolge somit diesen und hoffe auf einen schnellen Fix.

Gruß
Benjamin

Gleiches Verhalten bei mir seit 4.1. CPU-Last ist normal. Client-PC: Win 10, I3 mit 2.9GHz, 8GB Ram, SSD, LAN zum IPS-PC ist durchgehend Gigabit.

Es kann auch sein, dass euer System einfach zu viele Meldungen generiert. Ihr könnt über die Spezialschalter den Puffer von 8096 auf z.B. 16416 verdoppelt. Das sollte auch helfen!

paresy

Ich hatte das Problem auch, nachdem ich Philips Hue eingebunden habe, und habe tagelang gekämpft damit:

Zuerst hat IP-Symcon begonnen sich aufzuhängen (Totalabsturz -> nur noch HW-Reset war möglich).
Das ist inakzeptabel.
Vorher ist mir IPS 3 Jahre ohne Hänger gelaufen. Das erwarte ich auch von einer Server-App, die von zentraler Bedeutung ist. Das war einer der Gründe, warum ich IPS gewählt habe im 2015, weil absolut stabil.

Anschliessende Versuche:

  • Versuch 1: Upgrade von 4.3 auf 4.4. Hat aber nix gebracht.
  • Versuch 2: Abhängen des Philips Hue Moduls von Traxanos. Es hat gebessert.
  • Irgendwie stellte ich nun fest, dass mein Archiv überlastet war und habe dort aufgeräumt *)
  • Versuch 3: Ich habe die Philips Hue Schnittstelle selber programmiert.
  • Jetzt wurde die Console sehr schnell immer träger, sie lief max. 1 bis 5 min. und es gab den Fehler „…Nachricht ist grösser als Nachrichtenpuffer…“
  • Da bei mir ein grosses IPS läuft, habe ich nun für die Fehlersuche ein 2. IPS aufgesetzt ganz frisch und leer.
  • Mit Philips Hue konnte ich den Fehler tatsächlich wieder reproduzieren.
  • Philips Hue wird (je nach Einstellung) alle 5 bis 10 sec. abgefragt, das ist nötig wegen den Bewegungssensoren usw.
  • Ich stellte fest, dass wenn im Netzwerk ab und zu Hänger sind, das Hue-Ausleseskript mehrfach gleichzeitig aufgerufen wird. Im Extremfall hängt sich IPS dabei auf. Siehe Lösung 1)
  • Dann schaute ich mir die Werte an und stellte fest, dass sie nach jedem Zugriff auf Philips Hue gespiesen wurden. Das überfüllt den Nachrichtenpuffer innert kürzester Zeit, da es halt um viele Werte geht alle paar Sekunden. Siehe Lösung 2)

Lösungen:

  1. Unbedingt beim Hue-Auslese-Skript mit IPS_SemaphoreEnter und IPS_SemaphoreLeave arbeiten, damit das Skript jeweils nur einmal läuft. Das ist ganz wichtig.
  2. b) Möglicherweise ebenfalls wichtig ist, dass der CURL-Handle mit curl_close wieder geschlossen wird.
  3. Unbedingt die Variable in IPS von Hue nur abfüllen, wenn der neue Wert von Hue anders lautet als der alte Werte in IPS. Damit können tausende unnötige Werte im Puffer verhindert werden. Das ist ganz wichtig, denn sonst stürzt die Konsole ab.

Fazit 1:
Unterdessen wächst bei mir die Hue-Welt, bereits 2 Bridges sind aktiv, und IPS liest alle Hue-Werte alle 3 sec. und ist trotzdem wieder so stabil wie früher!

Fazit 2:
Der Fehler „…Bereich der Nachricht ist grösser als der Nachrichtenpuffer…“ hat eher nichts mit dem Meldungs-Fenster zu tun. Bei mir ist der Fehler entstanden, weil - wegen Hue - innert kurzer Zeit viel zuviele (und völlig unnötige) Variablen-Werte geschrieben wurden und den Puffer dafür überfüllt haben.

Fazit 3:
Das Traxanos-Modul für Hue hab ich nicht mehr getestet (habe jetzt eigenen Code), aber es muss möglicherweise noch optimiert werden in die obengenannte Richtung (habe den Traxanos-Code nicht überprüft).

[i]*) Ein anderes Thema:

  • Der IPS-Dienst hat viel zu lange gebraucht zum Starten (ca. 2 min.).
  • Im LOG hab ich gesehen, dass er alle Archiv-Variablen einliest und dafür sehr lange benötigt.
  • Ich habe von 1000 Variablen auf gute 400 reduziert.
  • Beim IPS-Dienst starten hat sich der Speicherbedarf von 1000 MB auf ca. 500 MB reduziert.
  • Und der Start ist wieder schneller (ca. 40 sec.) oder so.
  • Warum IPS soviel Speicher benötigt, abhängig von der Anzahl archivierter Variablen, ist mir vorerst noch ein Rätsel.
  • Jedenfalls organisiert sich IPS selber, und nach ein paar Stunden sinkt der Speicherbedarf nachhaltig auf ca. 70 MB.[/i]