Modul 93_Log2Syslog - FHEM Logs an Syslog-Server leiten und Syslogs empfangen

MaMi7880 · 20 Oktober 2018, 21:08:24

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.

MaMi7880 · 20 Oktober 2018, 22:10:47

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.

DS_Starter · 20 Oktober 2018, 22:17:39

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

MaMi7880 · 21 Oktober 2018, 18:51:02

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

majorshark · 08 Februar 2019, 07:42:09

Hallo Heiko,

kannst Du Bitte mal das Leerzeichen aus dem

Code Auswählen

apt-get install libio-socket- multicast-perl nehmen.

Code Auswählen

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

DS_Starter · 08 Februar 2019, 08:09:37

Morgen Frank,

mach ich ... danke für den Hinweis

Grüße
Heiko

majorshark · 08 Februar 2019, 08:25:03

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?

DS_Starter · 08 Februar 2019, 14:56:58

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

DS_Starter · 08 Februar 2019, 15:02:12

Ä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

majorshark · 08 Februar 2019, 16:31:30

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

DS_Starter · 08 Februar 2019, 16:41:25

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.

DS_Starter · 08 Februar 2019, 16:48:21

Mir ist noch etwas eingefallen, was sagt denn

hostname -f

auf der BS-Ebene ? Möglicherweise hast du keinen FQDN gesetzt.

majorshark · 08 Februar 2019, 18:37:55

Code Auswählen

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.

Code Auswählen

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.

majorshark · 14 Februar 2019, 15:49:48

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.

Code Auswählen

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

DS_Starter · 14 Februar 2019, 18:31:18

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