Inspiriert vom Modul 92_rsyslog (aus contrib) von betateilchen (herzlichen Dank dafür!) habe ich dieses kleine Modul erstellt, welches das FHEM Systemlog und/oder FHEM-Events an einen remoten Syslog-Server weiterleitet. Es soll all jenen nützlich sein, die in ihrer Umgebung einen zentralen Syslog-Server bereits für das Logging von Geräten wie Router, Switsches o.ä. verwenden und gern die Meldungen von FHEM mit integrieren möchten.
Direkt nach der Definition sendet das neue Device alle neu auftretenden FHEM Systemlog Einträge und Events ohne weitere Einstellungen an den Zielhost, Port=514/UDP Format:IETF, wenn reguläre Ausdrücke für Events/FHEM angegeben wurden.
Wurde kein Regex gesetzt, erfolgt keine Weiterleitung von Events oder FHEM Systemlogs.
Alle Messages werden mit Severity "notice" weitergeleitet wenn nicht der Event oder FHEM-Log Eintrag das Suchwort "Warning" oder "Error" enthält. In diesen Fällen wird auch die Severity entsprechend gesetzt. Die Verbose-Level im FHEM-Log werden entsprechend ihrer Wertigkeit umgesetzt.
Getestet habe ich es mit dem Synology On-Board Syslog-Server (Protokoll-Center) und der Enterprise-Lösung Splunk (kann bis 500 MB
tägliches Datenvolumen kostenfrei genutzt werden) -> https://www.splunk.com/en_us/products/splunk-enterprise.html.
Voraussetzungen:
1. das Modul muss aus ./contrib nach ./FHEM gebracht werden, entweder als Kopie oder als symlink.
2. Es wird das Perl Modul "IO::Socket::INET" benötigt und muss installiert sein. Das Modul kann über CPAN oder mit apt-get install libio-socket-multicast-perl (auf Debian Linux Systemen) installiert werden.
Definition:
define <name> Log2Syslog <Zielhost> [ident:<ident>] [event:<regexp>] [fhem:<regexp>]
<destination host> = Zielhost auf dem der Syslog-Server läuft
[ident:<ident>] = optinaler Programm Identifier. Wenn nicht gesetzt wird per default der Devicename benutzt.
[event:<regexp>] = optionaler regulärer Ausdruck zur Filterung von Events zur Weiterleitung
[fhem:<regexp>] = optionaler regulärer Ausdruck zur Filterung von FHEM Logs zur Weiterleitung
Beispiel um alles zu loggen:
define splunklog Log2Syslog splunk.mydomain.dom event:.* fhem:.*
Attribute:
Siehe Hilfe mit "help Log2Syslog".
Das Modul ist eingecheckt und ab dem 29.08.2017 per Update verfügbar.
Wie immer sind Feedback / Hinweise gewünscht.
Eine aktuelle Entwicklungsversion (Weiterentwicklung) stelle ich weiterhin unter ./contrib zum Test zur Verfügung sofern es eine Version zum Test gibt.
Grüße,
Heiko
ZitatAlle Messages werden mit Severity "information" weitergeleitet wenn nicht der Event oder FHEM-Log Eintrag das Suchwort "Warning" oder "Error" enthält. In diesen Fällen wird auch die Severity entsprechend gesetzt.
Eigentlich ist verbose anders definiert: https://fhem.de/commandref.html#verbose
Ich meine folgende Zuordnung waere sinnvoll:
0: Critical
1: Error
2: Warning
3: Notice
4: Informational
5: Debug
Tolle Sache!
Schließe mich Rudis Hinweis zu Logleveln an. Nur für Events müsste man sich was überlegen...
Von unterwegs gesendet.
Guten Morgen zusammen,
die Idee hinter der Severity-Level bezog sich tatsächlich weniger auf die verbose-Level, sondern auf das Vorhandensein von bestimmten Signalwörtern im Meldungstext selbst. Eben aus dem Grund weil ich in den Events sonst nichts ableiten kann.
Rudi hat natürlich Recht und ich stelle das mal auf meine Weiterentwicklungsagenda den Schweregrad zu vereinheitlichen.
Es würde für mich so aussehen, dass alle Meldungen (vorrangig Events) mit Severity "Notice" rausgehen, es sei denn es finden sich die entsprechenden Signalwörter.
Bei den FHEM Logs würde ich den verbose-Level direkt auf die Severity mappen (je nachdem was Sys::Syslog hergibt). Sollte sich im Logtext wieder ein Signalwort finden, kann dieses die Severity übersteuern.
Denke das würde dann passen.
ZitatDie Weiterleitung der Events bremst bei meinen Tests das System merklich (apptime)...
Wuerde mich interessieren wieso: soweit ich es in diesem RFC (https://tools.ietf.org/html/rfc5424) sehe, gibt es keine Antwort vom Server, und damit sollten die Meldungen in den UDP/TCP Puffer des Client-Kernels verschwinden, und damit "gefuehlt" asynchron sein.
Vielleicht ist das ein Grund das Syslog Protokoll selbst zu implementieren :)
ZitatVielleicht ist das ein Grund das Syslog Protokoll selbst zu implementieren :)
Ja das ist auch nochmal eine Idee. Ich schau mal ob ich das hinbringe ... :)
Hallo Heiko,
kannst Du das Modul bis zu seiner Fertigstellung nicht einfach in ./contrib bereitstellen? Das würde die Einbindung auf Testsystemen, die i.d.R. ohnehin per SVN verwaltet werden, erheblich erleichtern. Man muss dann das Modul nicht dauernd neu aus dem Forum-Thread laden und auf irgendeinen eigenen Server kopieren, sondern kann einfach mit einem symlink arbeiten.
Hallo Udo,
ja klar, kann ich machen. Bin grad am schrauben. Wenn ich die nächste Version fertig habe passe ich das alles an.
was ich mir an dem Modul grundsätzlich anders wünschen würde:
Die Angabe der regexp dafür, was geloggt werden soll, sollte sich eher an der "Logik" von FileLog und DbLog orientieren, als Angabe von regexp bereits im define, anstatt zusätzlich mit Attributen zu arbeiten.
define <name> Log2Syslog <ident> <destination host> [event:<regexp>] [fhem:<regexp>]
Ausserdem würde ich das Defaultverhalten bei nicht angegebenen regexp umkehren: Nichts loggen. Auch damit würde man sich am bisher bekannten Verhalten von FileLog und DbLog orientieren. Per default alles zu loggen ist jedenfalls nichts, was ich als Anwender unbedingt haben möchte.
Damit erübrigen sich dann auch die Attribute logmode, FhemlogFilter, EventlogFilter.
Meine derzeitige Befürchtung ist, dass da gerade wieder ein Attribute-Moloch geschaffen wird, den ausser dem Entwickler selbst niemand mehr versteht und beherrscht, weil er sich an nichts hält, das man bisher aus FHEM kennt.
Hallo Udo,
die beiden RegEx im Def finde ich eine gute Idee. Werde ich bei der kommenden Version gleich mit vorsehen.
Die Idee per Default alles weiterzuleiten kam aus dem Gedankengang dass wir ja im eigentlichen Sinn nichts loggen wollen, sondern all das was der User im FHEM sehen würde an den zentralen Server weiterzuleiten.
Aber das geht natürlich auch wenn man im Define für beide RegEx ".*" setzt.
Komme ganz gut mit der eigenen Implementierung des syslog Protokolls voran. Performance ist Klasse wie es sein soll. Stoße aber immer wieder darauf dass der syslog-server meine Message nicht so versteht wie ich es erwarte.
Baue Mal weiter (heute Abend).
Grüße
Heiko
Jetzt habe ich die Verbesserungsvorschläge umgesetzt und und das syslog Protokoll nachgbildet (IETF, BSD).
Den Eingangsbeitrag habe ich angepasst weil sich sowohl die Definition als auch die Attribute verändert haben.
Der Ident-String ist im Def entfernt, aber wird im Modul aus dem Devicenamen und dem Logtyp, also entweder event oder fhem, zusammengesetzt und an den Server übertragen. So kann man im Syslog Server die Übersichtlichkeit erhöhen und Filter setzen etc.
Die Performance ist auch jetzt so wie ich sie haben möchte -> ca. 6 ms mit apptime gemessen bei Freischaltung aller Events und logs (also 2 x ".*").
Ach ja ... im contrib ist es nun auch :D
Grüße
Heiko
Gratuliere!
Hast du eine Idee, warum die alte Implementierung nicht so effizient war?
Hallo Rudi,
in die Ursachenforschung hatte ich nicht wirklich viel Energie reingesteckt weil ich von der Idee es selbst zu implementieren gleich begeistert war und mich darauf konzentriert habe.
Aber ich vermute ! das es es mit Systemaufrufen zu Unix syslog(3) zu tun hat da SYS::SYSLOG sich dessen bedient.
Erschwerend kam sicherlich dazu dass ich als Ziel ein DNS Namen benutzt habe statt einer IP. Das war wahrscheinlich keine so gute Idee.
Möglicherweise wären andere Tester zu einem anderen Ergebnis gekommen.
Wenn daran Interesse besteht kann ich die alte Version gerne nochmal zur Verfügung stellen. Vielleicht schau ich mit der alten V auch nochmal.
Bin gespannt was die ersten Tests bei anderen Usern ergeben ;)
Grüße,
Heiko
Du wolltest es so :D
Ich habe Version 2.0.0 und ein Device definiert
defmod syslog Log2Syslog 192.168.254.20 event:.* fhem:.*
attr syslog room DbLog
attr syslog verbose 3
setstate syslog active
setstate syslog 2017-08-17 16:28:19 state active
a) Beim Anlegen des Device wird folgende Meldung ausgegeben:
2017.08.17 16:20:01.332 1: PERL WARNING: "my" variable $sock masks earlier declaration in same scope at ./FHEM/93_Log2Syslog.pm line 176.
2017.08.17 16:20:01.333 1: PERL WARNING: "my" variable $sock masks earlier declaration in same scope at ./FHEM/93_Log2Syslog.pm line 220.
b) ein Event ":Garten.LCG.Environment -> error: 0" wird als Severity "error" geloggt
c) 93_Log2Syslog übernimmt (logisch) ab "Server started with 138 defined entities", allerdings laufen nur/noch einige Log-Mitteilungen ins fhem.log
2017.08.17 16:28:19.852 0: Server started with 138 defined entities (fhem.pl:14854/2017-08-06 perl:5.020002 os:linux user:fhem pid:31485)
2017.08.17 16:28:20.172 1: 192.168.254.25:9090 reappeared (CuBoxI4Pro)
2017.08.17 16:28:20.181 1: 192.168.254.27:9090 reappeared (Cubox_i4)
2017.08.17 16:28:20.189 1: 192.168.254.26:9090 reappeared (Hummingboard)
2017.08.17 16:28:22.595 3: Can't connect to 192.168.254.40:23: connect to http://192.168.254.40:23 timed out
2017.08.17 16:28:22.596 3: SIGNALduino sduino: connect to http://192.168.254.40:23 timed out
2017.08.17 16:28:24.004 3: DbRep db5.rep - connected
2017.08.17 16:28:24.008 3: DbRep Rep.Agent - connected
2017.08.17 16:28:24.013 3: DbRep db10.rep - connected
2017.08.17 16:28:25.675 4: ESPEasy ESPEasy_D1pro_01_Env: set statusRequest
2017.08.17 16:28:25.676 5: ESPEasy ESPEasy_D1pro_01_Env: Start internalTimer +300 => 2017-08-17 16:33:26
2017.08.17 16:28:26.328 3: UWZ Unwetterzentrale: Run.1000 Done fetching data
2017.08.17 16:29:22.440 4: HttpUtils url=http://192.168.254.40:23/
2017.08.17 16:30:19.784 1: miniCUL433: answer: Please define miniCUL433 first
2017.08.17 16:30:25.922 4: HttpUtils url=http://192.168.254.40:23/
Auf dem Syslog-Server finde ich jedoch nur einen einzelnen "syslog_fhem" Eintrag, nämlich den: Server started with 138 defined entities (fhem.pl:14854/2017-08-06 perl:5.020002 os:linux user:fhem pid:31485
Alles andere wandert munter ins fhem.log
Ja, wollte ich :)
a) Entwickler Fehler, mache ich heute Abend weg
b) das ist so designed ... Signalwort "error"
c) Also fhem.log wird natürlich weiterhin bedient wenn nicht ausgeschaltet. Das nur eine Message ankommt und dann nicht mehr ist sicher ungewöhnlich und ist bei auch nicht so. Rollt alles schön rein. Nun ist UDP nicht das zuverlässigste Protokoll. Mach das Ganze Mal mit TCP. Musst auf Empfänger Seite auch einrichten natürlich.
Einen hätte ich noch...
Aug 17 17:40:20 192.168.254.20 1 2017-08-17T17:40:20.526Z DiskStation syslog_fhem 31485 FHEM - :5: LCG.miniCUL433: dispatch OK 22 20 135 3 222 240 0 3 222 240 0 0 58 215 170 0 6 90 42 1 0
Das 'Z' im Timestamp "2017-08-17T17:40:20.526Z" bezieht sich auf "ZULU" - da müsste also die GMT-Zeit drin stehen, nicht die Lokalzeit.
... und noch ein Wunsch:
entweder den 'Hostname' konfigurierbar oder den 'Program Name' (syslog_event, syslog_fhem).
Hintergrund: Wenn du bspw. zwei Docker-Instanzen auf dem gleichen Host laufen hast, kannst Du im Syslog ansonsten nicht unterscheiden von wem die Einträge kommen.
ZitatDas 'Z' im Timestamp "2017-08-17T17:40:20.526Z" bezieht sich auf "ZULU" - da müsste also die GMT-Zeit drin stehen, nicht die Lokalzeit.
Das stimmt natürlich, arbeite ich nach.
Zitat... und noch ein Wunsch
Ahh... ok. Das sind dann so die Feinheiten.
Was nutzt du gerade als Logserver ? Du hast ja auch eine Syno ... das Protokollcenter ?
ZitatDas stimmt natürlich, arbeite ich nach.
Musst eigentlich nur das Z weglassen...
Ich habe mir nochmal den Fall c) angeschaut.
Als Versuchskaninchen habe ich bei meinen EC3000 mal verbose=5 gesetzt, da kommt dann schon etliches ins fhem.log. Allerdings sind es nicht berauschend viele Daten.
Für mich sieht es so aus, als ob beim Senden selbst Pakete verloren gehen.
Entweder kommen die Events oder die FHEM-Logeinträge. Aber nicht beide.
Schiebst Du die Daten erst in eine FIFO bevor du sie abschickst?
Es wird nur ein Socket UDP oder TCP geöffnet und dann der zusammengestellt Payload mit send auf den Socket verschickt. Das wars. Syslog erwartet und bekommt ja auch keine Betätigung. Ich lasse hier so nebenbei mein Protokollcenter laufen und da rauscht alles rein Events und Logs gleichermaßen (UDP).
Aber jetzt fällt mir noch etwas auf bzw. ein. Die Messages dürfen nicht zu lang (>1024 Byte) sein. Zumindest ist das in der RFC3164 definiert. Das muß ich noch mit einbauen. In der RFC5424 für IETF habe ich das noch nicht gelesen ... aber lass mich mal schauen.
Ich mach mal nen tcpdump auf dem Server damit brauchbare Infos vorliegen.
Das ist das was du erwartest und auch siehst ?
Nö - das war ein falsches Beispiel da auf dem Device 'Event-on-change' gesetzt ist.
Ich mach morgen einen sauberen Test
Ok. Ich mache noch meine Änderungen rein die ich ergänzen will wegen der Längenbegrenzung und lade das Modul wieder runter auf contrib.
Dann nimm das neue morgen gleich für den Test.
Die V2.2.0 ist nach contrib geladen. Die Zeit ist korrigiert, die Längenbegrenzung nach RFC3164 eingebaut und im payload werden Zeichen entfernt die nach RFC5424 vermieden werden sollten.
Grüße
Heiko
Ich habe soeben die Version 2.3.0 nach ./contrib hochgeladen.
Es gibt im Define nun die optionale Angabe des "ident". Ist dieser Parametergesetzt wird der Programmname aus diesem Wert zzgl. "fhem" oder "event" zusammengesetzt wie es sich SusisStrolch gewünscht hat. Ist er nicht gesetzt, wird wieder der Devicename statt dessen verwendet.
Der Anfangsbeitrag ist entsprechend angepasst.
Edit: Ich habe noch einen Screenshot angehängt der zeigt wie auch umfangreiche Payload vom Syslog-Server akzeptiert und dargestellt wird. Das Bild zeigt die raw-Messages in einem Splunk-Server.
VG
Heiko
Guten Morgen,
habe gerade das Modul aktiviert. Folgende erste Auffälligkeiten.
Das speichern der der (FHEM) Konfig wird im Syslog auf der Syno als Error interpretiert. In der Nomenklatur sieht man auch das errorflag (1).
Danke für Feedback. Falls weitere Infos oder Tests nötig sind, gern.
Grüße Sebastian
Hallo Sebastian,
bei den fhem logs werden die Verbose-Level direkt in die Severity Übersetzt. Also Meldungen mit Verbose 1 in Fhem ergeben in Syslog "error". Ich nehme das mal mit in die Beschreibung auf.
Achte auch darauf dass das logFormat BSD bzw. IETF mit den Einstellungen auf der Syno übereinstimmt.
Grüße
Heiko
Soeben habe ich die V2.4.0 nach ./contrib geladen.
Eingebaut ist der verbose Level support für das EIGENE Sys2SysLog-Device. Verbose 4,5 Ausgaben werden NUR in das FHEM Logfile geschrieben und nicht weitergeleitet damit keine Schleifen entstehen.
Ausgaben für verbose 4,5 sind bisher nur an zwei Stellen eingebaut, aber man kann schon vergleichen welche Payload mit den Events bzw. fhemlog-Einträgen erstellt wird.
Gerne wieder weitere Tests und Feedback.
schönen Sonntag @all,
Heiko
Guten Morgen,
die V2.4.1 ist nach ./contrib geladen. Neben kleineren internen Codeänderungen wird das Syslog-Feld PROCID mit einer fortlaufenden Nummer, die sich mit jedem Event/FhemLog um 1 erhöht, gefüllt.
Damit kann man die lückenlose Übertragung zum Syslog-Server nachverfolgen sofern der Syslog-Server dieses Feld mit ausgiebt (nur IETF).
In Splunk sieht man das (siehe Anhang).
Zur Zeit arbeite ich noch an der Integration der TLS-Verschlüsselung zur Übertragung an den Syslog-Server.
VG,
Heiko
Hallo zusammen,
die Version 2.5.1 ist verfügbar. Nun wird das TLS Transport Prokokoll unterstützt. Ist TLS gewählt, wird automatisch zu TCP umgeschaltet.
Es sind noch ein paar Readings dazu gekommen. Zum Besipiel wird im Fall von TLS die verwendete SSL-Version und der Algorithmus angezeigt.
Das Reading Transfered_logs_per_minute enthält die durchschnittliche Übertragungsrate (logs/minute).
Das ist zusammengefasst der gegenwärtige Stand.
Ich würde mich über ein paar Rückmeldungen zu Tests - auch positive falls nichts auffallen sollte - freuen.
viele Grüße
Heiko
Die geplant finale Version habe ich nach ./contrib hochgeladen.
Es hat sich noch folgendes geändert:
- es können mehrere LogSyslog-Devices definiert werden (z.B. wenn man die Weiterleitung von FHEM-Logs und Events trennen möchte)
- das Attribut "type" wurde nach "protocol" umbenannt. Type war ein Arbeitstitel.
Das Modul werde ich dann in Kürze einchecken.
VG
Heiko
Hey danke für das Modul, gleich aktiviert :)
Und "plappert" gleich los in Richtung graylog2.
Hallo dtavb,
super :)
Könntest du vielleicht ein Screenshot dranhängen und kurz angeben ob du IETF oder BSD benutzt ?
Es ist einfach mal interessant wie gut das Parsing mit anderen Syslog-Produkten als Splunk bzw. Synology Protocolcenter funktioniert.
LG
Heiko
Hoi DS_Starter,
ja klar:
Format: IETF
Hier das define:
defmod tosyslog Log2Syslog collector.media.home event:.* fhem:.*
attr tosyslog alias syslog
attr tosyslog icon lan_rs485
attr tosyslog port 8514
attr tosyslog protocol UDP
attr tosyslog room Unsorted
setstate tosyslog active
setstate tosyslog 2017-09-12 05:22:33 SSL_Algorithm n.a.
setstate tosyslog 2017-09-12 05:22:33 SSL_Version n.a.
setstate tosyslog 2017-09-15 06:13:30 Transfered_logs_per_minute 14
setstate tosyslog 2017-09-13 08:56:19 state active
In graylog habe ich ein Input-Objekt definiert, ohne weitere Angabe.
Wobei graylog im Standard IETF erwartet, meine ganzen rsyslog-Definitionen sind danach ausgerichtet.
Für ossec zB gibt es ein plugin für graylog damit er diese gleich schön formatiert ausgibt, da diese in einem eigenen Format sind.
Grüsse,
dtavb
Hallo zusammen,
nach längerer Zeit habe ich das Modul weiterentwickelt und ihm nun auch eine Syslog-Serverfunktion spendiert und insgesamt weiterentwickelt.
Download aus dem contrib-Verzeichnis: https://svn.fhem.de/trac/browser/trunk/fhem/contrib
Die deutsche Commandref ist im Modul bereits angepasst.
Nach der Installation des Moduls ist sie über "help Log2Syslog" aufrufbar.
Das Modul hat nun das Unterscheidungsmerkmal Internal MODEL.
MODEL = Sender -> Syslog-Client wie bisher
MODEL = Collector -> Syslog-Servermode
Zur Erstellung eines Collectors gibt es einen neuen Definitionsaufruf ohne weitere Parameter.
Definition eines Collectors
define <name> Log2Syslog
Wegen der momentan andauernden Fortentwicklung erstmal contrib.
Über Mitteilungen zu Einsatz-/Testergebnissen würde ich mich freuen.
LG,
Heiko
Hallo Heiko,
genial, herzlichen Dank! An solche Möglichkeiten hatte ich noch gar nicht gedacht!!!
Das Eröffnet ganz neue Horizonte!!!
Ich bin erst am Testen und "einlernen" mit den Möglichkeiten davon.
Bekomme zB folgende Parserfehlermeldung:
Log2Syslog SyslogServer - error parse msg: system,info Router: dhcp server dhcp-vrrp changed by admin
mit RAW wird es natürlich angezeigt. Ist es gedacht, dass man für sowas dann einen eigenen Parser schreibt?
Ist es so gedacht, dass ich dann zB mit einem Notify die Events filtere und mir daraus je nach bedarf zB ein Reading oer etwas anderes generiere?
Ich versuche gerade, darüber die Anwesenheitserkennung durch Abgreifen des DHCP-Servers zu verbessern, was sehr vielversprechend aussieht
und sogar einfacher, bzw. schneller zu funktionieren scheint wie SNMP.
Danke für die Info,
sG
Joe
Morgen Joe,
ZitatBekomme zB folgende Parserfehlermeldung:
Schau mal ob ob du das richtige Format BSD/IETF eingestellt hast
verbose 5 im Zweifel mal posten.
Zitatmit RAW wird es natürlich angezeigt. Ist es gedacht, dass man für sowas dann einen eigenen Parser schreibt?
Hast du richtig erkannt ;)
Idee ist dass spezielle PArser im Attribut parseProfile zu hinterlegen (z.Zt. raw/default) bzw. dem User die Möglichkeit zu geben eigene Parser einzubinden.
ZitatIst es so gedacht, dass ich dann zB mit einem Notify die Events filtere und mir daraus je nach bedarf zB ein Reading oer etwas anderes generiere?
Genau. Oder im DbLOg mit valueFn die zu loggenden Werte zu extrahieren für SVGs etc.
Der Phantasie sind ja kaum grenzen gesetzt.
Grüße
Heiko
Zitat von: DS_Starter am 02 August 2018, 08:34:44
Schau mal ob ob du das richtige Format BSD/IETF eingestellt hast
verbose 5 im Zweifel mal posten.
Das war mein Verbose 5 Log ;-)
Mehr steht da nicht. aber wie gesagt, sind erst die ersten Gehversuche...
Das Format habe ich richtig eingestellt. Habe auch auf beiden Seiten mal auf BSD umgestellt, was mir nicht schlechter gefällt,
daher bin ich noch unentschieden, welches Format ich letztlich tatsächlich verwenden soll/werde.
Zitat von: DS_Starter am 02 August 2018, 08:34:44
Idee ist dass spezielle PArser im Attribut parseProfile zu hinterlegen (z.Zt. raw/default) bzw. dem User die Möglichkeit zu geben eigene Parser einzubinden.
Schön wäre natürlich, wenn ich so einen Parser in einem Attribut ähnlich wie valueFn hinterlegen könnte.
Nur als Verständnisfrage: Wenn dein Regex auf die Daten nicht stimmt, bedeutet das, dass mein Router keine Standardkonformen Syslog-Meldungen schickt?
(habe mich in den Standard noch nicht eingelesen...)
Dein Regex passt jedenfalls nicht auf die Meldungen meines Routers!
Anbei dein Regexp mit benannten Backreferences: Wäre es möglich, solche zu verwenden? Diese sind meine rMeinung nach viel leichter lesbar und besser debugbar
und sollte ohne sonstige Änderung auch direkt so genutzt werden können. $1, etc. funktionieren damit immer noch!
Zumindest als Beispiel! (siehe Screenshot).
^<(?<priority>\d{1,3})>(?<version>\d+)\s(?<date>\d{4}-\d{2}-\d{2})T(?<time>\d{2}:\d{2}:\d{2})\S*\s(?<host>\S+)\s(?<ident>\S+)\s(?<pidid>\S+)\s(?<mid>\S+)\s(?<sdfield>\[.*\]|-)\s(?<content>.*)Wenn mein Router gewisse Werte wie PIDID nicht liefert, sollte die entsprechende Regex-Klammer dann einfach leer bleiben?
Danke, sG
Joe
HI Joe,
wenn das die Raw Message ist:
Zitatsystem,info Router: dhcp server dhcp-vrrp changed by admin
Dann ist die Meldung weder nach Standard BSD noch nach IETF.
Wie der Messageaufbau nach RFC ist, habe ich versucht in der Hilfe darzustellen. Siehst du mit "help log2syslog".
ZitatWenn mein Router gewisse Werte wie PIDID nicht liefert, sollte die entsprechende Regex-Klammer dann einfach leer bleiben?
Technisch sicherlich ok so.
Aber wenn das parseProfil "standard" eingestellt ist, soll das Parsing strikt nach den Vorgaben der Syslog-RFC Dokumente erfolgen.
Wenn das Parsing damit nicht funktioniert, soll eben die Möglichkeit bestehen ein anderes/eigenes Parsing-Profil zu verwenden.
Im Zweifel raw.
ZitatAnbei dein Regexp mit benannten Backreferences: Wäre es möglich, solche zu verwenden? Diese sind meine rMeinung nach viel leichter lesbar und besser debugbar
Das ist gut, ich checke es und übernehme deinen Vorschlag wenn alles passt :)
LG,
Heiko
Hallo Joe,
habe das Modul im contrib upgedated.
Es wird nun immer der peerHost/peerAdresse ermittelt und als Reading im erstellten Event verwendet unabhängig davon ob der Sender sie in der Message mitliefert.
Ich habe nämlich festgestellt, dass meine TP-Link WLAN Accesspoints auch keine BSD/IETF-konforme Message senden.
Bei denen sieht es z.B. so aus:
<4> <;4>LAN IP and mask changed to 192.168.2.3 255.255.255.0
Hier scheint jeder Hersteller etwas eigenes zu machen. Man erkennt es _wahrscheinlich_ daran, dass man im Setup vom Syslog in dem entsprechenden Gerät weder BSD noch IETF Format auswählen kann. Fehlt diese Auswahl auch bei deinem Router ?
Bei meiner Synology kann ich z.B. auswählen ob sie Meldungen in BSD oder IETF Format an einen Syslog-Server sendet.
Welchen Typ Router hast du denn ?
Und kannst du bitte nochmal verifizieren ob die raw-Message wirklich so ist wie du oben geschrieben hattest ?
Vielleicht bietet es sich an, für einige gebräuchliche Geräte entsprechende Parseprofile auswählbar zu hinterlegen.
Ansonsten will ich dann noch ein Attribut "parseFn" einfügen mit dem der Nutzer eigene Parsingmöglichkeiten entwickeln kann.
Edit: BTW ... welchen Regex-Tester verwendest du ?
Grüße,
Heiko
Hallo Heiko, sorry, bin ab heute im Urlaub.
Mein Router kann "irgendwas" senden, oder eben BSD.
Ich nutzte Mikrotik Router und habe davon 8 Stück im Haus
(Mesh Netzwerk). Das Regex Programm heißt Regexbuddy, und ist genial. Kostet aber ein paar Euro.
Was ich ehrlich gesagt noch toll fände ist, wenn man Reading s ohne Notify erzeugen könnte, also als Art erweiterte "userreadings". Ich würde dafür sogar die Eventerzeugung in ein Attribut packen, damit man auf diese verzichten kann, wenn man alles über seine userreadings erschlagen hat. Dies wurde die Übersicht enorm vereinfachen. Aber das Mal nur so als Gedanke, ich melde mich die Tage, sicher aber wieder nach meinem Urlaub zurück... 😁.
SG Joe
Habe eine weiterentwickelte Version nach contrib geladen.
Über Attr parseProfile kann man neben den festen Auswertungsprofilen IETF,BSD,raw auch "ParsFn" auswählen um eine eigene Parsefunktion zu schreiben.
Im attr "parseFn" wird die Funktion dann hinterlegt.
Es werden umfangreiche Variablen/Felder für die Programmierung zur Verfügung gestellt. Mit dem attr "outputFields" können flexibel die Felder und deren Reihenfolge definiert werden, aus denen sich der generierte Event zusammensetzen soll.
Mit dem Attribut "makeMsgEvent" wird gesteuert, ob nur Events über die interne Logik (default), nur Readings ohne Event oder Readings mit Eventgenerierung in Abhängigkeit der event-on-.* Attribute erstellt werden sollen.
In der deutschen Modulhilfe "help Log2Syslog" ist alles beschrieben.
Grüße
Heiko
Ein Device vom Typ "Sender" kann nun Testmessages im BSD/IETF/raw Format senden.
Im Collecter habe ich das BSD-Parsing überarbeitet/verfeinert.
Download aus dem contrib-Verzeichnis: https://svn.fhem.de/trac/browser/trunk/fhem/contrib
Mit dem Attribut "sendSeverity" kann nun im Sender-Device gefiltert werden, dass nur Syslog-Nachrichten versendet werden deren Schweregrad in diesem Attribut enthalten ist. Per default sind es natürlich alle.
Hi,
bei mir beendet sich FHEM direkt nach dem Definitionsaufruf der aktuellen Version aus dem Contrib als Collector.
Folgende Infos stehen im FHEM Log.
Zitat2018.08.10 07:58:07.689 3: Log2Syslog RemoteSyslog - entering Syslog servermode ...
2018.08.10 07:58:07.690 3: Log2Syslog RemoteSyslog - Opening socket ...
2018.08.10 07:58:07.690 3: Log2Syslog RemoteSyslog - port 1514/udp opened for Syslog Collector on interface "global"
Undefined subroutine &main::ReadingsSingleUpdateValue called at ./FHEM/93_Log2Syslog.pm line 315.
Ich hatte das Modul (auch die erweiterte Version aus dem Conrib) vorher noch nicht im Einsatz.
Greetz
Eldrik
Moin Eldrik,
danke für den Hinweis.
Das kommt davon wenn man ein paar Aufrufe einfach aus DbRep kopiert und nicht daran denkt dass jemand kein DbRep einsetzen könnte. :)
Hab's korrigiert ....
Grüße
Heiko
Hi,
klasse jetzt klappts!
Jedoch haben sich bei mir beim Testen ungereimtheiten aufgetan :)
Folgende Dinge habe ich vorhin ausprobiert.
Modul lediglich definiert
Meinen TPLink Switch angewiesen an den Host zu senden, hier kann ich keinen Standard definieren
Ergebnis: Folgende Meldung taucht im FHEM Log auf:
Zitat2018.08.10 09:03:58.469 1: Log2Syslog RemoteSyslog - error parse msg -> <131>2018-08-10 09:03:58 10.0.x.y 31890 Login the web by admin on web (10.0.x.y).
Meine Synology Diskstation angewiesen an den Host zu senden
Ergebnis: Folgende Meldung taucht im FHEM Log auf:
2018.08.10 09:26:29.655 1: Log2Syslog RemoteSyslog - error parse msg -> <14>Aug 10 09:26:29 eldrik-htpc System Test message from Synology Syslog Client from (xyz)
Im Modul parseProfile explizit auf BSD gesetzt und Test vom TPLink ausgeführt:
Ergebnis: Folgende Meldung taucht im FHEM Log auf
Zitat2018.08.10 09:29:48.849 1: PERL WARNING: Use of uninitialized value $Mmm in concatenation (.) or string at ./FHEM/93_Log2Syslog.pm line 520.
2018.08.10 09:29:48.849 1: PERL WARNING: Use of uninitialized value $dd in concatenation (.) or string at ./FHEM/93_Log2Syslog.pm line 520.
2018.08.10 09:29:48.850 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/93_Log2Syslog.pm line 520.
2018.08.10 09:29:48.850 1: PERL WARNING: Use of uninitialized value $ts in concatenation (.) or string at ./FHEM/93_Log2Syslog.pm line 520.
2018.08.10 09:29:48.850 1: PERL WARNING: Use of uninitialized value $host in concatenation (.) or string at ./FHEM/93_Log2Syslog.pm line 520.
2018.08.10 09:29:48.850 1: PERL WARNING: Use of uninitialized value $id in concatenation (.) or string at ./FHEM/93_Log2Syslog.pm line 520.
2018.08.10 09:29:48.850 1: PERL WARNING: Use of uninitialized value $host in string eq at ./FHEM/93_Log2Syslog.pm line 521.
Erneut via Synology Testprotokolle gesendet.
Ergebnis:
Das Reading Transfered_logs_per_minute wird hochgezählt im FHEM Log tauchen jedoch keine Zeilen auf, wo finde ich die Einträge nun?
Dann habe ich das Modul auf parseProfile raw gestellt, daraufhin wurde weiter nichts (sowohl senden von Diskstation als auch TP Link Switch) im FHEM Log angezeigt.
- Dann habe ich das Modul wieder auf BSD zurückgestellt, weiterhin taucht nichts im FHEM Log (sowohl senden von Diskstation als auch TP Link Switch) auf.
- Modul auf verbose5 gestellt nun erscheint beim einem Testlogin von meinem TPLink folgende Meldung im FHEM Log, mich wundert, dass hier von raw message gesprochen wird obwohl BSD gesetzt ist.
Zitat2018.08.10 09:54:14.042 5: Log2Syslog RemoteSyslog - ### new Syslog message Parsing ###
2018.08.10 09:54:14.042 5: Log2Syslog RemoteSyslog - message peerhost: localhost,127.0.0.1
2018.08.10 09:54:14.042 5: Log2Syslog RemoteSyslog - raw message -> <131>2018-08-10 09:54:14 10.0.x.y 31891 Logout the web by admin on web (10.0.x.y).
2018.08.10 09:54:14.043 4: RemoteSyslog - parsed message -> FAC: local0, SEV: Error, MM: , Day: , TIME: , TS: , HOST: , ID: , CONT: 2018-08-10 09:54:14 10.0.x.y 31891 Logout the web by admin on web (10.0.y.x).
2018.08.10 09:54:17.120 5: Log2Syslog RemoteSyslog - ### new Syslog message Parsing ###
2018.08.10 09:54:17.120 5: Log2Syslog RemoteSyslog - message peerhost: localhost,127.0.0.1
2018.08.10 09:54:17.120 5: Log2Syslog RemoteSyslog - raw message -> <131>2018-08-10 09:54:17 10.0.y.x 31890 Login the web by admin on web (10.0.x.y).
2018.08.10 09:54:17.121 4: RemoteSyslog - parsed message -> FAC: local0, SEV: Error, MM: , Day: , TIME: , TS: , HOST: , ID: , CONT: 2018-08-10 09:54:17 10.0.x.y 31890 Login the web by admin on web (10.0.y.y).
Greetz
Eldrik
Hi Eldrik,
lass uns mal die Sachen nach und nach durchgehen, sonst ist es zuviel auf einmal ;)
Grundsätzlich siehst du ohne irgendwelchen Einstellungen die geparsten Messages direkt im Eventmonitor. Du kannst das Attr "makeMsgEvent" verwenden um Readings mit/ohne Eventgeneration zu erstellen (-> help Log2Syslog).
Wenn im Log die Meldung "error parse msg ->" kommt, kann der eingestellte Parser die Message nicht auflösen. Hier hilft ein anderer Parser zu probieren oder einen eigenen schreiben oder "raw" zu verwenden, was quasi immer geht. Ich versuche den Standard IETF/BSD so gut es mir gelingt abzubilden und vollständig zu parsen.
Dein TPLink sendet keine Standard BSD oder IETF Message. Deswegen auch nicht im Router auswählbar (mein Vermutung). TPLink wird sicherlich häufig verwendet.
Dafür würde ich mal einen Parser bauen und mit integrieren. Hoffentlich wendet TPLink bei seinen Switches immer den gleichen Message-Aufbau an. :)
Deine Synology Testnachricht :
<14>Aug 10 09:26:29 eldrik-htpc System Test message from Synology Syslog Client from (xyz)
ist Standard-BSD. Ist auch im Syno Prokoll-Center auswählbar. Dann musst du im Modul auch im parseProfile BSD setzen. Wenn keine Fehler passieren sieht man im Modul
nicht viel, es sei denn du hast das Attr "makeMsgEvent" verwendet. Ansonsten erscheinen die Meldungen direkt im Eventmonitor (zur Weiterverarbeitung/Logging, was auch immer)
Mit verbose 4/5 siehst du Logeinträge zur Fehlersuche.
Deine Frage:
Zitat
mich wundert, dass hier von raw message gesprochen wird obwohl BSD gesetzt ist.
Mit verbose 5 wird immer zunächst die empfangene message komplett ( raw message ->) ausgedruckt. Dann erscheint noch das was der eingestellte Parser (Attr parseProfile) daraus gemacht hat (parsed message -> ).
Die Warnungen habe ich eleminiert und den IETF-Parser nachgebessert.
Lass uns erstmal ein paar Tests mit der Synology machen, die benutze ich während der Entwicklung auch und kann es gut nachvollziehen.
BTW: wenn du einen Sender mit Log2Syslog erstellst und disable=maintenance einstellst, kannst du beliebige Testnachrichten an den Empfänger senden um zu schauen was er daraus macht. Diese Funktion ist speziell bei den ersten Schritten ganz hilfreich.
EDIT: Schreib mir bitte noch deine Routerbezeichnung. Ich glaube nach ein paar Google-Suchen dass TPLink doch nicht ganz homogen arbeitet.
Grüße
Heiko
Hi,
ahja der Eventviewer :D ok da tauchen entsprechende Nachrichten auf.
help Log2Syslog habe ich ein paar Mal, unter anderem als mein Fhem bei den ersten Versuchen abgeraucht ist, ausgeführt.
Die Hilfe Seite die mir daraufhin angezeigt wird enthält aber nichts zum neuen Collector Modus sowie dem Attribut makeMsgEvent, in der .pm Datei kann ich die Infos nachlsen aber in FHEM wird mir nichts angezeigt :o
Mein TP Link Switch ist vom Modell TL-SG2424
Danke dir für den restlichen Input, damit komme ich weiter :)
Greetz
Eldrik
Du musst wirklich "help Log2Syslog" aufrufen und nicht links den "Commandref"-Link verwenden.
Oder im definierten Device "Device specific help" tut es auch.
Hi eldrik,
habe eine erweiterte Version nach contrib geladen. Es gibt ein parseProfile für TPLink-Switch.
Probiers mal aus.
Grüße
Heiko
Hallo Heiko,
klasse und danke für die Mühe, schaut soweit ich das beurteilen kann ganz gut aus!
Readings
MSG_10.0.x.y
FAC: local0 || SEV: Error || ID: 31890 || CONT: Login the web by admin on web (10.0.x.y).
Greetz
Eldrik
Ja, sieht gut aus.
Das IETF-Parsing habe ich weiter verfeinert und die Version nach contrib geladen.
Mit der V4.8.2 in contrib kann der Collector angewiesen werden nur auf Mitteilungen bestimmter Schweregrade zu reagieren.
Dazu wurde das Attr "sendSeverity" umbenannt zu "respectSeverity" und gilt nun sowohl für Sender als auch für Collector für die entsprechenden Funktionen.
Das Attr "makeMsgEvent" wurde umbenannt zu "makeEvent", was die Funktion eindeutiger beschreibt.
Hallo Heiko,
experimentiere gerade mit der neuen Version:
Das Default "BSD" schneidet mir bei der ID die MAC-Adresse ab.
Hier ein Beispiel:
FAC: system || SEV: Notice || ID: received request from B8 || CONT: XX:XX:XX:XX:XX with
B8 ist also noch Teil der Macadresse!
macht ja nichts, darum habe ich mir eine parseFn geschrieben.
Dazu eine Frage: Wie rufe ich
$Log2Syslog_BSDMonth{$Mmm}
aus der parseFn auf?
Bekomme da diese Fehlermeldung
Global symbol "%Log2Syslog_BSDMonth" requires explicit package name
Mit
{
$DATA =~ /^<(?<prival>[^>]*)>(?<month>[^\s]*)\s(?<day>[^\s]*)\s(?<time>[^\s]*)\s(?<host>[^\s]*)\s(?<tail>.*)$/;
$PRIVAL = $+{prival};
my $Mmm = $+{month};
my $dd = $+{day};
$TIME = $+{time};
$HOST = $+{host};
$CONT = $+{tail};
my $month = "08" ##should be $Log2Syslog_BSDMonth{$Mmm} ;
$TS = "$year-$month-$dd $TIME";
}
bekomme ich schon mal recht brauchbare Ergebnisse!
Wunsch: Könnte ich hier eventuell noch eine "exit"-Möglichkeit bekommen ähnlich wie in valueFn?
Ich muss manche Dinge hier filtern, da mein Router mich nur wenig filtern lässt....
(BZW. ich manche Informationen nur in den Debug-Logs vom Router erhalte)....
DANKE!! Tolles Modul!
sG
Joe
Hi Joe,
ZitatDas Default "BSD" schneidet mir bei der ID die MAC-Adresse ab.
Da muss ich versuchen den BSD Standard zu verfeinern. Sollte eigentlich machbar sein diesen Fall (XX:XX:XX...) mit zu berücksichtigen.
Aber mit der parseFN zu arbeiten führt auch zum Ziel.
ZitatDazu eine Frage: Wie rufe ich
Code: [Auswählen]
$Log2Syslog_BSDMonth{$Mmm}
aus der parseFn auf?
Definiere die parsFn mal so:
{
our %Log2Syslog_BSDMonth;
$DATA =~ /^<(?<prival>[^>]*)>(?<month>[^\s]*)\s(?<day>[^\s]*)\s(?<time>[^\s]*)\s(?<host>[^\s]*)\s(?<tail>.*)$/;
$PRIVAL = $+{prival};
my $Mmm = $+{month};
my $dd = $+{day};
$TIME = $+{time};
$HOST = $+{host};
$CONT = $+{tail};
my $month = $Log2Syslog_BSDMonth{$Mmm};
$TS = "$year-$month-$dd $TIME";
}
ZitatWunsch: Könnte ich hier eventuell noch eine "exit"-Möglichkeit bekommen ähnlich wie in valueFn?
Du meinst damit sicherlich die Variable $IGNORE, die wenn gesetzt, den Datensatz ins Nirvana entlässt, oder ?
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 20 August 2018, 18:16:58
Da muss ich versuchen den BSD Standard zu verfeinern. Sollte eigentlich machbar sein diesen Fall (XX:XX:XX...) mit zu berücksichtigen.
Da steck ich leider noch nicht tief genug drinnen um mitreden zu können....
Zitat von: DS_Starter am 20 August 2018, 18:16:58
Du meinst damit sicherlich die Variable $IGNORE, die wenn gesetzt, den Datensatz ins Nirvana entlässt, oder ?
Genau!! Mich interessiert praktisch nur ob eine dhcp adresse vergeben wurde und wann sie wieder deassigned wurde.
Dazu muss ich aus relativ vielen Meldungen die richtige herausfiltern.
Ist es so gedacht, dass im Reading immer alle diese Daten angezeigt werden müssen?
Mir würde für meinen Fall ein einfacher kurzer Text völlig ausreichen, den ich $CONT setzen könnte,
also zB $CONT = "online" oder eben $CONT = "offline".
Aber ich fürchte fast,ass mein spezieller Usecase damit weit von deiner ursprünglichen Intention entfernt ist?!??
Danke jedenfalls, macht spaß mit dem Modul zu experimentieren!!!
sG
Joe
Habe soeben eine Version nach contrib gebracht die deinen Fall mit dem Standard BSD-Parsing mit abdeckt.
Kannst du mal probieren, aber mit der parseFn zu arbeiten übt auch und macht Spaß :)
Das IGNORE baue ich nachher mit ein.
ZitatIst es so gedacht, dass im Reading immer alle diese Daten angezeigt werden müssen?
Nein. Du kannst das Attr "outputFields" benutzen um die anzuzeigenden Felder sowie deren Reihenfolge zu bestimmen.
In deinem Fall wäre es eben nur CONT.
Hast du das Attr "makeEvent" auch schon gesehen ?
Neue Version ist hochgeladen. $IGNORE kann jetzt verwendet werden. verbose 5 zeigt einen Logeintrag falls ein Datensatz IGNORiert wurde.
Der Term "our %Log2Syslog_BSDMonth;" hatte noch nicht richtig in der parseFn gezogen. Habe ich mit korrigiert.
LG,
Heiko
Hallo heiko,
Zitat von: DS_Starter am 20 August 2018, 19:29:00
Das IGNORE baue ich nachher mit ein.
DANKE!!!
Zitat von: DS_Starter am 20 August 2018, 19:29:00
Du kannst das Attr "outputFields" benutzen um die anzuzeigenden Felder sowie deren Reihenfolge zu bestimmen.
In deinem Fall wäre es eben nur CONT.
Ich bräuchte aber für diverse Geräte unterschiedliche "outputFields".
Ich löse das im Moment so dass ich outputFields auf CONT stelle und mir dort alles zusammenbaue.
Funktioniert einwandfrei, als schöner würde ich persönlich es jedoch empfinden wenn es reichen würde, eine
Variable auf undef oder "" zu setzen, um die Anzeige zu unterbinden....
Zitat von: DS_Starter am 20 August 2018, 19:29:00
Hast du das Attr "makeEvent" auch schon gesehen ?
Ja, habe aber keine Erklärung für "intern" gefunden. Auch aus dem Quellcode wurde mit dieser Parameter nicht klar.
Nutze daher im Moment "reading" und setze den host einfach auf den Wert, den ich benötige. Ist gut,
wobei ich den verpflichteten Prefix "MSG_" hinterfrage... aber funktioniert auch gut mit!
Danke,
sG
Joe
Morgen Joe,
ZitatIch bräuchte aber für diverse Geräte unterschiedliche "outputFields".
Wenn du ein unterschiedliches Setup brauchst um die Geräte unterschiedlich zu behandeln definiere dir doch einen weiteren Collector auf einen anderen Port und lasse das Gerät dahin loggen. Dann kannst du die anzuzeigenden Felder individuell definiere.
So hatte ich es mir für solche Fälle jedenfalls gedacht ;)
ZitatJa, habe aber keine Erklärung für "intern" gefunden. Auch aus dem Quellcode wurde mit dieser Parameter nicht klar.
Intern bedeutet dass die Eventgenerierung direkt im Modul passiert, keine Readings erstellt werden und nur im Eventmonitor die Daten ersichtlich sind. Dabei ist das Reading im Event immer nur der Hostname des Senders. Ich versuche die Beschreibung zu verbessern damit es deutlicher wird.
Zitatwobei ich den verpflichteten Prefix "MSG_" hinterfrage... aber funktioniert auch gut mit!
Bin mir grad nicht sicher, aber es war nur ein Sortierkriterium damit im Device diese Readings immer vor state etc. erscheinen. Aber kann auch noch einen tieferen Sinn haben ... möglicherweise hatte ich mir überlegt dem User die Möglichkeit zu geben einen eigenen Präfix zu definieren und MSG_ ist der default.
LG
Heiko
Bin nochmal in mich gegangen und nachgeschaut ... ich brauchte ein eindeutiges Merkmal im Readingnamen um beim Wechsel von Attr makeEvent die _richtigen_ Readings löschen zu können. Dazu war der Präfix "MSG_" gut geeignet.
Werde demnächst mal die englische Commandref noch aufbauen und die neue Modulversion normal einchecken.
LG
Heiko
Servus!
Bin wegen einem Baggerunfall leider zZ getrennt von meinen Installationen, daher kann ich im Moment nichts weiter testen!
Kann noch dauern, wurde mir gesagt :-[...
sG
joe
Hi Joe,
was machst du denn für Sachen ? :o
Gute Besserung !!!
Ich denke die Weiterentwicklung ist schon gut gereift. Änderungen wird es immer noch geben. Aber die sind dann sicherlich nicht mehr so gravierend. Außerdem geht es auch bei mir nicht sooo schnell. Doku schreiben ist nicht gerade meine Lieblingsbeschäftigung. ;)
LG,
Heiko
Hey Heiko,
Oh nein, sorry, missverständlich geschrieben.
Vor dem Haus gabs einen Baggerunfall-... Ein Bagger ist umgekippt und hat den Internet-Verteilerkasten umgerissen... Darum sind meine Installationen offline
und ich kann vom Ausland aus keinen LTE-Stick oder ähnliches dranhängen ;-)
Die Anwesenheitserkennung damit scheint enorm gut und genau zu funktionieren. Ich lasse mir zZ einmal pro Minute eine Syslog-Nachricht schicken, wenn
ein bestimmtes Handy online ist und auch wenn es daten verbraucht. Funktioniert besser wie alles bisherige!! Genial!
Dazu kombiniere ich einfach die Info, ob eine DHCP-Adresse vergeben wurde (das passiert auch im Ruhemodus!) und eben ob Traffik generiert wird!... :D
Damit kann ich zB den Rasenmäherroboter sofort nach Hause schicken, wenn jemand in der Nähe des Hauses ist!
Danke für die tolle Entwicklung!!
sG
Joe
Das war jetzt ein schönes Missverständnis. *grins*
Na dann ist ja alles gut ... :)
Ging nun doch schneller als gedacht mit der Dokuerstellung.
Die Weiterentwicklung ist eingecheckt und aus contrib entfernt.
LG,
Heiko
Hallo zusammen,
ich habe soeben die Version 5.0.0 nach contrib geladen:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/
Mit dieser Version ist nun neben UDP auch der TCP-Servermodus möglich, optional mit SSL-Unterstützung.
Weiterhin gibt es einige interne Weiterentwicklungen sowie für den Anwender sichtbare Änderungen:
* das verwendete Parse-PROFILE ist im Internal ersichtlich
* Reading "Parse_Err_No" gibt die Anzahl der fehlerhaften Parsings seit Start aus.
* das Attribut "octetCount" schaltet die Syslog Framing Methode um. Wen es interessiert, kann sich Infomationen dazu in RFC6587 "Transmission of Syslog Messages over TCP" anschauen.
* ein set "reopen" Kommando. Damit können Client/Server-Verbindungen geschlossen und wieder eröffnet werden. (z.B. bei "broken pipe)
Über Testergebnisse würde ich mich wie immer freuen. Ich selbst werde sicherlich auch noch das eine oder andere Szenario ausprobieren. Viel erfolgreich probiert habe ich mit FHEM <-> FHEM und Synology-Protokollcenter <-> FHEM, sowohl UDP als auch TCP(SSL).
LG,
Heiko
Guten Morgen,
eine Version 5.1.0 steht im contrib zur Verfügung.
Was sich seit 5.0.0 für den Nutzer geändert hat, ist mit
get <name> versionNotes
zu sehen.
LG,
Heiko
Die weiterentwickelte Version ist eingecheckt und aus contrib entfernt da ich auf Grund fehlender Rückmeldungen annehme, dass es auch bei euch problemlos funktioniert.
LG und schönen Feiertag
Heiko
Hallo,
erst mal danke für das Modul, welches ich jetzt auch entdeckt habe, soweit funktioniert es ohne Probleme, aber .... ;)
Beim ersten definieren erhalte ich folgenden Fehler
2018.10.20 17:57:42.124 1: define FHEM2Synlog Log2Syslog 192.168.12.2 fhem:.*: Bad regexp: Undefined subroutine &main::SYS_getdomainname called at /usr/share/perl/5.24/Net/Domain.pm line 160.[/code]
Definiere ich im Anschluss noch ein mal ist der Fehler weg und das Device wird auch angelegt und funktioniert. List:
Internals:
CFGFN
DEF 192.168.12.2 fhem:.*
MODEL Sender
MYFQDN FHEMpi
MYHOST FHEMpi
NAME FHEM2Synlog
NR 1385
NTFY_ORDER 50-FHEM2Synlog
PEERHOST 192.168.12.2
SEQNO 1
STATE initialized
TYPE Log2Syslog
VERSION 5.3.0
HELPER:
FHEMLOG .*
LTIME 1540051120.473
OLDSEQNO 1
OLDSTATE initialized
SSLALGO n.a.
SSLVER n.a.
READINGS:
2018-10-20 17:58:40 SSL_Algorithm n.a.
2018-10-20 17:58:40 SSL_Version n.a.
2018-10-20 17:58:40 Transfered_logs_per_minute 0
2018-10-20 17:58:40 state initialized
Attributes:
Wenn ich jetzt aber einen Neustart von FHEM mache taucht die Fehlermeldung wie folgt wieder auf
2018.10.20 17:59:52.231 0: Server shutdown
2018.10.20 18:00:25.234 1: Including fhem.cfg
2018.10.20 18:00:37.068 1: SZ.HT: no I/O device
2018.10.20 18:00:37.420 1: WZ.HT: no I/O device
2018.10.20 18:00:37.470 1: AZ.HT: no I/O device
2018.10.20 18:00:37.501 1: KLIMA.T: no I/O device
2018.10.20 18:00:37.516 1: BAD.HT: no I/O device
2018.10.20 18:00:37.567 1: OUT.HT: no I/O device
2018.10.20 18:00:42.877 1: 192.168.12.203:5900 reappeared (UMBox)
2018.10.20 18:00:44.114 1: define FHEM2Synlog Log2Syslog 192.168.12.2 fhem:.*: Bad regexp: Undefined subroutine &main::SYS_getdomainname called at /usr/share/perl/5.24/Net/Domain.pm line 160.
2018.10.20 18:00:44.115 1: Including /media/usb0/log/fhem.save
2018.10.20 18:00:44.729 1: configfile: Bad regexp: Undefined subroutine &main::SYS_getdomainname called at /usr/share/perl/5.24/Net/Domain.pm line 160.
/media/usb0/log/fhem.save: Please define FHEM2Synlog first
Please define FHEM2Synlog first
Please define FHEM2Synlog first
Please define FHEM2Synlog first
Please define FHEM2Synlog first
Evtl. weis der Modulentwickler oder sonst jemand einen Rat.
Vielen Dank im Voraus.
Grusa
Ma.
Hallo Ma,
konnte dein Problem noch nicht nachvollziehen.
Ich habe ebenfalls Perl 5.24.
Deine Definition
define FHEM2Synlog Log2Syslog 192.168.12.2 fhem:.*
habe ich soeben bei mir ausgeführt ohne jegliche Fehlermitteilung.
Also ich kann mir noch keinen Reim auf diesen Fehler machen, da er offensichtlich tiefer liegt und ein verwendetes Perl-Standardmodul (Net::Domain) seinerseits diesen Fehler wirft.
Welches Betriebssystem hast du ? Ich muss mal etwas googeln.
Vielleicht hat noch jemand eine Idee ...
Grüße
Heiko
Hallo Ma,
ich habe die bei dir problematische Stelle im Modul etwas abgeändert.
Bitte lade dir die Version aus contrib nach ./FHEM:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter (Download-Button verwenden)
Danach FHEM restarten.
Wie sieht es dann aus ?
Hallo Heiko,
erst mal danke für die schnelle Antwort und den umgehenden Support.
Ich werde deine Anweisung gleich umsetzen.
FHEM läuft auf einem 3er RPi mit OS Raspbian 9 (Stretch). Die System-Pakete sind aktuell.
Ich melde mich wieder
Gruß
Ma.
Hallo,
leider besteht das Problem immer noch. Evtl liegt es doch an meiner Konfi, ich werde mich diesbezüglich mal schlau machen. Könnte es evtl. an einem im Netzwerk betriebenen PiHole liegen?
Bis dahin, ich melde mich wieder.
Gruß
Ma.
Ok, schade. Allerdings müsste sich das Verhalten dahingehend geändert haben, dass es evtl. eine Fehlermitteilung gibt, die aber keinen negativen EInfluss auf das Modul oder dessen Ladeverhalten mehr hat. Hast du restartet ?
Kurios ist, dass ich ebenfalls Debian 9 betreibe, wobei es kein Pi ist. Aber das sollte keinen Einfluss haben und andere Nutzer haben eine solche Fehlermeldung auch noch nicht gepostet.
Etwas eigenartig, weil es eben eine Meldung von dem Perl-Standardmodul ist.
PiHole kenne ich nicht, aber nach einem kurzen googeln danach würde ich nicht vermuten dass dieser Fehler etwas damit zu tun haben könnte. Aber wer weiß ...
LG,
Heiko
Hallo Heiko,
an dem Verhalten hat sich nichts geändert, genau das gleich wie zuvor.
Ja ich habe nach dem dem einspielen neu gestartet, zuvor das alte Device gelöscht (danach auch neu gestartet). Ich werde mich die kommende Woche etwas ausgiebiger damit beschäftigen, heute habe ich keine Muse mehr ;)
Bis dahin, schönen Sonntag noch.
Gruß
Manuel
Hallo Heiko,
kannst Du Bitte mal das Leerzeichen aus dem apt-get install libio-socket- multicast-perl nehmen.
apt-get install libio-socket-multicast-perl
Das hat bei mir gerade wieder ne viertel Stunde gedauert bist ich mitbekommen habe, dass es nur ein Paket ist und nicht zwei. ;-)
Grüße Frank
Morgen Frank,
mach ich ... danke für den Hinweis :)
Grüße
Heiko
Noch ne Frage.
Bei mir wir auf der Synology der Hostname nur mit 0.0.0.0 geführt. Kann man das ändern. Habe hier nichts gefunden oder habe ich was überlesen?
Hallo Frank,
das was bei dir als 0.0.0.0 erscheint, ist eigentlich der Hostname des Senders.
Er wird im Device beim FHEM/Device-Start ermittelt per hostname().
Was ergibt denn hostname auf BS-Ebene ?
Ich könnte den Wert per Attribut auch einstellbar machen, aber es sollte automatisch ziehen.
EDIT: Test geht auch mit {hostname()} in der FHEM Kommandozeile
Grüße
Heiko
Ähh... auch noch ne Frage ... wo hast du denn das Leerzeichen gesehen ?
Wenn ich in meine Hilfe schaue, dann sieht alles gut aus -> Anhang.
Könnte es sein, dass du nicht die aktuellste Version hast ? Das ist die 5.3.1
Hallo Heiko,
auf BS Ebene gibt localhost ,,FHEM-Test" aus. Ich habe gerade noch einmal einen Neustart des BS gemacht aber auch da bleibt der Hostnamen im Protokoll Center auf 0.0.0.0
Die 5.3.1 habe ich auch.
Wenn ich den {hostname()} in FHEM abfrage bekomme ich keine Ausgabe.
Das Lehrzeichen ist im ersten Beitrag in diesem Thread zu viel.
Grüße
ZitatDas Lehrzeichen ist im ersten Beitrag in diesem Thread zu viel.
Ah ... habs geändert.
ZitatWenn ich den {hostname()} in FHEM abfrage bekomme ich keine Ausgabe.
Ja das ist der Grund, bei mir wird der Hostname geliefert.
Ich schaue mal, notfalls biete ich dem User das Setzen des Senderhostnamens per Attribut an. Damit könnte er ihn auch überschreiben um den Sender zu kennzeichnen.
Poste bitte mal noch ein List von deinem Device.
Mir ist noch etwas eingefallen, was sagt denn
hostname -f
auf der BS-Ebene ? Möglicherweise hast du keinen FQDN gesetzt.
root@FHEM-Test:/home/frank# hostname -f
hostname: Name or service not known
Da liegt also der Fehler.
Ich habe gleich mal meine /etc/hosts entsprechend angepasst.
root@FHEM-Test:/home/frank# hostname -f
FHEM-Test
Jetzt fluppts! Und {hostname()} liefert auch den korrekten Namen in FHEM.
Danke für den Hinweis.
Wo wir gerade dabei sind. Wo und wie stelle ich jetzt den LogLevel ein? mit 'verbose' in 'global' oder im Modul. Das hat aber keinerlei Auswirkung zu haben.
Edit:
Ich habe es. Es waren ja auch nur noch Events im Log. Die habe ich je in der Definition event:.* mit vereinbart.
Ich habe da mal noch ne Frage zum Modul:
Die Erweiterungen [ident:<ident>] [event:<regexp>] [fhem:<regexp>] machen mir ein wenig Probleme. Mit folgender Definition wird das Device angelegt und funktioniert einwandfrei.
defmod Log2Syslog Log2Syslog 192.168.3.3 ident:FHEM-Test event:.* fhem:.*
attr Log2Syslog room SYSTEM
Wenn ich dann, weil mir zu viele Informationen in Protokoll erscheinen das "event:.*" lösche, wird das Device obwohl es in der fhem.cfg steht, nicht mehr angezeigt. Das ist auf meinem Testsystem eindeutig reproduzierbar. Ich dachte die o.g. Erweiterungen sind optional!?
Grüße
Hallo Frank,
ZitatDas ist auf meinem Testsystem eindeutig reproduzierbar. Ich dachte die o.g. Erweiterungen sind optional!?
Das sind sie auch !
Ich kann das bei mir auch nicht nachvollziehen. Habe exakt deine Definition ohne "event:.*" angelegt und das Device ist auch ganz normal im Raum SYSTEM sichtbar.
siehe Anhang.
Kann ich mir nicht erklären was du da hast ???
Grüße,
Heiko
Hallo zusammen,
ich habe dem Modul eine automatische Erkennung des BSD/IETF Syslog-Formats spendiert.
Für das Attribut "parseProfile" gibt es dazu nun auch den Wert "Automatic" was gleichzeitig der Standard nach der Definition eines Collectors ist.
Zum Testen befindet sich die Modulversion zunächst im contrib:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter (Downloadbutton benutzen)
Grüße,
Heiko
Hallo, ich nutze Fhem bereits etwas länger und habe dank des Forums alle Unklarheiten beseitigen können.
Nun muss ich aber auch mal eine Frage stellen.
Ich möchte auch gerne meine Logs an meine Synology weiter leiten.
Das klappt allerdings so gut, dass ich am ersten Tag bereits nach ca. 8 Stunden 46.000 Einträge hatte.
Also habe ich noch mal in der Commandref nachgelesen und versucht nur bestimmte verbose-level zu berücksichtigen.
Das hat aber scheinbar nicht richtig funktioniert.
Wenn ich global verbose auf 3 stelle und in meinem fhem-log ~100 Einträge habe, hätte ich jetzt im Prokotoll-Center auch ~100 Einträge erwartet.
Das sind aber immer noch viel mehr.
Hier mal mein Device:
Internals:
DEF 192.168.148.46 ident:fhem event:.* fhem:.*
FUUID 5c900f3a-f33f-8e7c-735c-acf1993b4e95d11b
MODEL Sender
MYFQDN homeserver
MYHOST homeserver
NAME Syslog
NR 717
NTFY_ORDER 50-Syslog
PEERHOST 192.168.168.46
SEQNO 1
STATE disabled
TYPE Log2Syslog
VERSION 5.3.2
HELPER:
EVNTLOG .*
FHEMLOG .*
IDENT fhem
LTIME 1553149578.32221
OLDSEQNO 1
OLDSTATE disabled
SSLALGO n.a.
SSLVER n.a.
READINGS:
2019-03-20 22:05:16 SSL_Algorithm n.a.
2019-03-20 22:05:16 SSL_Version n.a.
2019-03-21 07:26:18 Transfered_logs_per_minute 0
2019-03-21 07:26:30 state disabled
Attributes:
disable 1
icon edit_paste
respectSeverity Emergency,Alert,Critical,Error,Warning,Notice
Auch sind mir die Parameter noch nicht ganz klar:
define <name> Log2Syslog <Zielhost> [ident:<ident>] [event:<regexp>] [fhem:<regexp>]
event scheint klar zu sein, da kann ich gezielt nur temperature oder humidity loggen.
Aber der Parameter fhem ist mir noch nicht klar:
optionaler regulärer Ausdruck zur Filterung von FHEM Logs zur Weiterleitung
Kann ich hier nur bestimmte Logs berücksichtigen?
Dann könnte ich hier ja fhem: fhem.* nehmen damit nur die fhem-logs berücksichtigt werden.
Habe ich natürlich probiert, aber das hat auch nicht funktioniert.
Wäre um paar Hinweise dankbar. Danke und viele Grüße, Tarja
Hallo TarjaT,
willkommen im Forum. :)
Grundsätzlich verarbeitet das Modul FHEM Logs, d.h. Einträge die im FHEM-Logfile erstellt werden, und die Events.
Die eingestellten verbose Level global bzw. pro Device steuern zwar die Einträge im FHEM Log, aber mit deiner Einstellung
192.168.148.46 ident:fhem event:.* fhem:.*
überträgst du alles was an Events erstellt wird und das was in dem FHEM Log entsteht.
Zitat
Aber der Parameter fhem ist mir noch nicht klar:
optionaler regulärer Ausdruck zur Filterung von FHEM Logs zur Weiterleitung
...
Kann ich hier nur bestimmte Logs berücksichtigen?
Dann könnte ich hier ja fhem: fhem.* nehmen damit nur die fhem-logs berücksichtigt werden.
Habe ich natürlich probiert, aber das hat auch nicht funktioniert.
Ja, das kannst du tun. Dafür sind die Filter im Define gemacht.
Der Parameter "fhem" funktioniert genauso wie "events", nur dass sich der nach "fhem" angegebene reguläre Ausdruck auf entstehende Einträge des FHEM-Logs bezieht.
So werden mit
fhem:.*Thermostat.*nur Einträge weitergeleitet, die "Thermostat" im Satz enthalten. ZUsätzlich können Schwergrade eingeschränkt werden mit dem respectSeverity Attribut. Hast du ja auch schon.
Wenn du Schwierigkeiten hast, setze im Log2Syslog-Device verbose 4 oder 5 und poste entstsprechende Auszüge aus dem Log gemeinsam mit einem List wie du es schon getan hast.
LG,
Heiko
Okay, danke. Dann habe ich das soweit verstanden.
Schade ist allerdings, dass die Keywords "error" grundsätzlich verwertet werden.
Meine Wanscam hat die Readings:
> Error: none
> Errorcode: none
Die tauchen nun ständig im Protokoll-Center auf, obwohl das ja keine ERROR sind.
Was mich noch stört ist der Hostname, der ist nämlich eigentlich homeserver.local:
> hostname
homeserver.local
> hostnamectl
Static hostname: homeserver.local
> /etc/hosts
127.0.0.1 localhost
127.0.1.1 homeserver.local
In der Synology steht allerdings: homeserver.fritz.box
In meiner Fritzbox ist der Server namentlich mit "Homeserver" angegeben.
Eine Idee woher der sich den "falschen" Namen noch zieht?
Zitat
Schade ist allerdings, dass die Keywords "error" grundsätzlich verwertet werden.
Meine Wanscam hat die Readings:
> Error: none
> Errorcode: none
Ja, das Mapping ist nicht ganz unproblematisch.
Hilfreiche Vorschläge nehme ich gerne entgegen.
Zitat
Eine Idee woher der sich den "falschen" Namen noch zieht?
Es wird im Prinzip das verwendet, was der FHEM-Server liefert wenn man
hostname
bzw.
hostname -f
auf Betriebssystemebene ausführt.
Die /etc/hosts sollte also enthalten:
127.0.1.1 homeserver.local homeserver
EDIT: Jetzt habe ich deinen Post nochmal gelesen und bin der Meinung, dass der Hostname durch den DNS bestimmt wird.
Kannst ja mal schauen was mit
nslookup 127.0.1.1
angezeigt wird.
Für die Implementierung einer Negativliste bezüglich Error-Schweregrad habe ich inzwischen auch eine Idee.
Werde das bei Gelegenheit versuchen umzusetzen und melde mich wenn ich etwas erreicht habe.
Also hostname als auch hostname -f liefern das gleiche Ergebnis: homeserver.local
> nslookup 127.0.0.1
Server: 192.168.168.1
Address: 192.168.168.1#53
Non-authoritative answer:
1.0.0.127.in-addr.arpa name = localhost.
Authoritative answers can be found from:
Hast du hosts so umgeändert wie ich es geschrieben hatte ?
Die Adresse in nslookup ist falsch. Probiers nochmal mit der richtigen .
Edit
Deine netzkonfig kommt mir bisschen komisch vor. Wieso nutzt du 127er Adressen ? Normal wäre mM nach 192.168.x.x
Hallo zusammen,
habe soeben eine Version eingecheckt, die das Attribut exclErrCond enthält um bestimmte Events vor der Zuweisung des
Schweregrades "Error" zu schützen.
* exclErrCond <Pattern1,Pattern2,Pattern3,...>Wird in einem Event der Text "Error" erkannt, bekommt diese Message automatisch den Schweregrad "Error" zugewiesen. Im Attribut exclErrCond kann eine durch Komma getrennte Liste von Events angegeben werden, deren Schweregrad trotzdem nicht als "Error" gewertet werden soll. Kommas innerhalb von <Pattern> müssen mit ,, (doppeltes Komma) escaped werden. Das Attribut kann Zeilenumbrüche enthalten.
Beispiel
attr <name> exclErrCond Error: none,
Errorcode: none,
Dum.Energy PV: 2853.0,, Error: none,
.*Seek_Error_Rate_.*,
.*Raw_Read_Error_Rate_.*,
.*sabotageError:.*,
Ist morgen früh im Regelupdate. Wer es eilig hat (vllt. TarjaT), kann die Version auch aus dem contrib laden.
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter (Downloadbutton benutzen)
Top, super. Vielen Dank dafür.
Wegen des Hostnamen muss ich mich noch mal melden wenn ich wieder zu Hause bin.
Hallo Zusammen,
versuche das log2syslog modul zu nutzen, um JSON messages eines devices (Wiffi-Pump2) im raw-format zu empfnagen und dann weiter zu verarbeiten. Allerdings werden die JSON Messages meist in zwei Stücke zerlegt, so dass nur das letzte Stück zur weiteren Verarbeitung im Reading steht. Unten sieht man im Log eine "unzerteilte", danach eine zerteilte Message - leider bleibt nur der zweite Teil erhalten, die Nutzdaten sind aber meistens im 1. Teil.
Any hints?
VG Timmo
Auszug Log File
2019.07.17 21:08:18.173 4: Connection accepted from SyslogServer_192.168.178.65_20304
2019.07.17 21:08:18.175 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:18.175 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.17 21:08:18.176 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:18.176 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20304
2019.07.17 21:08:18.177 5: Log2Syslog SyslogServer - Buffer content:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.92"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"1996","zeitpunkt":"2019-07-17 21:08:17","firmware":"wiffi_pump2_91"}}
2019.07.17 21:08:18.178 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.17 21:08:18.178 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.92"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"1996","zeitpunkt":"2019-07-17 21:08:17","firmware":"wiffi_pump2_91"}}
2019.07.17 21:08:18.179 4: Log2Syslog SyslogServer - {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.92"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"1996","zeitpunkt":"2019-07-17 21:08:17","firmware":"wiffi_pump2_91"}}
2019.07.17 21:08:18.204 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:18.205 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.17 21:08:18.205 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:18.205 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20304
2019.07.17 21:08:18.207 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_20304: EOF
Und hier die session mit der zerteilten Nachricht - mittedrin beginnt ein neues Systlog Parsing:
2019.07.17 21:08:55.555 4: Connection accepted from SyslogServer_192.168.178.65_20028
2019.07.17 21:08:55.557 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:55.557 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.17 21:08:55.558 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:55.558 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20028
2019.07.17 21:08:55.559 5: Log2Syslog SyslogServer - Buffer content:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.62"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.17 21:08:55.560 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.17 21:08:55.560 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.62"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.17 21:08:55.561 4: Log2Syslog SyslogServer - {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.62"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.17 21:08:55.599 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:55.600 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.17 21:08:55.600 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:55.601 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20028
2019.07.17 21:08:55.601 5: Log2Syslog SyslogServer - Buffer content:
"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-46","sec_seit_reset":"2034","zeitpunkt":"2019-07-17 21:08:55","firmware":"wiffi_pump2_91"}}
2019.07.17 21:08:55.602 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.17 21:08:55.602 4: Log2Syslog SyslogServer - raw message -> "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-46","sec_seit_reset":"2034","zeitpunkt":"2019-07-17 21:08:55","firmware":"wiffi_pump2_91"}}
2019.07.17 21:08:55.602 4: Log2Syslog SyslogServer - "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-46","sec_seit_reset":"2034","zeitpunkt":"2019-07-17 21:08:55","firmware":"wiffi_pump2_91"}}
2019.07.17 21:08:55.617 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:55.618 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.17 21:08:55.618 4: Log2Syslog SyslogServer - #######################################################
2019.07.17 21:08:55.618 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20028
2019.07.17 21:08:55.620 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_20028: EOF
List des Moduls
Internals:
CONNECTS 6
FD 23
FUUID 5d2b3d43-f33f-b872-6c66-157ec1caf94e23c0
FVERSION 93_Log2Syslog.pm:v5.6.1-s19029/2019-03-25
INTERFACE global
MODEL Collector
MYFQDN fhemserver
MYHOST fhemserver
NAME SyslogServer
NR 279
NTFY_ORDER 50-SyslogServer
PORT 1883
PROFILE raw
PROTOCOL tcp
SEQNO 11
STATE active
TYPE Log2Syslog
HELPER:
LTIME 1563390676.63314
OLDSEQNO 9
OLDSTATE active
PACKAGE main
TCPPADDR 192.168.178.65
VERSION 5.6.1
HIPCACHE:
192.168.178.27 ESP-49B323.fritz.box
192.168.178.65 ESP-D95E39.fritz.box
OLDREADINGS:
READINGS:
2019-07-17 21:11:32 MSG_ESP-D95E39.fritz.box "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"2191","zeitpunkt":"2019-07-17 21:11:31","firmware":"wiffi_pump2_91"}}
2019-07-17 21:11:16 Transfered_logs_per_minute 0
2019-07-17 21:11:32 p_status "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"2191","zeitpunkt":"2019-07-17 21:11:31","firmware":"wiffi_pump2_91"}}
2019-07-17 21:11:32 state active
Attributes:
makeEvent reading
parseProfile raw
port 1883
protocol TCP
room 9.0_System
userReadings p_status {my $w = ReadingsVal("SyslogServer","MSG_ESP-D95E39.fritz.box",0);; $w =~ s/.*"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":("true"|"false").*/$1/ ;; $w }
verbose 5
OrginalJSON
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"52.72"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"2168","zeitpunkt":"2019-07-17 21:11:09","firmware":"wiffi_pump2_91"}}
Hallo Timmo,
ich vermute du hast ein carrige return + new line in deinem JSON enthalten.
Ich hatte im Parsing ein split für diese Zeichen drin. Kann momentan nicht mehr sagen warum das so ist.
Aber ich habe dir eine angepasste Version in mein contrib geladen (siehe Fußnote).
Lade sie dir mal herunter (Downloadtaste benutzen!) und probiere es mal. Ich habe deinen String bei mir damit problemlos übertragen können.
Grüße,
Heiko
Hallo Heiko,
vielen Dank für die wahnsinnig schnelle Reaktion!
Scheint jetzt mal zu funktionieren, mal nicht - dann an der gleichen Stelle (unten direkt nacheinander einmal gut, einmal nicht gut). Gibt es eine Möglichkeit, die ankommende Raw-Message aufzufangen - i.e. dass ich mal mit einem Editor reinschaue? Vielleicht auch ausserhalb des Moduls, so das mann die Message wirklich Raw sieht? Vielleicht streut der Kollege Wiffi ab und an wilde Zeichen rein... oder es ist ein timing Problem.
Let me know, vg Timmo
Internals:
CONNECTS 3
FD 15
FUUID 5d2b3d43-f33f-b872-6c66-157ec1caf94e23c0
FVERSION 93_Log2Syslog.pm:v5.6.3-s19029/2019-03-25
INTERFACE global
MODEL Collector
MYFQDN fhemserver
MYHOST fhemserver
NAME SyslogServer
NR 279
NTFY_ORDER 50-SyslogServer
PORT 1883
PROFILE raw
PROTOCOL tcp
SEQNO 7
STATE active
TYPE Log2Syslog
HELPER:
LTIME 1563473184.33408
OLDSEQNO 7
OLDSTATE active
PACKAGE main
SSLALGO n.a.
SSLVER n.a.
TCPPADDR 192.168.178.65
VERSION 5.6.3
HIPCACHE:
192.168.178.65 ESP-D95E39.fritz.box
OLDREADINGS:
READINGS:
2019-07-18 20:05:54 MSG_ESP-D95E39.fritz.box "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-46","sec_seit_reset":"84652","zeitpunkt":"2019-07-18 20:05:54","firmware":"wiffi_pump2_91"}}
2019-07-18 20:06:24 Transfered_logs_per_minute 4
2019-07-18 20:06:24 p_status "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-46","sec_seit_reset":"84652","zeitpunkt":"2019-07-18 20:05:54","firmware":"wiffi_pump2_91"}}
2019-07-18 20:05:54 state active
Attributes:
makeEvent reading
parseProfile raw
port 1883
protocol TCP
room 9.0_System
userReadings p_status {my $w = ReadingsVal("SyslogServer","MSG_ESP-D95E39.fritz.box",0);; $w =~ s/.*"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":("true"|"false").*/$1/ ;; $w }
verbose 5
2019.07.18 20:10:54.587 4: Connection accepted from SyslogServer_192.168.178.65_31509
2019.07.18 20:10:54.588 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:10:54.589 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.18 20:10:54.589 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:10:54.589 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_31509
2019.07.18 20:10:54.590 5: Log2Syslog SyslogServer - Buffer content:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.32"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-45","sec_seit_reset":"84952","zeitpunkt":"2019-07-18 20:10:53","firmware":"wiffi_pump2_91"}}
2019.07.18 20:10:54.591 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.18 20:10:54.591 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.32"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-45","sec_seit_reset":"84952","zeitpunkt":"2019-07-18 20:10:53","firmware":"wiffi_pump2_91"}}
2019.07.18 20:10:54.591 4: Log2Syslog SyslogServer - {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.32"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-45","sec_seit_reset":"84952","zeitpunkt":"2019-07-18 20:10:53","firmware":"wiffi_pump2_91"}}
2019.07.18 20:10:54.606 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:10:54.606 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.18 20:10:54.607 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:10:54.607 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_31509
2019.07.18 20:10:54.608 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_31509: EOF
2019.07.18 20:13:07.167 4: Connection accepted from SyslogServer_192.168.178.65_3888
2019.07.18 20:13:07.167 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:13:07.168 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.18 20:13:07.168 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:13:07.169 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_3888
2019.07.18 20:13:07.169 5: Log2Syslog SyslogServer - Buffer content:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.14"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.18 20:13:07.170 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.18 20:13:07.170 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.14"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.18 20:13:07.170 4: Log2Syslog SyslogServer - {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.14"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.18 20:13:07.186 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:13:07.186 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.18 20:13:07.186 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:13:07.187 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_3888
2019.07.18 20:13:07.187 5: Log2Syslog SyslogServer - Buffer content:
"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"85084","zeitpunkt":"2019-07-18 20:13:06","firmware":"wiffi_pump2_91"}}
2019.07.18 20:13:07.188 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.18 20:13:07.188 4: Log2Syslog SyslogServer - raw message -> "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"85084","zeitpunkt":"2019-07-18 20:13:06","firmware":"wiffi_pump2_91"}}
2019.07.18 20:13:07.188 4: Log2Syslog SyslogServer - "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-47","sec_seit_reset":"85084","zeitpunkt":"2019-07-18 20:13:06","firmware":"wiffi_pump2_91"}}
2019.07.18 20:13:07.202 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:13:07.203 4: Log2Syslog SyslogServer - ######### new Syslog TCP Parsing #########
2019.07.18 20:13:07.203 4: Log2Syslog SyslogServer - #######################################################
2019.07.18 20:13:07.204 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_3888
2019.07.18 20:13:07.205 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_3888: EOF
Hallo Timmo,
ich habe das Modul nochmal dahingehend geändert, dass im raw-Mode maximal 16384 Zeichen auf einmal empfangen werden können. Aber das ist eigentlich nur ein Negativtest, ich glaube nicht dass es daran liegt.
Zieh dir das Modul bitte nochmal aus dem contrib.
Im Prinzip ist das was nach "2019.07.18 20:13:07.187 5: Log2Syslog SyslogServer - Buffer content:" angezeigt wird, genau der Content der vom Interface geliefert wird. Du kannst aber auch mit tcpdump auf BS-Ebene versuchen etwas herauszubekommen.
Ich vermute allerdings eher, dass auf Senderseite etwas zu machen wäre. Der Sender müsste ja nach jedem Datensatz ein Endezeichen senden oder CR/LF tut es auch, deswegen hatte ich wohl den split drin.
Ich habe einen Test gemacht. Ein FHEM mit einem Collector im raw-Mode und in einem anderen FHEM einen Sender definiert. Den Sender kann man mit "disable = maintenance" in einen manuellen Modus setzen.
Dann kann man mit:
set <name> sendTestMessage {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"49.32"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-45","sec_seit_reset":"84952","zeitpunkt":"2019-07-18 20:10:53","firmware":"wiffi_pump2_91"}}
die Mitteilung an den Collector senden. Auch als Schleife, z.b. mit einem AT. Dann habe ich noch ein expandJSON-Device definiert und angewendet. Damit wird dann auf Empfängerseite dein JSON sauber in Einzelreadings aufgedröselt.
Also das klappte ganz prima :)
Wie sendest du denn den String ?
LG,
Heiko
Hallo Heiko,
danke Dir... habe es nochmals probiert (Du hattest die Version nicht verändert?) - keine Veränderung. Ich habe den Entwickler angepingt (Eugen Stall), ob er eine Idee hat - mal schauen.
Mit dem TCP sniffer muss ich mich am WE auseinandersetzen, da muss ich erstmal die manpages lesen.. ;-)
VG Timmo
Link zum Homematik-Forum in dem die Wiffis diskutiert werden:
https://homematic-forum.de/forum/viewtopic.php?f=31&t=32030&p=518955#p518955 (https://homematic-forum.de/forum/viewtopic.php?f=31&t=32030&p=518955#p518955)
(Der Wiffi-Bausatz dient zur Steuerung der Warmwasser-Umwälzpumpe - ich würde gerne statt ständigem Pollen die Push-Telegramme auswerten, um den Status der Umwälzpumpe zu erkennen)
Ja, die Version hatte ich jetzt nicht verändert.
Na mal schauen was da rauskommt, interessiert mich auch.
Also das einfachste wäre nach jedem Datensatz ein CR/LF einzufügen. Das würde erkannt werden. Wobei die sauberste Lösung m.M. nach ein "End of File" EOF wäre.
LG,
Heiko
Hallo Heiko,
kurzes Update... Nachdem ich mich durch TCP-Sniffing durchgearbeitet habe, einen neuen Raspi mit FHEM aufgesetzt habe, und zwei Wiffimodule genutzt habe (wer weiss, was ich da alles in drei Jahren verkonfiguriert habe...)..
Ich habe den Eindruck, dass der Wiffi und der Raspi auf der TCP Ebene während einer Connection mehrere Versuche brauchen, das Telegramm sauber rüberzubekommen. Im Protokoll unten ist sichtbar, dass zwischendurch Checksum Probleme auftauchen, und dann das Telegramm erneut teilweise gesendet wird (Anfang des Telegramms ist immer "Modultyp", Ende immer die Firmwareversion). Es ist auch nicht immer die gleiche Stelle, wo das Ganze abbricht.
Insofern fällt das vielleicht eher unter feature, nicht bug... die Netzwerkverbindung enthält WLAN und powerline. Aber wo steht dann der zusammengesetzte, komplette Inhalt der Session, die am Port ankommt? Ich habe die Telegrammer auch mal an meinen Windows-Rechner geschickt, hier kommt das Telegramm immer vollständig an (allerdings kenne ich die Intelligenz des Programms "Port Listener" nicht - ob der (oder der Windows-TCP Stack) die Teilmessages zusammensetzt).
Any idea?
Immerhin habe ich in den letzten Stunden was über den TCP-Stack gelernt - auch gut ;-)
Noch ein Gedanke... kann es an der Implementierung UDP vs TCP liegen? TCP macht ja eine Error-Recovery, und die scheint hier nicht beachtet zu werden, sondern es werden einfach die Teilstücke als Message weitergereicht?
VG Timmo
11:49:01.886814 IP (tos 0x0, ttl 128, id 19099, offset 0, flags [none], proto TCP (6), length 44)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [S], cksum 0x7b9d (correct), seq 473817479, win 5840, options [mss 1460], length 0
E..,J.....
{.......I...].=......`...{.........
11:49:01.886940 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [S.], cksum 0xe5d4 (incorrect -> 0x3e9a), seq 2486390142, ack 473817480, win 29200, options [mss 1460], length 0
E..,..@.@.U....I.....]...3M~.=..`.r.........
11:49:01.891040 IP (tos 0x0, ttl 128, id 19100, offset 0, flags [none], proto TCP (6), length 40)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [.], cksum 0xb197 (correct), seq 1, ack 1, win 5840, length 0
E..(J.....
~.......I...].=...3M.P.............
11:49:01.892142 IP (tos 0x0, ttl 127, id 19101, offset 0, flags [none], proto TCP (6), length 664)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [P.], cksum 0x83af (correct), seq 1:625, ack 1, win 5840, length 624
E...J..... ........I...].=...3M.P.......{"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"192.168.178.27"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"30.3"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"30.3"},{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"30.3"},{"name":"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},
11:49:01.892213 IP (tos 0x0, ttl 64, id 37132, offset 0, flags [DF], proto TCP (6), length 40)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [.], cksum 0xe5d0 (incorrect -> 0x49a7), seq 1, ack 625, win 31824, length 0
E..(..@.@......I.....]...3M..=..P.|P....
11:49:01.899226 IP (tos 0x0, ttl 127, id 19102, offset 0, flags [none], proto TCP (6), length 1055)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [P.], cksum 0xdd21 (correct), seq 625:1640, ack 1, win 5840, length 1015
E...J..............I...].=...3M.P....!..{"name":"2","homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"100.0"},{"name":"17","homematic_name":"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"30.8"},{"name":"18","homematic_name":"w_regensensor_wert","desc":"regenmelderwert","type":"number","unit":"","value":"7"},{"name":"7","homematic_name":"w_regenmelder","desc":"regenstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","type":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number","unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm","value":"0.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","value":"0.0"},{"name":"27","homematic_name":"","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"0.5"},
11:49:01.899319 IP (tos 0x0, ttl 64, id 37133, offset 0, flags [DF], proto TCP (6), length 40)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [.], cksum 0xe5d0 (incorrect -> 0x3b32), seq 1, ack 1640, win 34510, length 0
E..(..@.@......I.....]...3M..=..P.......
11:49:01.909351 IP (tos 0x0, ttl 127, id 19103, offset 0, flags [none], proto TCP (6), length 844)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [P.], cksum 0xa26d (correct), seq 1640:2444, ack 1, win 5840, length 804
E..LJ......W.......I...].=...3M.P....m..{"name":"3","homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1018.62"},{"name":"11","homematic_name":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"fallend"},{"name":"4","homematic_name":"w_wind_mittel","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.6"},{"name":"5","homematic_name":"w_wind_spitze","desc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.0"},{"name":"24","homematic_name":"w_windstaerke","desc":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"0"},{"name":"23","homematic_name":"w_windrichtung","desc":"windrichtung","type":"string","unit":"","value":"N"},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"number","unit":"grad","value":"0"},
11:49:01.909453 IP (tos 0x0, ttl 64, id 37134, offset 0, flags [DF], proto TCP (6), length 40)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [.], cksum 0xe5d0 (incorrect -> 0x2c29), seq 1, ack 2444, win 37555, length 0
E..(..@.@......I.....]...3M..=..P.......
11:49:01.916019 IP (tos 0x0, ttl 127, id 19104, offset 0, flags [none], proto TCP (6), length 1080)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [P.], cksum 0x2785 (correct), seq 2444:3484, ack 1, win 5840, length 1040
E..8J......j.......I...].=...3M.P...'...{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":"3651.0"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","value":"20.7"},{"name":"15","homematic_name":"","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"51.1"},{"name":"16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"true"},{"name":"26","homematic_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"5.4"},{"name":"12","homematic_name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"57.1"},{"name":"13","homematic_name":"w_azimut","desc":"sonne_azimut","type":"number","unit":"grad","value":"138.6"},{"name":"30","homematic_name":"w_minuten_vor_sa","desc":"minuten_vor_sa","type":"number","unit":"min","value":"-372"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minuten_vor_su","type":"number","unit":"min","value":"553"}],
11:49:01.916130 IP (tos 0x0, ttl 64, id 37135, offset 0, flags [DF], proto TCP (6), length 40)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [.], cksum 0xe5d0 (incorrect -> 0x1c5c), seq 1, ack 3484, win 40560, length 0
E..(..@.@..
...I.....]...3M..=.#P..p....
11:49:01.920027 IP (tos 0x0, ttl 127, id 19105, offset 0, flags [none], proto TCP (6), length 260)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [P.], cksum 0xd7ae (correct), seq 3484:3704, ack 1, win 5840, length 220
E...J.....
........I...].=.#.3M.P......."Systeminfo":{"MAC-Adresse":"60:1:94:49:b3:23","Homematic_CCU_ip":"192.168.178.73","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-86","sec_seit_reset":"48593","zeitpunkt":"2019.07.20/11:49:01","firmware":"weatherman_107"}}.
11:49:01.920081 IP (tos 0x0, ttl 64, id 37136, offset 0, flags [DF], proto TCP (6), length 40)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [.], cksum 0xe5d0 (incorrect -> 0x1360), seq 1, ack 3704, win 42640, length 0
E..(..@.@.. ...I.....]...3M..=..P.......
11:49:01.935287 IP (tos 0x0, ttl 128, id 19106, offset 0, flags [none], proto TCP (6), length 40)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [F.], cksum 0xa31f (correct), seq 3704, ack 1, win 5840, length 0
E..(J.....
x.......I...].=...3M.P.............
11:49:01.942318 IP (tos 0x0, ttl 64, id 37137, offset 0, flags [DF], proto TCP (6), length 40)
fhem2.fritz.box.1885 > ESP-49B323.fritz.box.6881: Flags [F.], cksum 0xe5d0 (incorrect -> 0x135e), seq 1, ack 3705, win 42640, length 0
E..(..@.@......I.....]...3M..=..P.......
11:49:01.947936 IP (tos 0x0, ttl 127, id 19107, offset 0, flags [none], proto TCP (6), length 40)
ESP-49B323.fritz.box.6881 > fhem2.fritz.box.1885: Flags [.], cksum 0xa31f (correct), seq 3705, ack 2, win 5839, length 0
E..(J......w.......I...].=...3M.P.............
Windoes output ohne hickups:
Client connected
{"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"
192.168.178.27"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"
30.6"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"30.6"}
,{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"30.2"},{"name":
"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},{"name":"2"
,"homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"97.9"},{"name":"17","homematic_name"
:"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"30.6"},{"name":"18","homematic_name":"w_regensenso
r_wert","desc":"regenmelderwert","type":"number","unit":"","value":"7"},{"name":"7","homematic_name":"w_regenmelder","desc":"re
genstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","typ
e":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number",
"unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm"
,"value":"0.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","va
lue":"0.0"},{"name":"27","homematic_name":"","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"0.5"},{"name":"3","
homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1018.58"},{"name":"11","homematic_name
":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"fallend"},{"name":"4","homematic_name":"w_wind_mitte
l","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"1.0"},{"name":"5","homematic_name":"w_wind_spitze","d
esc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"1.6"},{"name":"24","homematic_name":"w_windstaerke","desc
":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"2"},{"name":"23","homematic_name":"w_windrichtung","desc":"wi
ndrichtung","type":"string","unit":"","value":"SW"},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"numbe
r","unit":"grad","value":"225"},{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":
"4253.0"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","valu
e":"18.0"},{"name":"15","homematic_name":"","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"48.6"},{"name":"
16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"true"},{"name":"26","homemati
c_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"5.6"},{"name":"12","homematic_
name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"58.4"},{"name":"13","homematic_name":"w_azi
mut","desc":"sonne_azimut","type":"number","unit":"grad","value":"143.3"},{"name":"30","homematic_name":"w_minuten_vor_sa","des
c":"minuten_vor_sa","type":"number","unit":"min","value":"-384"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minut
en_vor_su","type":"number","unit":"min","value":"541"}],"Systeminfo":{"MAC-Adresse":"60:1:94:49:b3:23","Homematic_CCU_ip":"192.
168.178.50","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-84","sec_seit_reset":"49317","zeitpunkt":"2019.07.20/12:01:04","firmwar
e":"weatherman_107"}}
Client disconnected
Hallo Timmo,
ich war auch nicht untätig die letzten Stunden und habe im Modul einige Umbauten vorgenommen. Das betrifft eigentlich weniger dein Problem an sich, als mehr die Übersichtlichkeit und Behandlung der Logausgaben. Und auch ein paar kleinbere Bugs habe ich dadurch gefunden und beseitigt. Betrifft eine eigene DbLog-Split Funktion, die disabled Funktion und anderes was zwar nicht die Funktion mindert, aber störend sein kann.
ZitatNoch ein Gedanke... kann es an der Implementierung UDP vs TCP liegen? TCP macht ja eine Error-Recovery, und die scheint hier nicht beachtet zu werden, sondern es werden einfach die Teilstücke als Message weitergereicht?
Das ist eine gute Frage. Ich benutze im Modul die TCPServerUtils von Rudolf König um entsprechende Dienste zu nutzen. Aber wenn ich meinen code anschaue, werden fehlerhafte Pakete verworfen. Wenn Perl einen Fehler vom Interface signalisiert bekommt, werden die Daten nicht zurück gegeben und verarbeitet.
Vielleicht muss da nochmal in die TCPServerUtils reinschauen, ist schon eine Weile her. ;)
Aber ich habe im Code noch eine Logausgabe mit verbose 2 eingebaut, falls das Modul einen Interfacefehler bekommt. Der Fehler wird im Log mit ausgeschrieben.
Habe ich wieder ins contrib gestellt zum Test...
PS: Hättest du denn mit Wiffi auch die Möglichkeit UDP zu benutzen zum Vergleich ?
LG,
Heiko
Hallo Heiko,
mit der neuen Version kommen noch "New Syslog TCP receive" in der Session rein. Unten ist einmal die Message ganz durchgegangen. Danach gabs wieder Ärger, und Teile wurden nachgereicht. Die "Summe" der Teile der Session scheint die gesamte Message zu ergeben.
Auf den Sourcecode des Wiffi habe ich keinen Zugriff.... Eugen Stall ist online, aber ist da zurückhaltend.
Nachtrag - habe gerade netcat gefunden - und das liest die Messages jedes mal vollständig (Port musste ich ändern, da 1885 durch FHEM belegt war). Das sieht für mich so aus, dass die Routine, die den Port ausliest, die Fehlerkorrektur des Betriebssystems nicht mit berücksichtigt (so wie es NetCat scheinbar nutzt). Netcat liest TCP. BTW - sowohl in Netcat als auch bei Windows ist die Message ohne Sonderzeichen am Ende.
VG Timmo
https://www.commandlinux.com/man-page/man1/nc.1.html (https://www.commandlinux.com/man-page/man1/nc.1.html)
}pi@fhemserver:~ $ sudo nc -lv 1886
Listening on [0.0.0.0] (family 0, port 1886)
Connection from ESP-D95E39.fritz.box 7007 received!
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"51.55"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-48","sec_seit_reset":"12279","zeitpunkt":"2019-07-20 15:53:26","firmware":"wiffi_pump2_91"}}
2019.07.20 15:41:15.805 4: Connection accepted from SyslogServer_192.168.178.65_8457
2019.07.20 15:41:15.807 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:17.369 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 15:41:17.370 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:17.370 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_8457
2019.07.20 15:41:17.371 5: Log2Syslog SyslogServer - Buffer 830 chars length:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"51.55"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-48","sec_seit_reset":"11548","zeitpunkt":"2019-07-20 15:41:15","firmware":"wiffi_pump2_91"}}
2019.07.20 15:41:17.371 4: Log2Syslog SyslogServer - ######### Parse Message #########
2019.07.20 15:41:17.372 5: Log2Syslog SyslogServer - parse profile: raw
2019.07.20 15:41:17.372 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.20 15:41:17.373 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"51.55"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-48","sec_seit_reset":"11548","zeitpunkt":"2019-07-20 15:41:15","firmware":"wiffi_pump2_91"}}
2019.07.20 15:41:17.389 1: [Freezemon] myFreezemon: possible freeze starting at 15:41:16, delay is 1.389 possibly caused by: tmr-HMUARTLGW_CheckCredits(myHmUARTLGW2)
2019.07.20 15:41:17.404 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:17.405 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 15:41:17.405 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:17.405 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_8457
2019.07.20 15:41:17.407 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_8457: EOF
2019.07.20 15:41:46.284 4: Connection accepted from SyslogServer_192.168.178.65_20663
2019.07.20 15:41:46.285 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:46.286 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 15:41:46.286 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:46.287 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20663
2019.07.20 15:41:46.287 5: Log2Syslog SyslogServer - Buffer 609 chars length:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"51.74"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.20 15:41:46.288 4: Log2Syslog SyslogServer - ######### Parse Message #########
2019.07.20 15:41:46.288 5: Log2Syslog SyslogServer - parse profile: raw
2019.07.20 15:41:46.288 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.20 15:41:46.289 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"51.74"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.20 15:41:46.305 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:46.305 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 15:41:46.306 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:46.306 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20663
2019.07.20 15:41:46.306 5: Log2Syslog SyslogServer - Buffer 220 chars length:
"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-49","sec_seit_reset":"11578","zeitpunkt":"2019-07-20 15:41:46","firmware":"wiffi_pump2_91"}}
2019.07.20 15:41:46.307 4: Log2Syslog SyslogServer - ######### Parse Message #########
2019.07.20 15:41:46.307 5: Log2Syslog SyslogServer - parse profile: raw
2019.07.20 15:41:46.308 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.20 15:41:46.308 4: Log2Syslog SyslogServer - raw message -> "Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-49","sec_seit_reset":"11578","zeitpunkt":"2019-07-20 15:41:46","firmware":"wiffi_pump2_91"}}
2019.07.20 15:41:46.322 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:46.322 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 15:41:46.323 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 15:41:46.323 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_20663
2019.07.20 15:41:46.325 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_20663: EOF
Hi Timmo,
ja sieht tatsächlich so aus. Ich habe auch eine Idee im Kopf.
Zieh dir das Modul bitte wieder und setze dann das Attribut "waitForEOF".
Mal schauen ob wir auf dem richtigen Weg sind. Wenn ja, kann ich den Weg weiter ausbauen.
LG
Hi Heiko,
ich glaube der Weg ist richtig, klappt aber noch nicht mit dem Auswerten...
Test nachher oder morgen früh etwas mehr ... muss zum Abendessen... ;-)
VG timmo
2019.07.20 20:05:26.437 4: Connection accepted from SyslogServer_192.168.178.65_21736
2019.07.20 20:05:26.438 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:26.439 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:26.440 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:26.440 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:26.441 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_21736
2019.07.20 20:05:26.441 5: Log2Syslog SyslogServer - Buffer 829 chars length:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"44.98"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-44","sec_seit_reset":"13818","zeitpunkt":"2019-07-20 20:05:26","firmware":"wiffi_pump2_91"}}
2019.07.20 20:05:26.454 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:26.454 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:26.455 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:26.455 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:26.455 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_21736
2019.07.20 20:05:26.456 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_21736: EOF
2019.07.20 20:05:49.267 4: Connection accepted from SyslogServer_192.168.178.65_5829
2019.07.20 20:05:49.268 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:49.269 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:49.269 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:49.269 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:49.269 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_5829
2019.07.20 20:05:49.270 5: Log2Syslog SyslogServer - Buffer 609 chars length:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"45.37"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"true"}],
2019.07.20 20:05:49.272 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:49.272 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:49.273 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:49.273 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:49.273 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_5829
2019.07.20 20:05:49.273 5: Log2Syslog SyslogServer - Buffer 220 chars length:
"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-45","sec_seit_reset":"13841","zeitpunkt":"2019-07-20 20:05:48","firmware":"wiffi_pump2_91"}}
2019.07.20 20:05:49.286 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:49.286 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:49.287 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:49.287 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:49.287 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_5829
2019.07.20 20:05:49.287 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_5829: EOF
2019.07.20 20:05:59.514 4: Connection accepted from SyslogServer_192.168.178.65_30215
2019.07.20 20:05:59.515 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:59.516 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:59.516 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:59.516 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:59.517 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_30215
2019.07.20 20:05:59.517 5: Log2Syslog SyslogServer - Buffer 610 chars length:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"45.93"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],
2019.07.20 20:05:59.518 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:59.519 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:59.519 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:59.520 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:59.520 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_30215
2019.07.20 20:05:59.520 5: Log2Syslog SyslogServer - Buffer 220 chars length:
"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-45","sec_seit_reset":"13851","zeitpunkt":"2019-07-20 20:05:58","firmware":"wiffi_pump2_91"}}
2019.07.20 20:05:59.531 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:59.532 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 20:05:59.532 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 20:05:59.532 4: Log2Syslog SyslogServer - wait for EOF: 1
2019.07.20 20:05:59.533 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_30215
2019.07.20 20:05:59.533 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_30215: EOF
Hi Heiko,
Nur ein Gedanke - kannst Du das Problem eigentlich bei Dir reproduzieren? Oder soll ich Dir eine Leitung an den Wiffi legen...bzw anders rum? Müsste man wahrscheinlich über ein VPN machen. Let me know.
Viele Grüße - Timmo
Ist ja schonmal ein Ansatz.
Direkt nachstellen kann ich es nicht. Bei mir klappts einwandfrei.
Aber ich habe ein bisschen Phantasie ;)
Ich versuche noch etwas und melde mich wieder ...
Bitte nochmal laden und testen.
Grüße,
Heiko
Hallo Heiko,
ich glaube, das ist es! Grandioos...! Der Buffer wird sauber zusammengesetzt, die Messages sind an den Nahtstellen richtig (also nicht zuviele / zuwenige Character)
Ein letzter Punkt:
Am Ende ist immer das kleine Quadrat sichtbar - ist das das EOF-Byte? Ich bin mir nicht sicher, aber das sollte dann nicht mit in die Nutzlast, (da es ja zum Protokoll gehört)?
Und noch einer:
Wenn ich beide Wiffis auf dem gleichen Port habe, wird der zweite, der sendet, wahrscheinlich mal einen Port in Benutzung sehen. Wenn der gut programmiert ist, probiert er es halt nochmal, und hat dann mehr Glück. Oder macht es Sinn, zwei Instanzen von Log2Syslog mit zwei Ports laufen zu haben (nicht sehr schön)?
Viele Grüße und schönen Abend!
Timmo
(etwas längerer Logauszug, man sieht Messages von beiden wiffis)
2019.07.20 23:25:36.940 4: Connection accepted from SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.942 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.943 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:36.943 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.943 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:36.944 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.944 5: Log2Syslog SyslogServer - chars 624 length added to buffer:
{"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"192.168.178.27"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},
2019.07.20 23:25:36.950 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.951 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:36.951 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.951 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:36.952 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.952 5: Log2Syslog SyslogServer - chars 1015 length added to buffer:
{"name":"2","homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"100.0"},{"name":"17","homematic_name":"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"17.7"},{"name":"18","homematic_name":"w_regensensor_wert","desc":"regenmelderwert","type":"number","unit":"","value":"7"},{"name":"7","homematic_name":"w_regenmelder","desc":"regenstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","type":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number","unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm","value":"0.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","value":"0.0"},{"name":"27","homematic_name":"","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"0.5"},
2019.07.20 23:25:36.955 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.955 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:36.955 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.956 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:36.956 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.956 5: Log2Syslog SyslogServer - chars 808 length added to buffer:
{"name":"3","homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1020.50"},{"name":"11","homematic_name":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"steigend"},{"name":"4","homematic_name":"w_wind_mittel","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.2"},{"name":"5","homematic_name":"w_wind_spitze","desc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"1.2"},{"name":"24","homematic_name":"w_windstaerke","desc":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"1"},{"name":"23","homematic_name":"w_windrichtung","desc":"windrichtung","type":"string","unit":"","value":"SO"},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"number","unit":"grad","value":"135"},
2019.07.20 23:25:36.961 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.961 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:36.961 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.962 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:36.962 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.962 5: Log2Syslog SyslogServer - chars 1041 length added to buffer:
{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":"0.0"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","value":"1.3"},{"name":"15","homematic_name":"","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"21.7"},{"name":"16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"false"},{"name":"26","homematic_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"13.6"},{"name":"12","homematic_name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"-16.6"},{"name":"13","homematic_name":"w_azimut","desc":"sonne_azimut","type":"number","unit":"grad","value":"332.1"},{"name":"30","homematic_name":"w_minuten_vor_sa","desc":"minuten_vor_sa","type":"number","unit":"min","value":"-1068"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minuten_vor_su","type":"number","unit":"min","value":"-143"}],
2019.07.20 23:25:36.966 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.966 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:36.966 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.967 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:36.967 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.967 5: Log2Syslog SyslogServer - chars 219 length added to buffer:
"Systeminfo":{"MAC-Adresse":"60:1:94:49:b3:23","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-84","sec_seit_reset":"90387","zeitpunkt":"2019.07.20/23:25:36","firmware":"weatherman_107"}}
2019.07.20 23:25:36.980 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.980 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:36.981 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:36.981 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:36.981 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.27_18310
2019.07.20 23:25:36.982 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.27_18310: EOF
2019.07.20 23:25:36.983 5: Log2Syslog SyslogServer - Buffer 0 chars length:
{"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"192.168.178.27"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},{"name":"2","homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"100.0"},{"name":"17","homematic_name":"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"17.7"},{"name":"18","homematic_name":"w_regensensor_wert","desc":"regenmelderwert","type":"number","unit":"","value":"7"},{"name":"7","homematic_name":"w_regenmelder","desc":"regenstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","type":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number","unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm","value":"0.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","value":"0.0"},{"name":"27","homematic_name":"","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"0.5"},{"name":"3","homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1020.50"},{"name":"11","homematic_name":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"steigend"},{"name":"4","homematic_name":"w_wind_mittel","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.2"},{"name":"5","homematic_name":"w_wind_spitze","desc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"1.2"},{"name":"24","homematic_name":"w_windstaerke","desc":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"1"},{"name":"23","homematic_name":"w_windrichtung","desc":"windrichtung","type":"string","unit":"","value":"SO"},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"number","unit":"grad","value":"135"},{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":"0.0"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","value":"1.3"},{"name":"15","homematic_name":"","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"21.7"},{"name":"16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"false"},{"name":"26","homematic_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"13.6"},{"name":"12","homematic_name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"-16.6"},{"name":"13","homematic_name":"w_azimut","desc":"sonne_azimut","type":"number","unit":"grad","value":"332.1"},{"name":"30","homematic_name":"w_minuten_vor_sa","desc":"minuten_vor_sa","type":"number","unit":"min","value":"-1068"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minuten_vor_su","type":"number","unit":"min","value":"-143"}],"Systeminfo":{"MAC-Adresse":"60:1:94:49:b3:23","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-84","sec_seit_reset":"90387","zeitpunkt":"2019.07.20/23:25:36","firmware":"weatherman_107"}}
2019.07.20 23:25:36.984 4: Log2Syslog SyslogServer - ######### Parse Message #########
2019.07.20 23:25:36.984 5: Log2Syslog SyslogServer - parse profile: raw
2019.07.20 23:25:36.984 5: Log2Syslog SyslogServer - message peer: ESP-49B323.fritz.box,192.168.178.27
2019.07.20 23:25:36.985 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"192.168.178.27"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"20.4"},{"name":"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},{"name":"2","homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"100.0"},{"name":"17","homematic_name":"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"17.7"},{"name":"18","homematic_name":"w_regensensor_wert","desc":"regenmelderwert","type":"number","unit":"","value":"7"},{"name":"7","homematic_name":"w_regenmelder","desc":"regenstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","type":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number","unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm","value":"0.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","value":"0.0"},{"name":"27","homematic_name":"","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"0.5"},{"name":"3","homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1020.50"},{"name":"11","homematic_name":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"steigend"},{"name":"4","homematic_name":"w_wind_mittel","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.2"},{"name":"5","homematic_name":"w_wind_spitze","desc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"1.2"},{"name":"24","homematic_name":"w_windstaerke","desc":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"1"},{"name":"23","homematic_name":"w_windrichtung","desc":"windrichtung","type":"string","unit":"","value":"SO"},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"number","unit":"grad","value":"135"},{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":"0.0"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","value":"1.3"},{"name":"15","homematic_name":"","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"21.7"},{"name":"16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"false"},{"name":"26","homematic_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"13.6"},{"name":"12","homematic_name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"-16.6"},{"name":"13","homematic_name":"w_azimut","desc":"sonne_azimut","type":"number","unit":"grad","value":"332.1"},{"name":"30","homematic_name":"w_minuten_vor_sa","desc":"minuten_vor_sa","type":"number","unit":"min","value":"-1068"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minuten_vor_su","type":"number","unit":"min","value":"-143"}],"Systeminfo":{"MAC-Adresse":"60:1:94:49:b3:23","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-84","sec_seit_reset":"90387","zeitpunkt":"2019.07.20/23:25:36","firmware":"weatherman_107"}}
2019.07.20 23:25:49.481 4: Connection accepted from SyslogServer_192.168.178.65_17029
2019.07.20 23:25:49.482 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:49.483 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:49.483 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:49.483 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:49.484 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_17029
2019.07.20 23:25:49.484 5: Log2Syslog SyslogServer - chars 610 length added to buffer:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"45.93"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],
2019.07.20 23:25:49.485 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:49.486 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:49.486 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:49.487 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:49.487 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_17029
2019.07.20 23:25:49.487 5: Log2Syslog SyslogServer - chars 220 length added to buffer:
"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-43","sec_seit_reset":"25841","zeitpunkt":"2019-07-20 23:25:49","firmware":"wiffi_pump2_91"}}
2019.07.20 23:25:49.498 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:49.499 4: Log2Syslog SyslogServer - ######### new Syslog TCP Receive #########
2019.07.20 23:25:49.499 4: Log2Syslog SyslogServer - #######################################################
2019.07.20 23:25:49.499 4: Log2Syslog SyslogServer - wait for EOF: 1, SSL:
2019.07.20 23:25:49.499 4: Log2Syslog SyslogServer - childname: SyslogServer_192.168.178.65_17029
2019.07.20 23:25:49.500 4: Log2Syslog SyslogServer - Connection closed for SyslogServer_192.168.178.65_17029: EOF
2019.07.20 23:25:49.501 5: Log2Syslog SyslogServer - Buffer 0 chars length:
{"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"45.93"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-43","sec_seit_reset":"25841","zeitpunkt":"2019-07-20 23:25:49","firmware":"wiffi_pump2_91"}}
2019.07.20 23:25:49.502 4: Log2Syslog SyslogServer - ######### Parse Message #########
2019.07.20 23:25:49.502 5: Log2Syslog SyslogServer - parse profile: raw
2019.07.20 23:25:49.502 5: Log2Syslog SyslogServer - message peer: ESP-D95E39.fritz.box,192.168.178.65
2019.07.20 23:25:49.503 4: Log2Syslog SyslogServer - raw message -> {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"45.93"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-43","sec_seit_reset":"25841","zeitpunkt":"2019-07-20 23:25:49","firmware":"wiffi_pump2_91"}}
(für die Doku der List)
Internals:
CONNECTS 45
FD 15
FUUID 5d2b3d43-f33f-b872-6c66-157ec1caf94e23c0
FVERSION 93_Log2Syslog.pm:v5.8.0-s19029/2019-03-25
INTERFACE global
MODEL Collector
MYFQDN fhemserver
MYHOST fhemserver
NAME SyslogServer
NR 278
NTFY_ORDER 50-SyslogServer
PORT 1885
PROFILE raw
PROTOCOL tcp
SEQNO 46
STATE active
TYPE Log2Syslog
HELPER:
LTIME 1563659395.87775
OLDSEQNO 46
OLDSTATE active
PACKAGE main
SSLALGO n.a.
SSLVER n.a.
TCPPADDR 192.168.178.27
VERSION 5.8.0
HIPCACHE:
192.168.178.27 ESP-49B323.fritz.box
192.168.178.65 ESP-D95E39.fritz.box
OLDREADINGS:
READINGS:
2019-07-20 23:46:34 MSG_ESP-49B323.fritz.box {"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"192.168.178.27"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"19.9"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"19.9"},{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"19.9"},{"name":"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},{"name":"2","homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"100.0"},{"name":"17","homematic_name":"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"17.2"},{"name":"18","homematic_name":"w_regensensor_wert","desc":"regenmelderwert","type":"number","unit":"","value":"7"},{"name":"7","homematic_name":"w_regenmelder","desc":"regenstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","type":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number","unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm","value":"0.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","value":"0.0"},{"name":"27","homematic_name":"","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"0.5"},{"name":"3","homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1020.69"},{"name":"11","homematic_name":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"steigend"},{"name":"4","homematic_name":"w_wind_mittel","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.4"},{"name":"5","homematic_name":"w_wind_spitze","desc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.8"},{"name":"24","homematic_name":"w_windstaerke","desc":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"1"},{"name":"23","homematic_name":"w_windrichtung","desc":"windrichtung","type":"string","unit":"","value":"S"},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"number","unit":"grad","value":"180"},{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":"0.0"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","value":"1.5"},{"name":"15","homematic_name":"","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"21.2"},{"name":"16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"false"},{"name":"26","homematic_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"13.6"},{"name":"12","homematic_name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"-18.1"},{"name":"13","homematic_name":"w_azimut","desc":"sonne_azimut","type":"number","unit":"grad","value":"337.0"},{"name":"30","homematic_name":"w_minuten_vor_sa","desc":"minuten_vor_sa","type":"number","unit":"min","value":"-1089"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minuten_vor_su","type":"number","unit":"min","value":"-164"}],"Systeminfo":{"MAC-Adresse":"60:1:94:49:b3:23","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-83","sec_seit_reset":"91645","zeitpunkt":"2019.07.20/23:46:33","firmware":"weatherman_107"}}
2019-07-20 23:45:51 MSG_ESP-D95E39.fritz.box {"modultyp":"wiffi-pump","vars":[{"name":"0","homematic_name":"wiffi_pump_ip","desc":"ip des wiffi-pump","type":"string","unit":"","value":"192.168.178.65"},{"name":"4","homematic_name":"wiffi_ntc","desc":"Temperatur_NTC","type":"number","unit":"%","value":"46.99"},{"name":"2","homematic_name":"wiffi_ww_temp","desc":"Temperatur_A","type":"number","unit":"gradC","value":"0.0"},{"name":"3","homematic_name":"wiffi_vorlauftemp","desc":"Temperatur_B","type":"number","unit":"gradC","value":"0.0"},{"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":"false"}],"Systeminfo":{"MAC-Adresse":"5c:cf:7f:d9:5e:39","Homematic_CCU_ip":"192.168.178.2","WLAN_ssid":"sturmnetz","WLAN_Signal_dBm":"-43","sec_seit_reset":"27043","zeitpunkt":"2019-07-20 23:45:51","firmware":"wiffi_pump2_91"}}
2019-07-20 23:49:55 Transfered_logs_per_minute 0
2019-07-20 23:49:55 p_status "false"
2019-07-20 23:46:34 state active
Attributes:
makeEvent reading
parseProfile raw
port 1885
protocol TCP
room 9.0_System
userReadings p_status {my $w = ReadingsVal("SyslogServer","MSG_ESP-D95E39.fritz.box",0);; $w =~ s/.*"name":"1","homematic_name":"wiffi_pump","desc":"Zirkulationspumpe","type":"boolean","unit":"","value":("true"|"false").*/$1/ ;; $w }
verbose 5
waitForEOF 1
Na das ist schon ein guter Erfolg :)
Das Quadrat am ende (ich sehe es grad nicht) ist bestimmt ein Steuerzeichen. Du kannst versuchen es mit dem attr useParsefilter zu eliminieren.
Mit zwei wiffis musst du mal testen. Aber ich vermute es ist sicherer wenn du zwei Syslog Devices dafür benutzt. Musst ja auch daran denken dass das Modul eigentlich für das Syslog Protokoll gebaut wurde. :)
Morgen schauen wir weiter.
GN erstmal....
LG,
Heiko
Guten morgen...
das Sonderzeichen am Ende geht mit useParsefilter raus (dann klappt auch expandJSON). Ich kam nur deshalb drauf, weill das konsistent am Ende steht, und hab vermutet dass dass ASCCII 4 ist für EOF/EOT. Dann sollte es raus, wenn jemand Sonderzeichen übertragen will, sollten die ja kommen - und dennoch das EOF nicht dabei sein. Mit den port-Tools, die den Stream richtig zusammensetzen, kommt das auch nicht.
Fürs Log2syslog habe ich auch noch eine Verwending - mal die diversen ESPS einfangen und ordentlichberichten lassen ..
VG timmo
Moin Timmo,
ja, ich hatte ja auch schon überlegt den Filter für Steuerzeichen generell anzuwenden dann würde der Nutzer davon nichts mitbekommen, aber im Sinne der Flexibilität hatte ich mich für das Attribut entschieden.
Im Normalfall braucht man es auch nicht.
Ich freue mich jedenfalls, dass wir eine Lösung für dich gefunden haben. Jetzt muss ich nur noch schauen, dass ich etwas zur Vermeidung einer Endlosschleife einbaue wenn der Nutzer "waitForEOF" einsetzt und der Sender überhaupt kein EOF verwendet. Wäre schön wenn du dich wieder an einem Test beteiligst wenn ich etwas fertig habe.
Die jetzige Version will ich noch durchtesten um sicher zu sein, dass die bisherigen Funktionen durch die Erweiterung nicht an irgendeiner Stelle tangiert wurden und dann einchecken.
Vielleicht wäre es auch eine Anregung an den Wiffi Entwickler, die Informationen per Syslog zu versenden. Die Payload kann kann durchaus JSON sein. Jedenfalls wäre es ein Protokoll was in der IT weit verbreitet ist und einen definierten Aufbau hat.
Der Aufbau ist per RFC definiert. Einen Verweis darauf findet man im Device mit "get <name > versionNotes 1".
schönen Sonntag und LG,
Heiko
Hallo Heiko,
testen mache ich gerne. Ich bin noch bis Freitag im Lande, dann eine Woche Urlaub... dannwieder eine Woche da, dann zwei Wochen nicht da... insofern wirds ein bisserl "patchy".
Mit Syslog sage ich ihm.
VG Timmo
Hallo Timmo,
ich habe die Version 5.8.0 jetzt finalisiert und noch einen Max-Wert des Empfangspuffers eingeführt. Dieser verhindert dass es zu einer Endlosschleife kommt wenn der Nutzer das Attribut "waitForEOF" einsetzt und der Sender dieses Signal nie sendet.
Im Log gibt es dann die die Warnung "Buffer overrun" und das Parsing wird erzwungen.
Ansonsten habe ich alles mögliche getestet und keine negativen Nebeneffekte festgestellt.
Zieh dir bitte die Version nochmal aus dem contrib und wenn dir auch nichts mehr auffällt würde ich die Version morgen Abend einchecken wollen.
Alle anderen interessierten User können die Version natürlich auch gerne mal ausprobieren :)
Grüße,
Heiko
Ich habe noch eine Änderung vorgenommen.
Das Attribut waitForEOF hat sich in useEOF geändert !!
Hintergrund ist, dass es jetzt sowhl für den Typ Sender als auch für den Typ Collector gilt.
useEOF
Model Sender (Protokoll TCP):
Nach jedem Sendevorgang wird eine TCP-Verbindung mit EOF beendet.
Model Collector:
Es wird mit dem Parsing gewartet, bis der Sender ein EOF Signal gesendet hat. Wird TLS verwendet, hat dieses Attribut keine Auswirkung.
Hinweis:
Wenn der Sender kein EOF verwendet, wird nach Überschreiten eines Puffer-Schwellenwertes das Parsing der Daten erzwungen und die Warnung "Buffer overrun" im FHEM Log ausgegeben.
Ist im contrib hochgeladen.
Hi Heiko,
läuft sofort problemlos. Morgen richte ich noch den zweiten Wiffi ein.
Die Sender-Util kann ich nicht testen, habe da keinen Anwendungsfall.
Habe mein Szenario unter https://forum.fhem.de/index.php/topic,86097.msg960650.html#msg960650 (https://forum.fhem.de/index.php/topic,86097.msg960650.html#msg960650) im Forum veröffentlicht, da die Frage immer mal wieder kam.
Vielen Dank nochmal!
VG Timmo
Hallo Timmo,
danke für die Rückmeldung, prima :)
Aber wer ist Jens ? :D
Ich checke das Modul jetzt ein, ist dann morgen früh im Regelupdate.
LG,
Heiko
Hallo Heiko
Mei, sorry! Hatte etwas Stress, da habe ich intensiv den ganzen Tag mit einen Jens gearbeitet...,
Viele Grüße - Timmo
Hier mal aus aktuellem Anlass ein beispielhafter Use Case für den Einsatz des Syslog-Servers in FHEM.
Ich betreibe auf meiner Synology einen eigenen Mailplus-Server. Auf der Syno gibt es ja, wer es kennt, das Protokoll-Center. Dort kann man einstellen, dass Meldungen der Syno an einen Syslog-Server weitergeleitet werden können. Das Protokoll-Center kann auch empfangen, aber ist für das Beispiel nicht relevant.
Heute hat der Syslog-Server in FHEM Meldungen dieser Art von der Synology erhalten:
Connection postfix: User [alfa] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-00-24__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [alma] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-07-05__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [alnoor] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-13-48__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [alumni] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-20-28__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [amdintest] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-27-13__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [andreia] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-34-06__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [ap01] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-40-57__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [augusta] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-47-35__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [auxiliar] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_08-54-16__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [book] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_09-00-57__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [box] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_09-07-38__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [brenda] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_09-14-17__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [cash] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_09-20-58__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [catherine] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
2019-07-24_09-27-42__1__SyslogServer_Automatic_TCP__SDS1 FAC: user || SEV: Warning || CONT: Connection postfix: User [chestnut] from [185.234.219.70] failed to log in via [MailPlus Server] due to authorization failure.
(Das ist ein Auszug aus einem DbRep-Report auf eine DbLog-Datenbank).
Man sieht deutlich, wie automatisiert alle 7 Minuten ein Login-Versuch am Mailserver stattfand. Hier wurde also ein Angriff ausgeübt.
Um solche Situationen zu erkennen, habe ich ein Notify auf die Ausgaben des Log2Syslog-Devices definiert, über das mir eine Mail mit dem Sachverhalt zugesendet wird. Dann habe ich die Möglichkeit zu reagieren und die IP-Adresse im DSM zu sperren. Es gibt zwar auch eine automatische Sperre, aber die war auf 5 Fehlversuche innerhalb 1 Minute eingestellt. Die Ganoven sind auch nicht ungeübt und ließen nur alle 7 Minuten einen Versuch starten.
Für die Interessenten hier die raw-Definitionen der Komponenten.
Das Log2Syslog Device:
defmod SyslogServer_Automatic_TCP Log2Syslog
attr SyslogServer_Automatic_TCP TLS 0
attr SyslogServer_Automatic_TCP alias Collector - Automatic - TDP/4614
attr SyslogServer_Automatic_TCP disable 0
attr SyslogServer_Automatic_TCP icon edit_paste
attr SyslogServer_Automatic_TCP makeEvent intern
attr SyslogServer_Automatic_TCP parseProfile Automatic
attr SyslogServer_Automatic_TCP port 4614
attr SyslogServer_Automatic_TCP protocol TCP
attr SyslogServer_Automatic_TCP rateCalcRerun 80
attr SyslogServer_Automatic_TCP room Dienste->Logging
attr SyslogServer_Automatic_TCP stateFormat state : Transfered_logs_per_minute
attr SyslogServer_Automatic_TCP verbose 3
Das notify:
defmod N.SyslogServer.Detect.MailAttack notify SyslogServer.*:.*Connection.postfix:.User.*failed.to.log.*MailPlus.Server.* \
{\
$EVENT =~ /.*User.\[(.*)\].from.\[(.*)\].failed.to.log.*/;;\
my $uname = $1;;\
my $addr = $2;;\
DebianMailnbl ('<Mailempfänger>','Mailserver Angriff',"Details des Angriffs:\n\n Source-Adresse: $addr \n User: $uname \n\nFHEM-Server") \
}\
attr N.SyslogServer.Detect.MailAttack room Dienste->Logging
attr N.SyslogServer.Detect.MailAttack verbose 2
Im Synology Protokoll-Center muss die Weitergabe der Messages natürlich auf die IP des FHEM-Servers und den im Log2Syslog-Device angegebenen Port zeigen.
Grüße,
Heiko
Syslog Meldungen von UniFy Access Points empfangen und parsen
Die UniFi AP-AC-(Lite) bieten die Möglichkeit, Meldungen an einen Syslog-Server zu senden. Dazu aktiviert man im Unify-Controller in den Einstellungen das Remote Logging (Remote Syslog-Server und ggf. Debug-Logging aktivieren) und die Adresse des FHEM-Servers angeben.
Ein als Collector definiertes Log2Syslog Device kann dieses Meldungen entgegennehmen und entsprechende Events daraus erstellen. Für das Parsing der Unify-Meldungen ist es günstig ein eigenes Parsing zu erstellen. Im Attribut parseFn wird die entsprechende Parsingfunktion und aktiviert sie mit dem Attribut parseProfile = ParseFn.
Eine solche Parsingfunktion kann zum Beispiel so aussehen. Meldungen des Netconsole Logservers (falls aktiviert) werden in das BSD Format umgesetzt:
{
$DATA =~ /^<(?<prival>\d{1,3})>((?<month>\w{3})\s+(?<day>\d{1,2})\s+(?<time>\d{2}:\d{2}:\d{2}))?\s+(?<host>[^\s]*)?\s((:)?(?<id>([^:]*)):)?(?<tail>.*)$/;
$PRIVAL = $+{prival};
if($PRIVAL) { # Syslog-Message
my $year = strftime "%Y", localtime;
my $month = $+{month};
my $day = $+{day};
my $time = $+{time};
my $id = $+{id};
$TS = "$year-$month-$day $time";
$ID = $id?$id:"";
$CONT = $+{tail};
} else {
$PRIVAL = "62"; # SEV (7*8)+6, FAC: System (Netconsole Logserver)
$CONT = $DATA;
}
}
Die mit dieser Funktion erstellten Parsings generieren im Eventmonitor Meldungen in dieser Form:
2020-03-23 18:56:03.629 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: hostapd || CONT: ath0: STA 18:e8:29:cd:79:34 DRIVER: Sead AUTH addr=9c:e0:63:cb:70:91 status_code=0
2020-03-23 18:56:03.635 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: wevent[24355] || CONT: wevent.ubnt_custom_event(): EVENT_STA_LEAVE ath0: 9c:e0:63:cb:70:91 / 6
2020-03-23 18:56:03.643 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: hostapd || CONT: ath0: STA 9c:e0:63:cb:70:91 IEEE 802.11: associated
2020-03-23 18:56:03.652 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: hostapd || CONT: ath0: STA 9c:e0:63:cb:70:91 WPA: pairwise key handshake completed (RSN)
2020-03-23 18:56:03.697 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: wevent[24355] || CONT: wevent.ubnt_custom_event(): EVENT_STA_JOIN ath0: 9c:e0:63:cb:70:91 / 6
2020-03-23 18:56:07.523 Log2Syslog SyslogServer_Unify 192.168.2.4: SEV: Informational || ID: stahtd[18158] || CONT: [STA-TRACKER].stahtd_dump_event(): {"auth_ts":"0.0","assoc_status":"0","event_type":"fixup","message_type":"STA_ASSOC_TRACKER","dns_resp_seen":"yes",
"mac":"9c:e0:63:cb:70:91","vap":"ath0","event_id":"5"}
2020-03-23 18:56:13.651 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: hostapd || CONT: ath0: STA 9c:e0:63:cb:70:91 RADIUS: starting accounting session ADB8E3D140C8DF58
2020-03-23 18:56:13.740 Log2Syslog SyslogServer_Unify 192.168.2.5: SEV: Informational || ID: stahtd[24356] || CONT: [STA-TRACKER].stahtd_dump_event(): {"message_type":"STA_ASSOC_TRACKER","assoc_delta":"10000","mac":"9c:e0:63:cb:70:91","vap":"ath0","wpa_auth_delta":"30000",
"event_id":"12","event_type":"soft
Über ein entsprechendes Notify kann somit auf Fehlermitteilungen etc. reagiert werden.
Für Interessierte hier noch die komplette Raw-Definition des Log2Syslog-Devices:
defmod SyslogServer_Unify Log2Syslog
attr SyslogServer_Unify alias Collector - Unify - UDP/6514
attr SyslogServer_Unify disable 0
attr SyslogServer_Unify icon edit_paste
attr SyslogServer_Unify makeEvent intern
attr SyslogServer_Unify outputFields FAC,SEV,ID,CONT
attr SyslogServer_Unify parseFn {\
$DATA =~ /^<(?<prival>\d{1,3})>((?<month>\w{3})\s+(?<day>\d{1,2})\s+(?<time>\d{2}:\d{2}:\d{2}))?\s+(?<host>[^\s]*)?\s((:)?(?<id>([^:]*)):)?(?<tail>.*)$/;;\
$PRIVAL = $+{prival};; \
if($PRIVAL) { # Syslog-Message\
my $year = strftime "%Y", localtime;;\
my $month = $+{month};; \
my $day = $+{day};; \
my $time = $+{time};;\
my $id = $+{id};; \
$TS = "$year-$month-$day $time";;\
$ID = $id?$id:"";;\
$CONT = $+{tail};; \
} else {\
$PRIVAL = "62";; # SEV (7*8)+6, FAC: System (Netconsole Logserver)\
$CONT = $DATA;;\
}\
}
attr SyslogServer_Unify parseProfile ParseFn
attr SyslogServer_Unify port 6514
attr SyslogServer_Unify protocol UDP
attr SyslogServer_Unify rateCalcRerun 80
attr SyslogServer_Unify room Dienste->Logging
attr SyslogServer_Unify stateFormat state : Transfered_logs_per_minute
attr SyslogServer_Unify verbose 3
Wenn sich das Parsing bewährt, könnte ich es als UniFi AP-AC spezifischen Eintrag im Attribut parseProfile zur Nachnutzung hinterlegen.
Hallo zusammen,
weiß einer zufällig, was das zu bedeuten hat?
2020.03.30 10:25:15 1: PERL WARNING: Use of uninitialized value $pp in pattern match (m//) at ./FHEM/93_Log2Syslog.pm line 465.
2020.03.30 10:25:15 1: stacktrace:
2020.03.30 10:25:15 1: main::__ANON__ called by ./FHEM/93_Log2Syslog.pm (465)
2020.03.30 10:25:15 1: main::Log2Syslog_Read called by fhem.pl (3772)
2020.03.30 10:25:15 1: main::CallFn called by fhem.pl (757)
Da ist eine Variable nicht definiert. Nichts schlimmes, ich beseitige das. Hast du die aktuellste version im Einsatz ?
Edit: In der aktuellsten Version dürfte diese Warnung eigentlich nicht auftreten (gibt es bei mir auch nicht). Solltest du die aktuellste im Einsatz haben, bräuchte ich noch ein List des Devices damit ich einen Anhaltspunkt finden kann.
Ja, hab die Version 5.8.1 im Einsatz.
Meinst du RAW Defintion? ???
Ähhm ... 5.8.2 wäre die aktuelle: FVERSION 93_Log2Syslog.pm:v5.8.2-s19905/2019-07-28
Ansonsten wäre Raw ok. bzw einfach ein
list <Device>
LG,
Heiko
Sorry, mein Fehler! Es ist natürlich die 5.8.2
... hier das was du wolltest:
Internals:
CONNECTS 11
FD 41
FUUID 5e62a5ed-f33f-f45a-1d3d-80f57a00cbfbebb0
FVERSION 93_Log2Syslog.pm:v5.8.2-s19905/2019-07-28
INTERFACE global
MODEL Collector
MYFQDN raspberrypi
MYHOST raspberrypi
NAME Weatherman.Daten
NR 413
NTFY_ORDER 50-Weatherman.Daten
PORT xxxxx
PROFILE raw
PROTOCOL tcp
SEQNO 12
STATE active
TYPE Log2Syslog
HELPER:
LTIME 1585600885
OLDSEQNO 12
OLDSTATE active
PACKAGE main
SSLALGO n.a.
SSLVER n.a.
TCPPADDR xxx.xxx.xxx.xxx
VERSION 5.8.2
HIPCACHE:
xxx.xxx.xxx.xxx ESP-DB14F6
READINGS:
2020-03-30 22:40:43 MSG_ESP-DB14F6 {"modultyp":"weatherman","vars":[{"name":"0","homematic_name":"w_ip","desc":"weatherman_ip","type":"string","unit":"","value":"xxx.xxx.xxx.xxx"},{"name":"1","homematic_name":"w_temperatur","desc":"aussentemperatur","type":"number","unit":"gradC","value":"-0.6"},{"name":"21","homematic_name":"w_windchill","desc":"gefuehlte_temperatur","type":"number","unit":"gradC","value":"-0.6"},{"name":"9","homematic_name":"w_taupunkt","desc":"taupunkt_temperatur","type":"number","unit":"gradC","value":"-11.1"},{"name":"14","homematic_name":"w_himmeltemperatur","desc":"himmel_temperatur","type":"number","unit":"gradC","value":"0.0"},{"name":"2","homematic_name":"w_feuchte_rel","desc":"rel_feuchte","type":"number","unit":"%","value":"45.0"},{"name":"17","homematic_name":"w_feuchte_abs","desc":"abs_feuchte","type":"number","unit":"g/m3","value":"2.1"},{"name":"18","homematic_name":"w_regensensor_wert","desc":"regenmelderwert","type":"number","unit":"","value":"0"},{"name":"7","homematic_name":"w_regenmelder","desc":"regenstatus","type":"boolean","unit":"","value":"false"},{"name":"8","homematic_name":"w_regenstaerke","desc":"regenstaerke","type":"number","unit":"mm/h","value":"0.0"},{"name":"19","homematic_name":"w_regen_letzte_h","desc":"regen_pro_h","type":"number","unit":"mm","value":"0.0"},{"name":"20","homematic_name":"w_regen_mm_heute","desc":"regen_mm_heute","type":"number","unit":"mm","value":"1.0"},{"name":"32","homematic_name":"w_regenstunden_heute","desc":"regenstunden_heute","type":"number","unit":"h","value":"0.0"},{"name":"27","homematic_name":"w_regen_mm_gestern","desc":"regen_mm_gestern","type":"number","unit":"mm","value":"3.9"},{"name":"3","homematic_name":"w_barometer","desc":"nn_luftdruck","type":"number","unit":"mb","value":"1024.62"},{"name":"11","homematic_name":"w_barotrend","desc":"luftdrucktrend","type":"string","unit":"","value":"stabil"},{"name":"4","homematic_name":"w_wind_mittel","desc":"avg_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.0"},{"name":"5","homematic_name":"w_wind_spitze","desc":"peak_windgeschwindigkeit","type":"number","unit":"m/s","value":"0.0"},{"name":"24","homematic_name":"w_windstaerke","desc":"bft_windgeschwindigkeit","type":"number","unit":"bft","value":"0"},{"name":"23","homematic_name":"w_windrichtung","desc":"windrichtung","type":"string","unit":"","value":""},{"name":"6","homematic_name":"w_wind_dir","desc":"windwinkel","type":"number","unit":"grad","value":"0"},{"name":"10","homematic_name":"w_lux","desc":"helligkeit","type":"number","unit":"lux","value":"0.0"},{"name":"28","homematic_name":"w_uv_index","desc":"uv-index","type":"number","unit":"uv_index","value":"0.000"},{"name":"22","homematic_name":"w_sonne_diff_temp","desc":"sonnen_difftemperatur","type":"number","unit":"gradC","value":"-7.7"},{"name":"15","homematic_name":"w_sonnentemperatur","desc":"sonnen_temperatur","type":"number","unit":"gradC","value":"-8.3"},{"name":"16","homematic_name":"w_sonne_scheint","desc":"sonne_scheint","type":"boolean","unit":"","value":"false"},{"name":"26","homematic_name":"w_sonnenstunden_heute","desc":"Sonnenstunden_heute","type":"number","unit":"h","value":"5.3"},{"name":"12","homematic_name":"w_elevation","desc":"sonne_elevation","type":"number","unit":"grad","value":"-26.1"},{"name":"13","homematic_name":"w_azimut","desc":"sonne_azimut","type":"number","unit":"grad","value":"310.9"},{"name":"30","homematic_name":"w_minuten_vor_sa","desc":"minuten_vor_sa","type":"number","unit":"min","value":"-929"},{"name":"31","homematic_name":"w_minuten_vor_su","desc":"minuten_vor_su","type":"number","unit":"min","value":"-168"}],"Systeminfo":{"MAC-Adresse":"xx:xx:xx:xx:xx:xx","Homematic_CCU_ip":"xxx.xxx.xxx.xxx","WLAN_ssid":"xxxxxxxxx","WLAN_Signal_dBm":"-78","sec_seit_reset":"887106","zeitpunkt":"2020.03.30 /22h40","firmware":"weatherman_136"}}
2020-03-30 22:26:24 Parse_Err_No 0
2020-03-30 22:26:24 SSL_Algorithm n.a.
2020-03-30 22:26:24 SSL_Version n.a.
2020-03-30 22:41:25 Sonnenstunden_heute 5.3
2020-03-30 22:41:25 Transfered_logs_per_minute 1
2020-03-30 22:41:25 abs_feuchte 2.1
2020-03-30 22:41:25 aussentemperatur -0.6
2020-03-30 22:41:25 avg_windgeschwindigkeit 0.0
2020-03-30 22:41:25 bft_windgeschwindigkeit 0
2020-03-30 22:41:25 gefuehlte_temperatur -0.6
2020-03-30 22:41:25 helligkeit 0.0
2020-03-30 22:41:25 himmel_temperatur 0.0
2020-03-30 22:41:25 luftdrucktrend stabil
2020-03-30 22:41:25 minuten_vor_sa -929
2020-03-30 22:41:25 minuten_vor_su -168
2020-03-30 22:41:25 nn_luftdruck 1024.62
2020-03-30 22:41:25 peak_windgeschwindigkeit 0.0
2020-03-30 22:41:25 regen_mm_gestern 3.9
2020-03-30 22:41:25 regen_mm_heute 1.0
2020-03-30 22:41:25 regen_pro_h 0.0
2020-03-30 22:41:25 regenmelder 0
2020-03-30 22:41:25 regensensor_wert 0
2020-03-30 22:41:25 regenstaerke 0.0
2020-03-30 22:41:25 regenstunden_heute 0.0
2020-03-30 22:41:25 rel_feuchte 45.0
2020-03-30 22:41:25 sonne_azimut 310.9
2020-03-30 22:41:25 sonne_elevation -26.1
2020-03-30 22:41:25 sonne_scheint 0
2020-03-30 22:41:25 sonnen_difftemperatur -7.7
2020-03-30 22:41:25 sonnen_temperatur -8.3
2020-03-30 22:40:43 state active
2020-03-30 22:41:25 taupunkt_temperatur -11.1
2020-03-30 22:41:25 uv-index 0.000
2020-03-30 22:41:25 windrichtung 0
2020-03-30 22:41:25 windwinkel 0
Attributes:
group Wetterstation
makeEvent reading
parseProfile raw
port xxxxxx
protocol TCP
room 00-Outside
useEOF 1
useParsefilter 1
userReadings aussentemperatur { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_temperatur".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
gefuehlte_temperatur { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_windchill".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
taupunkt_temperatur { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_taupunkt".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
himmel_temperatur { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_himmeltemperatur".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
rel_feuchte { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_feuchte_rel".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
abs_feuchte { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_feuchte_abs".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
regensensor_wert { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regensensor_wert".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
regenmelder { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regenmelder".*?"value":"(true|false)".*/$1/ ;; $w =~ s/true/1/g ;;$w =~ s/false/0/g ;; $w },
regenstaerke { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regenstaerke".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
regen_pro_h { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regen_letzte_h".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
regen_mm_heute { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regen_mm_heute".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
regenstunden_heute { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regenstunden_heute".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
regen_mm_gestern { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_regen_mm_gestern".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
nn_luftdruck { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_barometer".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
luftdrucktrend { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_barotrend".*?"value":"(fallend|stabil|steigend)".*/$1/ ;; $w },
avg_windgeschwindigkeit { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_wind_mittel".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
peak_windgeschwindigkeit { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_wind_spitze".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
bft_windgeschwindigkeit { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_windstaerke".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
windrichtung { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_windrichtung".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
windwinkel { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_wind_dir".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
helligkeit { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_lux".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
uv-index { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_uv_index".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
sonnen_difftemperatur { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_sonne_diff_temp".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
sonnen_temperatur { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_sonnentemperatur".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
sonne_scheint { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_sonne_scheint".*?"value":"(true|false)".*/$1/ ;; $w =~ s/true/1/g ;;$w =~ s/false/0/g ;; $w },
Sonnenstunden_heute { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_sonnenstunden_heute".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
sonne_elevation { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_elevation".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
sonne_azimut { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_azimut".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
minuten_vor_sa { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_minuten_vor_sa".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w },
minuten_vor_su { my $w=ReadingsVal($name,"MSG_ESP-DB14F6",0) ;; $w =~ s/.*"w_minuten_vor_su".*?"value":"([+-]?\d*[\.\d]\d*)".*/$1/ ;; $w }
Ok, danke ... schaue ich mir aber morgen an ;)
Melde mich wieder ...
LG,
Heiko
Kein Ding, ist ja auch nicht gerade wenig :) ... Grüße
Die Warnung habe ich nun eliminiert denke ich.
Neue Version ist in mein contrib geladen zum Test.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"
Und restarten.
Probiers bitte auch bei dir...
Grüße,
Heiko
Ok super! Mach ich sobald ich heut Abend daheim bin. Danke!
Eben getestet, bekomme keine Fehlermeldung mehr. Vielen Dank ;)
Freut mich dass es auch bei dir klappt. :)
Werde es einchecken und ist morgen dann im Update.
Grüße,
Heiko
Hallo zusammen,
ich hatte das Parsing aus #125 nun eine Weile für UniFi Controller laufen und hat das getan was es sollte.
Nun habe ich es fest eingebaut und ist im parseProfile als "UniFi" auswählbar.
Dazu noch einiges an Code review.
Die Version ist zum Test wieder in mein contrib geladen:
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"
Und restarten.
Grüße,
Heiko
Habe die Version 5.9.0 heute den ganzen Tag auf zwei Sytemen getestet und ist anstandslos gelaufen.
Die Version ist eingecheckt und morgen früh im Regelupdate enthalten.
Grüße,
Heiko
Definieren des devices lässt bei mir FHEM abstürzen:
define syslogSender Log2Syslog 10.0.20.37 event:.* fhem:.*
Aus irgendeinem Grund versucht er dann permanent, dasselbe alte Logfile in den Archive Ordner zu schieben und nach gefühlt 1 Milliarde versuchen pro Sekunde, stürzt der Prozess dann ab.
Hier beißt sich offenbar was mit der FHEM global archive Funktion.
Ich habe im global device definiert:
nrarchive 3
archivedir /opt/fhem/log/archive
archiveCompress 1
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
Bei mir sammelt ein Graylog die Daten ein.
Der versteht aber offenbar die Uhrzeiten falsch und schreibt alles 2 Stunden in die Zukunft. Offenbar wird kein UTC als Zeitstempel mitgegeben. Ist das konfigurierbar?
Ich sehe das der Timestamp keine Zeitzonen-Angabe enthält, wie man es eigentlich erwarten würde:
<45>1 2020-04-03T10:29:44 fhem. syslogSender_event 268 FHEM [version@Log2Syslog version="5.8.3"] EG.fl.Fully motion_detection: off
Müsste hier eigentlich einen Zeitstempel 2020-04-03T10:29:44+0200 haben. Alternativ 2020-04-03T08:29:44Z wenn es GMT wäre.
RFC 5424 zeigt das in Sektion 6.2.3.1 bei den Beispielen: https://tools.ietf.org/html/rfc5424#section-6.2.3
RFC 3339 beschreibt Timestamp allgemein: https://tools.ietf.org/html/rfc3339#section-4.2
Vielleicht kann das optional konfigurierbar gemacht werden?
Hallo Phiolin,
das Verhalten konnte ich bei mir noch nicht beobachten, allerdings habe ich bei mir auch kein archivedir gesetzt.
Ich versuche es mal nachzuvollziehen, wobei der Zusammenhang mir etwas suspect vorkommt.
Es wird die lokale Zeit verwendet. Greylog kannst du m.W. entsprechend konfigurieren:
https://community.graylog.org/t/time-configuration/6932
Jetzt läuft es wohl da du ja Werte im Syslog-Server bekommst ?
EDIT: Zeitangabe konfigurierbar machen kann ich mal mit vorsehen. Die RFC's kenne ich danke. ;)
LG,
Heiko
Hallo Phiolin, @all,
ich habe deine Anregung bzgl. einstellbarer Zeitformate übernommen und im Modul umgesetzt.
Es gibt ein Attribut timeSpec welches zur Umschaltung dient wenn gewünscht. Es werden die Zeitformen gemäß RFC 3339 verwendet.
* timeSpec [Local | UTC]
Verwendung des lokalen bzw. UTC Zeitformats im Device. Nur empfangene Zeitdatagramme, die die Spezifikation gemäß RFC 3339 aufweisen, werden entsprechend umgewandelt. Die Zeitspezifikation beim Datenversand (Model Sender) erfolgt immer entsprechend des eingestellten Zeitformats.
Default: Local.
Beispiele unterstützter Zeitspezifikationen
2019-04-12T23:20:50Z
2019-12-19T16:39:57-08:00
2020-01-01T12:00:27+00:20
2020-04-04T16:33:10+00:00
2020-04-04T17:15:00+02:00
Bezüglich deines Absturzproblems konnte ich nichts nachvollziehen. Habe bei mir ebenfalls archivedir eingestellt und alles mögliche durchgespielt inklusive neu definieren -> kein Prob.
Die Version 5.10.0 liegt zum Test wieder in meinem contrib. Download wie weiter oben bereits beschrieben.
Restart bitte nicht vergessen.
Freue mich über eine Rückmeldung wie es mit Greylog zusammenspielt. Meine Tests mit Synology Protokoll-Center und zwei FHEM Instanzen untereinander (Sender -> Collector) waren durchweg erfolgreich.
LG,
Heiko
Version 5.10.0 ist eingecheckt. Ich habe noch einiges im Code weiterentwickelt, z.B. bzgl. Octet Counting Erweiterung gemäß RFC 6587.
VG
Sorry, war ein paar Tage beschäftigt.
Also Graylog kann man zwar wie von dir verlinkt konfigurieren, diese Einstellung hat aber keinen Einfluss auf die Zeitzone die für Syslog Inputs herangezogen wird. Der Syslog Input erwartet immer einen Timestamp mit Zeitzonenangabe, wenn diese fehlt, nimmt er UTC an. Die konfigurierte root Timezone setzt nur den Standard, falls für einen User nichts anderweitiges konfiguriert ist. Auf den Input selbst hat es leider keinen Einfluss.
Mit deiner Änderung funktioniert es jetzt, Logs kommen ordentlich zur richtigen Zeit im Graylog an. :)
Was mit dem Absturz wegen des Log-Archives falsch war, hab ich leider nicht herausgefunden. Er hat immer versucht, das Dezember Log zu archivieren und das irgendwie nicht hinbekommen, mit dem File selber war aber nichts auffälliges.
Hab das Dezember Log einfach gelöscht, danach war Ruhe. ;)
Prima ... danke für die Rückmeldung :)
Hallo zusammen, schöne Idee dieses Modul
Kurze Unterstützung bitte:
Ich habe ein kl. Problem mit dem Attrib "exclErrCond"
Ganz einfach es filtern nichts, selbst einfache Events.
Internals:
DEF x.x.x.x event:.* fhem:.*
FUUID 5e898b9f-f33f-0190-238e-6b325fa8319695be
FVERSION 93_Log2Syslog.pm:v1.1.1-s21611/2020-04-05
MODEL Sender v5.12.0
MYFQDN xxxxxxx
MYHOST xxxxxxx
NAME mysyslog
NR 340
NTFY_ORDER 50-mysyslog
PEERHOST x.x.x.x
SEQNO 68
STATE active
TYPE Log2Syslog
HELPER:
EVNTLOG .*
FHEMLOG .*
LTIME 1589296310
OLDSEQNO 68
OLDSTATE active
PACKAGE FHEM::Log2Syslog
SSLALGO n.a.
SSLVER n.a.
VERSION 5.12.0
READINGS:
2020-05-12 16:38:29 SSL_Algorithm n.a.
2020-05-12 16:38:29 SSL_Version n.a.
2020-05-12 17:11:50 Transfered_logs_per_minute 5
2020-05-12 17:12:32 state active
Attributes:
disable 0
exclErrCond Internals:
DEF x.x.x.x event:.* fhem:.*
FUUID 5e898b9f-f33f-0190-238e-6b325fa8319695be
FVERSION 93_Log2Syslog.pm:v1.1.1-s21611/2020-04-05
MODEL Sender v5.12.0
MYFQDN xxxxxxx
MYHOST xxxxxxx
NAME mysyslog
NR 340
NTFY_ORDER 50-mysyslog
PEERHOST x.x.x.x
SEQNO 68
STATE active
TYPE Log2Syslog
HELPER:
EVNTLOG .*
FHEMLOG .*
LTIME 1589296310
OLDSEQNO 68
OLDSTATE active
PACKAGE FHEM::Log2Syslog
SSLALGO n.a.
SSLVER n.a.
VERSION 5.12.0
READINGS:
2020-05-12 16:38:29 SSL_Algorithm n.a.
2020-05-12 16:38:29 SSL_Version n.a.
2020-05-12 17:11:50 Transfered_logs_per_minute 5
2020-05-12 17:12:32 state active
Attributes:
disable 0
exclErrCond Vacuum error_code: None,Vacuum error: none,DS1 Error: none,DS1 Errorcode: none,
logFormat IETF
respectSeverity Critical,Error
room Systeminfos,Vacuum error: none,DS1 Error: none,DS1 Errorcode: none,
logFormat IETF
respectSeverity Critical,Error
room Systeminfos
Auch ein .*Vacuum.*error_code:.*None.* oder error_code:.*None.* .*error_code:.*[Nn]one.* bringt keine Änderung
Jemand einen Tipp.
Definiere bitte "filtern" mal genauer was du darunter verstehst.
:)Danke für die schnelle Hilfe,
Ich habe einige Devices die halt alle 10 Min Events senden, wo halt ein z.B. Vacuum error: none als Meldung auf im Syslog Protokoll der Syno steht.
2020-05-12 17:19:36 Fehler hostx syslog mysyslog_event Vacuum error_code: None
:)
Das scheint zu greifen..
exclErrCond error_code: None,error: none,Error: none,Errorcode: none
Vacuum error_code: None mag der "Error - Filter" so nicht
Passt :)
Bei Vacuum error_code: None könntest du mal probieren "Vacuum\serror_code:\sNone"
:) Thx, klappt
Danke für den Support
Hi, jemand einen Tipp, wie man den "Error" (z.B. Schweregrad)
bei den normalen Updates der FHEM Module einschränken kann?
Der Inhalt des Protokolls ist wie folgt:
1: UPD FHEM/14_CUL_MAX.pm
Wenn es 12 Modul Updates in FHEM gibt, gibt 12 Err Meldungen
2020-05-15 09:49:47 Fehler hostx syslog mysyslog_fhem 1: UPD FHEM/10_MAX.pm
Moin,
das muß ich im Code ähnlich den "Events" nachbauen.
Danke für den Hinweis ...
Melde mich wieder mit einer Anpassung.
LG,
Heiko
Ich habe das Modul jetzt angepasst. Du kannst es vorab aus meinem contrib laden und dann restarten.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"
LG,Heiko
hi, thx für die schnelle Aktion,
leider sind es mehr Meldungen als vorher:
Hier nur ein kl. Auszug, nach dem dem Restore der Updates(FHEM) von heute.
Danach reboot und ein neues update durchgeführt
2020-05-15 18:53:30 Fehler hostx syslog mysyslog_fhem 1: backup done: FHEM-20200515_185313.tar.gz (39577467 Bytes)
2020-05-15 18:53:45 Fehler hostx syslog mysyslog_fhem 1: UPD FHEM/48_BlinkCamera.pm
2020-05-15 18:53:45 Fehler hostx syslog mysyslog_fhem 1: UPD FHEM/39_gassistant.pm
2020-05-15 18:53:48 Fehler hostx syslog mysyslog_fhem 1: update finished, "shutdown restart" is needed to activate the changes.
2020-05-15 18:53:50 Fehler hostx syslog mysyslog_fhem 1:
-rw-r--r-- 1 fhem dialout 175807 Mai 15 18:04 93_Log2Syslog.pm
die neue Version ist im Einsatz
Selbst einfach ein "backup" über Befehlszeile wird als Error erfasst.
2020-05-15 19:47:20 Fehler hostx syslog mysyslog_fhem 1: NOTE: make sure you have a database backup!
Sorry, ich hätte natürlich noch erwähnen müssen, dass du die gewünschten Pattern in Attr 'exclErrCond' einfügen musst wie für die Events auch (dachte du weißt das noch ;) )
z.B.
attr <name> exclErrCond Errocode: none, UPD FHEM
Damit du nicht bis morgen warten musst kannst du es so testen:
{ Log (1, "UPD FHEM blabla") }
Einfach im FHEMWEB in der Kommandozeile ausführen.Auf der Syno kommt es dann wie im Screenshot an.
LG,Heiko
:)Danke auch für den Hinweis, ich werde es mal genau durchspielen und noch ein kurzes Feedback geben.
:)Gute Anpassung, sehr Hilfreich, reduziert die Meldungen nach der Anpassung "exclErrCond" auf wirklich nur das "Wichtige! im syslog
@Heiko, kleines Bier hast Dir am Abend verdient. Danke!
Prima :)
Und die Freude ich ganz meinerseits ... herzlichen Dank !! :D
Die geänderte Version checke ich heute Abend ein und ist morgen früh dann im Regelupdate.
schönen Abend noch !
LG,
Heiko
Mit Log2Syslog werte ich die von meinem Weatherman gesendeten Daten aus.
Nachdem Update auf die aktuelle Version tut sich leider nichts mehr.
Was muss ich in der Definition ändern, damit wieder Daten angenommen werden ?
defmod WMpush Log2Syslog
attr WMpush room Wetter
attr WMpush group Weatherman
attr WMpush makeEvent reading
attr WMpush parseProfile raw
attr WMpush port 1885
attr WMpush protocol TCP
attr WMpush useEOF 1
attr WMpush useParsefilter 1
Das letzte Update ist aber schon 2 Monate zurück. ;)
Ich kann das wegen zu wenig Infos nicht einschätzen. Kann zunächst sagen läuft geräuschlos bei mir.
Aber das hilft dir jetzt natürlich nicht.
Deswegen dreh mal verbose hoch auf 5 und schau mal ins Logfile. Es kommen dann solche Meldungen wie hier bei mir:
2020.08.04 19:59:14.452 4: Log2Syslog SyslogServer_Unify - #######################################################
2020.08.04 19:59:14.453 4: Log2Syslog SyslogServer_Unify - ######### new Syslog UDP Receive #########
2020.08.04 19:59:14.453 4: Log2Syslog SyslogServer_Unify - #######################################################
2020.08.04 19:59:14.453 5: Log2Syslog SyslogServer_Unify - Buffer 147 chars ready to parse:
<31>Aug 4 19:59:14 U7LT,18e829cc7934,v4.3.20.11298: hostapd: ap_handle_timer: register ap_handle_timer timeout for 2c:3a:e8:06:08:fa (318 seconds)
2020.08.04 19:59:14.453 4: Log2Syslog SyslogServer_Unify - ######### Parse Message #########
2020.08.04 19:59:14.453 5: Log2Syslog SyslogServer_Unify - parse profile: UniFi
2020.08.04 19:59:14.454 5: Log2Syslog SyslogServer_Unify - message peer: ,192.168.2.5
2020.08.04 19:59:14.454 4: Log2Syslog SyslogServer_Unify - raw message -> <31>Aug 4 19:59:14 U7LT,18e829cc7934,v4.3.20.11298: hostapd: ap_handle_timer: register ap_handle_timer timeout for 2c:3a:e8:06:08:fa (318 seconds)
2020.08.04 19:59:14.454 4: SyslogServer_Unify - parsed message -> FAC: system, SEV: Debug, TS: 2020-08-04 19:59:14, HOST: U7LT,18e829cc7934,v4.3.20.11298, ID: hostapd, CONT: ap_handle_timer: register ap_handle_timer timeout for 2c:3a:e8:06:08:fa (318 seconds)
Edit: Kenne Weatherman nicht, aber möglicherweise hilft useEOF = 0 falls das Gerät kein EOF sendet.
Ich hatte nach längerer Zeit mal wieder ein Update gemacht, deswegen ist das erst jetzt aufgefallen.
Dann zuerst die vorherige Version zurückkopiert. Reload Modul. Alles wieder OK.
Neue Version reinkopiert. Reload Modul. Geht nicht.
Dann mit der vorherigen laufen lassen.
Jetzt wollte ich die neue Version mit verbose 5 testen.
Und nun geht es auch hiermit.
Keine Ahnung, was da schiefgelaufen ist.
Auf jeden Fall jetzt alles im grünen Bereich.
Und Danke
Also wenn du nur reload ausgeführt hast, ist das klar.
Restart ist notwendig, da es mit V 5.11.0 am 14.04. ein größere Änderung im Perl Coding gab.
Aber schön das es jetzt geht. :)
Danke für die Info.
Wieder was gelernt :)
Hi,
ich versuche gerade das Modul in meinem Docker-Container zum laufen zu bringen.
Angelegt habe ich das Device folgendermaßen:
defmod syslog_client Log2Syslog fhemtest 192.168.168.100 ident:Test event:.* fhem:.*
attr syslog_client port 1514
Folgende Fehlermmeldung bekomme ich:
unable open socket for fhemtest, tcp, 1514: Invalid argument
Hat jemand eine Idee an was das liegen könnte?
VG
Thorsten
Hallo Thorsten,
in deiner Definition ist eine Angabe zu viel drin. Richtig wäre z.B.:
defmod syslog_client Log2Syslog 192.168.168.100 ident:Test event:.* fhem:.*
oder der Name des Zielservers statt IP 192.168.168.100.
Grüße,
Heiko
Super, funktioniert. :)
Vielen Dank für Deine schnelle Hilfe.
Viele Grüße
Thorsten
Hallo zusammen,
ich hatte bei der definition vor einigen Tagen genau dasselbe Problem mit der Logfile Archivierung. Irgendwann hat es dann funktioniert das Device zu erstellen und es lief einige Tage. Heute musste ich Fhem allerdings neustarten und das Modul hat beim Starten genau dieselben Fehler geschmissen bis Fhem wegen "Out of Memory" abbricht nach 36MB Logfiles. Dies hat sich in einer Schleife bis ins unendlich wiederholt, da Fhem automatisiert neugestartet wird, sollte der Service nicht laufen.
Ich musste das Modul leider wieder aus meiner Konfiguration schmeißen, da es einfach zu risikoreich ist um es produktiv zu nutzen, obwohl ich es geliebt habe die Logdaten zentral auf meinem DB Server zu haben.
Meine global Einstellungen:
archivedir /opt/fhem/log/oldlogs
nrarchive 4
Ein archivecompress habe ich nicht eingestellt.
Zitat von: Phiolin am 03 April 2020, 10:11:57
Definieren des devices lässt bei mir FHEM abstürzen:
define syslogSender Log2Syslog 10.0.20.37 event:.* fhem:.*
Aus irgendeinem Grund versucht er dann permanent, dasselbe alte Logfile in den Archive Ordner zu schieben und nach gefühlt 1 Milliarde versuchen pro Sekunde, stürzt der Prozess dann ab.
Hier beißt sich offenbar was mit der FHEM global archive Funktion.
Ich habe im global device definiert:
nrarchive 3
archivedir /opt/fhem/log/archive
archiveCompress 1
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive
Bei mir sammelt ein Graylog die Daten ein.
Der versteht aber offenbar die Uhrzeiten falsch und schreibt alles 2 Stunden in die Zukunft. Offenbar wird kein UTC als Zeitstempel mitgegeben. Ist das konfigurierbar?
Ich sehe das der Timestamp keine Zeitzonen-Angabe enthält, wie man es eigentlich erwarten würde:
<45>1 2020-04-03T10:29:44 fhem. syslogSender_event 268 FHEM [version@Log2Syslog version="5.8.3"] EG.fl.Fully motion_detection: off
Müsste hier eigentlich einen Zeitstempel 2020-04-03T10:29:44+0200 haben. Alternativ 2020-04-03T08:29:44Z wenn es GMT wäre.
RFC 5424 zeigt das in Sektion 6.2.3.1 bei den Beispielen: https://tools.ietf.org/html/rfc5424#section-6.2.3
RFC 3339 beschreibt Timestamp allgemein: https://tools.ietf.org/html/rfc3339#section-4.2
Vielleicht kann das optional konfigurierbar gemacht werden?
Das Modul hat mit der Verwaltung der Logfiles nichts zu tun. Ich kann es bei mir auch nicht nachvollziehen.
Generell ... du musst sicherstellen, dass das Verzeichnis /opt/fhem/log/oldlogs existiert und auch den entsprechenden Owner (fhem:dialout) sowie Schreibrechte für ihn existieren.
Sonst wird FHEM ständig versuchen zum entsprechenden Zeitpunkt das eingestellte Regime umzusetzen was im Fall Nichtvorhandensein des Archive-Verzeichnisses nicht vollzogen werden kann.
Bei mir steht z.B.
archivedir = ./log/archive
Hallo fhemxperte, @all,
jetzt hat mir das Ganze doch keine Ruhe gelassen und ich habe eine Stelle gefunden, die möglicherweise in ungünstigen Fällen doch eine unerwünschte Nebenwirkung haben könnte. Ich habe die Stelle beseitigt.
Bitte teste(t) die Version in meinem contrib.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"
Grüße,
Heiko
Hi,
schaue ich mir an. Gebe gleich Rückmeldung.
Berechtigungen und alles andere sind in meiner Fhem Installation korrekt und hatte bisher auch nie Probleme (läuft seit mehreren Jahren stabil).
Vielen Dank für die Mühe.
Gruß,
Michael
Zitat von: DS_Starter am 02 November 2020, 15:31:25
Hallo fhemxperte, @all,
jetzt hat mir das Ganze doch keine Ruhe gelassen und ich habe eine Stelle gefunden, die möglicherweise in ungünstigen Fällen doch eine unerwünschte Nebenwirkung haben könnte. Ich habe die Stelle beseitigt.
Bitte teste(t) die Version in meinem contrib.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"
Grüße,
Heiko
Hi,
das Device konnte ohne Probleme erstellt werden und hat mehrere (alle) Restarts überlebt. Ich denke da hast du die Stelle gefunden, die zu Problemen geführt hat. Vielen Dank. Sollte es doch nicht diese Stelle gewesen sein, werde ich mich nochmal melden.
Ggf. kann Phiolin ja auch nochmal gegenprüfen...
PS: Sehr geniales Modul! Mich freut es, dass ich es weiter verwenden kann in einer wahrscheinlich nun stabilen Version.
Viele Grüße,
Michael
Zitat von: DS_Starter am 02 November 2020, 15:31:25
Hallo fhemxperte, @all,
jetzt hat mir das Ganze doch keine Ruhe gelassen und ich habe eine Stelle gefunden, die möglicherweise in ungünstigen Fällen doch eine unerwünschte Nebenwirkung haben könnte. Ich habe die Stelle beseitigt.
Bitte teste(t) die Version in meinem contrib.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"
Grüße,
Heiko
Hallo Michael,
danke für die Rückmeldung.
Checke es heute Abend noch ein und ist dann morgen früh im Regelupdate.
Grüße,
Heiko
:)Hallo zusammen,
Ich habe seit ein paar Tagen, wenn ich mal auf Verbose 5 schalte, sehr viele Meldungen im log.
Hat jemand einen Tipp?
021.05.25 08:52:46 5: Log2Syslog mysyslog - Warning - Payload NOT sent due to Message Severity not in attribute "respectSeverity"
Moin,
ja. Du hast wahrscheinlich so wie es in der Meldung steht die zu übermittelnden Schweregrade mit dem Attr respectSeverity gefiltert. D.h. es kommen Schweregrade im System vor die wegen der Filterung nicht übertragen werden was ja i.A. dem Willen des Anwenders entspricht sonst hätte er den Filter nicht gesetzt. ;)
respectSeverity
Es werden nur Nachrichten übermittelt (Sender) bzw. beim Empfang berücksichtigt (Collector), deren Schweregrad im Attribut enthalten ist. Ist "respectSeverity" nicht gesetzt, werden Nachrichten aller Schweregrade verarbeitet.
Also entweder die Nachricht ignorieren (ist ja verbose 5) oder den Filter anpassen/löschen.
LG,
Heiko
Vielen Dank für die schnelle Reaktion,
Grund warum ich verbose 5 eingeschaltet habe war eine andere Meldung >200 x im Syslog.
nfo
2021-05-25 08:01:48 SYSTEM
Event detection: Received log which severity is [err]. Log content: [1: Error parsing >connected< for]
Info
2021-05-25 08:01:42
SYSTEM
Event detection: Received log which severity is [err]. Log content: [1: Error parsing >disconnected< for]
Habe jetzt wieder alles aktivert, mal schauen ob der Fehler wieder kommt.
Moin Moin,
ich nutze seit ein paar Tagen das Modul als Collector um DHCP Infos von meinem Mikrotik Router zu empfangen und so eine Anwesenheitserkennung durchzuführen. Das funktioniert auch alles problemlos.
Heute ist mir aufgefallen, das durch das Modul und evtl. der Hostnameabfragen eine sehr große Menge an DNS Abfragen auf meinem Pi-Hole zu sehen sind, was natürlich ganz schön meine Statistik verfälscht.
Habe die DNS Abfragen im Router mal mitgeloggt und für jedes SysLog Event erfolgt eine Abfrage, was ca. 40-60 Einträge pro Minute zur Folge hat.
Wäre es möglich diese Abfragen im Modul zu deaktivieren?
Viele Grüße
Hallo KurtK,
das Modul hat einen integrierten Hostnamencache sofern der DNS-Server den Hostnamen zu er empfangenen Adresse liefern kann.
Man kann das kontrollieren, indem man ein "list <name>" ausführt:
Internals:
FD 20
FUUID 5c44b572-f33f-b178-c1b3-7532097d28b2061b
FVERSION 93_Log2Syslog.pm:v5.12.4-s23875/2021-03-01
INTERFACE global
MODEL Collector v5.12.4
MYFQDN fhemtest.myds.me
MYHOST fhemtest
NAME SyslogServer_BSD
NR 480
NTFY_ORDER 50-SyslogServer_BSD
PORT 7514
PROFILE Automatic
PROTOCOL udp
SEQNO 2
STATE active : 0
TYPE Log2Syslog
HELPER:
LTIME 1624392258
OLDSEQNO 2
OLDSTATE active
PACKAGE FHEM::Log2Syslog
TCPPADDR 192.168.2.46
VERSION 5.12.4
HIPCACHE:
192.168.2.46 fhem.myds.me
Man findet dann die gecachten Adressen/Hostnamen nach dem Schlüssel HIPCACHE wie oben zu sehen.
Du musst nur dafür Sorge tragen dass dein DNS-Server die Adresse zu dem Hostnamen zuordnen kann.
Checke das mal bitte.
Grüße,
Heiko
Moin Moin,
danke für die schnelle Antwort und auch die schnelle Lösung.
Es lag tatsächlich an der fehlenden Namensauflösung.
Als die häufigen Anfragen auftraten, war unter HIPCACHE kein Eintrag vorhanden.
Habe einen entsprechenden Eintrag in die Hosts-Datei des FHEM-Server gemacht welcher mit list auch sofort aufgeführt wird und die Anfragen beim pi-hole beendet hat.
Viele Grüße