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

[matzefisi]

Ist das "directions" Attribut nicht neu?  Ich dachte das wäre jetzt erst mit dem letzten Update gekommen.

[tatu123]

Ich habe auch seit einiger Zeit mal wieder ein update gemacht. Jetzt geht auch das Attribut "extChannels" nicht mehr. Alles es noch groß geschrieben wurde war noch alles gut.

Viele Grüße

[Icinger]

Das directions-Attribut ist jetzt knappe 2 Jahre alt, siehe https://forum.fhem.de/index.php/topic,51948.msg437018/topicseen.html#msg437018

Auch am extChannels habe ich nicht wirklich was geändert :O

[matzefisi]

Oh sorry  . Dann liegt es wohl woanders dran und ich habe mich heftigst verlesen.
Ich werde nächste Woche mal etwas debuggen und hier berichten.

[tatu123]

Also in Version 15760 geht "ExtChannels" wie erwartet. In der neuen Version mit "extChannels" passiert nichts. Das heisst ich denke ob ich das Attribut setzte oder nicht immer das gleiche Ergebnis. Das Modul verhält sich wie ohne das Attribut.

Viele Grüße

[matzefisi]

Ich merke gerade, dass ich schon lange nicht mehr aktualisiert habe. Die vorherige Version mit der die Directions noch aktualisiert wurden war die hier:

Code Auswählen Erweitern

$Id: 47_OBIS.pm [b]14235 [/b]2017-05-09 19:24:14Z Icinger $

Ich habe die jetzt erstmal wieder zurückgesichert. Ich hoffe ich habe diese Woche nochmal etwas Zeit weiter zu analysieren.

[willybauss]

Eine Versionsnummer im Modul könnte nicht schaden ...

[tatu123]

So konnte heute das Problem mit dem nicht funktionierenden Attribut "extChannels" beheben.

Kurzbeschreibung: ExtChannles -> extChannels Line 502

[Icinger]

@tatu123: Danke, ist gefixt und eingecheckt...

[FunkOdyssey]

Ich weiß, dass das wahrscheinlich nicht zusammenhängt, aber ich habe seit der Aktivierung des letzten Updates neue Readings mit dem Suffix ,,.255".

Code Auswählen Erweitern


     2018-02-15 10:55:10   total_consumption 965931.0197
     2018-02-17 10:52:45   total_consumption.255 983223.7839
     2018-02-15 10:55:10   total_consumption_Ch1 965721.0815
     2018-02-17 10:52:45   total_consumption_Ch1.255 983013.8458
     2018-02-15 10:55:10   total_consumption_Ch2 209.9381
     2018-02-17 10:52:45   total_consumption_Ch2.255 209.9381


Leider funktionieren seitdem sämtliche Berechnungen nicht mehr, da sich das Basisreading geändert hat. Hast du eine Idee woher das kommt?

[tatu123]

Ich würde denken du hast "extChannels" aktiviert.

[FunkOdyssey]

Aktiviert hatte ich das seit der Einführung. Mit dem Fix vom 13.2. wurde das Attribut erstmals scharf geschaltet. Ich hatte damals gemeckert, dass man das Attribut extChannels und nicht ExtChannels nennen soll. Das habe ich nun davon.
Ich habe es gelöscht und prompt wird ,,total_consumption" wieder aktualisiert. Danke für den Hinweis.

Ich wundere mich nur, warum mit ,,extChannels = on" das primäre Reading ,,total_consumption" nicht aktualisiert wird und plötzlich ,,total_consumption.255" erscheint.

[Belit]

Hallo, ich habe ganz frisch mit fhem angefangen.
Ziel ist es die aktuellen PV Überschüsse in der Küche auf einem Display anzuzeigen, und möglichst automatisiert in warmes Wasser und eine warme Wohnung zu verwandeln.
Der erste Schritt ist mit dem Raspberry pi 3 (Raspian) und einen EMLOG IR Schreib/ Lesekopf USB von Weidmann Elektronik die Werte des Zweirichtungsstromzählers Elster AS1440 auszulesen.

Der Zähler ist mit einer Initialisierungssequenz anzusprechen bevor er Daten sendet. Diese beinhaltet in meinem Fall die 8 stellige Identifikationsnummer des Zählers:
/?<Identifikationsnummer>! <CR/LF>
(Führende Nullen der Identifikationsnummer können ignoriert werden). Siehe: https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/elster_as1440

Wenn ich wie in diesem pdf vom Optokopf-Hersteller beschrieben vorgehe, kann ich die Zählerdaten als lesbaren Text (OBIS Protokoll) im LXTerminal sehen:
https://shop.weidmann-elektronik.de/media/files_public/9d73b590bf0752a5beff32d229d4497d/HowToRaspberryPi.pdf
Alle Werte im Terminal stimmen mit den Daten vom Display des Stromzählers überein.

Das 47_OBIS.pm Modul habe ich wie folgt definiert:

Code Auswählen Erweitern

Internals:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06GH3P-if00-port0@300,7,E,1 AS1440
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06GH3P-if00-port0@300,7,E,1
   MeterType  AS1440
   NAME       MVVZaehler
   NR         25
   PARTIAL   
   STATE      opened
   TYPE       OBIS
   READINGS:
     2018-04-02 11:17:24   Version         ?!
     2018-04-02 21:36:38   state           opened
   helper:
     EoM        -1
     SPEED      0
     SPEED2     0
     TRIGGERTIME 1522702934.82179
     DEVICES:
       /2!

       10
       000

Attributes:
   interval   10
   pollingMode on
   verbose    5

Es kommen keinerlei Daten vom Zähler in den readings / dem Logfile an, wahrscheinlich weil die Identifikationsnummer des Zählers in der Anforderungssequenz fehlt.

Ich habe versucht die Änderung in ein edit file auf der Basis von 47_OBIS.pm einzubauen, finde jedoch nicht die neuralgische Stelle im Code und mache das alles hier sowieso nur auf Cargo-Kult Niveau. Hat Icinger / Stefan eine Möglichkeit das Modul anzupassen? Oder brauche ich nur einen guten Tipp von euch?

Das Logfile zeigt:

Code Auswählen Erweitern

2018.04.01 23:57:30 5: OBIS (MVVZaehler) - Internal timer set to 2018-04-01 23:57:40
2018.04.01 23:57:40 5: SW: 2f32210d0a
2018.04.01 23:57:40 4: Wrote /2!

Übrigens hat der Zähler nur auf /?! reagiert und nicht auf /2! wie es bei 'Meter Type: AS1440' im OBIS Modul hinterlegt ist. Das ist zwar für andere User egal weil die einfach einen anderen Meter Type wählen können, aber wenn die Möglichkeit zur Eingabe der Identifiktionsnummer nur beim 'Meter Type AS1440' mit der festen Anforderungssequenz /2! eingebaut werden würde, hätte ich wieder ein Problem...

[Belit]

Ich habe nun doch über ein edit file das OBIS Modul in Zeile 152 angepasst und der Zähler wirft wenn ich ihn mit
/?01234567!
statt mit
/2!
anspreche Daten aus. (Hierbei ist 1234567 stellvertetend für meine 8 Stellige Identifikationsnummer ohne führende 0 zu verstehen) Das sehe ich daran dass die grüne Kontroll LED auf der Rückseite des IR Sensors nun blinkt und zwar in der gleichen Weise wie sie auch blinkt wenn ich mit cat die Daten im LXTerminal empfange. Ausserdem kann ich die IR LED des Stromzählers wenn ich den IR Sensor während der Übertragung herunternehme auch mit dem bloßen Auge schwach leuchten / blinken sehen. Auf Hardwareebene scheint jetzt also alles in Butter.

Das hatte vorher zunächst nicht funktioniert und im logfile stand trotz des geänderten OBIS codes immer noch der Aufruf /2! aber nachdem ich meine Device einmal gelöscht und neu definiert hatte ging es dann doch.

Nur: Immer noch keine sinnvollen readings. Ich bekomme

Code Auswählen Erweitern

Version: �1���@�zg�.u�Tg�n� 2018-04-07 22:56:25
state: opened 2018-04-08 10:25:26
und das wars.

Auch das logfile zeigt mit verbose 5 nur

Code Auswählen Erweitern

2018.04.09 20:21:09 5: OBIS (MVVZaehler) - Msg-Parse: 2.8.85.k22)
2018.04.09 20:21:30 5: SW: 2f3f31323334353637210d0a
2018.04.09 20:21:30 4: Wrote /?1234567!

2018.04.09 20:21:30 5: OBIS (MVVZaehler) - Internal timer set to 2018-04-09 20:22:02
2018.04.09 20:22:02 5: SW: 2f3f31323334353637210d0a
2018.04.09 20:22:02 4: Wrote /?1234567!

2018.04.09 20:22:02 5: OBIS (MVVZaehler) - Internal timer set to 2018-04-09 20:22:34
2018.04.09 20:22:34 5: SW: 2f3f31323334353637210d0a
2018.04.09 20:22:34 4: Wrote /?1234567!

Die Zählerdaten werden von fhem nicht richtig angenommen und ich habe aktuell keine Idee hierzu.

[Icinger]

Schon komisch.....Deinem Log-Auszug zufolge kommen nähmlich gar keine Daten im Obis-Modul an.....

Das mit der Init-Sequenz kann ich evtl. über ein zusätzliches Attribut lösen, muss ich mir mal ansehen.

lg, Stefan