SYSMON erzeugt unaufhörlich Events

Begonnen von Michi240281, 30 August 2015, 11:19:08

Vorheriges Thema - Nächstes Thema

rapster

Hast du den Linux Befehl schonmal ausprobiert:
ps aux | grep [f]hem
?

frank

hast du schon mal nach fehlermeldungen/warnings in fhem.log geschaut?
auf der fritzbox ist zb die perlversion unzureichend für sysmon. wie sieht das auf dem nas aus?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Michi240281

root@raspberrypi:/home/pi# ps aux | grep [f]hem
fhem     32398  8.5 28.5 275452 270852 ?       S    Aug29 358:30 /usr/bin/perl fhem.pl fhem.cfg


Was bedeutet die Ausgabe?

@Frank: Da ist nichts Besonderes drin! Ich habe Fhem ja nicht auf dem NAS, sondern auf dem RPi2! Ich frage nur per Telnet die Daten vom NAS ab mittels SYSMON!
FHEM 5.6 auf RPi2 / HM LAN Adapter / diverse HM-Devices
FHEM-Remote-App
QNAP 419P / Onkyo TX-SR 608
DM500HD / GM Spark One
Sony 52HX905

rapster

Die Ausgabe sieht erstmal OK aus, und besagt das fhem nur 1x läuft.
Sehr seltsam...

Michi240281

Was geht denn damit ab? Jetzt habe ich folgendes Attribut gesetzt:

event-on-change-reading eth0_speed

Dennoch kommt

2015-09-01 21:01:32.745 SYSMON Qnap419P frei_2: 92540
2015-09-01 21:01:32.745 SYSMON Qnap419P frei: 92.54
2015-09-01 21:01:33.203 SYSMON Qnap419P frei_2: 92540
2015-09-01 21:01:33.203 SYSMON Qnap419P frei: 92.54


Kann doch wohl nicht wahr sein..........
FHEM 5.6 auf RPi2 / HM LAN Adapter / diverse HM-Devices
FHEM-Remote-App
QNAP 419P / Onkyo TX-SR 608
DM500HD / GM Spark One
Sony 52HX905

Felix_86

#20
@ Michi240281
Kamst du hier damals zu einer Lösung?

Ich nutze SysMon schon ewig zur Überwachung des Hosts und bisher hat es immer problemlos funktioniert. Heute habe ich mir ein userReadings und ein stateFormat in dem SysMon-Objekt eingebaut und habe nun das gleiche Verhalten.
Das userReading erzeugt alle 60 Sekunden ein Event, auch wenn es sich nicht ändert, trotz event-on-change-reading.
Es sieht so aus, als würden die INTERVAL_MULTIPLIERS für das userReading  nicht greifen, sondern der INTERVAL_BASE.

Über Rückmeldung würde ich mich freuen.
Danke vorab.


Antwort von Michi240281 per PM:

ZitatAntw:SYSMON erzeugt unaufhörlich Events
« Senden an: Felix_K am: Heute um 09:12:03 »

Hallo Felix,

leider gar nicht, ich habs dann so gelassen. Betraf auch nur ein einziges Event, das immer doppelt kam. Da ich inzwischen auf eine VM auf meinem NAS gewechselt bin, die ziemlich leistungsfähig ist, kümmert mich dieses eine event nicht.

Sorry dass ich dir nicht helfen kann.

FHEM 5.6 auf RPi2 / HM LAN Adapter / diverse HM-Devices
FHEM-Remote-App
QNAP 419P / Onkyo TX-SR 608
DM500HD / GM Spark One
Sony 52HX905
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT, SD_GT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

peterk_de

@Felix habe gerade beim Aufräumen der DBLog die gleiche Beobachtung gemacht: event-on-change-reading auf ein Userreading ist Wirkungslos -> es kommen Events, auch wenn sich der Wert nicht ändert. Bei allen anderen Readings geht es wie erwartet.

Da ich über die userDefined-Commands mit SYSMON den Status meiner virtuellen Maschinen abfrage (stopped / running etc.)  und dann mit einem Userreading parse, ändert sich der Wert des Userreadings so gut wie nie, aber wenn, dann brauch ich schnell nen Event ...
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

peterk_de

OK es liegt daran dass SYSMON etwas zu akribisch bei jedem Update die Readings aufräumt. Dabei werden die Userreadings fälschlicherweise aus dem Hash geworfen und danach gleich wieder neu angelegt.

Quick-and-Dirty-Patch:

in der 42_SYSMON.pm Zeile 1096 auskommentieren, das ist diese:


delete $defs{$name}{READINGS}{$aName};


Mögliche Nebenwirkungen (soweit ich das auf die schnelle Überblicke): Es werden dann gar keine Readings mehr automatisch gelöscht. Allerdings hab ich keine Ahnung, wozu genau dieses ständige Löschen bei jedem Update überhaupt gut sein soll ... Der Maintainer hat sich da aber sicher was bei gedacht und kann das sicher ggf. schöner fixen ;-) Ich kann damit so jetzt allerdings gut leben.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...