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...
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 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.
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
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?
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.
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...
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.
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.
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?
Ü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.
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.