Moinsen,
Klappe ja, Also du hast eine Schalter der über - was - zwei Zustände meldet.
Du kannst mit einem klassischen Umschalter wo nur der HIGH Pegel auf einen anderen Draht gelegt wird nichts definiertes Auswerten.
Dabei ist es egal ob du mit 2 GPIO jeweils für ein Event Open oder Close nur auf einen Wechselzustand "to High" triggerst. Oder ob du mit einem GPIO jeweils über ein Status-Bit die Interrupt Funktion umkehrst. Aus "Rising" wird "Falling" wenn die Klappe mit "Risung" als geöffnet detektiert wurde, und umgekehrt. Hier musst du das Status-Bit in den User-ROM schreiben, damit es über den DeepSleep erhalten bleibt.
Also ist die Auswerung auch sehr aufwendig von der Auswertelogik. Denn du muss mit dem WakeUP auch erst noch das Status-BIT aus dem User-ROM zurücklesen, und dann eine logische ( Programmlogik ) Auswertung durchführen.
Egal wie man es nimmt, mit einem mech. Schaltkontakt ( Reed-Schalter /-Relais ) wirst du immer ein Prellen auf dem GPIOs haben, die die Pegel vom Schaltkontakt zum ESP Transportieren. Hier kann und muss man sehr harte Richtlinien einhalten. Wenn der ESP Geweckt wurde und das Programm wieder startet ( meist bei Null = Deepslepp ) kommt es auf den Faktor Zeit an. mechanische Schaltkontakte sind immer besonders in der Abhängigkeit ihrer Lebenszeit ( Anzahl der bisher vollzogenen Schaltspiele ) ein Unsicherheitsfaktor.
Das heißt die Dauer der Prellzeit verlängerst sich mit jedem 10^ x Schaltspielen im Bereich von unter 1 ms bis über 200 ms. Dieses Prellen selber kann man elektronisch versuchen mittels eines Filters zu umgehen, Stichwort RC Glied, aber das funktioniert nur bis etwa 35-50 ms Überbrückungsdauer noch halbwegs funktionssicher. Wird dieser Zeitrahmen des Prellens selber die Zeitspanne 80 ms überschreiten, ist das der falsche Lösungsansatz. Also bleibt dir in dem Moment nur noch eine SW Lösung die Openend versucht einen stabilen Eingangspegelzustand zu detektieren.
Also muss du im ersten Schritt ein FLAG setzen, dann diesen Interrupt mittels cli() oder noInterrupts() aussetzen, dieses Status-Bit in den User-ROM schreiben, und dann musst du für eine Zeit X auf diesem GPIO pollen, bis der Zustand des Prellens potentiell überwunden ist, und du eine momentan klaren Endzustand als Pegel erkennen kannst. Dann erst kannst du dahergehen und einen neuen neuen Interrupt-Handler initiieren, der dann wahrscheinlich auf den entgegengesetzten Zustand triggert. Und hier kommt dann noch das zuvor eingelesene Status-Bit zum tragen, ob dieser einzelne Impuls welcher den ESP geweckt hat, überhaupt dazu ausreichend von der Dauer ist, falls der Endzustand dann doch wieder der Ausgangszustand ist, das es sich um einen Einwurf handelt und nicht um eine Signalstörung. Also die Logik aus dem Weckprozess heraus, ist sehr sehr kompliziert, weil du muss nicht nur auf die einzelne Flanke reagieren, du muss eine Plausibilitätsprüfung machen, ob dieser Impuls "technisch" gesehen ausreicht eine Einwurf für plausibel zu erklären, und dann hast du noch das Problem des mech. Schalterprellens !
Alles eine sehr ungünstige Kombination, besonders wenn die Schaltung schon für eine längere Zeit im Gebrauch ist, und sich somit auch die Prellzeiten ständig zum negativen | länger verändern werden.
Oder was passiert ( ich keine deinen Briefkasten nicht ) aber bei uns ist es normal, das auch mal durch Windangriffe die Briefkastendeckel anfangen zu klappern. Also hast du kurzzeitig Zustände wo diese Klappen mit einer Frequenz von 1-2 ggf 3 Hz klappern, was aber zeitlich niemals für einen tatsächlichen Einwurf ausreichen würde. Auch diese möglichen Störungen müssen von deiner Signal-Verarbeitungslogik sicher erkannt werden, und als Fehlerzustand auch so sicher behandelt werden, damit es zu keiner Fehlbenachrichtigung kommt.
Deswegen hatte ich dir den Vorschlag mit einer Gabellichtschranken basierten Klappenüberwachung gemacht. Hier hast du knallharte Digitale Signale ohne jedes Prellverhalten, und man kann sogar mech. über die Schlitzlänge für die Position "Geschlossen", diesen Fehlerfall "Windangriff" ausklammern. So kann man sagen der Deckel kann sich aus der geöffnet Position um X mm herausbewegen, was aber definitiv nicht für einen Einwurfvorgang ausreicht, und der ESP bekommt davon schon einmal gar nichts mit. Weil es von der Lichtschranke nicht als Unterbrechung wahrgenommen wird. Und wenn aus diesem Dunkel Zustand heraus wieder ein Hell festgestellt wird kann es nur bedeuten, die Klappe ist wieder zu oder offen. Und dann kann man mittels analoger Signalauskopplung über den ADC abfragen.
Damit hast du 3 Analogwerte:
- 100% Lichtdurchlass = Klappe zu
- unter 10 % Lichtdurchlass, die Klappe ist nicht vollständig auf oder zu,
- einen Wert 50-80 % Lichtdurchlass = Die Klappe steht bis Anschlag offen
Jetzt könnte man noch einen Timer-Baustein derhernehmen, oder eine LOW Power diskrete Zeitschaltung aufbauen, damit die Lichtschranke nicht ständig Strom verbraucht, und dieses dieses Mixed Signal aus Timer = Lichtschranke ist aktiv + Signalwert Lichtschranke Ausgang dem ESP zuführen. Aus der Ausgangslogik des Timers hast du dann über eine Flipflop immer die Zustände:
Lichtschranke aus - letzter gespeicherter Pegel wird zum GPIO geleitet,
Lichtschranke an - aktueller Wert wird mit dem gespeicherten Wert verglichen und im Falle einer Änderung invertiert gespeichert und zum GPIO geleitet.
Grob mit CMOS Bauteilen, wen man dafür keinen separaten µC ( ATTINY 13/25/45/85) abstellen will, hättest du mit Ausnahme des Stromverbrauchs der Lichtschranke selber einen zusätzlichen Stromverbrauch im Bereich 80-130 µA für diese Timerschaltung, die zB nur jede Sekunde die Lichtschranke für 50/50% anschaltet.
Das grundsätzliche Problem bei solchen Überwachungsschaltungen lässt sich auf 2 Entscheidungsfaktoren zusammenfassen. Entweder du kämpfst gegen einen mech. Schaltkontakt der dich unterm Strich auch wieder nur Strom kostet, weil die Auswerteeinheit so lange Aktiv sein muss bis dieser sein Prellen beendet hat, oder wenn man auf Lichtschranken setzt, die aber einfacher und logischer auszuwerten sind, und man hat einen Mehrstromverbrauch der dem Funktionsprinzip der Lichtschranke geschuldet ist. Hier muss man dann wirklich abwägen was kostet einem Netto mehr Strom - eine kleine Lichtschranke die im Dauerbetrieb / oder gepulst läuft, oder der Mehrstromverbrauch, der den auswertenden µC länger aktiv lässt weil man ein mech. Schalterprellen überbrücken muss.
ESP32 Interrupthandling und DeepSleep
-
framp -
July 15, 2024 at 11:08 PM -
Thread is Resolved
-
-
ESP32 Interrupthandling und DeepSleep? Schau mal ob du hier fündig wirst!
-
Ich gebe zu an das Prellen habe ich nicht gedacht
Allerdings habe ich den Eindruck dass der Magnetschalter nicht prellt bzw das keine Auswirkungen auf den Detektionsalgorithmus zu haben scheint denn er funktioniert bei mir ohne Probleme. Das Prellen kann ich aber mangels Oszi nicht nachpruefen. Aber fuer eine Rocketscience sollte man das natuerlich im Hinterkopf haben und entsprechende HW Massnahmen ergreifen um das Prellen zu verhindern. Das SW seitig zu loesen ist aufwaendig und wenn ich den ESP soweit richtig mit seinem Interuptverhalten bzw DeepSleep Wakeup richtig verstehe ist das sogar nicht moeglich.Oder was passiert ( ich keine deinen Briefkasten nicht ) aber bei uns ist es normal, das auch mal durch Windangriffe die Briefkastendeckel anfangen zu klappern. Also hast du kurzzeitig Zustände wo diese Klappen mit einer Frequenz von 1-2 ggf 3 Hz klappern, was aber zeitlich niemals für einen tatsächlichen Einwurf ausreichen würde. Auch diese möglichen Störungen müssen von deiner Signal-Verarbeitungslogik sicher erkannt werden, und als Fehlerzustand auch so sicher behandelt werden, damit es zu keiner Fehlbenachrichtigung kommt.
Du willst mich wohl unbedingt auf die Lichtschranke bringen
. Ich sehe den Vorteil - aber ich bleibe bei dem Magnetschaltern 
Sie eignen sich perfekt fuer meinen Anwendungsfall und der Beruecksichtigung von KISS.Der Briefkasten haengt an der Nordseite. Die vorherschenden Winde kommen bei mir aus Westen. D.h. es ist sehr unwahrscheinlich dass dieser Effekt bei mir eintritt. Und wenn doch? Dann bekomme ich eine Nachricht dass ich eine Mail bekommen habe - oeffne den Briefkasten - und finde keine Post vor. So what ... von diesem Ereignis haengt kein erfolgreiches Raketenmanoever ab
Das grundsätzliche Problem bei solchen Überwachungsschaltungen lässt sich auf 2 Entscheidungsfaktoren zusammenfassen. Entweder du kämpfst gegen einen mech. Schaltkontakt der dich unterm Strich auch wieder nur Strom kostet, weil die Auswerteeinheit so lange Aktiv sein muss bis dieser sein Prellen beendet hat, oder wenn man auf Lichtschranken setzt, die aber einfacher und logischer auszuwerten sind, und man hat einen Mehrstromverbrauch der dem Funktionsprinzip der Lichtschranke geschuldet ist.
Darum moechte ich ja keine zusaetzliche HW nutzen. Und da ich keine Probleme mit dem Prellen bemerken kann ergreife ich auch keine weiteren HW Massnahmen um das Prellen zu verhindern.
-
Ich habe nicht alles gelesen.. Aber:
Ich habe vor einiger Zeit einige Interrupts gebraucht. Das ist beim ESP32 etwas tricky.
Du kannst mithilfe der RTC-Werte auch im DeepSleep speichern (OHNE!) den EEPROM zu benutzen: https://randomnerdtutorials.com/esp32-timer-wake-up-deep-sleep/
Generell gilt, versuche dich an die Syntax der IDF zu gewöhnen. Die Abstraktionsschicht der Arduino IDE erzeugt bei komplexeren Themen mehr Probleme als es hilft.
Bei Interrupts, ist die Syntax und die Reihenfolge extrem wichtig. Der ESP32 ist da wirklich eine Zicke.
Ist doch eigentlich ziemlich trivial:Klappe auf, ESP32 wacht auf, speichert Zustand, sendet Zustand, legt sich schlafen.
Klappe zu, esp32 wacht auf, liest Zustand, wenn zuvor offen, dann geschlossen, speichere Zustand geschlossen, sende Zustand, lege schlafen.
Sollte mit einem einzigen PinChangeInterrupt gehen.. -
Ich habe nicht alles gelesen.. Aber:
NP
Du kannst mithilfe der RTC-Werte auch im DeepSleep speichern (OHNE!) den EEPROM zu benutzen
Das ist ein nettes Feature und nutze ich auch um mir den jeweiligen Status zu merken bevor der ESP sich wieder schlafen legt.
Bloed ist dass man beim ESP zwar auf Flankenwechsel IRQ setzen kann - aber das leider nicht beim DeepSleep
. Aber fuer meinen Anwendungsfall reicht es auch auf HIGH oder LOW zu reagieren und den entsprechenden Wakeup IR zu enablen. -
Urspruenglich hatte ich gedacht keine Benachrichtigung mehr zu schicken wenn mal eine Mail erkannt wurde und das durch einen zweiten Magnetschalter an der Briefkastenoeffnungsklappe zu resetten.
Den Code hatte ich schon soweit geschrieben aber ich habe mich dann doch entschlossen bei jedem Oeffnen der Klappe eine Benachrichtigung zu schicken. Dadurch entfaellt der zweite Magnetschalter fuer den Reset.
Dann habe ich noch mal alles umgestellt und die von mir eingefuehrten States verworfen. Jetzt wird der Klappenstatus zum Zeitpunkt des Schlafenlegens wie raspbastler vorschlug ueber die Wakeups persistiert und dann mit dem aktuellen Status zum Zeitpunkt des Aufwachens verglichen und entsprechend reagiert. Das macht den Code wesentlich einfacher zu lesen und zu verstehen.
Wie ich gelernt habe prellt auch ein Magnetschalter und ein HALL Sensor wuerde das nicht mehr tun (Thx Franky07 ) . Allerdings hat sich der Magnetschalter beruhigt wenn der ESP wieder erwacht ist. Somit ist es weder mit einer HW noch SW Loesung notwendig den Magnetschalter zu entprellen und der Einsatz von einem HALL Sensor ebenso ueberfluessig wenn man keine HW zur Entprellung einsetzen will.
Der Code erkennt jetzt zuverlaessig Klappe oeffnen/schliessen und dass die Klappe offen geblieben ist bei einem groesseren Briefumschlag und dann keine repititive Benachrichtigung geschickt werden. Alles ohne zusaetzliche HW
Momentan habe ich schon mal Pushover Code eingepflegt zur Benachrichtigung. Final soll dann eine MQTT Message per ESPNow geschickt werden. Das ESPNow Handling ist etwas komplizierter so dass ich jetzt erst einmal die direkte Benachrichtigung per Pushover einbaue. Dazu fehlt aber noch der vorherige WLAN Connect.
-
Mittlerweile wird auch eine eMail gesendet wenn eine neue eMail eingeworfen wurde.
Deshalb bin ich jetzt dabei eine Platine zusammenzulöten die mit einem nackten ESP32 die Benachrichtigung per WLAN verschickt. Auf dem Breadboard funktioniert alles perfekt. Da der nackte ESP32 leider nicht auf ein Breadboard gesteckt werden kann ist nun eine custom made Platine notwendig ...
Die Pulldown Widerstände für den Magnetschalter habe ich drauf damit der Wechsel deterministisch erkannt wird.
Ich höre und lese immer wieder dass auch noch andere Pulldownwiderstände beim ESP32 notwendig sein sollen. Komischerweise funktioniert mein Setup auf dem Breadboard ohne Probleme. Bei espressif finde ich einfach nicht ob und welche externe Beschaltung beim nackten ESP32 notwendig bzw angeraten ist
Vielleicht hat ja jemand einen Link zu den Details die ich nicht finde
Danke
-
Nach längerem Suchen fand ich heraus dass ein Pullup mit 100k und 1uF oder 0.1uF an EN gelegt werden soll. Nicht ganz klar ist ob es 1uF oder 0.1uF sein muss
-
Nicht ganz klar ist ob es 1uF oder 0.1uF sein muss
Zur Not einfach beide.
-
Wie war das: Cs parallel geschaltet ergeben die Summe der Kapazitäten. Also 1.1uF. Der Unterschied zu 1uF ist dann wohl unerheblich. Die Frage ist nach dem Unterschied von 1uF und 0.1uF
-
Ich habe jetzt mal wie es im AZ Delivery BegleitPDF steht den EN einfach mit 3.3V verbunden. Der ESP bootet zuverlässig und reagiert auch zuverlässig auf PIN 15 und PIN 33 die ich nutze um zu erkennen ob eine Briefkastenklappe offen oder zu ist.
Die beiden Tasten auf der Platine REST und IO00 funktionieren offensichtlich nicht. Warum auch immer ... LifePo4 einlegen und der ESP32 läuft.
Um ihn zu flashen habe ich zwei PINS von GPIO0 und GPIO2 rausgeführt und wenn ich die verbinde und den LiFePo4 einlege ist der ESP32 wie erwartet im Flashmode.
Auf dem Photo sieht man oben links den Schaltkontakt, rechts oben den angeschlossenen LiFePo4 und die Kabel von rechts unten sind vom angeschloessenen USB2TTL Adapter zum Flashen und Ansehen der Serial Ausgaben.
Die rote Schleife ist die Flashverbindung von GPIO0 und GPIO2.
Jetzt muss ich immer den LiFePo4 einlegen um zu booten oder zu flashen. Wenn jemand weiss wie ich die beiden Buttons dazu nutzen kann - just let me know.
Anyhow - mein Briefkastenmelder funktioniert als Prototyp. Die Tage baue ich ihn mal in meinen Briefkasten ein. Bin mal gespannt wie lange der LiFePo4 hält. Bislang habe ich nur ESP8266 mit LiFePo4 im DeepSleep betrieben. U.U. muss ich noch alles auf ESPNow umstellen.
-
framp
February 12, 2025 at 10:24 PM Changed the title of the thread from “ESP Interrupthandling und DeepSleep” to “ESP32 Interrupthandling und DeepSleep”. -
Moin framp,
vielleicht hilft das hier weiter: https://www.mikrocontroller.net/topic/474265
Weiter unten ist auch ein Schaltplan. Der hat aber schon mehr drin...
73 de Bernd
-
Weiter unten ist auch ein Schaltplan.
Perfekt. Vielen Dank. Sowas habe ich gesucht. Auf das Forum bin ich gar nicht gekommen dort mal zu suchen
Muss ich mir merken.Dort sieht man sehr gut dass der EN mit einem 10k Pullup Widerstand angeschlossen wird. Gesagt - getan - und jetzt funktioniert auch die Reset Taste an dem ESP. Einen 1uF habe ich leider gerade nicht zur Hand um den auch noch gegen GND anzuschliessen.
Auch sieht man dass ein 10uF und 100nF noch an die Spannungsversorgung angeschlossen ist.
Im zweiten Schaltplan sind die Werte etwas anders. Aber die im ersten Schaltplan passen zu dem was ich schon beim rumlesen gestern gesehen habe.
Die 3 Kondensatoren muss ich mir jetzt noch besorgen. Allerdings funktioniert der ESP mit der jetzigen Beschaltung gut. Aber vielleicht funktioniert dann ja auch der zweite Taster auf dem Board
-
Du solltest auch einen S3 nehmen, dieser hat USB direkt im Chip ist einfacher zu programmieren
-
Ich habe ESP32s mit USB Anschluss. Mit dem läuft mein Developmentenvironment.
Da das aber final alles über Akku betrieben werden soll kommt es auf jedes uA an. Und der ganze USB Kram zieht final unnütz Strom
Deshalb nutze ich einen nackten ESP32 -
Mein ESP startet nicht mehr wenn er in meiner gebauten Platine steckt
Das blöde ist dass man den nicht in ein Breadboard stecken kann da er jeweils zwei Pinleisten auf jeder Seite hat um mal prototypenmässig alles auf einem Breadboard zusammenzustecken.
Das habe ich jetzt mit Kabelage mal gemacht und festgestellt dass die beiden Tasten RESET und IO00 perfekt funktionieren wenn keine Pullupwiderstände auf EN und GPIO0 existieren. Mit RESET bootet der ESP (EN -> GND) und wenn IO00 parallel gedrückt wird (IO00 -> GND) geht der ESP in den Flashmode.
Mit einem 1uF Kondensator an EN zusätzlich zu dem 10k Widerstand gibt es auch nur Bootprobleme
Somit lasse ich jetzt bei der nächsten Platine mal die Finger von externer Beschaltung und nutze Pullupwiderstände nur bei den beiden REED Kontakten deren Status ohne diese nicht zuverlässig erkannt werden. -
Nachdem nichts mehr ging mit meiner ersten Platine habe ich mal alles auf einem Breadboard aufgebaut. Zuerst funktionierte noch alles gut. Da kam dann irgendwann ab und zu mal ein Brownout beim Einschalten, zuletzt immer und final konnte ich keinen Code mehr flashen
An der Verdrahtung habe ich in der Zeit nichts geändert...Daraufhin habe ich eine neue Platine zusammenglötet mit nur Vcc und GND sowie die USB2TTL Verbindungen ohne irgendwelche weitere externe Beschaltung und der ESP startet wieder ohne Brownout und lässt sich auch wieder flashen
Scheint so als ist ein Breadboard nicht die ideale HW um die feinfühlige Diva ESP32 darauf zu entwickeln
PS: Testweise hatte ich dann mal die Spannungsversorgung von meinem Labornetzteil von 3.3V auf 3.5V erhöht und der Brownout verschwand
-
Hast du einen Elko dran ?
-
Ja. Am Breadboard. Anbei der Schaltplan. Das ausgexte fehlt auf der Platine.
-
Nachtrag: Irgendwann habe ich festgestellt dass mein Prototyp auf dem Breadboard nicht funktioniert da der Reedschalter nicht mehr korrekt durchschaltete
Mit einem anderen Reed Schalter funktionierte alles perfekt wie vorher.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!