[OBIS V2] - Jetzt auch mit SML-Unterstützung

Begonnen von Icinger, 08 April 2016, 19:54:44

Vorheriges Thema - Nächstes Thema

Elektron

Hallo zusammen,

Kann es sein, dass seit einem der letzten Updates das Attribut Intervall nich mehr funktioniert?
Hatte das bisher auf 15 stehen und bekam alle 15 Sekunden einen Wert.
Nun bekomme ich auf einmal jede Sekunde einen Wert obwohl ich nichts geändert habe.

Vielen Dank und Grüße
Michael

gvzdus

Hast Du pollmode auf "on"?
Es war vorher inkonsistent, jetzt ist es konsistent:

Intervallpollen nur, wenn pollmode auf "on" ist *und* ein Interval gesetzt ist.

Elektron

Hallo,

Top, das war's.

Vielen Dank und Grüße
Michael

papa

Ich habe jetzt auch mal die aktuelle Version ausprobiert. Bisher hatte ich immer "interval=30" und "pollingMode=on". Beide Attribute habe ich gelöscht und event-aggregator wie folgt definiert "power:30:linear:mean,total_consumption:30:none:v,total_feed:30:none:v". Es gibt auch ein Event alle 30 Sekunden. Soweit so gut .... leider habe ich jetzt auf dem Bananpi immer ca. 60% CPU Last durch den FHEM-Perl-Prozess. Vor dem Update des Modules war er eigentlich immer im Idle. Meine Vermutung ist jetzt, dass das Parsen der Daten die ganze CPU-Zeit benötigt - es kommen ja ca. alle 2 Sekunden neue Daten rein.
Hat jemand eine Idee, ob man das reduzieren kann ? Braucht das Parsen wirklich so viel Zeit ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

gvzdus

Zur Not gehe auf jeden Fall wieder zurück. Der Parser ist brilliant und effizient geschrieben, sagt der Autor :-)
Im Ernst: Ich kann mir eigentlich nicht den Parser als Problem vorstellen, für wahrscheinlicher halte ich den Overhead des "Einsammelns" eines Paket. Du könntest versuchen, ob man irgendwie die Blockgröße beim Lesen vom seriellen Port erhöhen kann (ich weiß aber nicht wie). Bei meinem Raspi 3 ist die Load mit sekündlichem Updateinterval vielleicht um die 5-10%.

papa

Hm - mit so einer Antwort hatte ich gerechnet. Werde mal (wenn Zeit vorhanden) ein leeres FHEM aufsetzen und nur den Zähler anlegen. Mal sehen, wie dann die CPU-Load aussieht.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

gvzdus

Du könntest auch mal mit "strace" gucken, wie viele "reads" erfolgen.

Bei mir:
strace -p [pid von fhem] > log 2>&1
nach 10 Sekunden abgebrochen.
Dann log durchgeguckt, und festgestellt, dass die read-Zeilen auf FD 43 die vom OBIS-Zähler sind.

Davon habe ich 191 in den (etwa) 10 Sekunden. Es werden typischerweise 14-16 Bytes gelesen:
read(43, "\0\2\10\1\377\1\1b\36R\377Y\0\0", 4096) = 14
read(43, "\0\0\1\336\312\306\1w\7\1\0\2\10\2\377\1", 4096) = 16
read(43, "\1b\36R\377Y\0\0\0\0\0\0\0\0\1w", 4096) = 16
read(43, "\7\1\0\20\7\0\377\1\1b\33R\0U\0", 4096) = 15


Pi mal Daumen habe ich also knapp 20 Leseoperationen inkl. des großen FHEM-"select", bis der Parser "ran darf". Daher meine Vermutung, dass das Zusammenklauben und der Vollständigkeitscheck eher teuer sind, nicht das Parsen. Wenn Du bei Dir noch kleinere Pakete sehen solltest, wäre eben ein größerer Buffer vielleicht hilfreich.

papa

ich schau mir das mal mit einem separaten Setup an.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Das sieht hier ganz übel aus

read(5, "\7", 255)                      = 1
read(5, "\1\0", 255)                    = 2
read(5, "`", 255)                       = 1
read(5, "Z", 255)                       = 1
read(5, "\2\1", 255)                    = 2
read(5, "\1", 255)                      = 1
read(5, "\1\1", 255)                    = 2


Hat jemand ne Idee, wie ich es schaffe, die Anzahl der Byte pro Read zu erhöhen ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Nighthawk

Hallo zusammen,

auch bei mir (Raspberry 4B mit 4GB RAM) ist die Systemlast in letzter Zeit deutlich auf ~60% gestiegen (hatte nach längerer Zeit mal wieder ein Update durchgeführt).
Vorher hatte ich die definition mit intervall 30 ohne das pollingMode Attribut.
Deaktiviere ich OBIS, geht die Systemlast auf idle zurück.
aktiviere ich das attr pollingmode, geht die Systemlast auf ~20% zurück, lösche ich beide Attribute (intervall und pollingmode), so steigt die Systemlast wieder auf ~60%.
Das attr event-aggregator sieht bei mir folgendermaßen aus:
power:30:linear:mean,power_L1:30:linear:mean,power_L2:30:linear:mean,power_L2:30:linear:mean,total_consumption:30:none:v

Wie bekomme ich die Systemlast wieder auf ein annehmbares Niveau runter?

Gruß
Alex

gvzdus

Ist es vielleicht bei Dir auch ein "Micro-Read" (Byteweise?).
Ich habe am Freitag (nach Deinem Posting) mein Raspian Buster und FHEM auf den letzten Stand gebracht. Obwohl meine CPU deutlich schwächer ist (Raspi 3B) und mein Stromzähler quasi sekündlich inkl. 3 Phasen raushaut, liege ich bei < 15% - mit riesiger Eventverarbeitungskette.

Guck' Dir bitte mal mein Posting vom 25.04. (gleiche Seite) an... Allerdings ist das Pimpen des Bufferings nicht mein Knowhow-Gebiet.

Nighthawk

Sieht ganz so aus.
Wie bekomme ich das in den Griff?

read(10, "729.82924505*kWh)\r\n1-0:16.7.0*25"..., 255) = 39
read(41, "", 256)                       = 0
read(10, "3.2", 255)                    = 3
read(10, "6", 255)                      = 1
read(10, "*", 255)                      = 1
read(10, "W", 255)                      = 1
read(10, ")", 255)                      = 1
read(10, "\r", 255)                     = 1
read(10, "\n", 255)                     = 1
read(10, "1-", 255)                     = 2
read(10, "0", 255)                      = 1
read(10, ":", 255)                      = 1
read(10, "3", 255)                      = 1
read(10, "6", 255)                      = 1
read(10, ".", 255)                      = 1
read(10, "7", 255)                      = 1
read(10, ".", 255)                      = 1
read(10, "0", 255)                      = 1
read(10, "*", 255)                      = 1
read(10, "2", 255)                      = 1

papa

Meine letzte Idee war ser2net zwischen zu schalten. Da kann man per dev-to-net-bufsize Option die Größe des Readpuffer bestimmen. Leider ist bei meiner Uraltdistro diese Option noch nicht verfügbar. Aber vielelicht ist das für Dich eine mögliche Lösung.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Nighthawk

Ist für mich leider, zumindest im Moment ebenfalls keine Lösung da ich mich knapp 9000km von dem Zähler entfernt aufhalte ;-)

gvzdus

ser2net ist eine Software :-)

Läuft bei mir normalerweise statt der direkten /dev/... - Konfiguration in FHEM, weil ich so auch mit meinem Test-Raspi gleichzeitig den OBIS-Zähler auslesen kann (2 FHEM-Instanzen auf 2 Raspis, aber nur ein Lesekopf am ersten Raspi).