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

[RalfRog]

.....
Vielleicht findet aber jemand auch den Trick oder Fehler, wie man's wieder so wie gewollt machen kann. 
....
Ciao
Tom

Das ist doch im Log-Level 5 die Ausgabe des Parsers. Das ist bestimmt so gewollt von Icinger und steht nicht in deinen Daten, die sind korrekt ohne <.
(Zeile 54  http://www.stefan-weigert.de/php_loader/sml.php)

Wichtig ist doch, dass das Ergebnis korrekt dargestellt wird: 2022.11.07 21:00:01 4: OBIS (Stromzaehler) - Set total_consumption to 353884.9
So steht es doch auch bestimmt im Reading, oder?

Code Auswählen Erweitern


2022.11.07 22:00:01 5: OBIS (Stromzaehler) - SML-Parse 1B1B1B1B010101017605F792FD02620062007263010176010102310B0A01445A4700039E91AA72620164FF34966202636C53007605F892FD02620062007263070177010B0A01445A4700039E91AA070100620AFFFF72620164FF34967577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A4700039E91AA01 ----> 77070100010800FF641C01047262016200621E52FF6436226501 <---- 77070100020800FF017262016200621E52FF6501C4E5690177070100100700FF017262016200621B52FE54031AC801010163F9AB007605F992FD026200620072630201710163464E000000001B1B1B1B1A035D03

Dieser Part ist:
77
  070100010800FF   --> OBIS Kennung bezogene Energie (Zählertstand)
  641C0104
  72
     6201
     6200       
  621E         --> Einheit Wh
  52FF         --> Faktor 0.1
  64362265 --> Wert 3547749
  01

Gruß Ralf

[parabacus]

Hallo Ralf,

sorry, vielleicht hab ich das nicht präzise genug beschrieben.
In der Vergangenheit hab ich mit Attribut "channels" die Umbenennung gemacht. Natürlich wollte ich das mit dem neuen Zähler ebenso tun, klappt aber nicht.

Zum Test hab ich das jetzt nochmal gemacht:

Code Auswählen Erweitern

channels   {"1-0:1.8.0*255"=>"Verbrauch_aktuell","1-0:2.8.0*255"=>"Einspeisung_aktuell"}

Das Ergebnis ist dann im Log folgendermassen:

Code Auswählen Erweitern

2022-11-14_16:00:00 Stromzaehler Verbrauch_akt: 442.4262
2022-11-14_16:00:00 Stromzaehler Einspeisung_akt: 2976.9969
2022-11-14_17:00:01 Stromzaehler Verbrauch_aktuell: <445169.9
2022-11-14_17:00:01 Stromzaehler Einspeisung_aktuell: 2980974.2
2022-11-14_17:00:01 Stromzaehler Verbrauch_akt: 442.4262
2022-11-14_17:00:01 Stromzaehler Einspeisung_akt: 2976.9969
2022-11-14_18:00:01 Stromzaehler Verbrauch_aktuell: <445175.4
2022-11-14_18:00:01 Stromzaehler Einspeisung_aktuell: 2980994
2022-11-14_18:00:01 Stromzaehler Verbrauch_akt: 442.4262
2022-11-14_18:00:01 Stromzaehler Einspeisung_akt: 2976.9969

Wie du siehst, ist auch hier das Sonderzeichen mit enthalten. Im eigentlichen Reading total_consumption, total_feed und seltsamerweise mittels Attribut "channels" erzeugtem Reading Einspeisung_aktuell passt's - nur nicht im Reading Verbrauch_aktuell.

Ich hoffe, damit kann man das Problem jetzt genauer nachvollziehen.
Wie gesagt - mit einem selbst definierten userReadings kann ich einen Workaround machen, der für mich funktioniert.

Ciao
Tom

[RalfRog]

....
Wie du siehst, ist auch hier das Sonderzeichen mit enthalten. Im eigentlichen Reading total_consumption, total_feed und seltsamerweise mittels Attribut "channels" erzeugtem Reading Einspeisung_aktuell passt's - nur nicht im Reading Verbrauch_aktuell.

Ich hatte das Modul bisher nur für einen schnellen Test benutzt und keine Erfahrung mit dem Attribut Channels.

Ich denke so:
wenn die Original-Readings stimmen

Code Auswählen Erweitern

2022-11-08 19:00:01   total_consumption 365052.6
2022-11-08 19:00:01   total_feed      2971920.1
dann kommen doch vom Zähler die korrekten Werte ohne "Sonderzeichen".
Also liegt das zusätzliche Zeichen doch eher an dem, was durch die Definition von Channels passiert und eher im Modul.

Wenn man eine Lösung hat muss man die Sache ja nicht bis ins letzte klären... andererseits wenn es tatsächlich durch das Modul verursacht ist...

[cocojambo]

OBIS Modul geht auf disconnected, wenn die Perl Pakete für den Betrieb einer Withings Körperwaage installiert werden.
--------------------------------------------------------------------------------------------------------------------------------
Hintergrund: Ich habe das Obis Modul seit ettlicher Zeit einwandfrei in Betrieb an einem MT691 Zähler. Jetzt habe ich mir eine Withings Waage zugelegt, das entsprechene 32_withings.pm Modul installiert und laut Anweisung des Modulentwicklers die dazugehörigen Perl Pakete installiert.

Code Auswählen Erweitern

sudo apt-get install libjson-perl libdigest-md5-file-perl liblwp-protocol-https-perl liblwp-protocol-http-socketunix-perl && sudo reboot

Nach dem reboot des Raspis steht sofort im state des Obis-Moduls "disconnected".
Ich habe daraufhin eine 2.SD-Karte ohne die "Withings-Pakete" versuchsweise im Raspi gestarted und Obis meldet "opend".

Wieso stören diese Pakete den Obis Betrieb und vor Allem, welche Abhilfsmassnahme gibt es dafür?

Gruß aus Köln
Norbert

[gvzdus]

Es wirkt sehr danach, als ob das neue Modul den Serial-Port belegt. Die Installation der Pakete allein löst (bei mir mit Rasbian Buster) zumindest nicht das Verhalten aus. Also würde ich prüfen, welchen Serial-Port das Modul verwendet.

Willst Du ausschließen, dass ein anderer Prozess sich den Serial-Port Deines SML-Readers geschnappt hat, könnte Dir fuser weiterhelfen:

root@sauerberry:/opt/fhem/log# fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0
/dev/ttyUSB1:         1035
root@sauerberry:/opt/fhem/log# ps -ef | grep 1035
fhem      1035     1 21 13:35 pts/0    00:01:52 perl fhem.pl fhem.cfg
fhem      1379  1035  1 13:35 pts/0    00:00:07 node /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg
root      3653   908  0 13:43 pts/0    00:00:00 grep 1035

[gvzdus]

Nachdem ich gespielt hatte, lief zwar mein SML-Gerät, dafür aber nicht mehr Homematic und der Conbee-(Zigbee)-Stick.
Ich habe das Paket "modemmanager" deinstalliert, das sich an den Serial-Ports zu schaffen machte:

Code Auswählen Erweitern

sudo apt-get remove modemmanager

Nach einem Reboot schnurrten die anderen Geräte wieder.

[cocojambo]

Ich werde mich heute nachmittag mal dransetzen, aber mir vorher eine SD Karten Kopie anlegen zum probieren.
Ich melde mich dann wieder.

Vielen Dank
Norbert

[cocojambo]

Ich habe wieder die Pakete geladen und sudo reboot gemacht und es kam wie erwartet disconnected.
Dann habe mit putty versucht den Lesekopf zu finden und es folgende Antwort:

Code Auswählen Erweitern

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 existiert nicht

Ein Neustart von FHEM und auch ein reload brachte nichts.
Ich habe daraufhin mal die Kabelverbindung zum Zähler im Keller unterbrochen und nach dem Einstecken kam diese Antwort:

Code Auswählen Erweitern

pi@raspberrypi-pi4-master:~ $ fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0
pi@raspberrypi-pi4-master:~ $


Aber nach jedem reboot des raspis ist die Verbindung wieder weg, und auch kein shutdown restart hilft.Ich müßte also immer in den Keller um die Verbindung kurzzeitig zu unterbrechen. Dann wird der Lesekopf wieder erkannt.
Leider kann ich aber im Moment nicht mehr weiter suchen, weil mir die USB Steckerverbindung kaputt gegangen ist und ich muß erst eine neues Verbindungskabel besorgen.

Dann kann ich weitere Versuche starten.
Gruß
Norbert

[gvzdus]

Ich bin kein Guru des Betriebssystems. Aber mit meinen 2Ct: Solange das Gerät nicht im /dev-Filesystem auftaucht, ist das ein Problem auf Betriebssystemebene (unwahrscheinlicher) oder - wahrscheinlicher - physikalischer Hardware.
Zu langes Kabel, kaputtes Kabel, Stromversorgung überlastet, etc.

[RalfRog]

Bin da jetzt auch nicht der Spezialist aber vielleicht hilft es ja auch mal mit "dmesg" (alternativ gibt es journalctl) auf der Konsole zu schauen ob und was beim ziehen/stecken USB-seitig ab-/angemeldet wird.
Das Device muss ja beim Reboot am gleichen USB-Port angemeldert werden. Kann man mal suchen ob es dazu während des Bootens eine (Fehler)Meldung gibt.
Ziehen/Stecken müssten solche Meldungen sein:

Code Auswählen Erweitern


[202276.456883] usb 1-1.3: USB disconnect, device number 7
[202276.458073] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[202276.458196] ftdi_sio 1-1.3:1.0: device disconnected


[202276.755751] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
[202276.913346] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[202276.913370] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[202276.913384] usb 1-1.3: Product: FT232R USB UART
[202276.913397] usb 1-1.3: Manufacturer: FTDI
[202276.913409] usb 1-1.3: SerialNumber: AL00F4TK
[202276.925488] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[202276.925772] usb 1-1.3: Detected FT232RL
[202276.927907] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0


Dazu gehört dann im /dev-Filesystem (FT232 am USB 1-3.1):

Code Auswählen Erweitern


pi@raspi-2:/opt/fhem $ ls  -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Sep 30 02:13 usb-FTDI_FT232R_USB_UART_AL00F4TK-if00-port0 -> ../../ttyUSB0

pi@raspi-2:/opt/fhem $ ls  -l /dev/serial/by-path/
insgesamt 0
lrwxrwxrwx 1 root root 13 Sep 30 02:13 platform-3f980000.usb-usb-0:1.3:1.0-port0 -> ../../ttyUSB0


Sinnvoll ist für eine eindeutige Zuordnung der USB/Seriell-Interfaces eine Definition über die ID - wie auch in der CommandRef erwähnt:
--> "or - to avoid wrong numbering on server reboots - use the ID of the USB device, e.g. /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0"

[cocojambo]

@gvzdus

Das mit der Betriebsspannung habe ich von Anfang an schon mit einem seperatem Netzteil gelöst.
Ich hatte mir in meiner Werkstatt ein Splittkabel gebaut das Daten und Versorungsspannung getrennt zusammenführt.
Die Kabellänge habe ich mit einem aktiven USB Kabel gelöst, das einen "Verstärker" im Kabel besitzt. Das ist jetzt mech.defekt und ich habe ein Neues geordert.
Das war aber auch von Anfang an ohne Probleme im Einsatz.

@RalfRog

Das mit dem direkten zuordnen des Lesekopfes über serial/by-id werde ich ,sobald das Kabel ersetzt ist, probieren. Ich meine das hätte ich irgendwann mal probiert, als Anfangs das OBIS Modul immer mal hängenblieb. Hatte in dem Fall aber kein Unterschied gemacht.

--------------------------------------------------

Wie gesagt, wenn der Lesekopf wieder Verbindung zum Raspi hat, melde ich mich.
Gruß
Norbert

[RalfRog]

Viel Erfolg 

aufgrund dieser Anmerkung von dir:

Dann habe mit putty versucht den Lesekopf zu finden und es folgende Antwort:

Code Auswählen Erweitern

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0JDXH6-if00-port0 existiert nicht
Ein Neustart von FHEM und auch ein reload brachte nichts.

scheint das Interface ja seitens Betriebssystem weg zu sein. Daher die Idee sich mit "dmesg" mal anzuschauen wann das Interface verschwindet bzw. ob und wie  es beim Reboot erkannt wird.
Vielleicht hatte das aktive Kabel ja ne Macke (nach "stromlos" erst wieder funktioniert) und alles ist mit nem neuen Kabel gut.

[cocojambo]

Das neue Kabel ist heute gekommen. Muß es erst aber durch den Kamin durchziehen.
Übrigens, der "USB Verstärker" und der Lesekopf werden ja nicht stromlos, da sie dauerhaft mit einem seperaten Netzteil versorgt werden.
Aber du hast recht, es könnte ja auch ein Defekt am Kabel sein.
Ich melde mich.

norbert

[cocojambo]

So Kabel drin und alles wieder angeschlossen, Neustart Raspi und der Lesekopf wird tatsächlich erkannt.

Code Auswählen Erweitern

2022.12.02 15:06:23 3: Opening ISKRA_MT691 device /dev/ttyUSB0
2022.12.02 15:06:23 3: Setting ISKRA_MT691 serial parameters to 9600,8,N,1
2022.12.02 15:06:23 3: OBIS (ISKRA_MT691) - Init done
2022.12.02 15:06:23 3: ISKRA_MT691 device opened
2022.12.02 15:06:23 3: OBIS (ISKRA_MT691) - Attr interval Val 30, dopoll =
2022.12.02 15:06:23 3: OBIS (ISKRA_MT691) - Attr pollingMode Val on, dopoll = 1

Auch ein shutdown restart bringt OBIS nicht durcheinander. Leider kann ich das alte Kabel nicht mehr vergleichsweise anschließen um zu sehen ob es daran liegt (habe ich zum Durchziehen zerteilt)

Hoffendlich bleibt es so.
Vielen Dank für Eure Ideen und Tipps

Norbert

[f_sieler]

Danke für das OBIS-Modul,
ich verwende es, seit einiger Zeit, für zwei Zähler (WS7412.2 und SGM-C4-1A620I). Mit dem SGM-C4.. funktioniert alles problemlos. Beim WS7412.2 gibt es ein Problem.
Im Bereich von ca.:327W bis ca. 680W werden negative Leistungswerte der Momentanleistung (power_L1) ausgegeben, die Absolutleistung (total_consumption) wird aber weiterhin richtig mit positiven Werten aufaddiert.
Habe ich etwas falsch konfiguriert?

Code Auswählen Erweitern


define Stromzaehler_Solar OBIS /dev/ttyUSB1@9600,8,N,1 SML
attr Stromzaehler_Solar event-on-change-reading .*
attr Stromzaehler_Solar room Energie
attr Stromzaehler_Solar stateFormat {sprintf("Leistung_absolut: %.0f kWh",ReadingsVal($name,"total_consumption",0) / 1000)}
attr Stromzaehler_Solar userReadings Power_kW {sprintf(ReadingsVal($name,"power_L1",0) / 1000)},\
Leistung_absolut {sprintf(ReadingsVal($name,"total_consumption",0) / 1000)},\
Energietagesertrag {sprintf("%.2f",get_d_Energieertrag('Stromzaehler_Solar', 'D_EnergieCNTATMIDNIGHT'));;},\
Energiemonatsertrag {sprintf("%.2f",get_d_Energieertrag('Stromzaehler_Solar', 'D_EnergieCNTAT1STDAYOFMONTH'));;},\
Energiejahresertrag {sprintf("%.2f",get_d_Energieertrag('Stromzaehler_Solar','D_EnergieCNTAT1STDAYOFYEAR'));;}\