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

[cs-online]

...hast du den FTDI an einem Hub dran gehabt ? Das war bei mir schon mal das Problem, weshalb sich der ständig connected/disconnescted hat...

[gvzdus]

Ich kenne die Meldung vor allem von Situationen, wo ich noch ein anderes Device auf den gleichen USB-Port definiert habe.
Oder einen externen Prozess. Außerdem verwende vielleicht besser /dev/serial/by-id/ statt dem direkten Port.

[hdgucken]

Melde folgenden Teilerfolg:

- MAX3232 eingeschleift
= SHM / Sunnyportal bekommt Werte und updated auch
= OBIS-Modul bekommt Werte und updated auch

Aber es gibt noch ein Problem:

Der FTDI-Adapter connected/disconnected ständig - mehrfach pro Sekunde. Daher ist es eher Zufall, ob ein Telegramm durchkommt.

Hat jemand eine Idee, woran dieses State "connected/disconnected" liegen kann?

Das sieht doch schon mal gut aus !

Wie gvzdus schrieb, serial by-id anstelle von ttyUSB0 ist auf jeden Fall zu empfehlen !
Dann ist es nämlich egal, an welchem USB-Port der FTDI angesteckt wird, er wir immer an Hand seiner eindeutigen ID erkannt.
Serial by-id herausfinden:

Mit putty auf dem RaspberryPi einloggen.
Ins Verzeichnis /opt/fhem/log wechseln und folgenden Befehl eingeben:
ls -al /dev/serial/by-id

es sollte in etwa solch ein Eintrag dabei sein:
lrwxrwxrwx 1 root root 13 Jun 24 17:29 usb-FTDI_FT232R_USB_UART_A5047XOF-if00-port0 -> ../../ttyUSB0

"usb-FTDI_FT232R_USB_UART_A5047XOF-if00-port0" ist die ID vom FTDI.

Die Definition müsste dann etwa so aussehen:

define ZAEHLER OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5047XOF-if00-port0@9600 Standard

Die Baudrate (9600) anzugeben sollte reichen. Ich glaube, 8N1 ist die Standardeinstellung für RS232, brauchst Du also nicht extra angeben.

Gruß Thomas

[assi05]

Hi ihr Drei,

danke für den Tipp!

Probiere ich asap aus; hab den Raspi aktuell nicht mehr am Stromkasten hängen.

Meinen Signalduino hab ich so eingebunden; sollte ich hinbekommen.

Schönen Abend!

[thor3]

Hallo,
ich habe auch mit dem Problem zu kämpfen das der Verbrauch nicht mehr aus dem SMA Portal ins FHEM kommt.
Der SHM1 liest den Zähler per original D0- Kopf aus und überträgt die Daten auch sauber ins SMA-Portal.
ESP8266 liegt hier auch noch rum, der hat früher den Ferraris-Zählern S0 Impulse entlocken wollen.
Aber wie genau soll der physikalische Anschluß denn sein?
Einfach TX vom D0-Lesekopf parallel auf RX vom 3,3 V ESP schalten klingt sportlich und himmelt wahrscheinlich den ESP, obwohl das noch die günstigste Komponente in diesem Konstruct ist.

Viele Dank für Hinweise und viele Grüße Nico

[hdgucken]

Hallo thor3,

siehe hier:
https://forum.fhem.de/index.php/topic,51948.msg1117497.html#msg1117497

Entweder die Transistorstufe oder den RS232 Wandler verwenden. Auf keinen Fall direkt zum ESP gehen, der würde zerstört werden !

Gruß Thomas

[tr_ex]

Hallo assi05,
ich habe einen neuen Zähler in Betrieb genommen und hatte ständig das Problem mit connected/disconnected.
Da mein Zähler ständig automatisch sendet half das Setzen des PollingModes

Code Auswählen Erweitern

attr xxx pollingMode on

[tr_ex]

Ich hab einen neuen Zähler mit dem OBIS Modul in Betrieb genommen. Da die Informationen zu diesem Gerät sehr schwer zu finden waren, habe ich dies einmal zusammengefasst:

Zähler: LOGAREX LK13BE

Definiert:

Code Auswählen Erweitern

define NameZaehler OBIS /dev/serial/by-id/usb-FTDI_xxx-port0@9600,7,E,1 SML
attr NameZaehler alignTime 00:00:00
attr NameZaehler channels {"1.0.14.7.0.255"=>"Freq", "1-0:1.8.0*96"=>"V01", "1-0:1.8.0*97"=>"V07", "1-0:1.8.0*98"=>"V30", "1-0:1.8.0*99"=>"V99", "1-0:1.8.0*100"=>"VG"}
attr NameZaehler extChannels on
attr NameZaehler interval 60
attr NameZaehler pollingMode on

Der Zähler sendet selbständig die Daten. Wenn der Zählerpin vorliegt, kann man am Gerät selbst, die vollständige Datenausgabe aktivieren (Inf auf on stellen). Ist dies der Fall, werden neben dem Zählerstand auch Strom, Spannung, Mommentanleistung, Frequenz, Phasenwinkel und Historische Werte ausgegeben.
Die Obiskennzahlen mit der Messgröße 81 sind die Phasenwinkel.
Der Zeitpunkt, wann die historischen Werte im Gerät gebildet werden, hängt vom Zeitpunkt ab, wann diese das letzte mal gelöscht wurden. Erfolgt das Rücksetzen (HiS CLr auf on, E CLr auf on) um 12:00 Uhr, werden die Werte entsprechend ab diesem Zeitpunkt rollierend gebildet.
Die Register für die Historischen Werte habe ich mir eigene Channels definiert.
V01 - 1 Tag   
V07 - 7 Tage
V30 - 30 Tage
V99 - 365 Tage
VG  - Gesamtverbrauch

[gmxspooker]

Hallo ich habe das gleiche Problem wie im Zitat unten beschrieben.
Wurde bereits ein möglicher Workaround gefunden?
Nach einer kurzen Internet Recherche ist dieses Problem auf beim Volkszähler aufgetreten.

https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/dzg_dvs74
https://github.com/jmberg/libsml/commit/81c4026e3d94f7a384cdd89f62a727b83269cdec

Dort gibt es einen möglichen Workaround. Dieser ist leider in der Programmiersprache C
Da ich leider nicht die nötigen Perl Kenntnisse besitze, wäre es schön, ob sich jemand bereiterklärt sich dem Thema anzunehmen.

Gruß Domenik

Moin,

ich habe einen neuen Stromzähler bekommen und versuche diesen nun auszulesen.
Es ist ein DZG DWS7412.1 mit optischer Schnittstelle.
Ich habe mir einen IR-Schrei/Lesekopf besorgt und ihn per USB mit meinem FHEM + OBIS gekoppelt.
Scheint soweit auch wunderbar zu funktionieren, ich empfange Daten.

Ich habe nur das merkwürdige Problem das ich mal plausible, mal negative Verbrauchswerte erhalte.
Eingrenzen oder reproduzieren kann ich es nicht. (OBIS zeigt z.B. -279W an während der Zähler selbst 500W anzeigt)
Der Gesamtverbrauch stimmt mit den Angaben des Zählers überein.

Ich habe keine Idee woran das liegen kann und hoffe jemand kann mir helfen.

Hier log vom gesamten Lesevorgang:

Code Auswählen Erweitern

2018.09.08 07:04:50 5: SW:
2018.09.08 07:04:50 4: Wrote
2018.09.08 07:04:50 5: OBIS (Stromzaehler) - Internal timer set to 2018-09-08 07:05:20
2018.09.08 07:04:51 5: SML-Parse 1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Full message-> 1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=1B1B1B1B01010101760587C61200620062007263010176010102310B0A01445A4700028275D772620164065A55620263724300760588C61200620062007263070177010B0A01445A4700028275D7070100620AFFFF72620164065A557477070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100600100FF017262016200620052000B0A01445A4700028275D70177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100010800FF641C01047262016200621E52FF6405893F0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 5: OBIS: Telegram=0177070100100700FF017262016200621B52FE539456010101634BA000760589C61200620062007263020171016332A000000000001B1B1B1B1A04518A
2018.09.08 07:04:51 4: MSG IS:
/
1-0:96.50.1*255(DZG)
1-0:96.1.0*255(
DZGu)
1-0:1.8.0*255(36281.5*Wh)
1-0:16.7.0*255(-275.62*W)
!

2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: /
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.50.1*255(DZG)
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
DZGu)
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(36281.5*Wh)
2018.09.08 07:04:51 5: Msg 1-0:1.8.0*255(36281.5*Wh) is of type Counter
2018.09.08 07:04:51 4: Set total_consumption to 36281.5
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(-275.62*W)
2018.09.08 07:04:51 5: Msg 1-0:16.7.0*255(-275.62*W) is of type Channels
2018.09.08 07:04:51 5: OBIS (Stromzaehler) - Msg-Parse: !

Und ein list vom Device:

Code Auswählen Erweitern

Internals:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90788VC-if00-port0@@9600,8,N,1
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90788VC-if00-port0@@9600,8,N,1
   MeterType  SML
   NAME       Stromzaehler
   NR         130
   PARTIAL   
   STATE      opened
   TYPE       OBIS
   Helper:
     DBLOG:
       power:
         logdb1:
           TIME       1536383271.01572
           VALUE      -207.91
   READINGS:
     2018-09-08 07:07:51   1.0.96.50.1.255 DZG
     2018-09-08 07:07:51   power           -207.91
     2018-09-08 06:55:20   state           opened
     2018-09-08 07:07:51   total_consumption 36300.6
   helper:
     BUFFER     
     EoM        -1
     SPEED     
     SPEED2     
     TRIGGERTIME 1536382520.06882
     Channels:
     DEVICES:
       
       30
       
     directions:
Attributes:
   interval   30
   pollingMode on
   verbose    1

[ioT4db]

Hallo,

habe das Modul jetzt seit einigen Tagen am laufen. Habe zwei Zähler über Netzwerk angebunden, einen über Lan (X-Port) und einen über WLAN (NodeMCU mit ESPEasy und ser2NET).
Es funktioniert alles einwandfrei bis zu einem Fhem-Neustart. Dann stehen beide Zähler auf Status "opened". Ich muss dann bei Beiden einmal das "Def" aufrufen und mit "modify" bestätigen, dann ist die Verbindung sofort wieder da. Ich meine, hier im Thread schon von dem Problem gelesen zu haben, gibt es inzwischen eine Lösung dafür ?

Gruß Thomas

Hi,

ich wollte das obige Thema nochmal ansprechen, da ich ein ähnliches Verhalten beobachte.
Ich habe u.a. 2 Zähler-Sensoren per USB an einem Raspi, auf dem Ser2Net läuft. Soweit läuft auch alles stabil. Sobald der Raspi aber mal rebootet bzw. nach Stromausfall neu startet, wird die Verbindung nicht automatisch wieder hergestellt.
(Ich "bediene" auch noch ein anderes Modul (konkret das THZ-Modul) über ser2net vom gleichen Raspi aus und dort die Verbindung automatisch wieder hergestellt)

Bei mir steht das OBIS-Modul dann auf "disconnected" und im Log steht bspw. "192.168.41.150:20001 disconnected, waiting to reappear (StromZ1)".
Daran ändert sich solange nichts, bis ich im Modul dann "Def" aufrufe und dann mit "modify" wieder schließe. Das muß ich 2x hintereinander machen und dann läuft die Verbindung wieder stabil bis eben der Raspi neu startet.

Gibt es hierzu weitere Erfahrungen von anderen oder Lösungsansätze?

Vielen Dank schonmal und Grüße
Daniel

[gvzdus]

Hi Domenik / Gmxspooker,

ich habe es mir mal angesehen. Unter Abnahme des Versprechens "Wir testen das dann bis Serienreife" mal anbei einer Version, die vielleicht hilft.
Ist aber schwierig, das Coden, ohne es vor sich zu sehen.

Ich bastele z.Zt. an eventuellen Patchen für das Modul - ich bin nicht der Maintainer!

Wenn es helfen sollte, schicke bitte einmal einen List Deines Devices, damit man - wie im Vorbild bei vzlogger - eine Erkennung auf den DZG-Zähler einbaut - die fehlt in meiner Version auf jeden Fall noch.

Viele Grüße, Georg

[hdgucken]

Hi,

ich wollte das obige Thema nochmal ansprechen, da ich ein ähnliches Verhalten beobachte.
Ich habe u.a. 2 Zähler-Sensoren per USB an einem Raspi, auf dem Ser2Net läuft. Soweit läuft auch alles stabil. Sobald der Raspi aber mal rebootet bzw. nach Stromausfall neu startet, wird die Verbindung nicht automatisch wieder hergestellt.
(Ich "bediene" auch noch ein anderes Modul (konkret das THZ-Modul) über ser2net vom gleichen Raspi aus und dort die Verbindung automatisch wieder hergestellt)

Bei mir steht das OBIS-Modul dann auf "disconnected" und im Log steht bspw. "192.168.41.150:20001 disconnected, waiting to reappear (StromZ1)".
Daran ändert sich solange nichts, bis ich im Modul dann "Def" aufrufe und dann mit "modify" wieder schließe. Das muß ich 2x hintereinander machen und dann läuft die Verbindung wieder stabil bis eben der Raspi neu startet.

Gibt es hierzu weitere Erfahrungen von anderen oder Lösungsansätze?

Vielen Dank schonmal und Grüße
Daniel

Hallo Daniel und Georg,

habe mich die letzten Tage auch mit dem OBIS Modul beschäftigt, weil die Verbindung zu meinen Zählern nach einem Restart zwar auf "connected" stand
aber keine Daten kamen. Habe einige kleine Änderungen beim Verbindungsaufbau gemacht und was soll ich sagen: es funktioniert jetzt !
Hänge meine Version ebenfalls mit an, vielleicht kann man ja auch die Änderungen von Georg mit einfügen, wenn alles getestet ist ;o)
@Daniel wenn "disconnected" im Status steht, konnte vom OBIS Modul (bzw. DevIo) wirklich keine Verbindung aufgebaut werden, Parameter z.B. Port falsch ?
Meine Version sollte eigentlich eine Fehlermeldung im Log erzeugen, in etwa so: "OBIS StromZ1 - error while connecting: Fehler xyz".

Gruß Thomas

[gvzdus]

Ich mische das gerne zusammen. Allerdings: Meine Version von gestern ist wirklich nur eine Version für die DZG-Zähler mit dem Bug! Da wird "hardgecodet" unter bestimmten Umständen ein Signed Int als Unsigned Int interpretiert - No go für bugfreie Zähler!

Ich habe in der Version oben noch nicht eingebaut, dass er das *nur* für die DZG-Zähler macht! Deswegen warte ich da auf Rückmeldung.

[hdgucken]

Ich mische das gerne zusammen. Allerdings: Meine Version von gestern ist wirklich nur eine Version für die DZG-Zähler mit dem Bug! Da wird "hardgecodet" unter bestimmten Umständen ein Signed Int als Unsigned Int interpretiert - No go für bugfreie Zähler!

Ich habe in der Version oben noch nicht eingebaut, dass er das *nur* für die DZG-Zähler macht! Deswegen warte ich da auf Rückmeldung.

Ok, dann warten wir erstmal auf Rückmeldung, um den DZG-Zähler korrekt mit einzubinden !

Gruß Thomas

[gmxspooker]

Hi Domenik / Gmxspooker,

ich habe es mir mal angesehen. Unter Abnahme des Versprechens "Wir testen das dann bis Serienreife" mal anbei einer Version, die vielleicht hilft.
Ist aber schwierig, das Coden, ohne es vor sich zu sehen.

Ich bastele z.Zt. an eventuellen Patchen für das Modul - ich bin nicht der Maintainer!

Wenn es helfen sollte, schicke bitte einmal einen List Deines Devices, damit man - wie im Vorbild bei vzlogger - eine Erkennung auf den DZG-Zähler einbaut - die fehlt in meiner Version auf jeden Fall noch.

Viele Grüße, Georg

Vielen Dank Georg.
Nachdem ich dein Modul eingespielt habe funktioniert nun alles wie es soll.
Es sind keine negativen werte mehr vorhanden.

Hier ist ein List von meinem Stromzähler:

Code Auswählen Erweitern


Internals:
   DEF        /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D3075R2F-if00-port0@9600,8,N,1 SML
   DeviceName /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D3075R2F-if00-port0@9600,8,N,1
   FUUID      60104d9e-f33f-c37e-31d8-2f948e9886b6d240
   MeterType  SML
   NAME       Stromzaehler
   NEXT       2021-02-03 23:31:10
   NR         64
   PARTIAL   
   STATE      702.27 W
   TYPE       OBIS
   READINGS:
     2021-02-03 23:30:50   1.0.96.50.1.255 DZG
     2021-02-03 23:30:50   Aktuelle_Leistung 702.27 W
     2021-02-03 23:30:50   Aktuelle_Leistung_Gleitendermittelwert_proMinute 589.971 W
     2021-02-03 23:30:50   Bezug           8277.1741 kWh
     2021-02-03 23:30:50   Einspeisung     49.2908 kWh
     2021-02-03 23:30:50   power           702.27
     2021-02-03 22:53:38   state           opened
     2021-02-03 23:30:50   total_consumption 8277174.1
     2021-02-03 23:30:50   total_feed      49290.8
   helper:
     BUFFER     
     EoM        -1
     SPEED      5
     SPEED2     5
     TRIGGERTIME 1612391470
     Channels:
     DEVICES:
       
       10
       
     RULECACHE:
       1-0:1.8.0*255 Counter
       1-0:16.7.0*255 Channels
       1-0:2.8.0*255 Counter
     directions:
Attributes:
   alignTime  00:00
   icon       measure_power_meter
   interval   10
   pollingMode on
   stateFormat {ReadingsVal($name,"power",0)." W"}
   unitReadings off
   userReadings Bezug {ReadingsNum("Stromzaehler","total_consumption",0)/1000 ." kWh"},
Einspeisung {ReadingsNum("Stromzaehler","total_feed",0)/1000 ." kWh"},
Aktuelle_Leistung {ReadingsNum("Stromzaehler","power",0)/1 ." W"},
Aktuelle_Leistung_Gleitendermittelwert_proMinute {movingAverage("Stromzaehler","power",60)/1 ." W"}

   verbose    3


Ich habe auch noch einen Plot angehängt zur Verdeutlichung.

Grüße Domenik