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

[willybauss]

Schau mal hier  https://forum.fhem.de/index.php/topic,51948.msg584868.html#msg584868

Derselbe Zähler, auch das Problem klingt ähnlich.

Evtl. kannst Du erst mal mit "interval" oder "event-min-interval" die unnötigen Einträge unterdrücken. Kommen denn irgendwann auch wieder "richtige" Werte?

[parabacus]

Servus Willy - ..und ein gutes Neues!!!

das Attribut interval hab ich ja gesetzt - zum Testen auf 10 Minuten und nachdem ich das beschriebene Verhalten mehrfach festgestellt hab und dann auch mal bisschen feiern wollte  , hab ich's auf 8h gestellt. Die Kontrolle heute früh zeigte dann identisches Verhalten. Es beginnt mit dem korrekten Werten und dann folgt das Runterzählen - bis eben Null.
Beim nächsten Aufruf dann wieder das gleiche Spiel.

Leider hab ich jetzt grad keine Zeit mehr - vielleicht heute Abend wieder ein Test.
Jetzt war mir mal das automatische tägliche Sichern der kompletten FHEM-Installation auf dem NAS-Backup-Share wichtiger... :-) - tut auch schon...

Ciao
Tom

[parabacus]

Mein Problem scheint tatsächlich das selbe zu sein, das tatu123 im Februar '17 geschildert hat.
https://forum.fhem.de/index.php/topic,51948.msg584868.html#msg584868

Jetzt ist mir auch klar, warum am Ende dann Null steht! In den nächsten Monaten würde dann einer der anderen Werte stehen. Den Zähler haben wir noch keine 15 Monate und daher ist im letzten Eintrag noch eine Null, da der Historienspeicher max. 15 Monate zurückreicht, wie tatu123 beschreibt und auch so im Datenblatt nachzulesen ist.

https://www.newfound-energy.co.uk/wp-content/uploads/2014/11/mt174.pdf

2.8.3. Data downloaded via optical port
Data downloaded via an interface (optical port or RS485 interface) are identified with OBIS (OBject Identification System) codes in compliance with IEC 62056-61 standard. On request the data identification
codes can be EDIS (Energy Data Identification System) in compliance with DIN43863, Part 3 standard. On request, historical data for previous billing periods, besides data for a current billing period, can be also downloaded via the optical port and an interface (if it is built-in). Historical data can be downloaded for maximum 15 last billing periods.

Das wäre also schon mal plausibel!
Scheinbar ist es optional, diese Daten über das Protokoll auszulesen. Leider habe ich auf die Schnelle nicht die Protokoll-Spezifikation gefunden (bzw. nur auf dem IEC-Dokumenten-Server und nicht kostenlos). Vielleicht gibt's sogar ein entsprechendes on/off-Bit im Protokoll?

Den Workaround, den Icinger (Stefan) gemacht hat https://forum.fhem.de/index.php/topic,51948.msg585181.html#msg585181, habe ich aber leider nicht wirklich verstanden. Vielleicht liegt das auch an den anders aussehenden Log - oder an meinen noch sehr beschränkten Kenntnissen bzgl. FHEM (..die ich aber nach und nach verbessern möchte).

Log von tatu123
1-0:1.8.0*255(0000344.481*kWh)
1-0:1.8.0*01(0000129.574*kWh)
1-0:1.8.0*02(0000000.001*kWh)
1-0:1.8.0*03(0000000.000*kWh)
1-0:1.8.1*255(0000219.574*kWh)
1-0:1.8.1*01(0000085.841*kWh)
1-0:1.8.1*02(0000000.001*kWh)
1-0:1.8.1*03(0000000.000*kWh)
1-0:1.8.2*255(0000124.908*kWh)
1-0:1.8.2*01(0000043.733*kWh)
1-0:1.8.2*02(0000000.000*kWh)
1-0:1.8.2*03(0000000.000*kWh)

Log via FHEM-OBIS-Modul:
2018-01-01_08:57:44 Stromzaehler total_consumption: 6044.62
2018-01-01_08:57:45 Stromzaehler total_consumption_Ch1: 6044.62
...
2018-01-01_08:57:51 Stromzaehler total_feed: 3565.513
2018-01-01_08:57:52 Stromzaehler total_feed_Ch1: 3565.513

Vorgeschlagener Workaround:

Code: [Auswählen]

{"1-0:1.8.0*01"=>"consumption_1","1-0:1.8.1*01"=>"consumption_2","1-0:1.8.3*01"=>"consumption_3"}
Kann mir bitte jemand - vielleicht sogar Stefan - helfen, was ich ändern bzw. wo ich eingreifen muss?

@Willy: Vielen Dank für deinen Hinweis auf den früheren Beitrag. Den hätte ich natürlich auch selbst finden können, hätte ich die Suche bemüht - hab da ehrlich gesagt nicht dran gedacht - sorry!

[willybauss]

@Willy: Vielen Dank für deinen Hinweis auf den früheren Beitrag. Den hätte ich natürlich auch selbst finden können, hätte ich die Suche bemüht - hab da ehrlich gesagt nicht dran gedacht - sorry!

Kein Thema. Ich habe mich auch nur deshalb auf die Suche gemacht, weil mir der Name ISKRA bekannt vorkam. Mein Bauchgefühl lag wohl richtig.

Es ist immer wieder "interessant", wie manche alten Hasen reagieren, wenn man als Neuling was anderes zu tun hat als 97 Seiten alter Beiträge zu lesen, nur um die 5%-Chance auf einen Treffer zu nutzen. Diese "RTFM" Reaktionen kann ich nicht immer nachvollziehen (nur wenn sich Jemand permanent sperrig stellt ...).

Ach ja: ... und die Suchfunktion des Forums ist eher besch...eiden.

[tatu123]

Die Werte des Zählers bekommst Du mit

z.B.
attr zaehler channels {"1-0:1.8.0*255"=>"verbrauch_akt","1-0:1.8.0*01"=>"verbrauch_letzter_Mon","1-0:1.8.0*02"=>"verbrauch_vor_2_Mon","1-0:1.8.0*03"=>"verbrauch_vor_3_Mon","1-0:1.8.0*04"=>"verbrauch_vor_4_Mon","1-0:1.8.0*05"=>"verbrauch_vor_5_Mon","1-0:1.8.0*06"=>"verbrauch_vor_6_Mon","1-0:1.8.0*07"=>"verbrauch_vor_7_Mon","1-0:1.8.0*08"=>"verbrauch_vor_8_Mon"}
attr zaehler event-on-change-reading verbrauch_akt

Das Modul kann offensichtlich nicht die Sub-Channel des Zähler richtig zuordnen. Es werden immer alle Werte von 1.08* in den gleichen Wert geschrieben und da der neueste Wert zu erst kommt wird er immer mit den älteren Werten überschrieben. Das setzen des channels-attributs umgeht das zumindest.

Wenn dich, wie mich, die vordefinierten Werte stören kannst Du die mit

attr zaehler suppressReading total_consumption.*

ausblenden. Steht eh nur quatsch drin.

Ich hoffe das die Unterstützung der Sub-channel irgend wann mal, für den Zähler, richtig implementiert wird. Aber da wir jetzt schon min 2 mit dem Zähler wird es vieleicht doch mal.
Ach und die schon lange in Planung befindliche Auslesegeschwindigkeitsumschaltung kommt dann hoffentlich auch.

Viele Grüße
tatu123

[parabacus]

Hallo tatu123!

danke dass du dich dazu meldest, allerdings hab ich's noch immer nicht ganz kapiert!

Mich stören natürlich nur die Folgewerte der Vormonate - der Wert total_consumption des aktuellen Zählerstandes interessieren mich natürlich schon.
Blende ich mit "attr zaehler suppressReading total_consumption.*" dann alles aus oder nur die der Vormonate? - oder was meinst du mit "vordefinierte Werte"?

Wenn's bisschen schneller gehen würde, wäre das natürlich auch toll - so kann man ja den einzelnen Bits fast zuschauen, wie sie rübertröpfeln... :-)

[willybauss]

Wenn ich das Problem richtig verstanden habe, dann heißen bei Dir alle Readings (auch die der Vormonate) "Stromzaehler total_consumption". Eine Unterscheidung anhand eines Suffixes (z.B. 1-0:1.8.0*02) ist also nicht möglich.

Findest Du evtl. eine Möglichkeit, den Zähler zu einer anderen Art der Werte-Darstellung zu überreden?

Schalt doch mal den Event Monitor ein mit einem Filter auf alles, was den Stromzähler betrifft, und poste den Inhalt hier. Vielleicht gibt es ja doch noch ein Unterscheidungsmerkmal.

Ansonsten würde mir einfallen, dass Du alle "Stromzaehler total_consumption" Readings mit dem vorigen Wert vergleichst, und nur dann ins Logfile schreibst, wenn der Wert höher ist als der vorige. Dazu müsstest du jedes mal, wenn ein Wert geschrieben wird, ihn zusätzlich in einer Dummy-Variablen speichern, die Du bei weiteren Werten als Basis für den Vergleich her nimmst.

[parabacus]

Hi Willy,

hier mal ein Log...

Vielleicht hab ich's jetzt kappiert...

Im Code steht folgendes:
my %OBIS_channels = ( "21"   =>"power_L1",
                     "41"   =>"power_L2",
                     "61"   =>"power_L3",
                     "12"   =>"voltage_avg",
                     "32"   =>"voltage_L1",
                     "52"   =>"voltage_L2",
                     "72"   =>"voltage_L3",
                     "11"   =>"current_sum",
                     "31"   =>"current_L1",
                     "51"   =>"current_L2",
                     "71"   =>"current_L3",
                     "1.8"   =>"total_consumption",
                     "2.8    =>"total_feed",
                     "2"     =>"feed_L1",
                     "4"     =>"feed_L2",
                     "6"     =>"feed_L3",
                     "1"     =>"power",
                     "15"   =>"power",
                     "16"   =>"power",
                     "24"   =>"Gas",
                    );

Wenn ich jetzt meinen Log betrachte, finde ich dann an den Stellen, wo 1.8 bzw. 2.8 ausgelesen wird, die Ersetzung mit der Bedeutung des Wertes - eben total_Consupmtion bzw total_feed.
Wenn ich jetzt - und so interpretiere ich die den Vorschlag von tatu123 - diese Ersetzung zurücksetze, müsste im Log die Bennenung nach OBIS-Protokoll erscheinen.
Dann wäre eine neue Zuweisung - auch nach Vorschlag von tatu123 - mit attr zaehler channels {"1-0:1.8.0*255"=>"verbrauch_akt","1-0:1.8.0*01"=>"verbrauch_letzter_Mon", ...} möglich und man könnte dann auf Wert verbrauch_akt filtern, womit man dann auch nur den einen Wert bekommt, da die weiteren Werte nicht mehr auf die selbe Variable geschrieben werden.

Hab ich das jetzt korrekt interpretiert?

[willybauss]

In deinem angehängten Textfile sehe ich durchaus Suffixe, z.B.

1-0:1.8.1*01(0005052.114*kWh)

Demnach dürfte das, was in deinen Logs steht ("total_consumption" in allen Zeilen) bereits die Interpretation sein, die zuschlägt, sobald sie irgendwas findet, das mit 1.8 anfängt (gemäß der zitierten Stelle im Code). Das von tatu123 vorgeschlagene Attribut

attr zaehler channels {"1-0:1.8.0*255"=>"verbrauch_akt","1-0:1.8.0*01"=>"verbrauch_letzter_Mon ...

scheint eine Präzisierung dieser pauschalen Zuweisung zu definieren. Versuch das mal.

Am Code des Moduls würde ich nach Möglichkeit nichts ändern, sonst musst Du das Modul von zukünftigen Updates ausschließen, damit Deine Änderungen erhalten bleiben. Ich vermute, dass die pauschale Interpretation (1.8 => ...) durch die präzisere ersetzt wird, sobald das Attribut gesetzt ist. Insofern braucht es wahrscheinlich keine Codeänderung.

PS:
Du bist hiermit bereits auf der Schattenseite von FHEM angekommen. Alles ist open source, alles ist mehr oder weniger supportet, und Vieles ist mit Ausnahmen und Sonderfällen behaftet, die Zeit und Verständnis benötigen.

[parabacus]

Das kommt raus, wenn man mal schnell schnell was macht zwischen Tür und Angel... - ich Hornochse hab den falsche Log hochgeladen  - das war einer mit dem Test-Programm EmLog, das mit dem IR-Lesekopf mitkommt.

Jetzt der richtige Log, aufgenommen mit dem FHEM-Event-Monitor.

[willybauss]

Das war wahrscheinlich sogar gut so. Denn sonst hätten wir nie gesehen, dass der Zähler tatsächlich die Werte mit Suffix liefert, die das Modul offenbar schon vor dem Event Monitor in "total_consumption" übersetzt. Hier sieht man es ja auch beispielsweise:

2018-01-02 10:04:52 OBIS Stromzaehler 1.0.1.6.1.01: 1712020515
2018-01-02 10:04:53 OBIS Stromzaehler 1.0.1.6.1.02: 1711181145
2018-01-02 10:04:55 OBIS Stromzaehler 1.0.1.6.1.03: 1710120715
2018-01-02 10:04:56 OBIS Stromzaehler 1.0.1.6.1.04: 1709210845
2018-01-02 10:04:57 OBIS Stromzaehler 1.0.1.6.1.05: 1708040800
2018-01-02 10:04:58 OBIS Stromzaehler 1.0.1.6.1.06: 1707250515
2018-01-02 10:05:00 OBIS Stromzaehler 1.0.1.6.1.07: 1706070330
2018-01-02 10:05:01 OBIS Stromzaehler 1.0.1.6.1.08: 1705060430
2018-01-02 10:05:02 OBIS Stromzaehler 1.0.1.6.1.09: 1704082200
2018-01-02 10:05:03 OBIS Stromzaehler 1.0.1.6.1.10: 1703232045
2018-01-02 10:05:05 OBIS Stromzaehler 1.0.1.6.1.11: 1702220745
2018-01-02 10:05:06 OBIS Stromzaehler 1.0.1.6.1.12: 1701240830
2018-01-02 10:05:07 OBIS Stromzaehler 1.0.1.6.1.13: 1612301230
2018-01-02 10:05:08 OBIS Stromzaehler 1.0.1.6.1.14: 1611271800
2018-01-02 10:05:10 OBIS Stromzaehler 1.0.1.6.1.15: 1611251145


Gib dem Attribut mal eine Chance.

[parabacus]

Yeah - der Workaround tut's...! 

In den Readings sehe ich jetzt...
Einspeisung_Vormon   3565.513  2018-01-02 12:47:50
Einspeisung_akt          3565.799  2018-01-02 12:44:54
Verbrauch_Vormon     6034.338  2018-01-02 12:45:32
Verbrauch_akt            6068.426  2018-01-02 12:44:47

Hier die Lösung meines Problems:

Code: [Auswählen]

attr Stromzaehler suppressReading {total_consumption.*, total_feed.*}
attr Stromzaehler channels {"1-0:1.8.0*255"=>"Verbrauch_akt","1-0:1.8.0*01"=>"Verbrauch_Vormon","1-0:2.8.0*255"=>"Einspeisung_akt","1-0:2.8.0*01"=>"Einspeisung_Vormon"}

Vielen Dank an tatu123, der das analog bei seinem Problem gemacht hat und an Willy mit seiner "Engelsgeduld" mir zu Helfen.
Again what learnd...! 

[FunkOdyssey]

Ich habe seit heute urplötzlich folgende Ausgabe im FHEM-Log:

Code: [Auswählen]

2018.01.02 17:14:50.130 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 378, <GEN286691> line 1.
2018.01.02 17:14:50.132 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/47_OBIS.pm line 382, <GEN286691> line 1.
Wie immer: Am System hat niemand etwas verändert. :-)

Hat jemand einen Tipp woher das kommt? Danke.

[willybauss]

Ich habe auch (immernoch) ein Problem.

Stefan antwortete mir damals:

Ich kann das zwar in keinster Weise nachvollziehen, aber einen Versuch ists alle mal wert, in der config zu schauen, ob "interval" vor dem "alignTime" definiert wird.

lg, Stefan

Das löste zwar das Problem insofern, dass die  "alignTime" Attribute nicht mehr gelöscht wurden, dennoch habe ich seither immer wieder Einträge im Logfile

Code: [Auswählen]

OBIS (Hausstrom_Zaehler): attr alignTime is useless, if no interval is specified

Das liegt nach wie vor daran, dass  FHEM beim speichern die Attribute alphabetisch sortiert. Aber das OBIS-Modul akzeptiert nicht, dass alignTime vor interval gelesen wird; deshalb kommt die Meldung ins Logfile.

Einer, der es wissen müsste, schrieb hier
https://forum.fhem.de/index.php/topic,69494.msg611381.html#msg611381:

Die Attribute werden immer alphabetisch sortiert gespeichert, d.h. eine manuelle Umsortierung ist hier nur von kurzer Dauer. Da der Modul-Maintainer sich darauf verlassen kann, kann er notfalls die Namen der Attribute anpassen. Oder die Pruefung erst nach der Initialisierung ($init_done) durchfuehren.

Mit anderen Worten: wenn das OBIS-Modul mit einer alphabetischen Sortierung der Attribute zu solchen Fehlermeldungen neigt, dann ist das ein Bug.

==> Stefan: kannst Du das bitte korrigieren, z.B. in der von Rudolf König vorgeschlagenen Weise?

[Icinger]

Hi Leute,

Frohes neues Jahr!

Hab grad nen kleines Update eingespielt:

*) Commandref-Patch von krikan
*) Die alignTime is useless, if no interval is specified-Meldung kommt nur mehr, wenn FHEM schon initialized ist.
*) Roro's "binärer Schrott"-Fehler sollte (hoffentlich) nicht mehr auftreten. Es werden in der SMLDecode-Routine nur mehr "printable chars" akzeptiert, alles andere wird durch nen . ersetzt (hoff ich mal)
*) tr_ex's Vorschlag für den AS1440 wurde implementiert. Der Zähler wird mit "/2!" initialisiert statt mit "/?!"....Damit bleiben bei seinem Zähler die Vorwerte weg. Könnte das jemand anders auch probieren, bitte?

Soweit mal ein Anfang

lg, Stefan