esp32 friert bei Programmausführung unter Micropython ein.

Hajulied Es ist in der Regel eine gute Idee Quelltexte die man irgendwo posted vorher mal aufzuräumen.

In beiden wird time importiert und aus time dann noch mal sleep(). In der Boot-Datei wird nichts davon verwendet. Im Hauptmodul wird sleep() über das Modul und der explizite Import verwendet. Wonach wird da entschieden wann was benutzt wird? Das sollte einheitlich sein. Die Module micropython, ntptime und MQTTClient aus umqttsimple werden in der Boot-Datei importiert, aber nicht verwendet. Letzteres sollte im Hauptmodul importiert werden. Im Hauptmodul wird socket importiert aber nirgends verwendet.

Was ist der Zweck der „garbage collection“ direkt nach dem Start? taste, topic_sub und topic_sub werden definiert aber nirgends verwendet. Im Hauptmodul werden nbCharsR und nbCharsL definiert aber nirgends verwendet.

Und da sind einige Namen die eine posSerL sind. Namen werden in Python klein_mit_unterstrichen geschrieben, ausser Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase). Und sie sollten keine kryptischen Abkürzungen enthalten, oder gar nur aus solchen bestehen.

Konstanten werden per Konvention KOMPLETT_GROSS geschrieben. Und man sollte Sachen dort definieren wo sie auch verwendet werden. Ist ja nett, dass alles aus der Boot-Datei auch automagisch im main-Modul sichtbar ist, aber übersichtlich ist das nicht. Wenn man ein main-Modul hat, dann ist das boot-Modul auch fast überflüssig.

Man macht keine Vergleiche mit literalen Wahrheitswerten. Entweder kommt dabei der Wert heraus den man sowieso schon hatte, dann kann man den auch gleich verwenden, oder dessen Gegenteil. Dafür gibt es not.

global hat in einem sauberen Programm nichts zu suchen. Macht hier auch gar keinen Sinn, weil man das einfach weglassen kann, ohne das sich am Programmablauf etwas ändert. Was man leicht(er) gesehen hätte wenn die Konstanten wie Konstanten geschrieben worden wären.

Der %s Platzhalter im print() in connect() macht keinen Sinn, weil der durch nichts ersetzt wird. Diese uralte Ersetzungsmethode verwendet man aber sowieso nicht mehr wenn da nicht einen sehr guten Grund für gibt. Es gibt die format()-Methode auf Zeichenketten und f-Zeichenkettenliterale für so etwas.

statR und statL werden als leere Zeichenkette initialisiert die aber nur verwendet wird falls in den empfangenen Daten jeweils das gesuchte nicht gefunden wird. Sowie dort etwas gefunden wurde, wird beim nächsten nicht-finden der letzte gefundene Wert verwendet. Soll das so? Das sieht falsch aus.

str() mit einem bytes-Objekt als Argument aufrufen ist falsch. Man operiert nicht auf der Zeichenkettendarstellung von Objekten, das ist Murks.

Das Ergebnis von find() einfach so als Index verwenden ist falsch, denn wenn nichts gefunden wurde, dann gibt die Methode -1 zurück, was aber ein gültiger Index ist, aber ziemlich sicher nicht der, den man haben wollte. Die index()-Methode löst eine Ausnahme aus, wenn nichts gefunden wurde. An der Stelle fehlt im Code dann auch was in diesem Fall überhaupt passieren soll‽

Was soll passieren wenn das gefundene Zeichen keine der vier Ziffern ist? Momentan bleibt einfach der alte Wert bestehen und wird noch mal gesendet.

Die Verarbeitung der beiden Datenquellen ist extrem ähnlich, das sollte da nicht alles zweimal im Code stehen.

Zwischenstand (ungetestet):

"""
boot.py für VictronMon
Wlan_einschalten.py
ohne Zeitabfrage
"""

import esp
import network
import webrepl
from machine import Pin


esp.osdebug(None)

# WLAN
SSID = "FRITZ!Box XXXX"
PASSWORD = "7913xx"

station = network.WLAN(network.STA_IF)
station.active(True)
station.active(False)
station.active(True)
station.connect(SSID, PASSWORD)
while not station.isconnected():
    pass
print("Connection successful")
print("Mit WLAN verbinden...")
# webrepl.start()

Und:

# Victron Regler auslesen main2408.py
# ohne Display und mqtt
#
from time import sleep

import machine
from machine import RTC, UART, Pin  # `RTC` nur für den Testlauf.
from umqttsimple import MQTTClient

# MQTT_SERVER = "18.192.155.25"  # emqx
# MQTT_SERVER = "rcf7cfbb.ala.eu-central-1.emqxsl.com"
# MQTT_SERVER = "5.196.78.28"  # test.mosquitto.org
# MQTT_SERVER = "192.168.178.58"  # Raspi2
# MQTT_SERVER = "broker.emqx.io"  # funktioniert gut
MQTT_SERVER = "143.198.156.229"  # bevywise
MQTT_USER = "TRYghxx"
MQTT_PASSWORD = "q5L7Upxxx"
CLIENT_ID = machine.unique_id().hex().encode("ascii")


def connect():
    client = MQTTClient(
        CLIENT_ID, MQTT_SERVER, user=MQTT_USER, password=MQTT_PASSWORD
    )
    client.connect()
    print("Connected to MQTT broker")
    return client


def restart_and_reconnect():
    print("Failed to connect to MQTT broker. Reconnecting...")
    sleep(5)
    machine.reset()


def parse_data(data, previous_stat, last_three_serial_number_bytes):
    try:
        index = data.index(b"CS")
    except ValueError:
        #
        # TODO Was soll in diesem Fall passieren?
        #
        ...
    else:
        digit = data[index + 3 : index + 4]
        if digit == b"3":
            stat = " Bulk "
        elif digit == b"4":
            stat = " Absorp"
        elif digit == b"5":
            stat = " Float "
        elif digit == b"0":
            stat = "  Off"
        else:
            #
            # TODO Soll in diesem Fall tatsächlich der alte Wert bestehen
            #      bleiben und gesendet werden‽
            #
            stat = previous_stat

    try:
        index = data.index(last_three_serial_number_bytes)
    except ValueError:
        #
        # TODO Was soll in diesem Fall passieren?
        #
        ...
    else:
        volt = data[index + 7 : index + 12]

    return stat, volt


def main():
    #
    # TODO Bessere Namen für alles was kryptische Zusätze hat.
    #
    rtc = RTC()
    led = Pin(27, Pin.OUT)
    led(0)
    stat_r = stat_l = ""  # XXX Soll das wirklich so?

    uart_r = UART(1, baudrate=19200, tx=32, rx=34)  # nur rx ist notwendig
    uart_l = UART(2, baudrate=19200, tx=33, rx=35)

    while True:
        sleep(0.1)

        # data_r = uart_r.read()
        # nur für test eingefügt
        data_r = (
            b"\r\nPID\t0xA053\r\nFW\t164\r\nSER#\tHQ2224Y7NTA\r\nV\t28320\r\n"
            b"I\t10\r\nVPV\t46310\r\nPPV\t0\r\nCS\t5\r\nMPPT\t1\r\n"
            b"OR\t0x00000000\r\nERR\t0\r\nLOAD\tOFF\r\nIL\t0\r\nH19\t24807\r\n"
            b"H20\t101\r\nH21\t406\r\nH22\t112\r\nH23\t387\r\nHSDS\t192\r\n"
            b"Checksum\tA\r\nPID\t0xA053\r\nFW\t164"
        )
        sleep(0.1)

        # data_l = uart_l.read()
        data_l = (
            b"\r\nPID\t0xA053\r\nFW\t164\r\nSER#\tHQ2048JQL3U\r\nV\t28300\r\n"
            b"I\t10\r\nVPV\t45510\r\nPPV\t0\r\nCS\t5\r\nMPPT\t1\r\n"
            b"OR\t0x00000000\r\nERR\t0\r\nLOAD\tOFF\r\nIL\t0\r\nH19\t25253\r\n"
            b"H20\t95\r\nH21\t395\r\nH"
        )
        sleep(0.1)

        stat_r, volt_r = parse_data(data_r, stat_r, b"NTA")
        stat_l, volt_l = parse_data(data_l, stat_l, b"L3U")

        try:
            client = connect()
        except OSError:
            print("88 failed to connect")
            restart_and_reconnect()

        try:
            client.publish(b"inverter12021012025_net/victron/StL", stat_l)
            client.publish(b"inverter12021012025_net/victron/VL", volt_l)
            client.publish(b"inverter12021012025_net/victron/StR", stat_r)
            client.publish(b"inverter12021012025_net/victron/VR", volt_r)
            print("116 alles gesendet")
            print("Stunde, Minute, Sekunde", *rtc.datetime()[4:7])
            client.disconnect()
        except OSError:
            restart_and_reconnect()

        led(0)
        sleep(0.05)
        led(1)
        sleep(7)

main()

Besonders robust sieht die Verarbeitung der gelesenen Daten nicht aus.

Noch mal als Nachtrag zum letzten Satz: Die Verarbeitung ist falsch/fehlerhaft. Man kann nicht sicher sein, dass

1. beide Informationen innerhalb des mehr oder weniger zufälligen Ausschnitts, den man da aus dem Empfangspuffer liest enthalten sind, und
2. das eine Information nicht abgeschnitten ist, weil sie gar nicht komplett im Empfangspuffer enthalten ist. Das führt dann zu einem abgeschnittenen Wert oder sogar einem IndexError wenn nicht mal der Anfangsindex im Bereich der Daten liegt.

Dieses „Wir Suchen nach zwei oder drei Zeichen und zählen von da ausgehend Bytes, und ignorieren die Nachrichtenstruktur vollständig”, die da durch Zeilenenden und Tabulatorzeichen ja durchaus enthalten ist, ist kaputt. Es ist ja beispielsweise auch nicht garantiert, dass der Volt-Wert immer 5 Zeichen lang ist. Das die letzten drei Zeichen der Seriennummer verwendet werden, weil nach einem einzelnen "V" zu suchen noch problematischer ist, führt dazu, dass nach der Seriennummer immer die Volt-Angabe kommen muss, sonst funktioniert das auch nicht mehr. Solche Fehler erkennt das Programm dann auch gar nicht.

Das Protokoll sind Zeilen mit jeweils einem Schlüssel/Wert-Paar das durch ein Tabulatorzeichen getrennt ist. Das ist also gar nicht so schwer robust zu verarbeiten.

Wenn man zwei von aussen kommende Datenströme ”gleichzeitig” verarbeiten will, bietet sich das select-Modul an, statt mehr oder weniger willkürlich sleep() Aufrufe einzubauen, die auch dazu führen könnten, dass Empfangspuffer voll laufen und Daten verloren gehen können.

Problematisch ist auch das senden von jeweils vier Werten aus zwei verschiedenen Datenquellen. Die müssen nicht synchron sein oder exakt gleich schnell/häufig diese Werte liefern, dann kann man die gar nicht so als Viererpaket garantieren/liefern.

Ist halt die Frage ob man wirklich immer Spannung und Status erwischt und es gibt ja auch so etwas wie Übertragungsfehler, das irgendwo mal ein Bit kippt, und dann kommt man zu Fällen, die der Code nicht behandelt. Und man könnte das halt auch deutlich robuster mit viel Weniger Prinzip Hoffnung machen.

Moin!

Da ich den ESP32 nicht mit Mikropython betreibe, habe ich eine Frage. Reicht Python die Exception-Meldungen durch?
Z.B.: Watchdogmeldungen

73 de Bernd

Moin Bernd666

ja, wenn eine Exception ausgelöst wird, dann bekommt der Benutzer das mit.

Grüße
Dennis

Bernd666 Sieht man doch auch im ersten Beitrag, den KeyboardInterrupt der da ausgegeben wird.

Hajulied Hat denn der Quelltext den Du hier gezeigt hast auch das Problem das der stehen bleibt? Du sagst Du hast da Code entfernt. Wenn der so ewig läuft und nicht hängen bleibt, dann ist es ja ziemlich wahrscheinlich, dass das Problem in Code steckt, den wird nicht gesehen haben, weil Du den nicht gezeigt hast. Wenn man abgespeckten Code zeigt, muss man auch testen ob der immer noch Probleme macht, denn sonst hilft das ja nicht weiter wenn wir Code bekommen der das Problem gar nicht hat.

Moin!

__blackjack__ Ich meinte sowas:

Speicherfragmentierung kann man auch ausschliessen?

73 de Bernd

Bernd666 Ähm, was ist das denn? Das ist kein Python‽

Speicherfragmentierung kann man mehr oder weniger ausschliessen, beziehungsweise gibt es in dem Fall das kein Speicher mehr angefordert werden kann, einen MemoryError und der müsste ausgegeben werden.

Moin __blackjack__ ,

noe, ist es nicht.
Ich denke das Micropython ein Wrapper für die ESP-IDF ist und die gibt solche Meldungen aus.
Oder liege ich mit meiner Vermutung mit dem Wrapper total daneben?

73 de Bernd

Ich würde das nicht Wrapper nennen. Micropython verwendet diese API. Unter welchen Umständen wird denn so etwas ausgegeben?

Moin __blackjack__,

gut, dann nutzen sie halt die API.
Der "Fehler" wird immer dann ausgegeben, wenn es einen schwerwiegenden Fehler gibt. Z.B.: Wenn der Watchdog nicht rechtzeitig bedient wird.
Der ESP gibt diese Trace-Punkte aus und bootet dann.

Entschuldige, wenn ich da nicht tiefer darauf eingehe, aber es gibt so viele Möglichkeiten eine Exception auszulösen. Zumal ich, im Moment, nicht wirklich in der ESP-Welt zuhause bin. Eher bei dem Raspberry Pi Pico W....

73 de Bernd

Bernd666 Diese Ausgabe und Reboot passt nicht zu der Beschreibung „friert ein“, also vermute ich mal dass da was an dem Code hängt den wir nicht kennen. Was ich auch nicht für so unvorstellbar halte wenn ich den gezeigten Code und die Einstellung des Autors anschaue. Das gezeigte ist ja nicht wirklich robust, und ich habe nicht den Eindruck, dass das interessiert.

Moin Hajulied,

ich sach ma NOE. zum schliessen der Diskussion.
Grund dafür: Wir Helfenden wollen auch wissen, was nun ist. Also sind wir immer dankbar, wenn es eine Rückmeldung gibt.

73 de Bernd