OBIS Stromzähler TTY Schnittstelle fällt aus

Begonnen von joergi, 30 Oktober 2018, 08:14:54

Vorheriges Thema - Nächstes Thema

joergi

Hallo, hat jemand eine Idee?

Ich habe meinen Stromzähler über eine serielle TTY Schnittstelle angeschlossen.

Definition:
define Stromzaehler /dev/ttyS0@300,7,E,1 VSM102

Es werden dann auch die entsprechenden Readings generiert, aber irgendwann bricht wohl die Kommunikation ab.
Der Status ist aber immer noch "opened".

Reload des OBIS Moduls hilft nicht.

Ich ändere dann die Definition über die Web Oberfläche in:

define Stromzaehler /dev/ttyUSB0@300,7,E,1 VSM102
und wieder zurück nach
define Stromzaehler /dev/ttyS0@300,7,E,1 VSM102

Dann läuft es wieder eine Zeitlang.

Meine Idee ist das über einen Watchdog zu realisieren wenn eine bestimmte Zeit keine Werte kommen.

Ich habe jedoch keinen Ansatz gefunden.

Gruß Jörg




yoda_gh

Spricht das Ding ernsthaft 300 Baud 7E1? Das habe ich seit meiner Kindheit nicht mehr gesehen...

Icinger

3007E1 ist durchaus möglich, ja. Meiner sendet zB mit 96007E1.

Vielleicht pfuscht ein anderes Device da mit rein und "klaut" die ttyUSB0?

Versuch mal, dem Device einen fixen Pfad zu geben. zB lt. http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/
bzw. das selbe mit anderen USB-Geräten ebenfalls machen.

Somit hast du auch keine Probleme mehr nach eine reboot, wo gelegentlich die Geräte dann plötzlich eine andere Adresse haben.

lg, Stefan
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

yoda_gh

9600 Baud oder meinetwegenmeinetwegen nochnoch 2400 Baud macht Sinn, damit das serielle Kabel länger sein darf - mit heute üblichen 57600 oder 115200 darf man offiziell nur wenige Meter überbrücken. Aber 300 Baud ist die Geschwindigkeit von ersten Akkustikkopplern, üblich in den späten 70ern, kann mir nicht vorstellen, dass das korrekt ist. Daher würde ich vermuten, dass hier die Ursache der Instabilität liegt.

Und ttyS0 sollte eigentlicheigentlich immer ttyS0 bleiben, wenn ich den originalen Post richtig verstehe, wird ttyUSB0 nur kurz verwendet, um die Definition zurück ändern zu können.

Icinger

Nein, das hat (leider) schon seine richtigkeit.....Gibt einige Zähler, die mit solch langsamen Geschwindigkeiten rumgurken.

Das war mir schon klar, dass ttyUSB0 nur kurz "mißbraucht" wird......Was aber nicht bedeutet, dass ihm eine andere Definition irgendwo den ttyS0 "klaut"
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

yoda_gh

Zitat von: Icinger am 31 Oktober 2018, 07:32:44
Das war mir schon klar, dass ttyUSB0 nur kurz "mißbraucht" wird......Was aber nicht bedeutet, dass ihm eine andere Definition irgendwo den ttyS0 "klaut"

Wenn jemand parallel ttyS0 öffnet und die Übertragung stört, werden aber udev-Regeln nicht vIel bringen, es sei denn, man schränkt die Rechte des Device so ein, dass nur noch FHEM lesen kann - aber erstens ist das ein Glücksspiel, wenn man nicht weiß, wer die andere Partei ist, und zweitens kann es nicht helfen, wenn es eine andere FHEM-Definition ist.

Da wird nur helfen, den Störenfried ausfindig zu machen (zB. im Fehlerfall mal in einer Shell "lsof | grep ttyS0" ausführen), wenn es denn einen gibt oder sich mit einen Workaround zu behelfen, wie anfänglich ja auch die Idee war.

Von sich aus sollten weder ein normales Linux noch FHEM einfach so an der seriellen Schnittstelle spielen - es sei denn, es ist ein Überbleibsel einer alten Definition noch aktiv, um den Stromzähler zu lesen, in oder außerhalb von FHEM. So was gibt's nicht, oder?

KölnSolar

Du könntest es z.B. mit einem periodischen at und ReadingsAge lösen
define check_working at +*00:00:05 {if (ReadingsAge('OBISdevice','state',100) > 60 ) {....Alarmierungsbefehle.....}

Ich hab bisher auch das ein oder andere Mal einen Ausfall der USB-Schnittstelle gehabt. Mit einem modify OHNE etwas an der config zu ändern läuft sie dann wieder. Als Ursache tippe ich auf mangelhafte Spannungsversorgung am Rpi(OBIS-USB nur an passivem USB-Hub).
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

ingo1870

Ich hatte aktuell diese Ausfälle, und zwar begannen sie als ich
stateFormat definierte. Ich denke der Fehler ist hier im Code:

sub OBIS_Ready($)
{
  my ($hash) = @_;
  return DevIo_OpenDev($hash, 1, "OBIS_Init", $hash->{helper}{NETDEV} ? "OBIS_Callback" : undef)
                if($hash->{STATE} eq "disconnected");



muss

sub OBIS_Ready($)
{
  my ($hash) = @_;
  return DevIo_OpenDev($hash, 1, "OBIS_Init", $hash->{helper}{NETDEV} ? "OBIS_Callback" : undef)
                if(DevIo_getState($hash) eq "disconnected");



heißen.

Denn $hash->{STATE} enthält das definierte stateFormat. DevIo_getState schaut dagegen auf das Reading state.
Vergleiche auch 00_CUL.pm.