pyserial stoppt nach ca 10 Minuten

[Bunta]

Hallo,
Ich habe mich wohl schon durch dieses Forum und durchgoogle gesucht aber komme keine Lösung die mir hilft. Den Code reiche ich später nach sobald ich zu Hause bin. Dennoch beschäftigt dieses Thema die ga Zeit Zeit das ich meine Frage los werden muss.
Ich habe ein atmega über einen ftdi mit dem pi verbunden und lese dort den Serial Verkehr aus. Dies sind Daten von Nodes die Wetter, und andere Daten, übermitteln. Mit Hilfe von pytho schreibe ich diese in eine MySQL Datenbank.

Das funktioniert auch echt super... für 10 ca 10 Minuten. Danach stoppt irgendwas im Script oder in der Serial Verbindung von pyserial. Es kommt kein Fehler. Am ftdi kann man gut erkennen das immernoch Werte ankommen und an den pi gesendet werden. Dieser verarbeitet es aber nicht. Wenn ich das script beende und neu starte geht es wieder für 10 Minuten bevor es den Dienst verweigert.

Wenn ich mein Gateway mit dem ftdi an eine Windows PC anschließe und z.b. über die arduino ide den seriellen stream verfolge kann ich das machen solang ich mag ohne Probleme.

Hat hier einer Rat?
Die Serial Verbindung in pyserial habe ich schon mit diversen timeouts probiert. Immer das selbe :/

Danke euch.

[__blackjack__]

@Bunta: Da kann man ohne Code nicht viel zu sagen. Deine Beschreibung klingt so als hättest Du auch noch nicht mal mindestens `print()`\s im Code verteilt um zu sehen was ausgeführt wird und an welcher Stelle es dann hängt. Statt `print()` ist auch das `logging`-Modul einen Blick Wert, weil man dann die Ausgaben im Code lassen kann und über das Loglevel und/oder verschiedene Logger festlegen kann ob tatsächlich etwas ausgegeben werden soll und was.

[Sirius3]

Wenn das serielle Terminal unter Windows funktioniert, würde ich das selbe erstmal auf dem Raspi mir anschauen, um zu entscheiden, ob es ein Hardware-Problem ist, oder ein Python-Problem.

[__deets__]

Ich haette ja - passende Pegel vorrausgesetzt - den PI direkt mit seinem UART an den ATmega gehangen. Statt ueber FTDI zu gehen. Aber wie dem auch sei, dort vermute ich mal eher das Problem, also im USB-Subsystem. Von Seiten pyserial kann man da nur so viel machen. Du kannst auch ggf. mal probieren mit "screen /dev/ttyUSB0 <bps>" arbeiten & dir anschauen, was da so ueber die Leitung kommt, und ob das auch irgendwann haengt. Dann mal mit dmesg nach Meldungen vom USB-Subsystem fischen.

[Bunta]

Hier mal der Code.

Code: Alles auswählen

import serial
import MySQLdb
from datetime import datetime
 
ser = serial.Serial('/dev/ttyUSB0',57600, timeout=1)
 
try:
        con = MySQLdb.connect(host="localhost", user="DatenbankUser", passwd="GeheimesPasswort", db="DatenBankName")
except:
        print "Verbindung zum SQL-Server fehlgeschlagen!"
        exit(0)
 
while (1):
        read_data = ser.readline()
        if(len(read_data)>0):
                da = read_data.split(';')
                now = datetime.now()
                f_date = now.strftime('%Y-%m-%d')
                f_time = now.strftime('%H:%M:%S')
                cur = con.cursor()
                cur.execute("INSERT INTO rbgn_nodes_data (Node,Batterylevel,Humidity,Pressure,Temperature,Brightness,Day,Time) VALUES (%s,%s,%s,%s,%s,%s,%s,%s)", (da[0],da[1],da[2],da[3],da[4],da[5],f_date,f_time,))
                cur.close()
                con.commit()
 
ser.close()

Prints hatte ich schon an allen möglichen stellen. Wie gesagt. Das programm läuft weiter ... aber irgendwie erkennt es den Seriellen Stream nicht mehr der vom Atmega.

[__deets__]

Und um das besser zu debuggen printe bitte mal gleich nach dem ser.readline() das Ergebnis aus. Mit deinem timeout sollten dann eigentlich nach den 10 Minuten Leerzeilen kommen. Kommen die?

Ein paar Anmerkungen zum Code:
- if und while sind keine Funktionen, spar die die ganzen Klammern.
- statt 1 nimmt man True fuer Endlosschleifen.
- statt len(read_data) > 0 reicht ein simples 'if read_data'.
- statt den Zeitpunkt muehselig in zwei Spalten zu stopfen, nimm EINE Spalten in der Datenbank vom Typ timestamp. Und die kann dann auch gleich das datetime-Objekt benutzen, statt da von Hand rumzuformatieren.

[Sirius3]

noch mehr Anmerkungen zum Code:
keine nakten excepts. Die "Fehlerbehandlung" verhindert, herauszufinden, warum die Verbindung nicht geklappt hat. Also am besten einfach weglassen.

Keine Abkürzungen für Variablennamen benutzen: con -> connection, ser -> serial, da -> ???. Keine unsinnigen Präfixe, was soll das f_ bedeuten?

Python2 ist veraltet. Benutze Python3.
MySQL kann selbst das aktuelle Datum einfügen, entweder als default-Wert oder über die NOW-Funktion.

Code: Alles auswählen

from serial import Serial
import MySQLdb

connection = MySQLdb.connect(host="localhost", user="DatenbankUser", passwd="GeheimesPasswort", db="DatenBankName")
with Serial('/dev/ttyUSB0',57600, timeout=1) as serial:
    for line in iter(serial.readline, ""):
        entry = line.split(";")
        cursor = connection.cursor()
        cursor.execute("INSERT INTO rbgn_nodes_data (Node,Batterylevel,Humidity,Pressure,Temperature,Brightness,Timestamp) VALUES (%s,%s,%s,%s,%s,%s,NOW())", entry)
        cursor.close()
        connection.commit()

[__blackjack__]

@Bunta: Anmerkungen zum Quelltext: Bitte nix mehr mit Python 2 anfangen. Das hat mittlerweile weniger als ein halbes Jahr bevor es dafür keinen Support mehr gibt: https://pythonclock.org/

Eingerückt wird mit vier Leerzeichen pro Ebene.

`exit()` sollte man nur verwenden wenn man auch tatsächlich den Rückgabecode für den Aufrufer angeben will. Sonst ist das einfach nur ein Hack den Code unstrukturiert verlassen zu können. Das bräuchte man nicht, wenn man ``else`` zum ``except`` verwenden würde.

Aber diese Ausnahmebehandlung ist sowieso mist. Denn wenn da „Verbindung zum SQL-Server fehlgeschlagen!“ ausgegeben wird, fragt man sich ja als nächstes *warum*. Die Information wird aber unterdrückt. Einfach weg mit dem ``try``/``except``.

`Serial`-Objekte sind Kontextmanager, können und sollten wenn möglich mit ``with`` verwendet werden. Dann wird das auch geschlossen wenn die ``while``-Schleife verlassen wird – egal warum.

Datenbankverbindungen sind laut DB API V2 keine Kontextmanager – da kann man mit `contextlib.closing()` nachhelfen. Das kann man auch für `Cursor`-Objekte verwenden.

Die ``while``-Schleife kann man durch eine ``for``-Schleife über das `Serial`-Objekt ersetzen.

Du gehst da irrtümlicherweise davon aus, dass die Zeile vollständig ist sofern mindestens ein Byte gelesen wurde: dem ist aber nicht so! Ich verstehe sowieso nicht warum Du da ein Timeout einbaust‽

[Bunta]

Soo danke erstmal für eure Zahlreiche Antworten. War leider nicht am PC gestern. Daher erst heute eine Antwort von mir.

@__deets__
Korrekt. Es kommen dann nur noch Leerzeilen. Aber der serielle Verkehr wird nicht mehr ausgegeben. Daher dachte ich ja das was mit dem "Serial" von Python nicht stimmt oder ich etwas vergessen habe.

Danke für die Anmerkungen.
Sollte nur was schnelles sein aus Snippets zusammenkopiert aus dem Netz. Dort stand dann auch das "(1)" anstelle von True. Bzw. habe ich beides häufiger gesehen.
Das mit dem Zeitpunkt "mühseelig" in zwei Spalten zu stopfen ist gewollt. Den Timestamp habe ich sowieso. Dieser ist in der DB aber so eingestellt das er sich bei jedem Update ändert. Danke aber für den Tipp.

@Sirius3
Jawohl wird gemacht! Nicht nackt ausziehen Spass bei seite, lasse dann mal den Try block weg.

Sollte eigentlich nur für mich sein, daher die kurzen namen. Klar zum Lesen für euch etwas ungünstig. Das "da" sollte DataArray bedeute... bis ich herausgefunden habe das es eine List ist. Das ist etwas was ich an Python nicht mag... Hier stopft man alles in Variablen ohne zu wissen welcher Datentyp es ist. Finde ich gruselig!

Ich hatte das installiert was in Raspberry mit bei war als Standard in in einer frischen installaation eines Images von Raspbian vom July 2019. Konnte ja nicht ahnen das da solch Antiquitäten als Standard angeboten werden. Änder ich dann auch mal ab. Funktionieren sollte es aber dennoch und daher belasse ich es für diesen Thread erstmal bei Python2. Ok oder ist das schlimm?

Deine Code läuft natürlich nur genau ein mal. Dann beendet sich das Programm mit oder ohne input seitens Serial. Ich brauche ja eher eine "Serial Listener" der schaut ob was rein kommt, und das was dann rein kommt verarbeitet.


@__blackjack__
Wenn es läuft installiere ich Python 3 und baue es um versprochen!

Jawohl rücke nur noch 4 mal ein, kein Tab mehr (8 Zeichen) liegt am Editor!

Kein exit mehr! Verstanden ... wurde gelöscht. War aus einem Snippet aus dem bösen Internet.

Das mit "with" habe ich aus dem Code von Sirius3 so übernommen. Ich denke so hast du das auch gemeint.

Wie genau meinst du das mit der For-Schleife? Aber gut bei Python scheint alles etwas anders

Du hast vollkommen recht. Davon bin ich ausgegangen. Auch davon, dass wenn ich mehr als einen Node an den Gateway senden lassen das dann jeder Empfang als eigene Zeile ankommt. Also sozusagen das Ende der Zeile die gelesen wird zeigt "Nachricht ist zuende, was jetzt noch im Buffer ist ist eine neue Zeile und somit neuer DB Eintrag". Dem ist also nicht so?

Das mit dem Timeout war eine von vielen eigenen Versuchen das irgendwie zu lösen. Ich hatte irgendwo gelesen das dadurch das "hängen bleiben" gelöst wird. Und ganz ehrlich. Ohne diesen kommt gar nichts an. So bekomme ich wenigstens in den ersten Minuten etwas.

@An Alle
Ich muss ja irgendwie den (ich nenne es mal Kanal) Seriellen Kanal offen lassen. Dann muss ich ja schauen ob da was rein kam und ob es ein "vollständiger Datensatz" ist. Also z.B. ein EOL oder sowas. Wenn ja dann print/oder in DB. Wenn nein dann warte noch.
Ich stelle mir das so vor, dass das programm entweder alle z.B. 5 Sekunden schaut ob was im Serialbuffer ist und das dann in die DB schreibt (sofern komplett), oder eine Art Listener besteht der nur dann anspringt sobald eine Zeile komplett in den Buffer geschrieben wurde und dann diese in die DB schreibt.
Evtl. war ich ja mit meiner anfänglichen Idee auf dem Holzweg. Nehme gern neue Ideen entgegen.

[__blackjack__]

@Bunta: „In Variablen stopfen“ ist an sich in Python ein falsches sprachliches Bild. Variablen sind nichts wo man etwas rein tut. In Python bindet man Namen an Werte. Die Adresse wo das im Speicher liegt hängt nicht am Namen, sondern am Wert. Genau wie der Typ nicht am Namen hängt, sondern am Wert. Also anders als beispielsweise bei C wo Adresse und Typ am Namen hängen.

Ob etwas ein Array oder eine Liste ist, ist egal solange man es nur als Sequenz oder gar nur als iterierbares Objekt behandelt.

Man kann Python 2 und 3 problemlos beide installiert haben. ``python`` ist Python 2.x und ``python3`` ist Python 3.x. Debian, und damit Raspbian, bietet schon ziemlich lange beides zum installieren an. Für diesen Thread ist 2 an sich nicht schlimm, ausser der zöge sich länger als bis zum Januar 2020, wenn Python 2 nicht mehr supported wird, hin. Wobei ich davon ausgehe, dass Linux-Distributionen auch Python 2 noch mit Sicherheitsupdates versorgen werden solange die Distributionsversion noch Support hat.

Was für Python 3 *jetzt* sprechen würde, ist das der Unterschied von Bytes und Zeichenketten und die entsprechenden Änderungen von Python 2 nach 3 dein Programm ziemlich direkt betreffen.

Tab ist übrigens ein Zeichen. Wo die Tabstopps gesetzt sind, hängt dann sehr von der Umgebung und deren Einstellungen ab. Editor, Webbrowser, Terminal, E-Mail-Client, grafische Oberfläche für Versionskontrollsoftware – die können und haben unterschiedliche Ideen davon was denn nun genau ein Tab ist.

Mit der ``for``-Schleife ist gemeint das `Serial`-Objekte iterierbar sind. Also ``for line in ser:`` iteriert über die Zeilen von `ser`.

Wenn Du ein `timeout` gesetzt hast, dann wird das auch von `readline()` berücksichtig, denn das verwendet ja unter der Haube `read()`. Wenn `readline()` trotz `timeout` blockieren würde, wozu wäre dann das `timeout` gut? `readline()` liest dann solange bis entweder ein '\n' gelesen wurde, oder `timeout` erreicht wurde, und gibt das bis dahin gelesene dann zurück. Wenn die Zeile also kein '\n' am Ende hat, dann ist sie nicht vollständig gelesen worden.

Hast Du es denn mittlerweie auf dem Raspi auch erst einmal mit einem Terminalprogramm versucht, um zu schauen ob das Problem auch ausserhalb Deines Codes schon existiert?

[Bunta]

Ok das „In Variablen stopfen“ habe ich der einfachheit halber geschrieben ohne gleich aus den Fachbüchern zitiren zu wollen. Wie das ganze bei C, C++, C#, Java, CAL, AL, usw usw aussieht ist mir klar. Diese sprachen benutze ich selber.
Ferner ist mir bewusst das Tab ein Zeichen ist. Man kann es aber in Editioren auch als "Leerzeichen" * n ausben lassen. Ist bei mir der Fall. Daher schrieb ich das oben genau so
Mir ist auch bewusst das man die beiden Versionen nebeneinander Installieren kann. Ich wollte nur, wenn es nicht wie hier nötig wäre, das Wechseln der Version im Thread vermeiden. Gut geht hier macht es sinn also wechsel ich.
Das Serial iterierbar ist konnte ich schon dem Code von Sirius3 entnehmen. Ich dachte nur noch einmal draußen herum. Weil ich wenn ich den Code von Sirius3 nehme ist nach einmal durchlaufen ende. Und hier würde ich sonst eine While nehmen die den Code immer wieder ausführt. Weil zwischen den seriellen Daten sind auch mal längere Pausen wo nichts kommt, weil gerade kein Node sendet.

Nein habe ich nicht weil ich keine GUI aktuell installiert habe. Werde es nachholen.

Ich bin dir wirklich sehr dankbar für deine ausführlichen erklärungen wie z.B. über den Tabstop, würde mich aber gern auf das wesentliche beschränken wenn das ok ist? Hoffe kommt nich falsch rüber.

[__blackjack__]

@Bunta: Wenn Dir das mit dem „duck typing“ bei Python nicht behagt und Du auch andere Sprachen kannst, dann könntest Du auch eine andere Sprache verwenden. Der Raspi ist ja letztlich ein relativ normaler Linuxrechner mit einem Haufen Optionen was Programmiersprachen angeht.

Im Code von Sirius3 wird nicht über das `Serial`-Objekt iteriert! Dort wird mittels `iter()` und der `Serial.readline()`-Methode ein Iterator erstellt der aufhört wenn das erste mal eine leere Zeichenkette kommt. Die kann durch das `timeout` entstehen. Wenn man über das `Serial`-Objekt direkt iteriert, dann hört das nicht auf wenn durch das `timeout` nichts gelesen wird, sondern läuft immer weiter.

Wobei ich den Sinn vom `timeout` wie gesagt nicht verstehe, denn Du willst ja eigentlich immer ganze Zeilen haben und Du machst ja auch nicht irgend etwas anderes wenn die Zeitüberschreitung erreicht ist.

Wieso GUI? Es gibt Terminalprogramme für, äh, das Terminal. Einfachster Kandidat wurde von __deets__ bereits in seinem ersten Beitrag hier im Thema angesprochen: ``screen /dev/ttyUSB0 <bps>``. Und wenn's hakt auch mal in den Protokolldateien nachschauen ob der Kernel da vielleicht etwas zu zu sagen hat.

[Bunta]

Stoppe das hier. Danke allen! Mit der anderen Sprache hats geklappt.