Hallo Foren Mitglieder,
ich habe mit einem Raspberry Pico W und DS18X20 Sensoren vor, meine
Fußboden Heizungstemperaturen auszulesen. Leider bekomme ich nach Tagen
bis zu Wochen irgendwann keine Daten mehr über MQTT gesendet, nur weiß
ich nicht warum...
Kann da jemand drüber schauen, wo der Fehler liegt?
geschrieben mit Micropython.
Verbindung zum "ioBroker"
Wenn keine Daten mehr kommen, bleibt die WLan Verbindung aufrecht.
Google-Bard meinte ich solle in der Funktion getTemp() try & except
einfügen. hat aber auch nicht geholfen...
Bitte um Hilfe.
Dank & Gruß,
Jack
Jack schrieb:> Google-Bard meinte ich solle in der Funktion getTemp() try & except> einfügen.
Nein!
Du findest heraus wo es hängt und stocherst nicht blind und ziellos im
Nebel herum.
Solltest du dann immer noch zu keinem vernünftigen Ergebnis kommen, als
Holzhammer-Methode wirkt WDT Wunder.
Und du solltest das beachten:
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Darf ich anfügen, dass das mein erster Mikrocontroller mit "meinem" -aus
allen möglichen Codeteilen zusammen gebasteltes- erstes Programm ist?
Und ich keine Ahnung habe WIE ich den Fehler finden soll, wenn ich so
manches an Code noch gar nicht verstehe?
Darf ich wenigstens um einen Hinweis bitten?
Jack schrieb:> Darf ich anfügen, dass das mein erster Mikrocontroller mit "meinem" -aus> allen möglichen Codeteilen zusammen gebasteltes- erstes Programm ist?> Und ich keine Ahnung habe WIE ich den Fehler finden soll, wenn ich so> manches an Code noch gar nicht verstehe?
Wissen wir ja nicht. Unsere diversen Glaskugeln sind gerade alle beim
Polieren und bekommen Updates.
Ein gutes Hilfsmittel sind z.B. Debugausgaben auf der seriellen
Schnittstelle. Das bedeutet allerdings, dass immer ein Terminal
mitlaufen muss. Oder du lässt die Wlan-Verbindung immer stehen und gibst
dort deine Meldungen aus. Irgendeinen Tod musst du halt sterben. Und 9
Onewire-Sensoren sind auch eine Menge. Wenn einer nicht mehr mag, geht
nichts mehr. Wie sieht's mit EMV aus? Wie lange ist die Leitung zu den
Sensoren. Ist sie geschirmt oder nicht. Welche Geräte sind in der Nähe,
die Störungen verursachen können? Wie gesagt, unsere Glaskugeln sind
momentan nicht verfügbar!
Wie haben wir das früher nur gemacht?
Moment … ja … genau … so war das … viel gelesen und gelernt.
Im Kleinen verschiedene Dinge ausprobiert, wie funktioniert dieser
Maschinenbefehl, wie reagiert jenes Flag.
Heute ist das alles viel einfacher, Google-Copy-Paste-Ask-Wait.
Helmut -. schrieb:> Ein gutes Hilfsmittel sind z.B. Debugausgaben auf der seriellen> Schnittstelle. Das bedeutet allerdings, dass immer ein Terminal> mitlaufen muss. Oder du lässt die Wlan-Verbindung immer stehen und gibst> dort deine Meldungen aus. Irgendeinen Tod musst du halt sterben.
Die DS18x20 sind auch bei mir manchmal bockig, gerade bei längeren
Leitungen (bei mir sind es 3 Sensoren über ca 8 m). Deswegen würde ich
zum debuggen Fehler provozieren, lass z.B. eine serielle Konsole
mitlaufen und mach mal absichtlich Wackelprobleme an der Sensorleitung.
Du kannst auch zusätzliche LEDs an die GPIOs hängen und die vor und nach
einem Berfehl ein- und ausschalten, dann siehst Du, wo es hängt. Und
schliess die DS18x20 3-polig an, nicht 2-polig im parasite-Modus
Norbert schrieb:>> Google-Bard meinte ich solle in der Funktion getTemp() try & except>> einfügen.
Das ist schon die richtige Stelle, um festzustellen, ob sich ein Sensor
verabschiedet hat. Wird den ein "ERROR" über MQTT gesendet, wenn du
einen Sensor testweise abklemmst?
Joe G. schrieb:> Norbert schrieb:>>> Google-Bard meinte ich solle in der Funktion getTemp() try & except>>> einfügen.>> Das ist schon die richtige Stelle, um festzustellen, ob sich ein Sensor> verabschiedet hat. Wird den ein "ERROR" über MQTT gesendet, wenn du> einen Sensor testweise abklemmst?
Lüge nicht so dreist und zitiere mich richtig oder zitiere mich gar
nicht.
Was soll diese Frechheit?
Ich schiebe das mal nach µC & Elektonik, denn für Projekte & Code gilt:
Hier könnt ihr Projekte, Schaltungen oder Codeschnipsel vorstellen.
Projekte bitte nur mit Code oder Schaltplan posten (falls ihr nur Fotos
vorstellen möchtet, bitte in "Zeigt her eure Kunstwerke"). Bitte hier
keine Fragen posten.
Hallo,
ich habe dieses Forum über Google Einträge entdeckt -no na ned- , und
empfand es "damals" als sehr hilfreich.
Leider bin ich heute mit der Situation in diesem Forum nicht ganz
glücklich...
Helmut -. schrieb:> Und du solltest das beachten:>> Wichtige Regeln - erst lesen, dann posten!>> Groß- und Kleinschreibung verwenden> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Ja, nach einem Punkt schreibt man mit einem Groß-Buch-Staben weiter. Hab
wohl die Shift-Taste nicht richtig erwischt. (nur wegen dem "h"?)
Findest Du dieses Bischen Code echt lang? - Eine genauere Angabe "Bitte
ab 5 Zeilen nicht mehr als Text einfügen" hab ich nicht gelesen.
Norbert schrieb:> Wie haben wir das früher nur gemacht?> Moment … ja … genau … so war das … viel gelesen und gelernt.> Im Kleinen verschiedene Dinge ausprobiert, wie funktioniert dieser> Maschinenbefehl, wie reagiert jenes Flag.>> Heute ist das alles viel einfacher, Google-Copy-Paste-Ask-Wait.
Ich weis nicht wie alt Du bist, aber als ich anfing Logik zu
programmieren, hatten die auf CERN auch noch keine Ahnung vom Internet.
Norbert schrieb:> Joe G. schrieb:>> Norbert schrieb:>>>> Google-Bard meinte ich solle in der Funktion getTemp() try & except>>>> einfügen.>>>> Das ist schon die richtige Stelle, um festzustellen, ob sich ein Sensor>> verabschiedet hat. Wird den ein "ERROR" über MQTT gesendet, wenn du>> einen Sensor testweise abklemmst?>> Lüge nicht so dreist und zitiere mich richtig oder zitiere mich gar> nicht.>> Was soll diese Frechheit?
Was hat das mit meinem Beitrag zu tun? In Foren wird geholfen, oder?
Benedikt L. schrieb:> Da reicht doch ein ESP8266 mit Tasmota oder ESPeasy.
Findest Du wirklich, das das mein Problem löst?
In "guten" Foren, schreibt, wer eine Idee oder einen Hinweis hat. Wer
nicht, der schreibt auch nichts.
Übrigens lag der Fehler an der Codezeile 64.
1
sensErr+=1
Es hätte davor die Variable aus Zeile 49 noch global deklariert werden
müssen. Seither läuft der Code.
Gruß,
Jack
Jack schrieb:> Leider bekomme ich nach Tagen> bis zu Wochen irgendwann keine Daten mehr über MQTT gesendet
Bei einem so sporadisch auftretenden Fehler willst Du nach max. 3
fehlerfreien Wochen schon wissen, daß Du den Fehler gefunden hast?
Jack schrieb:> Übrigens lag der Fehler an der Codezeile 64.sensErr += 1> Es hätte davor die Variable aus Zeile 49 noch global> deklariert werden müssen.
Ja, wenn das über die gesamte Laufzeit alle Fehler zählen soll, dann war
das wohl ein Fehler. Statt die Fehler mitzuzählen liefert er Dir sonst
halt immer ERROR 1 - das wars aber auch schon.
> Seither läuft der Code.
Das ist inzwischen wie lange?
Jack schrieb:> Wenn keine Daten mehr kommen, bleibt die WLan Verbindung> aufrecht.
Das weist Du ganz sicher, weil ??
Deine LED blinkt dann nach wie vor für 1 Sekunde alle 3 Minuten?
Falls nicht hängt sich Dein Programm irgendwo komplett auf.
Aber Du könntest z.B. mal in Deiner Hauptschleife jedesmal eine MQTT
Msg. absetzen oder Deine onboard LED abhängig vom WLAN-Status (dazu mußt
Du halt wlan aus Deiner wlanConnect()-Funktion zurückliefern, damit Du
auf den Status in der Hauptschleife zugreifen kannst) setzen, dann
wüßtest Du mehr.
Im Wesentlichen gibts zwei Möglichkeiten das Dein beschriebenes
Verhalten erklären könnte: ein abreißen der WLAN-Verbindung oder ein
(dauerhaftes) Scheitern des MQTT-Connect; vor allem auf g
Grund der großen zeitlichen Variation, wie lange es bis zum Auftreten
des Fehlers dauert, tippe ich stark auf ersteres, denn WLAN Verbindungen
sind nicht wirklich langzeitstabil, selbst wenn man die Störungen
normalerweise nicht bemerkt da normale Geräte die Verbindung einfach neu
aufbauen.