hohe CPU-Last durch Stromzähler, der dauernd Daten pusht

Begonnen von willybauss, 18 Februar 2016, 10:03:12

Vorheriges Thema - Nächstes Thema

willybauss

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).
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

ph1959de

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
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

dev0

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

willybauss

#3
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.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

ph1959de

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 schon mal ausführlich diskutiert worden).

Also: wie sind bei Dir ...-on-change und ...-on-update gesetzt?
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

willybauss

#5
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?
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

ph1959de

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?
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

rudolfkoenig

#7
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.

willybauss

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.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

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.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

rudolfkoenig

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.

ph1959de

@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
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

willybauss

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.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

willybauss

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.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

ph1959de

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
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"