LBS: SML-Reader

[toggle]

Es sieht in der Tat merkwürdig aus. Man kann Softwarefehler nie ausschließen, aber eine Erklärung für diese Werte hätte ich nicht. Denn die empfangenen Binärdaten bestehen aus einem Basiswert und einem Multiplikator, der in der Regel 1 (10⁰) oder 0,1 (10^-1) ist. Würde der Parser im Datenstrom "verrutschen", hätte es hochstwahrscheinlich mehrere Sprünge mit variierenden Werten gegeben. Wenn ich mich nicht täusche, ist im Diagramm Verbrauch in Wattstunden dargestellt. Und die Werte 3421000-3448000 liegen nicht in einem Bereich, wo ich einen Überlauf erwarten würde. Auch das Delta von ca. 20000 ist keine typische 2er Potenz. Ein Vertauschen von OBIS-Werten als Ursache wäre nur dann denkbar, wenn der Zähler mehrere Tarife verwaltet, die mehr oder weniger im Gleichtakt hochlaufen.

Wenn es öfters vorkommt, bitte die Binärdaten aufzeichnen, ich würde sie analysieren. Es wäre auch interessant zu wissen, was der Zähler zum gleichen Zeitpunkt anzeigt.

[Glotzkowski]

Für ca 2h kommen die Daten einfach mit einem negativen Offset an. Verschwindet einfach wieder.

Interessant, dass Du dies erwähnst, da ich dies letztes Jahr und davor auch schonmal exakt so
festgestellt hatte.
Ich werde heute nochmal ein Diagramm konfigurieren und nachsehen.

[Glotzkowski]

Es wäre auch interessant zu wissen, was der Zähler zum gleichen Zeitpunkt anzeigt.

Ich meine mich zu erinnern, dass der Zähler (digital) tatsächlich kurzzeitig rückwärts gelaufen ist und einen kleineren Wert anzeigte, als er bereits erreicht hatte.

[Ing-Dom]

Es wäre auch interessant zu wissen, was der Zähler zum gleichen Zeitpunkt anzeigt.

Ich war nicht mal zuhause..
Ich könnte mir aber einen E-Mail Alarm konfigurieren, dann hab ich wenigstens die Chance das festzuhalten.

Glotzkowski bei mir ist es ein ISKRA MT691. Bei dir?

[Ing-Dom]

Wenn ich mich nicht täusche, ist im Diagramm Verbrauch in Wattstunden dargestellt.

korrekt.
Der "Offset" betrug genau 19618,1, davon müsste man aber ~40 abziehen, was dem Verbrauch in der 1sek entspricht.

Ein Vertauschen von OBIS-Werten als Ursache wäre nur dann denkbar, wenn der Zähler mehrere Tarife verwaltet, die mehr oder weniger im Gleichtakt hochlaufen.

nein, ist nur ein Zweirichtungszähler. Das 2.8.0 hat 2-stellige Werte und Nachts passiert da nix (PV).

Basiswert und einem Multiplikator, der in der Regel 1 (10⁰) oder 0,1 (10^-1) ist.

0,1 - Zumindest kommen aus dem Baustein eine Nachkommastelle.

[Glotzkowski]

Glotzkowski bei mir ist es ein ISKRA MT691. Bei dir?

EMH eHZ-I, hab den "Rückwärtsgang" es in den Datenarchiven noch nicht gefunden. Suche morgen nochmal anders.

[Lapheus]

Hallo zusammen,

mein Zähler funktioniert ganz wunderbar mit dem Baustein. Läuft jetzt per Socat Verbindung auf einem Raspi, der beim Zähler sitzt.

Da der Zähler aber ca. alle zwei bis drei Sekunden(!) seine Werte sendet wird jedes mal eine Berechnungskette in Gang gesetzt.
Ich möchte das etwas Zähmen und den Zähler nur Minütlich oder alle fünf Minuten abfragen. Also brauch ich "etwas" das mir im Minuten Takt eine 1/0 generiert, für den Enable Eingang?
Bin auch für andere Ideen offen.

[Ing-Dom]

der Zähler sendet sowieso. Das bisl SML parsen stresst deinen Rechner auch nicht.
Wenn du die Werte nur alle Minuten auswerten willst, dann bau dir mit SystemKO Minütlich, Impulstrigger und Wertauslöser ne Logik hinter den LBS.

[Lapheus]

Ein Timer Baustein hat mir die Lösung gebracht.
"Das bisl SLM parsen" ist bei mir ja nicht alles, da werden Werte in Archive geschrieben. Ich habe es nun mit dem Timer Baustein auf eine Sekunde gestellt und selbst dann liefert der Zähler teilweise zwei Durchgänge.
Wenn das ohne den Timer läuft, ist der Edomi Rechner jede Sekunde mindestens damit beschäftigt drei Werte ins Archiv zu schreiben, meistens zwei oder dreimal drei Werte. Also ich kann die Last auf dem Edomi Rechner schon sehen. Weis nicht ob der Socat Prozess auch noch etwas zieht.
Naja, jetzt mit dem Timer Baustein davor ist es besser. Wenn ich mir mal wieder Zeit nehme kommt der Zähler wieder an den Arduino, aber in der Prioliste stehen da noch andere Dinge zuerst drauf.

[Ing-Dom]

da werden Werte in Archive geschrieben

deswegen habe ich ja empfohlen, nach dem SML LBS die Telegrammrate per SystemKO Minütlich, Impulstrigger und Wertauslöser zu begrenzen.

[Ing-Dom]

Brandaktuell hab ich das Problem mit den falschen Zählerstandswerten! Es dauert an.
Eine Aufzeichnung des Bitstroms hab ich gemacht. Während das Problem auftritt.

Der aktuell vom LBS gemeldete Wert fürs 2.8.0 liegt bei 66719.5 (Wh). Das Display zeigt 84kWh an.

In den Log des LBS läuft nichts rein, trace ist aktiviert.

Eine Projektaktivierung hat nichts verändert.

Soll ich evtl sonst noch was nachschauen, aufzeichnen, kontrollieren, machen, solange der falsche Wert da ist?

2020-02-19 15_41_09-EDOMI · Visualisierung.png

[toggle]

Wenn du mir die Aufzeichnung per PN zukommen lässt, kann ich nachschauen, was drin steht.

Zur Sicherheit - welche Edomi-Version benutzst du? Der Trace-Eingang kann in der hochgeladenen LBS-Version 1.3 leider nur bei LBS-Start aktiviert werden. Aber die Meldung "SmlReader v1.3 started with parameters ..." muss auf jeden Fall zu sehen sein. Es sei denn, die Funktion writeToCustomLog() ist in den Versionen > 1.62 abgeschafft oder umgestaltet worden - dann hätte es wahrscheinlich andere Probleme gegeben.

Wenn der Trace-Eingang bei LBS-Start aktiv war, sollte der Baustein ununterbrochen "blubbern" - bei jeder Message vom Zähler.

[Ing-Dom]

Ich lad die Dateien einfach hier hoch. Sind einfach mit "cat /dev/ttyUSB0 > sml.log" erstellt.

Das mit dem Log war ich. Habs aus Versehen nur Live umgestellt, dann Projekt aktiviert..

So sieht das aktuell aus:

2020-02-19 21:33:41 694896 4930 INFO: OBIS 1-0:96.1.0*255: 0a 01 49 53 4b 00 04 4c f1 06
2020-02-19 21:33:41 695012 4930 INFO: OBIS 1-0:1.8.0*255: 4898870.9
2020-02-19 21:33:41 695091 4930 INFO: OBIS 1-0:2.8.0*255: 67151.1
2020-02-19 21:33:41 695162 4930 INFO: OBIS 1-0:16.7.0*255: 791
2020-02-19 21:33:42 711936 4930 INFO: Read 236 bytes.
2020-02-19 21:33:42 716068 4930 INFO: OBIS 1-0:96.1.0*255: 0a 01 49 53 4b 00 04 4c f1 06
2020-02-19 21:33:42 716182 4930 INFO: OBIS 1-0:1.8.0*255: 4898871.2
2020-02-19 21:33:42 716263 4930 INFO: OBIS 1-0:2.8.0*255: 67151.1
2020-02-19 21:33:42 716331 4930 INFO: OBIS 1-0:16.7.0*255: 798
2020-02-19 21:33:43 725357 4930 INFO: Read 236 bytes.
2020-02-19 21:33:43 729619 4930 INFO: OBIS 1-0:96.1.0*255: 0a 01 49 53 4b 00 04 4c f1 06
2020-02-19 21:33:43 729747 4930 INFO: OBIS 1-0:1.8.0*255: 4898871.4
2020-02-19 21:33:43 729827 4930 INFO: OBIS 1-0:2.8.0*255: 67151.1
2020-02-19 21:33:43 729898 4930 INFO: OBIS 1-0:16.7.0*255: 776

Am Display 2.8.0 steht 86kWh. Bei 1.8.0 4899..

Das ist der SML-Teil auf den es wohl ankommt:

77 07 01 00 02 08 00 FF 01 01 62 1E 52 FF 65 00 0A 2C 39 01

=> 62 1E Einheit Wh
=> 52 FF Prescaler FF = -1 := 10^-1 = 0.1
=> 65 UINT 32
=> 00 0A 2C 39 = 666681
=> 01 Ende

66668,1 Wh

[Ing-Dom]

weiter geht die Forschung.

Der letzte ins Datenarchiv eingetrgene Wert war 85179,5, dann, 1min später, 65544,1. (Das Datenarchiv hat 60s Totzeit).

85179,5 =
00 0C FF 53

65544,1 =
00 0A 00 51

korrekt wäre wohl
00 0D 00 51 = 85204,9 (anhand der parallel abgespeicherten Leistung scheint der Wert plausibel)

von 0C also 0b1100

nach 0D also 0b1101

ging es nach 0A als 0b1010

[toggle]

Ich habe spontan eine Assoziation mit <CR><LF> (0x0D 0x0A). Es wäre nicht auszuschließen, dass die Einstellungen der seriellen Schnittstelle dazu beitragen könnten, dass der Treiber die Zeichen umdeutet/ersetzt. Andererseits hätte ich erwartet, dass so ein Problem viel früher auffalen würde.