Hi,
ich lese meinen Stromzähler mit dem OBIS-Modul aus. Der Zähler pusht ungefragt im Sekundentakt seine Daten über den Lesekopf an den USB-Port. Ich habe zwar mit
event-min-interval 60
erreicht, dass nur jede Minute ein Datensatz geloggt wird, aber das löst nur die Hälfte des Problems. Jede Sekunde empfängt fhem die Daten und reicht sie ans OBIS-Modul weiter, wo sie dann verworfen werden wegen event-min-interval. Das erzeugt eine ziemlich hohe CPU-Last. Sobald ich den Lesekopf vom Zähler entferne geht die Last deutlich runter:
top sagt:
- mit Daten vom Stromzähler 7 ... 15% für perl
- ohne Daten vom Stromzähler 0,7 ... 1% für perl
Der Screendump von SYSMON zeigt es ebenfalls. Man kann deutlich erkennen, wann der Lesekopf dran war und wann nicht (Ausnahme 4:00 Uhr: da lief das Backup => andere Ursache für die hohe Last).
Hat Jemand eine Idee, wie ich das besser lösen könnte?
global dupTimeout 60
habe ich bereits versucht; scheint keinerlei Effekt zu haben (sind halt keine Dup's).
Zitat von: willybauss am 18 Februar 2016, 10:03:12
Ich habe zwar mit
event-min-interval 60
erreicht, dass nur jede Minute ein Datensatz geloggt wird, aber das löst nur die Hälfte des Problems. Jede Sekunde empfängt fhem die Daten und reicht sie ans OBIS-Modul weiter, wo sie dann verworfen werden wegen event-min-interval.
Bist Du sicher, dass
event-min-interval das richtige Attribut für Deine Anforderung ist? Oder hast Du es mit
event-on-change-reading kombiniert? Das
event-min-interval sorgt nämlich dafür, dass ein Datenpunkt geloggt wird, wenn für das spezifizierte Intervall
kein Event aufgetreten ist.
Gruß, Peter
Wenn das Filtern der Events nicht den gewünschten Erfolg bringt und der Zähler sich nicht "erziehen" lässt, dann vielleicht den Zähler tauschen. Denn es gibt anscheinend welche, die die Daten erst auf Anfrage liefen: http://forum.fhem.de/index.php/topic,48143.msg399852.html#msg399852
Zitat von: ph1959de am 18 Februar 2016, 10:34:20
Das event-min-interval sorgt nämlich dafür, dass ein Datenpunkt geloggt wird, wenn für das spezifizierte Intervall kein Event aufgetreten ist.
Da wäre ich mir nicht so sicher.
Commandref:
Zitatevent-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.
Somit dürfte ich damit richtig liegen.
Aber das löst ja nicht das Problem. Beide Attribute werden erst im Modul verarbeitet. Wichtig wäre es, wenn schon fhem 59 Sekunden lang die Daten ignorieren, und nur in der 60. Sekunde ans Modul weiterreichen würde.
Zitat von: willybauss am 18 Februar 2016, 11:58:59
Da wäre ich mir nicht so sicher.
Zitat von: commandrefDieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.
Somit dürfte ich damit richtig liegen.
Tja, leider nicht ganz (oder "ganz nicht"?). Das
event-min-interval erzeugt ein
zusätzliches Event, wenn im spezifizierten Zeitraum vom eigentlichen Device keines gekommen ist (ist hier (http://forum.fhem.de/index.php/topic,36522.msg287948.html#msg287948) schon mal ausführlich diskutiert worden).
Also: wie sind bei Dir
...-on-change und
...-on-update gesetzt?
Schon wieder was gelernt. Die Commandref ist manchmal einfach sehr sparsam formuliert. Aber warum schaffe ich es dann mit
event-min-interval 60
die Log-Einträge auf 1 pro Minute zu begrenzen? Ich hätte mit dieser Beschreibung eigentlich 60+1 Log-Einträge pro Minute erwartet.
Habe es jetzt mal kombiniert:
event-min-interval 60
event-on-change-reading .*
==> 1 Eintrag pro Sekunde im Logfile. Siehe auch im verlinkten Beitrag:
ZitatBei event-on-change-reading wird event-min-interval ignoriert wenn sie die Werte änder und sofort ein Event gefeuert
event-min-interval 60
event-on-update-reading .*
==> 1 Eintrag pro Minute; CPU-Last bleibt unverändert hoch. Habe ich damit dennoch was gewonnen?
Willi, du hast in deinem Post(#5) zweimal die gleich event-min.../event-on... Kombination aufgeführt - das kann nicht passen und man kann jetzt nicht erkennen, wann du den Eintrag/Sec bzw. den /Min bekommst.
Darüberhinaus: hast Du schon mal mit dem Threshold beim event-on-... experimentiert?
Bevor hier was Falsches gelernt wird:
- event-min-interval sorgt dafuer, dass ein Event hoechstens alle X Sekunden (aber nicht haeufiger) durchgelassen wird, generiert aber selbst keine Events.
- event-on-change-reading laesst events nur bei Aenderung durch (optional mit mindest-delta).
- falls event-on-update-reading gesetzt ist, dann werden die nicht spezifizierten events nicht durchgelassen.
- das Wort "reading" ist in beiden Faellen irrefuehrend, da das Reading immer gesetzt wird, nur das Event wird nicht durchgelassen.
- mit _nicht_ durchlassen meine ich: Modul generiert Event, aber keiner kriegt es mit.
- falls event-on-change-reading zuschlaegt, filtert min-interval nicht (aber da bin ich mir nicht ganz sicher, der Code ist relativ verwirrend).
Das Setzen dieser Attribute erzeugt auch CPU-Last, ob es unter dem Strich weniger Last auf dem System ist, haengt vom Einzelfall ab.
Zitat von: ph1959de am 18 Februar 2016, 12:54:55
Willi, du hast in deinem Post(#5) zweimal die gleich event-min.../event-on... Kombination aufgeführt...
Darüberhinaus: hast Du schon mal mit dem Threshold beim event-on-... experimentiert?
HAbs korrigiert, danke.
Bei event-on-... gibt es als Parameter nur die Namen der betroffenen Readings. Von Threshold sehe ich in der Commandref nichts.
Zitat von: rudolfkoenig am 18 Februar 2016, 13:12:19
Bevor hier was Falsches gelernt wird:
- event-min-interval sorgt dafuer, dass ein Event hoechstens alle X Sekunden (aber nicht haeufiger) durchgelassen wird, generiert aber keine Events.
- event-on-change-reading laesst events nur bei Aenderung durch (optional mit mindest-delta).
- falls event-on-update-reading gesetzt ist, dann werden die nicht spezifizierten events nicht durchgelassen.
- das Wort "reading" ist in beiden Faellen irrefuehrend, da das Reading immer gesetzt wird, nur das Event wird nicht durchgelassen.
- mit durchlassen meine ich: Modul generiert Event, aber keiner kriegt es mit.
- falls event-on-change-reading zuschlaegt, filtert min-interval nicht (aber da bin ich mir nicht ganz sicher, der Code ist relativ verwirrend).
Das Setzen dieser Attribute erzeugt auch CPU-Last, ob es unter dem Strich weniger Last auf dem System ist, haengt vom Einzelfall ab.
Danke für die Erklärung. Dann war ich ja doch richtig.
Mein Versuch mit "event-on-update-reading
.*" ist dann so, als ob ich das Attribut gar nicht gesetzt hätte. Deshalb auch keine Auswirkung.
Das Problem scheint mir hier eher zu sein, dass alleine das "empfangen, weiterreichen ans Modul und Verarbeitung dort" bereits die erhöhte CPU-Last erzeugt. Und das jede Sekunde 1 mal. Mir wäre ein Weg lieber, bei dem die Daten bereits am USB-Port blockiert werden, so dass alle Folgeschritte gar nicht entstehen.
ZitatMein Versuch mit "event-on-update-reading .*" ist dann so, als ob ich das Attribut gar nicht gesetzt hätte. Deshalb auch keine Auswirkung.
Da waere ich nicht so sicher, leider brauche ich immer eine halbe Stunde, bis ich den Code bei Kombination beider Faelle verstehe.
ZitatMir wäre ein Weg lieber, bei dem die Daten bereits am USB-Port blockiert werden, so dass alle Folgeschritte gar nicht entstehen.
Alternativ fuegt man im Modul was zu event-min-interval Vergleichbares ein.
@Rudi: danke für die Klarstellung ... ich werde die Informationen im Wiki zusammenstellen und hoffe, dass damit dann mal völlige Klarheit in Bezug auf diesen Attribut-Satz geschaffen werden kann.
@Willybauss: Sorry, für die Verwirrung, die hier entstanden ist. Sieht so aus, als müsstest Du Dich doch an den Modulautor (icinger) wenden bzw. hoffen, dass der sich hier einschaltet. Vielleicht lässt sich da auf Modulebene was ändern.
Nachtrag zu "threshold":
Zitat von: commandref, event-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created. If an optional [:threshold] is given after a reading name events are only generated if the change is ...
Peter
Zitat von: rudolfkoenig am 18 Februar 2016, 13:38:11
Alternativ fuegt man im Modul was zu event-min-interval Vergleichbares ein.
Ja, sowas hat im OBIS-Thread gerade eben auch Jemand vorgeschlagen: USB-Port nur häppchenweise öffnen. Das muss sich dann der Modulautor ansehen.
Zitat von: ph1959de am 18 Februar 2016, 13:41:07
@Willybauss: Sorry, für die Verwirrung, die hier entstanden ist. Sieht so aus, als müsstest Du Dich doch an den Modulautor (icinger) wenden bzw. hoffen, dass der sich hier einschaltet. Vielleicht lässt sich da auf Modulebene was ändern.
Nachtrag zu "threshold":
Peter
Hi Peter,
kein Problem. Wie bereits erwähnt: die Commandref ist manchmal doch etwas sparsam formuliert und bietet dann Raum für Interpretationen.
Im OBIS Thread bin ich mit icinger bereits in der Diskussion. Ich hatte hier nochmal gefragt, weil es eher nach einer Lösung außerhalb des Moduls aussah.
Ich hatte die deutsche Version der Commandref. Darin taucht natürlich kein "Threshold" auf, sondern ein "Schwelle". Aber ich glaube nicht, dass mir das wirklich helfen würde, denn wie gesagt: wenn Threshold ausgewertet wird ist ja der ganze Ressourcen-fressende Weg schon durchlaufen. Außerdem sehe ich praktisch keine 2 gleichen Werte in den Daten - wäre also wirkungslos.
Zitat von: willybauss am 18 Februar 2016, 13:51:04
Außerdem sehe ich praktisch keine 2 gleichen Werte in den Daten - wäre also wirkungslos.
Genau dafür ist aber doch der Threshold gedacht ... um geringfügige Schwankungen, die eigentlich nicht interessieren, auszublenden. Wenn bei Dir allerdings die Schwankungen größer sind, als der Threshold, den Du maximal setzen würdest, dann hilft es allerdings nicht.
Peter
Hallo,
mit dem Modul SMLUSB hatte ich ein ähnliches Problem: mein über den Volkszähler-Sensor angeschlossene Stromzähler treibt die Last stark nach oben.
Ich konnte das Problem bei mir durch einen sehr kleinen Eingriff entschärfen: die USB-Anbindung der FHEM Module kennt 2 Mechanismen. Unter Linux wird mit Interrupts gearbeitet während unter Windows gepollt wird. Ich hab das Modul bei mir nun auf den Polling-Mechanismus umgestellt, obwohl mein System unter Linux läuft.
Seitdem ist die CPU-Last wieder viel niedriger.
Vielleicht hilft das bei dir ja auch...
Gruß
Leo
Könntest Du bitte genauer Dokumentieren was Du am SMLUSB Modul geändert hast.
Hallo,
im Anhang meine modifizierte Variante des SMLUSB Moduls.
Soweit ich mich erinnern kann, sind die einzige 3 relevanten geänderten Zeilen folgende aus der Methode SMLUSB_DoInit:
delete $hash->{FD};
delete($selectlist{"$name.$dev"});
$readyfnlist{"$name.$dev"} = $hash;
Gruß
Leo
supi, danke Dir ! :)
Danke. Spiel ich gleich mal ein.
Edit:
Funktioniert perfekt. Ich dachte erst FHEM läuft gar micht mehr weil es im 'top' nicht mehr oben aufgefürt war.
Bei mir ebenfalls. Habe jetzt einfach mal Init() und Undef() nahezu 1:1 ins OBIS-Modul übernommen. Ergebnis genau wie bei majorshark: CPU-Last von perl kaum noch erkennbar: 0,7 ... 1%; vorher 6 ... 10%.
DAAAAAANKE!
Habe den Fix jetzt mal an den OBIS-Autor weitergegeben in der Hoffnung, dass er es implementiert.
Nur als Info: ihr habt damit von "Sofortbenachrichtigung via select()" auf "Pollen alle 5 Sekunden" umgestellt. Das Intervall ist kuerzer, wenn andere select()-Verbindungen (USB/TCP/etc) gerade Daten schicken.
Hi limats,
vielen Dank, ich werde den Tip gleich nächste Woche in mein Modul aufnehmen.
MfG
Matzefisi
Auch von mir nochmal ein Nachtrag:
der Autor hat das OBIS-Modul inzwischen genauso upgedatet wie von limats vorgeschlagen. Bei mir läuft das neue Modul seit einigen Tagen fehlerfrei im Test. Ich gehe davon aus, dass er es demnächst einchecken wird, falls nicht bereits geschehen.
Beim OBIS ist das optional........Eingechekt wird heute abend, sobald ich meinen Entwickler-Laptop wieder habe ^^
Zitat von: Icinger am 28 Februar 2016, 14:38:05
Beim OBIS ist das optional.......
Könntest Du bitte erklären, weshalb man beide Modi alternativ verwenden muss? Ich habe Rudolfs Erklärung nicht so recht verstanden, war mir zu kurz.
Nicht MUSS....Du kannst entweder/oder verwenden.
Im Normalfall wird das Modul in dem Moment über neue Daten an der Schnittstelle informiert, in dem die tatsächlich ankommen. -> Sofortbenachrichtigung -> quasi Echtzeit
Beim Pollen schaut FHEM nur ca. alle 5 Sekunden, ob Daten anliegen, und informiert dann das Modul.
Somit kannst du also auch mal 5 Sekunden alte Daten haben, weil die zB ein paar Milisekunden nach dem letzten Poll angekommen sind.
Hoffe, das is so verständlich?
Zitat von: Icinger am 28 Februar 2016, 18:55:57
Nicht MUSS....Du kannst entweder/oder verwenden.
Ja, klar. Meine Frage war an dieser Stelle blöd formuliert.
So habe ich es nun verstanden, danke. Das ist für mich aber gar kein Problem, da ich ja ohnehin nur alle 60 Sekunden einen Wert haben möchte. Deshalb würde für mich sogar ein pollen alle 60 Sekunden ausreichen. Aber da das offenbar keine Auswirkungen mehr auf die CPU-Last haben würde ist es mir grade wurscht, ob alle 5 oder 60 Sekunden gepollt wird.
So, im SMLUSB Modul ist der optionale pollingMode nun auch hinterlegt. Vielen Dank an Euch für den Tip und an Icinger für die Vorarbeit im OBIS Modul :)
Hallo!
Kann mir jemand hier Beantworten wie ich mit z.B. event-on-change-reading und einen Parameter Werte "größer als" extrem Ausreißer verwerfen kann.
Habe die Frage in anderer Form schon im Forum gestellt. Leider keine Antwort.
Leider liefern manche Sensoren manchmal extreme Werte, die z.B. bei Heizungssteuerung fatal sind, und im Plott nicht schön aussehen.
2016-05-09_17:38:18 DS2 T: 16.187
2016-05-09_17:38:19 DS3 T: 21.125
2016-05-09_17:43:21 DS1 T: 127.687
2016-05-09_17:43:25 DS2 T: 16.187
2016-05-09_17:43:26 DS3 T: 21.187
2016-05-09_17:48:25 DS1 T: 17.75
2016-05-09_17:48:29 DS2 T: 16.187
2016-05-09_17:48:30 DS3 T: 21.187
2016-05-09_17:53:30 DS1 T: 17.687
2016-05-09_17:53:33 DS2 T: 16.187
2016-05-09_17:53:34 DS3 T: 21.062
2016-05-09_17:58:34 DS1 T: 127.687
2016-05-09_17:58:38 DS2 T: 16.187
2016-05-09_17:58:38 DS3 T: 21
2016-05-09_18:03:38 DS1 T: 127.687
2016-05-09_18:03:42 DS2 T: 16.187
lg
Wolfgang
Ich kann noch nicht nachvollziehen, wozu das gut sein soll. Wenn der Sensor die Werte korrekt misst und sie dann so hoch sind, dann ist das doch das Ziel eines Monitorings. Wenn Du eine Grafik willst, die nicht die Wirklichkeit abbildet, dann ist die ganze Monitorerei sinnlos.
Du kannst natürlich, anstatt die Readings zu loggen, ein userReading bauen und loggen, das jeden gemessenen Wert analysiert und bei entsprechend hoher Abweichung vom vorigen Wert die Zahl z.B. durch die des vorigen Readings ersetzt. Dazu brauchst Du eine Dummy-Variable für die Zwischenspeicherung des vorigen Wertes, sowie eine Art von if-then-else im userReading. Dazu könnte das DOIF-Modul hilfreich sein.
Aber wenn die HEizungssteuerung auf Ausreißer komisch reagiert, dann wäre die korrekte Variante so, dass Du in der HEizungslogik ein solches DOIF implementiertst und im OBIS-Modul die korrekt gemessenen Werte auch genau wie gemessen loggst.
Ich hab zwar keine Ahnung, was ein Onewire-Fehlerwert mit OBIS hier zu tun hat, aber einfach ein Userreading machen, bei dem du das "85" rausfilterst.
Und halt einfach dann der Wert des Userreadings loggen. Dann brauchts auch keine Dummy-Variable.
lg, Ici