Okay… dann sind es halt die 1MB HTMLBOX Variablen 
Michael
JSON-Error 5 ist JSON_ERROR_UTF8 (siehe PHP: json_last_error - Manual)
D.h. irgendwo (gerne bei Objekt-Name, ist eine nicht UFT-kodierte Bezeichnung vorhanden.
In Kern->Util gibt es ja die Möglichkeit, solche Bezeichner zu korrigieren.
gruß
demel
Hallo,
mir ist eingefallen, das ich in einem anderen Modul (IPSymconConfigVC) das UTF8-Problem schonmal als Thema hatte und eine Lösung dafür gefunden haben.
Ist eingebaut. versuche es doch noch einmal.
Gruß
demel
Hallo
Mit dem aktuellen Update laeuft es im Moment schon laengere Zeit als vorher. Zwischenzeitlich hatte ich mir an der Stelle wo du checkst ob ein Snapshot da ist eine zweite Moeglichkeit eingebaut.
Wenn kein Snapshot weil Timestamp weit ausserhalb der Moeglichkeit, dann Snapshot mit 0 holen. Also aktuellen.
Hat sich sozusagen wieder repariert.
Werde das weiter beobachten.
BTW Im Konfigurationsformular fehlen die Texte fuer die aktiven Nachrichten.
Gesendet von iPad mit Tapatalk
da ist ja jetzt auch eine solche Logik drin. kriege ich kein Snapshot zurück (was ja eigentlich durchaus sein könnte), initialisiere ich neu.
Es gibt in dem Fall eine NOTICE-Meldung im IPS-Log.
Wobei das eigentlich gar nicht vorkommen darf, das dann auf Dauer keine neuen Snaphshot-Changes mehr kommen … 
Ich befürchte, das dann Meldungen verloren gehen.
Was meinst du mit „ausserhalb der Möglichkeiten“, wie stellst Du das fest? Oder war das nur ein Rückschluss/eine Vermutung? Ich habe nämlich keine Ahnung, wie ich das feststellen und damit auch ggfs abfangen könnte.
Das ist eventuelle ein Problem mit den Aktualisierungsschritten. Wenn ich das Modul neu anlege oder „von früher“ aktualisieren, wird das bei mir korrekt gefüllt.
Wenn kein Snapshot dann ging ich davon aus , dass der Buffer
Ueberschritten wurde. Also quasi neu anfangen.
Ist seit dem neuesten Update aber nicht mehr vorgekommen.
Gesendet von iPad mit Tapatalk
ok, das mache ich jetzt auch so. Allerdings kann es schon vorkommen, das in de Zwischenzeit keine neue Nachrichten erzeugt wurde … ist aber bestimmte eher theoretisch.
Mir ist eine raise-condition eingefallen, die eventuell vorkommen und das Phänomen erklären könnte: wenn in einem Abruf-Intervall mehr Nachrichten erzeugt werden, als der Spezialschalter MessageRingBufferSize erlaubt, werden lt. Doku alte Nachrichten verworfen … und damit wäre der Counter ggfs zuweit „zurück“ und liefert IPS_getSnapshotChanges() nix mehr zurück und damit bleibt man hängen.
paresy hatte zu diesem Schalter mal was geschrieben: IP-Symcon Community Forum
wäre schön, wenn paresy was dazu sagen könnte, ob ich da auf der richtige Spur bin
Gruß
demel
ich habe noch etwas eingebaut, damit man bei einer reset sieht, wie der alte und der neue TimeStamp ist. Einfach damit man mal sieht, ob es wirklich eine entsprechende Differenz gibt
demel
Ohne jetzt ins Script geschaut zu haben, ist eine Meldung ins Log oder nur eine Modul Debug?
Hat man ja normalerweise nicht immer offen.
Gesendet von iPad mit Tapatalk
sowohl als auch 
Ich habe nun die Änderungen in den Branch :master_ übernommen, der Branch logger-test würde ich in ein paar Tagen löschen.
demel
Version 2.1 @ 02.03.2019 09:24
[ul]
[li]Anpassungen IPS 5, Abspaltung Branch ips_4.4
[/li][li]Protokollierung aller IPS-Protokoll-Messages …
[/li][/ul]
Version 1.1 @ 17.09.2018 17:47
[ul]
[li]Versionshistorie dazu,
[/li][li]define’s der Variablentypen,
[/li][li]Schaltfläche mit Link zu README.md im Konfigurationsdialog
[/li][/ul]
Version 1.0 @ 25.03.2018 10:07
[ul]
[li]Initiale Version
[/li][/ul]
@demel42 Modul funktioniert super. Kann ich auch irgendwie Debug Nachrichten zum Syslog Server schicken?
Wenn ich alles anhake (leider keine beschriftung) ändert das leider nichts
siehe README#zentrale Funktionen, da stehen die Funktionen beschrieben.
Durch das von Dir gemachte Anhaken bestimmt den Umfang des Symcon-Systemmeldungen; DEBUG würde ich nur begrenzt empfehlen, weil es doch einiges ist.
1 „Gefällt mir“
Danke! Dann habe ich noch eine letzte Frage. Symcon und syslog-ng laufen jeweils in einem Dockercontainer im selben Dockernetzwerk. Ich erreiche den Syslog Server aber nicht über die IP oder über Host des Docker containers. Eine Fehlermeldung in der Log kommt nicht, aber es kommt nichts am Syslog Server an. Verwende ich hingegen die LAN IP vom Host der Dockercontainer funktioniert es, das ist allerdings nicht die beste Lösung. In anderen Instanzen (wie z.B. dem MQTT Client) erreiche ich über den internen Host andere Dockercontainer. Hast du eine Idee und/oder kannst Debug Nachrichten zum Aufbau des Sockets einbauen? Vielen Dank!
Neins direkt gefällt mich nichts ein, nur die Frage: auf dem Docker-Host läuft kein weiter Syslog-Daemon?
Wenn der Host eine Synology ist und dort der Syslog-Dienst aktiv wäre, wäre das schon ein komischer Konflikt.
Wie man den Socken weiter Debugger könnte, fällt mich auch nicht ein.
Der Code ist ja schlicht, fängt aber alles ab
$sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
if (!$sock) {
echo 'unable to create socket(' . $server . ':' . $port . ')';
return -1;
}
$l = strlen($syslog_message);
$n = socket_sendto($sock, $syslog_message, $l, 0, $server, (int) $port);
if ($n != $l) {
echo 'unable to set messages "' . $syslog_message . '" to socket(' . $server . ':' . $port . ')';
return -1;
}
socket_close($sock);
Wenn da was schief gehen, würde müsste das entweder im Instanz-Debug erscheinen oder sogar im IPS-Log.
Ich bin in Docker nicht so firm und habe auch kein Docker mehr, aber ich denke mir, das ein Port, der in den Docker-Eigenschaften angegeben wird, an des Wirts-System weiter gegeben wird.
Aber da rede ich als Fast-Blinder von Farben …
Ich habe noch ein bisschen rum probiert
echo 'unable to create socket(' . $server . ':' . $port . ')';
und
echo 'unable to set messages "' . $syslog_message . '" to socket(' . $server . ':' . $port . ')';
Wird scheinbar nie aufgerufen/ausgegeben. Du kannst es nachstellen, indem du eine fiktive IP Adresse nimmst. Es kommt kein Fehler
socket_sendto an UDP wird immer funktionieren.
Ist ja ein zustandsloses Protokoll.
Fire and forget.
Michael