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

[Funnel]

Ich habe mal die Version von heute installiert, nach ca. 20 Minuten hatte ich den von dir beschriebenen Fehler (100%CPU).

[gvzdus]

Okay, dann war es wohl nicht der Parser (OBIS_Parse_List), sondern liegt noch außen drum herum. Dann ziehe ich erst mal das Ganze zurück und melde mich, wenn ich zumindest den nächsten Bug identifiziert habe.

Danke!

[gvzdus]

Ich denke, beides ist identifiziert und behoben:

• Die Meldung "substr outside..." kam, wenn im Input-Buffer ein endTag vor dem startTag von SML war. Reproduziert und behoben
• Man soll nie sagen: "Das war der letzte Bug". Aber ich konnte die "100% CPU" verifizieren, wenn ein CRC-Fehler auftritt. Stupid like that - wurde in der Schleife nicht sauber behandelt.

Anbei die natürlich beste Version aller Zeiten

[Funnel]

Die neueste Version ist jetzt über Nacht gelaufen, bisher keine Auffälligkeiten.

[stefanru]

Ok ich teste auch mal die neue Version und gebe Rückmeldung.

Danke,
Stefan

[gvzdus]

Ja, bei mir ist auch alles friedlich mit der aktuellen Version.

[stefanru]

Sorry ich hätte noch eine kurze Dummy Frage.

Ich nutze zur Zeit pollingmode = on und intervall = 2.
Was ist denn sinnvoller pollingmode off oder on?

Ich will eigentlich schon die aktuellen Daten live sehen.
Die Einstellung hatte ich gemacht da ich dachte damit die Last zu reduzieren.

Was wäre denn eure Empfehlung?

Ich habe zwei EMH SmartMeter die sekündlich Werte liefern an einem ESP8266 der das über zwei Serial Ports (pro Zähler einen) weiter gibt.

Gruß,
Stefan

[gvzdus]

Ausschalten! (Interval löschen, pollingMode off).

Zunächst mal hast Du den ganzen Overhead des Internal-Timers. Zweitens liest Du zu einem undefinierten Zeitpunkt, Du kannst also nicht sinnvoll mitteln. Wie ich schon schrieb: Zumindest bei mir entsteht die CPU-Last in der *Weiterverarbeitung* der Ergebnisse. Diese Last kann man viel genauer und besser mit event-aggregator auf dem Reading reduzieren.

Pollingmode ergibt m.E. erst ab allermindestens 1 Minute, besser 5 Minuten Sinn, und dann nur, wenn Du die "Momentanleistung" als

Code Auswählen Erweitern

(Neuer-Zählerstand - alter-Zählerstand)/Zeit
bestimmst. Da die Genauigkeit i.d.R. 0,1 Wh ist, ergibt sich bei minütlicher Auswertung eine Messgenauigkeit von 6 Watt, bei 5 Minuten von gut 1 Watt.

[stefanru]

Ok, danke hab es abgeschaltet.

Daten flutschen jetzt wirklich schnell.

Hab jetzt aber ziemlich oft CRC Fehler, vielleicht alle 3 bis 5 Sek einen.

Könnte aber an meinem Setup liegen, da ich die 2 Zähler mit einem ESP Auslese.
Das schaue ich mir bei Gelegenheit mal an.

Es kommen auf jeden fall sauber Daten durch.

Danke und Gruß,
Stefan

[gvzdus]

Ich würde auf unterschlagene Bytes tippen. Wenn Du mit "tcpdump" mitschneidest, sollte man das ja eingrenzen können. Auch ohne händische Analyse der SML-Bytes: Wenn Du 10 "Mess-Intervalle" als Hex untereinanderlegst, wird man das vermutlich erkennen können.

[stefanru]

Ok, danke werde ich mal probieren.

Gruß,
Stefan

[Icinger]

Zunächst mal hast Du den ganzen Overhead des Internal-Timers. Zweitens liest Du zu einem undefinierten Zeitpunkt, Du kannst also nicht sinnvoll mitteln.

Zu 1) Es gibt durchaus Zähler, die nicht von selbst senden, da macht Polling-Intervall absolut Sinn (zB meiner)
Zu 2) Mittels dem Attribut allignTime hat man danach sehr wohl ienen definierten Zeitpunkt, an dem gelesen wird.

Aber ja, wenn der Zähler von selbst sendet, hat pollingMode absolut keinen Sinn.

[gvzdus]

Moin, das "undefinierter Zeitpunkt" bezog sich auf so kurze Intervalle wie 2 Sekunden. Wenn die Werte "etwa sekündlich" kommen, hat man mit "etwa alle 2 Sekunden lesen" so ziemlich schlechteste Voraussetzungen, die Messwerte als äquidistante Zeitreihe zu interpretieren, weil zwischen 0 und 0,999 Sekunden der Zufallsfehler ist.

[stefanru]

Hi,

danke für den Input. Meine Zähler sendet ja insofern bin ich froh über den Tipp.

ich hab jetzt mal tcpdump angeworfen.
Werde aber nicht wirklich schlau daraus.

Code Auswählen Erweitern

tcpdump port 23 and src 192.168.69.45
ergibt:

Code Auswählen Erweitern

21:52:36.680271 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 1911301:1911406, ack 3335575270, win 5840, length 105
21:52:36.690494 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 105:116, ack 1, win 5840, length 11
21:52:36.700613 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 116:126, ack 1, win 5840, length 10
21:52:36.717293 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 126:139, ack 1, win 5840, length 13
21:52:36.731810 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 139:155, ack 1, win 5840, length 16
21:52:36.741803 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 155:165, ack 1, win 5840, length 10
21:52:36.752434 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 165:175, ack 1, win 5840, length 10
21:52:36.761343 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 175:184, ack 1, win 5840, length 9
21:52:36.770202 IP 192.168.69.45.telnet > 192.168.69.94.51272: Flags [P.], seq 184:193, ack 1, win 5840, length 9

usw.

wenn ich

Code Auswählen Erweitern

tcpdump -q -w output.dump 'port 23 and src 192.168.69.45'
Ist das dumpfile aber auch nicht besser:

Code Auswählen Erweitern

Ôò¡            
   "ÔK`Oa
Ÿ   Ÿ   ²åM·QORd+
M E  'Q  þ_zÀ¨E-À¨E^ ÈH *ÆÐÖæPÐæ  



vtümb b rc

v
ÿÿÿÿÿÿ
|T%

EMH  "5rb
e
|UÒb
c© vtünb b rc
wÿÿÿÿÿÿ

EMH  "5
b
ÿÿrb
e"ÔK`>‰
A   A   ²åM·QORd+
M E  3Q  þ_×À¨E-À¨E^ ÈH *nÆÐÖæPÐôK 
|UÒww
`2"ÔK`Å°
@   @   ²åM·QORd+
M E  2Q  þ_×À¨E-À¨E^ ÈH *yÆÐÖæPЧؠ





EMH"ÔK`íñ
C   C   ²åM·QORd+
M E  5Q  þ_ÒÀ¨E-À¨E^ ÈH *ƒÆÐÖæPÐñ€ 
w
`
ÿ



"ÔK`¢* F   F   ²åM·QORd+
M E  8Q  þ_ÎÀ¨E-À¨E^ ÈH *ÆÐÖæPÐ~v  

EMH  "5
w
"ÔK`«Q @   @   ²åM·QORd+

usw.

Wie genau muss man das denn auswerten, bzw aufrufen um Zeilen vergleichen zu können?

Danke und Gruß,
Stefan

[gvzdus]

Okay, andere Strategie: Prüfe, ob das Paket netcat installiert ist. Dann

Code Auswählen Erweitern

netcat <ip> <port> | od -A none -tx4

Guck' Dir kurz den Wikipedia-Artikel zu SML an: https://de.wikipedia.org/wiki/Smart_Message_Language
Du siehst: Jeder Block sollte eine durch 4 teilbare Anzahl Bytes haben.

Typischerweise wird Dein Output vom Kommando oben mit "1b1b1b1b 01010101 " anfangen, und das leitet jede Nachricht ein. Wenn dieses 1b1b1b1b im Laufe der Zeit "verrutscht", also zu einem "xxxx1b1b 1b1bxxxx" wird, fehlen Bytes.