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

[RalfRog]

Naja, wenn

Code Auswählen Erweitern

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0wirklich existiert könntest du ja in der Definition zum Test mal einen alternativen Pfad zum Serialdevice probieren.

Gruß Ralf

[alkazaa]

zum Test mal einen alternativen Pfad zum Serialdevice probieren.

Die Antwort überfordert mich jetzt. Warum sollte ich einen nicht-existierenden Pfad nehmen?
Ich habe zwei USB devices:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13  4. Jul 14:25 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13  4. Jul 14:25 usb-FTDI_FT232R_USB_UART_A9078004-if00-port0 -> ../../ttyUSB1
pi@raspberrypi:~ $ ls -l /dev/serial/by-path
insgesamt 0
lrwxrwxrwx 1 root root 13  4. Jul 14:25 platform-3f980000.usb-usb-0:1.1.3:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13  4. Jul 14:25 platform-3f980000.usb-usb-0:1.2:1.0-port0 -> ../../ttyUSB1
pi@raspberrypi:~ $Am USB1 hängt der Weidmann-Kopf, an USB0 ein CUL. Mein separates Testprogramm arbeitet korrekt mit "usb-FTDI_FT232R_USB_UART_A9078004-if00-port0".
Ich habe trotzdem mal
defmod E_Zaehler OBIS /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0,7,E,1 MT382
probiert. Mit gleichem Misserfolg.
Ich werde mal alle ports des Raspi durchprobieren. Verstehe aber trotzdem nicht, warum das Testprogramm funktioniert und 47_OBIS.pm (bzw. das darin aufgerufene DevIo.pm) nicht.

Gruß Franz

[RalfRog]

Die Antwort überfordert mich jetzt. Warum sollte ich einen nicht-existierenden Pfad nehmen?

Es geht nicht um einen nicht existierenden Pfad, sondern einfach nur darum einen möglicherweise wie auch immer gearteten Schreibfehler zu umgehen und das Device über einen seiner anderen Namen anzusprechen.

Code Auswählen Erweitern

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0
gleich
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0
gleich
/dev/ttyUSB1
War einfach als schneller kurzer Versuch gedacht, da ja die Fehlermeldung meint es gäbe "No such file or directory".

Update:
In der Commandref ist die Baudrate (@19200) noch aufgeführt  => "define myPowerMeter OBIS /dev/ttyPlugwise@9600,7,E,1 VSM102". Keine Ahnung wie das Modul den String auseinanderpflückt.

Die Hardware, Datenübertragung und Platzierung des Lesekopfes stimmen ja.

Gruß Ralf

[alkazaa]

Das mit der baudrate 19200 war im Testprogramm. Hatte ich nur gezeigt, um zu demonstrieren, dass sowas auch geht.

Im FHEM Kontext hatte ich mit der Standardrate 300 gearbeitet.

Zur Vorgeschichte: Ich habe jahrelang mit 300 bd gearbeitet, aber dann hat mich der Teufel geritten und ich wollte es endlich mal hinkriegen, die leidige Baudratenumschaltung bei einem Zähler dieses Typs zu realisieren. Was m.W. bisher keinem wirklich gelungen war. Zu dem Zweck habe ich erstmal außerhalb FHEM mit dem besagten Testprogramm ermittelt, was überhaupt "geht". Das klappte überraschenderweise bis bd=19200, und ich habe dann die 47_OBIS.pm mit meinen Erkenntnissen soweit abgeändert, bis es da auch funktioniert (300 bd ohne Umschaltung hat ja immer schon funktioniert). Mit einer Einschränkung: nach (im Mittel) 12..24 Stunden hat sich das ganze immer wieder aufgehängt und war nur mit einer Art 'Reset' wieder hinzukriegen. Der Reset bestand darin, einen Lesezyklus wieder ohne Umschaltung mit baud 300 zu machen und dann wieder auf höhere baud zu wechseln (9600 habe ich dafür immer genommen). Zuerst hatte ich den 'Reset' händisch gemacht, wenn ich merkte, dass wieder mal Daten fehlten. Dann hatte ich das automatisiert (per watchdog), und irgendwann ging dann nichts mehr (und ich bin ratloserweise ins diesem thread gelandet).

Wie auch immer: für mich deuten die Symptome darauf hin, dass die Port-Eröffnung in DevIo.pm, was die Port-Parameter angeht, viel kritischer gehandhabt wird als in dem Testprogramm. Ich habe aber keine Idee zum debugging in DevIo.pm, da werd ich mich wohl einfuchsen müssen.

Es sei denn, @rudolfkoenig liest hier mit, er ist ja der Vater von DevIo.pm. Ich denke aber insgesamt, dass meine Frage in einem anderem Thread vielleicht besser aufgehoben ist, da es eher kein 47_OBIS Problem ist. Mal schaun, welcher thread geeigneter ist.

Gruß Franz


Addendum:
Das hier war übrigens meine watchdog Definition, um den Lesekopf zu resetten, wenn er hängenblieb:

Code Auswählen Erweitern

defmod E_Zaehler_watchdog watchdog E_Zaehler:SerialNumber.* 00:02:00 E_Zaehler:SerialNumber.* {fhem ("set Pushover1 msg message='E_Zaehler stoooockt' sound='none'");;;;fhem("defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 MT382")} 

[RalfRog]

Na das klingt aber nach deutlich mehr als in #1694

Hallo zusammen!
Ich habe einen Fehler der Kategorie "Das ging doch gestern noch...".
Und zwar habe ich seit gestern keine Kommunikation mehr über die serielle Schnittstelle (mit der per USB ein Weidmann IR-Lesekopf ausgelesen wird).
Beim Befehl
Code Auswählen Erweitern

Code Auswählen Erweitern

defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0,7,E,1 MT382kommt die Log-Meldung:
Code Auswählen Erweitern

Code Auswählen Erweitern

E_Zaehler: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0,7,E,1: No such file or directory
Ein separates Perl-Testprogramm hat dagegen keine Probleme. Es liefert die Zählerdaten (sogar mit baudraten bis zu 19200)  , z.B.:
.........

[alkazaa]

Na das klingt aber nach deutlich mehr als in #1694

Ja, sorry. Aber ich wollte mit der komplexen Vorgeschichte nicht vom Kernproblem ablenken. Ich wüsste auch nicht, wie die Vorgeschichte zum Problem geführt haben könnte, denn Hänger gab es auch vorher schon, waren aber immer durch Ab/Anstöpseln heilbar.

EDIT:
Ich werd jetzt mal Dinge austauschen, die austauschbar sind:
a) Software: letztes Image (vom Ende Mai) auf den Raspi bringen
b) Hardware: das aktuelle Image auf meinen Backup-Raspi bringen (identischer Typ 3B+)
c) Soft- und Hardware: das Mai Image auf den Backup Raspi
Den IR-Lesekopf hab ich nur einmal, kann ich also nicht tauschen.
Mal schauen, ob (und in welcher Konfiguration) ich den alten Zustand wieder herstellen kann. Irgendwas muss sich ja irgendwo geändert haben.