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

[gvzdus]

Mir sind zwei Dinge aufgefallen:

• Ja, die Meldungen wie Deine (bzw. ähnliche) habe ich auch sporadisch. Sie sind ziemlich harmlos, aber eben irgendetwas, wo der Parser nicht glücklich ist. Ich werde mal "Langzeit-Mitschneiden", um die zugehörigen Rohdaten zu haben
• Etwas anders: ser2net läuft bei mir nicht besonders stabil mit 2 lesenden Clients. Ich hatte gestern und heute 1-2 Aufhänger. Mit strace stellte ich fest, dass ser2net zwar die TCP-Verbindungen hält, aber nichts mehr sendet. Was ich vermute: Das es unglücklich ist, wenn einer der beiden Clients sich plötzlich verabschiedet und keine Daten mehr annimmt. Denn meinem Test-Raspi wurde ein paar Mal der Strom genommen, sodass es zum unsauberen, einseitigen Ende der Verbindung kam.

[gvzdus]

Ich habe den Fehler (PERL WARNING, substr, u.s.w.) auch im Kasten. Außerdem die älteren Beiträge zum Thema gefunden. Das Ganze ist etwas Kniffeliger und geht ans Eingemachte: Die Message wird in Sequenzen, die mit 7707 beginnen, zergliedert. Kommt nun zufällig 7707 irgendwo "zufällig" vor, wird zu klein gehackt. Dabei ist 7707 obendrein "4bit-weise" zu verstehen, die Sequenz 37 70 73 würde auch matchen.

Etwas Geniales fällt mir nicht ein (ich finde den Code ohnehin schon ziemlich genial in Sachen Regexp-Anwendung). Lösung wäre ein sequentieller Parser, was aber auch wieder Gelegenheit zu vielen Fehlern bei der Implementierung bietet.

Deswegen nehme ich das erst einmal als "Known Bug" und "Todo".

P.S.: Ich habe übrigens die Typos in der Doku gefixt, die abc2006 im Herbst beschrieben hat - rund um die Seite, die papa verlinkt hatte. Ist im SVN, aber vielleicht nicht ganz der ultimative Grund für ein FHEM-Update.

[papa]

Ich habe den Fehler (PERL WARNING, substr, u.s.w.) auch im Kasten. Außerdem die älteren Beiträge zum Thema gefunden. Das Ganze ist etwas Kniffeliger und geht ans Eingemachte: Die Message wird in Sequenzen, die mit 7707 beginnen, zergliedert. Kommt nun zufällig 7707 irgendwo "zufällig" vor, wird zu klein gehackt. Dabei ist 7707 obendrein "4bit-weise" zu verstehen, die Sequenz 37 70 73 würde auch matchen.

Etwas Geniales fällt mir nicht ein (ich finde den Code ohnehin schon ziemlich genial in Sachen Regexp-Anwendung). Lösung wäre ein sequentieller Parser, was aber auch wieder Gelegenheit zu vielen Fehlern bei der Implementierung bietet.

Deshalb hatte ich mit dem extra Parser angefangen.

[gvzdus]

Ja, da steht auch noch die Antwort aus...
Ich bin da etwas im Konflikt:

• Das Ganze auf Binär umbauen? Z.B. gibt es die initiale Prüfung: Habe ich eine komplette Message erhalten? Das wird typischerweise mehrere Read-Optionen umfassen. Da wäre es schneller, binär zu bleiben, statt auf Hex zu konvertieren. Aber der Codeabschnitt funktioniert ja 100%ig
• Dann die "innere Schleife", wo es zur Split-Problematik kommt

Worüber ich nachdenke: Eine Binär-Logfunktion im Modul, um Testdaten zu haben: Etwas wie ein Attribut: "tracefile", dass allen eingehenden Verkehr in eine Datei mitschneidet, die man ggf. für Problemfälle zur Analyse verwenden kann und weniger "verbose" als das Logging im allgemeinen Logfile ist. Das Format müsste m.E. aber zusätzlich einen Zeitstempel und die einzelnen Reads wiedergeben, also kein reiner "cat /dev/ttyUSB0 > file.bin"-Mitschnitt sein. Ich hatte schon einmal geguckt, ob bei Volkszähler da ein Format "erfunden" wurde oder gar Beispiele für Parser-Tests vorhanden sind, habe aber nichts gefunden. Anregungen wären willkommen.

Wie schon geschrieben: Das ist Komplexer als mal eben ein Türmchen ans funktionierende Modul zu bauen.

[Violinux]

seltsamerweise gibts bei mir (ISKRA Zähler MT175 ) anscheinend keine Fehler, außer innerhalb 24Std 2 crc errors. womit ich leben kann.

Habe nun noch eine Frage zum ,,DirektionsByte  < >".
Das Statusbyte ist im diesem Zähler mitgegeben mit
1-0:1.8.0*255(>2282769.2*Wh) Bezug
1-0:1.8.0*255(<2301131.8*Wh) Einspeisung
beschrieben, da anscheinend kein extra Statusbyte anliegt.. Könnte man noch  consum & feedin in implementieren ? 
... ansonsten läuft alles super ohne Fehler. Besten Dank !

[gvzdus]

Das Statusbyte ist im diesem Zähler mitgegeben mit
1-0:1.8.0*255(>2282769.2*Wh) Bezug
1-0:1.8.0*255(<2301131.8*Wh) Einspeisung
beschrieben, da anscheinend kein extra Statusbyte anliegt..

Da muss ich mich noch einarbeiten. Könntest Du mal kurz auf "verbose 5" schalten und das Logfile von ein oder zwei "Zählerstandsübermittlungen" posten?
2 CRC-Fehler finde ich ziemlich normal, obwohl mein Lesekopf 0 produziert.

[Violinux]

anbei 2 Log´s , der erste mit ca 2KW Belastung, der zweite ohne, da ja PV Energie anliegt, das man besser in und out erkennt.

[gvzdus]

So mal als Zwischenstand: Ich habe jetzt eine inoffizielle Debug-Funktion eingebaut (nein, checke ich nicht ein):
Mit

Code Auswählen Erweitern

define <name> OBIS <dateiname mit pfad>
wird ein OBIS device angelegt, das seinen Input aus einer Text-Datei einliest. Und zwar nicht irgendeinem Binär-Format (da hatte ich ja mal drüber nachgedacht), sondern einfach dem FHEM-Logfile-Format. Konkret werden die

Code Auswählen Erweitern

<datum> OBIS (name) - Full message-> ....
Zeilen gelesen und dann den Parse-Funktionen übergeben. Somit kann ich (oder jemand, der sich versuchen möchte) einfach die in verbose 5 erzeugten Logmeldungen in eine Datei packen, ggf. zur Verkürzung auf die "Full Message"-Zeilen filtern, und das Ganze nachspielen. Am Ende wird in "state" des neuen und nutzlosen Devices eine Speed-Statistik ausgegeben. Die ist nicht zutreffend, weil ja der ganze Teil "mehrere Reads zusammensetzen, Checksumme prüfen" nicht abgedeckt ist. Sie eignet sich aber zum Vergleich von Optimierungen im inneren Parser. Mit meinem Test-Raspi, einem 3A+, und den ISKRA-Zähler-Daten (hängt ja auch von der Länge der Nachrichten ab) komme ich übrigens auf 181 Zeilen pro Sekunde. Das wären nur 0,5% der CPU bei einer Nachricht / Sekunde (Achtung, siehe Einschränkung äußerer Parser).

Ziel ist natürlich, Logmeldungen wie die aus dem letzten Beitrag bequem nachspielen und verarbeiten zu können. Oder die auch bei mir beobachteten Fehlermeldungen. Die brauche ich jetzt nur noch in eine Datei zu kopieren und einmal das "define x OBIS /filename" aufzurufen.

Modul anbei für Leute, die spielen wollen und das idealerweise auch nicht auf einem produktiven System tun müssen.

[gvzdus]

Sag mal, Violinux:

Könnte man noch  consum & feedin in implementieren ?

Was meinst Du damit? Konkret sehe ich halt bei Dir, wenn ich die Logzeilen von Dir ins System füttere, die üblichen Angaben:

• total_consumption
• total_feed

Was ist für Dich "consum" & "feedin"?

[Violinux]

hallo gvzdus,

Sag mal, Violinux:
Was ist für Dich "consum" & "feedin"?

Sorry, hatte mich falsch ausgedrückt.
Es wird ja immer 1-0:1.8.0*255(>xxx oder 1-0:1.8.0*255(<xxx 
geloggt, d.h. die Stromrichtung wird mit angegeben. Da wäre es doch prima auch
ein extra Reading zu haben welches standardmäßig "in" bzw. "out" beinhaltet.

[gvzdus]

Du meinst also die "Grundrichtung": Rein oder raus? Aber das ist ja eigentlich direkt das Vorzeichen von "power". Ehrlich gesagt: Das ist mir zu trivial als Reading, zumal ich es entweder für andere Zähler dann simulieren müsste, oder es spezifisch für den Zähler ist.

Ich wünsche mir schon, dass mehr Folgeskripte ausgetauscht werden können, und dafür ist es m.E. am besten, wenn "power" und "total_consumption" die "Einheitswerte" sind, plus "total_feed" für die Solaranlagenleute wie mich.

Für eine sinnvolle Steuerung muss man eh noch viel Logik aufsetzen. Bei mir geht "power" in ein Notify, was zunächst einen Satz dummys mit 0 oder 1 befüllt: "plus50", "plus100", "plus500" u.s.w. Darauf hängen wiederum Watchdogs wie "strom100plusisstable120" für 120 Sekunden stabil über 100 Watt Überschuss. Und diese Watchdogs schalten dann Verbraucher an, und bei "strom50minusisstable100" z.B. nach 100 Sekunden mit mehr als 50 Watt Netzbezug wieder aus.

Was willst Du mit der nackten "Direction" anfangen?

[Violinux]

gut, das wir darüber gesprochen haben. Du hast mich wieder auf den richtigen Weg gebracht, das mit den dummys und watchdog ist genial.
Besten Dank.

[gvzdus]

"Genial" weiß ich nicht. Ich beobachte viel, wie sich so das Regeln verhält. Generell schalte ich z.Zt. Verbraucher (TK-Truhe, HK-Pumpe und jetzt endlich auch das E-Auto) ein, wenn 1-2 Minuten der Überschuss vollumfänglich anliegt, und schalte sie nach 30-60 Sekunden deutlicher Unterdeckung aus. Mit dem Ausschalten versuche ich, dass z.B. der Kaffeevollautomat kein Abschalten auslöst: Dessen Aufheizperioden liegen < 60 Sekunden. Dagegen ist die Waschmaschine mit ihrem Grundmuster "Trommel drehen, Pause" das Gegenbeispiel: Alles < 60 Sekunden, aber soll jetzt abgeschaltet werden oder nicht? Außerdem ist das grundsätzlich nach der Maxime "Alles oder nichts": Voller Überschuss, um einzuschalten. Wenn ich aber weiß, dass ich jetzt noch 1 kW billigen Solarüberschuss mitnehmen kann, wenn ich 1 kW dazukaufe, um auf 2 kW zu kommen, ist es schlauer, das ab Nachmittag eher früher zu tun: Ein Später wird es nicht geben.

Aber da wird es echt kompliziert und fallspezifisch. Heute habe ich den ID.3 auf 85% geladen - am Ende unter Zukauf von 1 kW bei 1 kW Solarberschuss - weil es morgen mau werden wird. Ich weiß aber selber nicht, ob es nicht klüger wäre, den Wagen die nächsten 1-3 Tage halt auf 20% runterzufahren und auf die nächsten sonnigen Tage zu warten, wo ich mit 100% Solarüberschuss laden kann.
Ich wüsste gerne, wie da die Algorithmen vom HomeManager von sma oder E3DC sind. Falls jemand Literatur kennt: Ich wäre sehr interessiert.

E-Auto macht aber echt Spaß! Ich werte schon lange Autarkie und Nutzungsgrad aus: Ich würde sagen, man sieht, seit wann der ID.3 da ist (Standort: Grevenbroich):

Code Auswählen Erweitern

Econs = Stromverbrauch (kWh) des Haushaltes
Enet = davon aus dem Netz bezogen
Esol = davon Eigenverbrauch Solar
Esolt = Gesamterzeugung Solarpanel
Autark = Autarkiequote
Usage = Eigennutzungsanteil des Solarstroms

Date       Econs  Enet   Esol   Esolt  Autark  Usage
2021-02-01 11.194  8.178  3.016  4.325   26.9%  69.7%
2021-02-02  9.880  7.322  2.558  3.514   25.9%  72.8%
2021-02-03 10.390  8.149  2.240  3.833   21.6%  58.5%
2021-02-04 10.601  5.324  5.277 16.236   49.8%  32.5%
2021-02-05 12.908  8.230  4.677  6.900   36.2%  67.8%
2021-02-06 12.165  9.912  2.253  2.427   18.5%  92.8%
2021-02-07  7.756  7.558  0.198  0.199    2.6%  99.6%
2021-02-08 15.028 14.691  0.337  0.339    2.2%  99.6%
2021-02-09  9.509  6.530  2.979  8.668   31.3%  34.4%
2021-02-10 11.774  7.606  4.168 16.077   35.4%  25.9%
2021-02-11 12.446  7.349  5.097 18.316   41.0%  27.8%
2021-02-12 10.268  6.624  3.644 20.584   35.5%  17.7%
2021-02-13 16.200  5.518 10.682 21.125   65.9%  50.6%
2021-02-14 18.503  4.421 14.082 20.836   76.1%  67.6%


[hdgucken]

"Genial" weiß ich nicht. Ich beobachte viel, wie sich so das Regeln verhält. Generell schalte ich z.Zt. Verbraucher (TK-Truhe, HK-Pumpe und jetzt endlich auch das E-Auto) ein, wenn 1-2 Minuten der Überschuss vollumfänglich anliegt, und schalte sie nach 30-60 Sekunden deutlicher Unterdeckung aus. Mit dem Ausschalten versuche ich, dass z.B. der Kaffeevollautomat kein Abschalten auslöst: Dessen Aufheizperioden liegen < 60 Sekunden. Dagegen ist die Waschmaschine mit ihrem Grundmuster "Trommel drehen, Pause" das Gegenbeispiel: Alles < 60 Sekunden, aber soll jetzt abgeschaltet werden oder nicht? Außerdem ist das grundsätzlich nach der Maxime "Alles oder nichts": Voller Überschuss, um einzuschalten. Wenn ich aber weiß, dass ich jetzt noch 1 kW billigen Solarüberschuss mitnehmen kann, wenn ich 1 kW dazukaufe, um auf 2 kW zu kommen, ist es schlauer, das ab Nachmittag eher früher zu tun: Ein Später wird es nicht geben.

Aber da wird es echt kompliziert und fallspezifisch. Heute habe ich den ID.3 auf 85% geladen - am Ende unter Zukauf von 1 kW bei 1 kW Solarberschuss - weil es morgen mau werden wird. Ich weiß aber selber nicht, ob es nicht klüger wäre, den Wagen die nächsten 1-3 Tage halt auf 20% runterzufahren und auf die nächsten sonnigen Tage zu warten, wo ich mit 100% Solarüberschuss laden kann.
Ich wüsste gerne, wie da die Algorithmen vom HomeManager von sma oder E3DC sind. Falls jemand Literatur kennt: Ich wäre sehr interessiert.

E-Auto macht aber echt Spaß! Ich werte schon lange Autarkie und Nutzungsgrad aus: Ich würde sagen, man sieht, seit wann der ID.3 da ist (Standort: Grevenbroich):

Code Auswählen Erweitern

Econs = Stromverbrauch (kWh) des Haushaltes
Enet = davon aus dem Netz bezogen
Esol = davon Eigenverbrauch Solar
Esolt = Gesamterzeugung Solarpanel
Autark = Autarkiequote
Usage = Eigennutzungsanteil des Solarstroms

Date       Econs  Enet   Esol   Esolt  Autark  Usage
2021-02-01 11.194  8.178  3.016  4.325   26.9%  69.7%
2021-02-02  9.880  7.322  2.558  3.514   25.9%  72.8%
2021-02-03 10.390  8.149  2.240  3.833   21.6%  58.5%
2021-02-04 10.601  5.324  5.277 16.236   49.8%  32.5%
2021-02-05 12.908  8.230  4.677  6.900   36.2%  67.8%
2021-02-06 12.165  9.912  2.253  2.427   18.5%  92.8%
2021-02-07  7.756  7.558  0.198  0.199    2.6%  99.6%
2021-02-08 15.028 14.691  0.337  0.339    2.2%  99.6%
2021-02-09  9.509  6.530  2.979  8.668   31.3%  34.4%
2021-02-10 11.774  7.606  4.168 16.077   35.4%  25.9%
2021-02-11 12.446  7.349  5.097 18.316   41.0%  27.8%
2021-02-12 10.268  6.624  3.644 20.584   35.5%  17.7%
2021-02-13 16.200  5.518 10.682 21.125   65.9%  50.6%
2021-02-14 18.503  4.421 14.082 20.836   76.1%  67.6%


Das mit dem E-Auto regelt mein E3DC S10E  Da kann man einige Dinge zu einstellen: Sonnenmodus (Laden aus PV-Überschuss) oder normales laden, wenn kein PV-Überschuss vorhanden.
Man kann 1-phasiges oder 3-phasiges Laden auswählen und die max. Stromstärke zum laden einstellen. Man kann vorgeben, ob der Hausakku oder der Fahrzeugakku priorität beim Laden mit PV haben soll
und ob der Hausakku vom Fahrzeug entladen werden darf oder nicht. Dann gibt es noch die Möglichkeit, festzulegen, wie lange das Fahrzeug mit dem Mindeststrom (6A) weiterladen soll, wenn kein PV-Überschuss mehr vorhanden ist, ehe es abschaltet. Zeiten, in denen das Fahrzeug geladen werden darf, lassen sich ebenfalls einstellen. Alles in allem eine super Sache, das S10E von E3DC 
Die Wallbox stammt übrigends von Wallbe, auf E3DC gelabelt. Beide lassen sich über ModBus TCP auslesen, also problemlos in FHEM zu integrieren.
Im Moment steuere ich unsere Wärmepumpe so, dass die Warmwasser-Aufbereitung von 50 auf 55 Grad Celsius angehoben wird, wenn die PV-Anlage in die >70% Abregelung geht.
Ich fahre seit März 2019 elektrisch und kann Dir nur zustimmen, es macht richtig Spaß 

[ioT4db]

...
Ich wüsste gerne, wie da die Algorithmen vom HomeManager von sma oder E3DC sind. Falls jemand Literatur kennt: Ich wäre sehr interessiert.
...

oh ja, daran wäre ich auch interessiert. Ich suche schon länger nach einer Möglichkeit eine eigene Prognose berechnen zu können...

VG