SystemLog und scrollbare Listen - BETA

[NilsS]

Nein das ist so nicht gedacht.

Jeder SystemLog liegt nur auf dem "eigentlich" Systemweit einmalig 14Byte iKO "SystemLog XML".

Je nachdem was du jetzt anzeigen willst in der ScrollList legst du nun einen SystemLog Baustein an.

z.B.

Du möchtest auf deiner Visu in einem allgemein zugänglichen Bereich diverse Info's loggen (Alarm an/aus, Beschattung, Störungen ....)
Dort sollen diese vielleicht auch einfach zu bestätigen sein, oder vielleicht auch zu löschen sein.

Jetzt möchtest du jedoch auch noch für dich zum Beispiel alle Meldungen der Alarmanlage in einem weiteren Systemlog haben der nicht gelöscht wird, sodass du dort im Fehlerfall nachsehen kannst.

Du kannst jedoch auch alle "action" Eingänge gewissermaßen so verbinden, das aus deiner speziellen Ansicht (Alarmanlage/Rollladen....was auch immer) , Einträge in allen Listen gelöscht werden. Jeder Logeintrag erhällt eine einmalige ID. Wenn jetzt an alle ein del:ID gesendet wird, so wird der Eintrag überalll gelöscht. Der Löschen-Button der öffentliche Liste, wird nur mit dem action Eingang dieser Liste verbunden, und so wird auch nur dort der Eintrag gelöscht.

[eckerho1]

Hallo Nils

Das schreit mal wieder nach einem Beispiel.

Kapiert hab ichs nämlich noch immer nicht ganz.
Mein Problem ist, dass ich sehr viele events mit der severirty info generiere, diese mich aber eigentlich nicht interessieren und auch das Log iKO nicht vollmüllen sollen.
Für Debug Zwecke wäre es aber manschmal schon schön diese Infos zu haben, daher möchte ich sie im Baustein nicht grundsätzlich abschalten.

Ich habe mir vorgestellt ich könnte diese filtern bevor sie geschrieben werden und bei Bedarf diesen Filter deaktivieren.

Wenn das so nicht geht muss ich halt zwei Ausgänge bauen, einen mit error und warning und einen mit info und den info Ausgang dann nur bei Bedarf verbinden.

Gruss, Holger

[vento66]

Ich habe mir vorgestellt ich könnte diese filtern bevor sie geschrieben werden und bei Bedarf diesen Filter deaktivieren.

Hallo Holger!

Du kannst die Filter nicht zur Laufzeit ändern, da die nur beim initialisieren des Bausteins berechnet werden. (hat glaub irgendwas mit Python zu tun....)

[eckerho1]

Du kannst die Filter nicht zur Laufzeit ändern, da die nur beim initialisieren des Bausteins berechnet werden. (hat glaub irgendwas mit Python zu tun....)

Hallo Micha

Ja, das hab ich irgendwo in diesem Thread gelesen. Ist aber nicht mein eigentliches Problem.

Natürlich wäre es schön den Filter zur Laufzeit zu ändern, ich kann mich aber auch damit abfinden dazu die Logik neu zu laden.

Ich möchte während der Testphase alle Meldungen (also auch info) loggen. Wenn das System dann in Produktion geht brauche ich die infos (aber nur die infos von einem Baustein, nicht alle infos) nicht mehr, die würden mir nur unnötig das Log füllen.

Was ich vermeiden wollte ist, dass ich den Baustein mit 2 XML Ausgängen versehen muss, einen der alles liefert und einen der nur warning und error liefert.

Eine andere Möglichkeit wäre auch weitere severities zu verwenden und diesen Baustein nicht info sondern z.B. notice senden zu lassen. Das könnte ich dann ja auch wieder filtern. Ist aber schon etwas von hinten durch die Brust....

Ich habe mir halkt vorgestellt ich könnte pro facility definieren welche severirties ich loggen (nicht anzeigen) möchte.

Danke und Gruss, Holger

[eckerho1]

Hallo

Hab jetzt noch einen Eingang "Logging level" eingebaut.

O= keine Logeinträge, 1= nur error, 2= error und warning, 3= error, warning und info.

Somit kann ich für diesen Baustein jetzt zur Laufzeit bestimmen was geloggt werden soll.

Gruss, Holger

[NilsS]

Ich werd mir mal ansehen ob ich die Filter nicht mal anpassen kann, das sie
a) zur laufzeit zu ändern sind
b) spezieller sein können (z.B. Rollladen#>warn;Alarm#>notice;-Heizung#* )
Also alle Meldungen vom Rollladen die eine severity warn oder höher haben und bei Alarm notice und höher und keine Heizung

[eckerho1]

Hallo Nils

Das hört sich gut an.
Bin schon gespannt.

Gruss und ein schönes Wochenende, Holger

[woda]

Hallo Nils,

Hier die Tests die ich durchgeführt habe:
1. Bausteine Lister und Logger samt Puffer und Kom. Objekt gelöscht, gespeichert, komplett übertragen, Experte geschlossen und neu gestartet.
Alles einzeln neu eingefügt und verknüpft, geprüft, gespeichert, komplett übertragen und neu gestartet -> Ergebnis selber Fehler.

2. alles wie oben und zusätzlich den Baustein aus dem logic Verzeichnis gelöscht (alle Versionen), Experte neu gestartet, gespeichert, Experte beendet, Baustein wieder ins Logicverzeichnis (V0.8) und alles neu zusammenbauen. > Ergebnis selber Fehler

Was ich noch festgestellt habe:
Der Facility Filter funktioniert bei mir nur wenn ich im Ausschlussverfahren filtere :"-Alarmanlage,.*" für den Türklingel Logger und "-Klingel,.*" für den Alarmanlagen Logger.
Filtere ich normal mit "Alarmanlage" und "Klingel" landen alle Meldungen sofort in beiden Listen.
Laut HSMonitor wird nur der als erstes angelegte Puffer befüllt.

Zusätzlich gehen seit dem Update auf V0.8 nach dem Neustart die Meldungen die in dem Baustein bei dem der Puffer nicht befüllt wird verloren (eigentlich logisch).

Die Meldungen aus dem Baustein an dem der Puffer gefüllt wird sind dann nach dem Neustart in beiden Liste vorhanden.

Ich hoffe meine Schilderung kann verstanden werden, leider ist die Sache etwas verwirrend.

Schönen Gruß
Wolfgang

[NilsS]

leider ist das Fehlerbild noch genau gleich.
Ich hab mal mit dem HS-Monitor die Puffer ausgegeben, und festgestellt dass nur einer Daten enthält.
Es wird immernoch bei dem Systemlog-Baustein ohne Puffer am Anschluss 4, nach dem Neustart der Inhalt aus dem anderen Baustein mit Puffer angezeigt.

Es werden scheinbar auch alle Meldungen aus allen Systemlog Bausteinen nur in einen einzigen Puffer zusammengeschrieben.

alles klar Fehler bestätigt. Lösung wird gesucht

[NilsS]

Feedback benötigt

Hat leider ein bischen länger gedauert.

Das Problem ist damit erstmal behoben und auch ansonsten sind Neuerungen wie auch bei hsphone 3 enthalten. (Konfigeingang: usezlib=1 und listlength=500 )

Ich würde aber denoch den Baustein weiter sanieren, da er "by Design" kaputt ist. Die Filter sind nämlich vollkommen unbrauchbar. Meine Idee würde jedoch die kompatiblität zerstören, daher wollte ich kurz eure Meinung dazu.

Meine Idee wäre es 2 Filtereingänge zu machen, einer für das speichern und einen für das Anzeigen. Diese Filter müssten dann in einer Zeile, Facility#severity#message enthalten, denn es macht nur Sinn wenn ich sagen kann, das ich

Rollladen#-debug,*#*@Telefonbuch#*#-gestartet@*#-debug,-info,*#*

Die dann alle Meldungen vom Rollladen severity info+ und vom Telefobuch alles ausser der "gestartet" Meldung, und ansonsten alles mit notice+

Bitte um Feedback

Datei ist BETA

[vento66]

Hi Nils!

Solange es zum Tauschen nur erforderlich ist die Filtereinstallungen zu neu anzulegen sehe ich da jetzt nicht unbedingt das Problem, wenn der neue Baustein nicht kompatibel ist. Ich weis jetzt nicht wie viele den Baustein in welchen Mengen einsetzten, aber ich glaube das das doch überschaubar ist.
Vielleicht melden sich die betroffenen hier ja auch noch....

[eckerho1]

Hallo Nils

wäre für mich kein Problem. Die Idee mit den 2 Filtern finde ich sehr gut.

Danke und Gruss, Holger

[kippi]

Finde ich vom Prinzip her auch nicht schlecht, nur versuche ich gerade die letzten Zeilen bzw. Filtereinstellungen zu verstehen.

Facility#severity#message

das ist soweit klar

nur hier häng ich ein bisschen

Rollladen#-[URL="http://redaktion.knx-user-forum.de/lexikon/debug/"]debug[/URL],*#*@Telefonbuch#*#-gestartet@*#-[URL="http://redaktion.knx-user-forum.de/lexikon/debug/"]debug[/URL],-info,*#*

für was ist das *@ vorm TB bzw. nach gestartet, muss ich das verstehn so wie *@-suche bei Windoof?


müsste es bei mir dann für Rolladen dann so heissen für alle Meldungen höher als debug ?

Rolladen#-debug,#*

[NilsS]

Solange es zum Tauschen nur erforderlich ist die Filtereinstallungen zu neu anzulegen sehe ich da jetzt nicht unbedingt das Problem,

Das wäre das einzige, kompatibel ist er jedoch nur in eine Richtung.
Also nach dem Update auf 1.81+ gehts nicht wieder zurück ohne Datenbankverlust.

für was ist das *@ vorm TB bzw. nach gestartet, muss ich das verstehn so wie *@-suche bei Windoof?

Das @ war jetzt nur mal als Beispiel gedacht, um mehrere dieser Filter in einer Zeile zusammen zu setzen.

müsste es bei mir dann für Rolladen dann so heissen für alle Meldungen höher als debug ?

Rolladen#-debug,#*

Rolladen#-debug,*#*

[NilsS]

Ich hab der nächsten Version mal noch ein Debugeintrag den sich alle SystemLogs teilen spendiert.