RPi3 - Python 3 Uart Fehler nach zufälliger Zeit - UnicodeDecodeError: 'ascii'

Den Threadtitel bitte bearbeiten, das hat nicht geklappt. Ebenso das Post-Tag.

Zum eigentliche Problem: Seit über einem Monat, obwohl sich das nach 30 Sekunden suchen lösen lässt? Hmm.

https://stackoverflow.com/a/33239954/5952681

Immer noch falsch geschrieben.

Quote from xMicha

Ich mein aber nicht den Massage error sondern mir geht es um den UnicodeDecodeError: 'ascii'

Kann schon sein, dass da ab und zu mal Mist gelesen wird. Gibt dir halt den Bytestring vorm dekodieren mal aus und schaue nach, ob das nur Kauderwelsch ist. Die Info, ob es jedes mal "0xa7 in position 34" ist, hast du ja nicht gegeben.

Quote from xMicha

Aber in diesem Fall beendet er den kompletten Thread?!

Ja, weil eine Exception (AttributeError) geworfen wird, während du eine andere Exception (UnicodeDecodeError) abfängst. Also eine unabgefangene Exception, und das beendet dann den Hauptthread. Ist ja aber

Quote from xMicha

nur eine Sache nebenbei, die aber aktuell keine Prio für mich hat

Als Notmassnahme: die ganze Response mit and 0x7F auf den Ascii-Bereich begrenzen.

Als naechstes mal die Schnittstellenparameter genauer ansehen:

* 7Bit oder 8Bit Chars?

* Parity?

* ich glaube man kann den Terminaldriver so einstellen dass er das High-Bit ignoriert

Hallo,

Quote

Bin ein wenig zu sehr von anderen Programmiersprachen verwöhnt

Warum nimmst du dann nicht eine andere Programmiersprache?

Zu deinem Code:

_thread ist die low-level Schnittstelle, die man _nicht_ benutzen möchte, die möchtest das `threading` Modul nutzen.

Die massive Verwendung von `global`zeigt, dass du einen Fehler im Programmentwurf hast. Die Verwendung von `global` ist in 99,9% der Fälle falsch.

Anstatt einer Liste mit 20+ Einträgen solltest du vielleicht über ein Dict oder NamedTuple nachdenken.

Gruß, noisefloor

Hello xmicha, I have also a raspberry pi 3 and a stecca tarom and I want to read tarom data using its UART. Do you still have this working ?

Hello,

I think you should open your own thread, this is an old one.

If you do this, please write more details about your problem.

xMicha Ui toll, Python-Code. 😀

Das Problem mit dem _thread-Modul und dem global wurde ja bereits angesprochen.

solar sollte sowieso nicht ausserhalb sichtbar sein wenn die ganzen variablen mit den gleichen Daten ebenfalls sichtbar sind. Dann gibt es da ja keine einzelne Quelle der Wahrheit mehr weil Liste uns Einzelvariablen die gleichen Daten enthalten sollten das aber nicht zu jedem Zeitpunkt tatsächlich tun. So etwas ist bei nebenläufigen Programmen so gar keine gute Idee. Andere Threads können bei den ganzen Einzelvariablen auch nicht sicher sein, dass die alle zusammengehören und nicht welche noch alte Werte und andere schon neue Werte enthalten.

Serial-Objekte sind Kontextmanager die kann und sollte man also mit der with-Anweisung verwenden.

Die veraltete API von serial sollte man nicht mehr verwenden, also insbesondere alle Methoden und Attribute, die nicht der bei Python üblichen Namenskonvention entsprechen. Also beispielsweise reset_input_buffer() anstatt flushInput().

solar.clear() ist an der Stelle sinnfrei. Die Liste wird geleert und dann durch eine neue Liste ersetzt. Den Schritt die alte Liste zu leeren kann man sich sparen.

Wenn laut Beschreibung in den Daten eine zwei Byte lange Prüfsumme enthalten ist, dann ist ASCII natürlich falsch, denn ASCII kennt nur die Bytewerte 0 bis 127. Einfach nichts beim decode() anzugeben ist aber auch falsch, denn dann wird UTF-8 verwendet, was zwingend erwartet, dass die Bytes eben als solches dekodiert werden können. Das trifft aber nicht auf beliebige Bytefolgen zu, das heisst auch da wird die Prüfsumme Werte annehmen können die zu einem UnicodeDecodeError führen werden.

Wenn man beliebige Bytedaten als Text dekodieren möchte geht das immer sicher beispielsweise mit ISO-8859-1, weil da jedem Byte von 0 bis 255 ein Zeichen zugeordnet ist. ASCII ist eine Untermenge und Bytewerte ausserhalb von ASCII werden dann halt Zeichen zugeordnet, die hier eh nicht interessieren.

Sauberer wäre es natürlich die Bytes an den Semikolons zu trennen und dann erst die teile mit den Texten zu dekodieren. Und dann natürlich auch die Prüfsumme tatsächlich nachzurechnen und zu schauen ob die zum Rest der Nachricht passt. Denn nur dass man keinen Dekodierungsfehler bekommt, heisst ja noch nicht, dass die Daten valide sind.

Bei den logging-Aufrufen sollte man Werte nicht in Zeichenketten formatieren, sondern die Zeichenkette mit Platzhaltern und die Werte getrennt übergeben.

Die Funktion sollte das HTTPServer-Objekt als Argument bekommen und die Daten darauf setzen. Denn der HTTPHandler später kann auf den Server zugreifen und dort das Objekt lesen. Und zwar das Objekt als ganzes an einen lokalen Namen binden und nicht die Einzelwerte immer über den Weg über das Server-Objekt, denn sonst hat man wieder das Problem, dass die Werte nicht zu einem empfangenen Datensatz gehören müssen.

„Info“ ist nicht wirklich die richtige Logging-Stufe für unerwartete Ausnahmen. Da würde man eher „Error“ nehmen und das über logging.exception() machen um noch zusätzliche Informationen zur Ausnahme im Protokoll zu haben.

Der Code könnte dann so aussehen:

#!/usr/bin/env python3
import logging
import time
from collections import namedtuple

import serial

# WebSever zu Datenausgabe lasse ich mal codetechnisch weg

SolarData = namedtuple(
    "SolarData",
    (
        "datum zeit batteriespannung soc soh gesamtstrom eingangsstrom"
        "ladestrom laststrom temperatur error loadtoday loadtotal"
    ),
)


def read_uart(http_server):
    with serial.Serial("/dev/ttyS0", baudrate=4800) as connection:
        while True:
            try:
                connection.reset_input_buffer()
                data = connection.readline()
                logging.info("---- UART: Data recieved: %r", data)
                parts = data.split(b";")
                http_server.solar_data = SolarData(
                    *(
                        parts[i].decode("ascii")
                        for i in [1, 2, 3, 6, 7, 8, 9, 11, 13, 15, 16, 21, 22]
                    )
                )
            except Exception:
                logging.exception("---- UART: Unexpected error:")

            time.sleep(10)

BTW: Die letzte Aktivität von xMicha war der 15. März 2024

hyle Na es könnte ja aber auch noch jemand anders über die Frage und die Antwort stolpern. Oder wenigstens die LLMs in der nächsten Runde ein paar Zeilen mehr nicht ganz so schlechten Quelltext “lernen“. 😜

In fact I have the same hardware raspberry3 + steca tarom and I wanted to have help about it. I don't know which cable to use to connect them and I don't know if there is specific boot or OS configuration needed to have this working. The hardware is quite old and I'm sure it was done before so it would be better not to do it from 0.