Moin, ich möchte den ESP gerne als Wireless-Switch-Array für mein Smarthome nutzen. Allerdings müsste der ESP ja ständig aktiv sein, um die Taster abfragen zu können, was einen hohen Stromverbrauch zu Folge hätte ... Meine erste Idee war dann alle 500 ms aus dem Deep Sleep aufzuwachen und die Taster abzufragen. Das ist aber irgendwie unkomfortabel und auch nicht sooo effizient. Jetzt habe ich mir eine Schaltung (Schaltplan angehängt) aus Gattern überlegt die den ESP mit einem beliebigen Tastendruck aufweckt. Der ESP setzt GPIO2 auf HIGH, wenn er aktiv ist. Wenn irgend ein Button gedrückt wird und der ESP aus ist (also GPIO2 dann LOW) wird der Reset ausgelöst, sodass der ESP bootet. Irgendwie kommt mir das aber sehr aufwändig vor, denn man bräuchte die Gatter zum Aufwecken und ein Latch pro Taster, um den Tastendruck zu speichern bis der ESP gebootet und den Wert abgerufen hat.. Das wäre dann eine relativ aufwändige Platine für so eine "Kleinigkeit" :( Ich kenn mich mit E-Technik nicht so mega gut aus, vllt hat jemand eine bessere Idee? Ich hab auch überlegt, dass so etwas vllt einfacher wäre: http://www.ti.com/lit/ds/symlink/ticpal22v10z-25c.pdf Was meint ihr ? Gruß
:
Bearbeitet durch User
einen kleinen Tiny AVR 8 Beiner, der wacht aus dem deep sleep auf wenn ein Taster gedrückt wird, startet den ESP per power on, low drop regler mit on/off. Der Tiny macht Tasterentprellung, am Int0 oder PCint wenn es das gibt wird er geweckt, geht selber nach Wartezeit oder vom ESP geschickt wieder schlafen.
Für solche Zwecke hänge ich kleine AVRs als I2C Portexpander an den ESP. Die lassen sich auch im Tiefschlaf von Tastendrücken wecken. Und können ihrerseits den ESP wecken.
kann man den ESP selbst nicht auch per Puls an RST aus dem (dauer-)deep-sleep aufwecken? GPIO16 (RTC) macht da eigentlich auch nichts anderes...
Jan L. schrieb: > kann man den ESP selbst nicht auch per Puls an RST aus dem > (dauer-)deep-sleep aufwecken? Sehr gut erkannt! Der TE möchte allerdings die dazu notwendige Beschaltung vereinfachen. (habe ich so verstanden)
Jan L. schrieb: > kann man den ESP selbst nicht auch per Puls an RST aus dem > (dauer-)deep-sleep aufwecken? GPIO16 (RTC) macht da eigentlich auch > nichts anderes... Die Schaltung macht ja genau das ;) Arduino F. schrieb: > Jan L. schrieb: >> kann man den ESP selbst nicht auch per Puls an RST aus dem >> (dauer-)deep-sleep aufwecken? > > Sehr gut erkannt! > Der TE möchte allerdings die dazu notwendige Beschaltung vereinfachen. > (habe ich so verstanden) Ganz genau! :) Bzw auch Erfahrungen mit einem PAL hören ^^ Arduino F. schrieb: > Für solche Zwecke hänge ich kleine AVRs als I2C Portexpander an den ESP. > > Die lassen sich auch im Tiefschlaf von Tastendrücken wecken. > Und können ihrerseits den ESP wecken. Hm, nach einem Blick in das Datenblatt sieht das gar nicht so abwägig aus. Es fühlt sich nur falsch an, einen MC zu brauchen, um das Power-Management eines anderen MC zu machen :D
:
Bearbeitet durch User
Arduino F. schrieb: > Für solche Zwecke hänge ich kleine AVRs als I2C Portexpander an den ESP. > > Die lassen sich auch im Tiefschlaf von Tastendrücken wecken. > Und können ihrerseits den ESP wecken. Hm, hättest du eine Beispielbeschaltung? Wenn ich das richtig sehe, kann der AVR ja nur über einen bestimmten Pin geweckt werden...
Jens H. schrieb: > Arduino F. schrieb: >> Für solche Zwecke hänge ich kleine AVRs als I2C Portexpander an den ESP. >> >> Die lassen sich auch im Tiefschlaf von Tastendrücken wecken. >> Und können ihrerseits den ESP wecken. > > Hm, hättest du eine Beispielbeschaltung? Wenn ich das richtig sehe, kann > der AVR ja nur über einen bestimmten Pin geweckt werden... reicht ein Pin für einen Taster, dann int0 fertig ist es eine Matrix mehrere Taster? dann suche ich die Beschaltung für dich
Jens H. schrieb: > Es fühlt sich nur falsch an, einen MC zu brauchen, um das > Power-Management eines anderen MC zu machen Er ersetzt deinen PXF und die anderen Gatter und Flipflops. Aber, wo ich da gerade bin: Der PXF hat ja auch einen Int Ausgang. Und soweit mir bekannt, merkt er sich intern den Auslöser.
Joachim B. schrieb: > Jens H. schrieb: >> Arduino F. schrieb: >>> Für solche Zwecke hänge ich kleine AVRs als I2C Portexpander an den ESP. >>> >>> Die lassen sich auch im Tiefschlaf von Tastendrücken wecken. >>> Und können ihrerseits den ESP wecken. >> >> Hm, hättest du eine Beispielbeschaltung? Wenn ich das richtig sehe, kann >> der AVR ja nur über einen bestimmten Pin geweckt werden... > > reicht ein Pin für einen Taster, dann int0 fertig > > ist es eine Matrix mehrere Taster? dann suche ich die Beschaltung für > dich Natürlich reicht ein Taster nicht aus ;) Ich möchte möglist viele dran machen... bei einem ATmega8 müssten ja locker 15 drin sein.
Jens H. schrieb: > bei einem ATmega8 müssten ja > locker 15 drin sein. Arduino F. schrieb: > Ein Suchwort: "AVR PCINT"
Jens H. schrieb: > Natürlich reicht ein Taster nicht aus ;) > Ich möchte möglist viele dran machen... bei einem ATmega8 müssten ja > locker 15 drin sein. ich dachte du wolltest nicht so viele Beine deswegen Tiny, aber bitteschön: Beitrag "IR Fernbedienung bauen" das hier kannst du fast beliebig erweitern, dein Muster hatte nur 4 Tasten und viele ICs da reicht ein kleiner 8 Beiner Tiny
Jens H. schrieb: > Jan L. schrieb: >> kann man den ESP selbst nicht auch per Puls an RST aus dem >> (dauer-)deep-sleep aufwecken? GPIO16 (RTC) macht da eigentlich auch >> nichts anderes... > > Die Schaltung macht ja genau das ;) Ok, ich hatte bei "Puls" da eher an Taster, R und C gedacht, und nicht an grössere Schaltungen... :)
Hallo, problematisch könnte das Prellen der Taster sein, im Anhang mal die Schaltung meiner PIR-Sensoren. Geweckt wird mit der H-Flanke (PIR-Ausgang aktiv). Also Taster mit PullDown an die ESP-GPIO (4,5,12,14 sind unkritisch, haben keine störende Doppelbelegung in der Firmware). 4x Kondensator zur Basis. Die 0,22µ können vermutlich auch kleienr sein, es muß nur ein ausreichend langer Reset-Impuls erzeugt werden. Verlauf ist unkritisch, die interne Resetschaltung kommt mit der langsamen Flanke zuverlässig klar. Wenn die Taster prellen könnte es mehrere Rest-Impulse geben. Das stört den Ablauf hier ja nicht unbedingt. Wenn man vor Start der Anwendung ein passendes deay() einfügt, fliegt er bei Mehrfach-Rest höchstens da wieder raus und connectet und sendet eben erst, wenn "Ruhe" eigetreten ist. Bei mit läuft ein MQTT-Client auf dem ESP, die Auswertung passiert im Zielgerät (hier FHEM). Läuft hier mit Li-IO-Zelle inzwischen seit etlichen Wochen stabil. Gruß aus Berlin Michael
:
Bearbeitet durch User
Arduino F. schrieb: > Jens H. schrieb: >> bei einem ATmega8 müssten ja >> locker 15 drin sein. > > Arduino F. schrieb: >> Ein Suchwort: "AVR PCINT" Ja ich kenne die PCINT pins, davon sind ja aber meistens nur 1-3 vorhanden. Diese Schaltung arbeitet ja mit den Pins: Joachim B. schrieb: > Jens H. schrieb: >> Natürlich reicht ein Taster nicht aus ;) >> Ich möchte möglist viele dran machen... bei einem ATmega8 müssten ja >> locker 15 drin sein. > > ich dachte du wolltest nicht so viele Beine deswegen Tiny, aber > bitteschön: > > Beitrag "IR Fernbedienung bauen" > > das hier kannst du fast beliebig erweitern, dein Muster hatte nur 4 > Tasten und viele ICs da reicht ein kleiner 8 Beiner Tiny Ich habe dieses Sheet nur kurz überflogen: Arduino F. schrieb: > Oder sowas: http://www.atmel.com/images/doc2532.pdf Beides sind ja aber Matrizen. Ich dachte mehr an einen Pin pro Taster. Das ist einfach zu löten, einfach zu verstehen und einfach zu programmieren ... Wie gesagt, ein ATMega8 würde da auch völlig ausreichen :) Es ging ja mehr darum was zu finden, dass den PCINT triggert und trotzdem super einfach ist. Generell gefällt mir die Lösung mit der INT Line vom PCF aber sehr gut. Man braucht nur wieder ein Gatter ... vorher muss ich erstmal verstehen was der überhaupt ausgibt :/ Ich denke das sehe ich mir als erstes mal an...
Michael U. schrieb: > Hallo, > > problematisch könnte das Prellen der Taster sein, im Anhang mal die > Schaltung meiner PIR-Sensoren. > Geweckt wird mit der H-Flanke (PIR-Ausgang aktiv). > Also Taster mit PullDown an die ESP-GPIO (4,5,12,14 sind unkritisch, > haben keine störende Doppelbelegung in der Firmware). > > 4x Kondensator zur Basis. Die 0,22µ können vermutlich auch kleienr sein, > es muß nur ein ausreichend langer Reset-Impuls erzeugt werden. Verlauf > ist unkritisch, die interne Resetschaltung kommt mit der langsamen > Flanke zuverlässig klar. > Wenn die Taster prellen könnte es mehrere Rest-Impulse geben. Das stört > den Ablauf hier ja nicht unbedingt. > Wenn man vor Start der Anwendung ein passendes deay() einfügt, fliegt er > bei Mehrfach-Rest höchstens da wieder raus und connectet und sendet eben > erst, wenn "Ruhe" eigetreten ist. > > Bei mit läuft ein MQTT-Client auf dem ESP, die Auswertung passiert im > Zielgerät (hier FHEM). > Läuft hier mit Li-IO-Zelle inzwischen seit etlichen Wochen stabil. > > Gruß aus Berlin > Michael Prellen sollte über den PCF abgefangen werden (denke ich) .. wenn nicht würde ich das in Software abfangen. Wie du ja schreibst, kann man ja etwas warten beim booten des ESP. Ich muss zugeben, dass ich deine Schaltung nicht verstanden habe. Der Transistor zieht den Reset Pin auf LOW (was den ESP deaktiviert) wenn? Und wieso ist ein Kondensator zwischen der Base und dem PIR ? Ist das nicht ein Isolator im DC ? Was erreichst du denn für Laufzeiten mit deinem LiPo und wie groß ist der? Bewegungsmelder bräuchte ich auch noch 2 oder 3 aber ich würde sie ungern öfter als 1x im Jahr laden müssen.
Jens H. schrieb: > Ja ich kenne die PCINT pins, davon sind ja aber meistens nur 1-3 > vorhanden. ? "meist"? Eher: Nein! Der ATMega8 hat kein PCINT, Null Komma gar nicht. Aber, wenn du unbedingt Antiquitäten benutzen willst... Jens H. schrieb: > Ich dachte mehr an einen Pin pro Taster. Und ich da dachte eher an eine "Lösung" deines Problems. Was aber dem "einen Pin pro Taster" nicht entgegen spricht. Jens H. schrieb: > Es ging ja mehr darum was zu finden, dass den PCINT triggert und > trotzdem super einfach ist. Dann betrachte AVR243 als Anregung, wie man einen AVR aus dem Schlaf holt wenn einer von 8 Pins getriggert wird... Huch, 8 PCINT Pins... ;-) das geht doch gar nicht! ;-)
Hallo, Jens H. schrieb: > Prellen sollte über den PCF abgefangen werden (denke ich) .. wenn nicht > würde ich das in Software abfangen. Wie du ja schreibst, kann man ja > etwas warten beim booten des ESP. um wieviele Tasten geht es bei Dir? Wozu der PCF? Der ESP8266-12 hat doch etliche I/O, die man mit Tasten belegen kann. >Ich muss zugeben, dass ich deine Schaltung nicht verstanden habe. Der >Transistor zieht den Reset Pin auf LOW (was den ESP deaktiviert) wenn? >Und wieso ist ein Kondensator zwischen der Base und dem PIR ? Ist das >nicht ein Isolator im DC ? Der Transistor ist mangels Basisspannung im Normalfall gesperrrt, Reset des ESP durch dessen internen PullUp also auf High und der ESP startet normal. Bei mir macht er ann den WLAN-Connect und schickt eine MQTT-Message. Danach geht er in DeepSleep und bleibt so. Der PIR wechselt bei Akzion von Low nach High. Der Ladestrom des Kondensators über die BE-Strecke des Transistors macht den leitend und er zeiht Reset des ESP auf Low. Wenn sich der Kondensator weit genug aufgeladen hat reicht der Bassstrom nicht mehr und der Transistor sperrt und der ESP startet. Deine RS-FF sind eigentlich eine brauchbare Lösung, die Ausgänge können doch direkt an GPIOs vom ESP. MOS 4044 bei Reichelt 0,29€ sollte passen. Den Resetimpuls muß man noch basteln, vermutlich 4 Dioden an die /Q Ausgänge auf einen Kondensator zum Reset des ESP müßte eigentlich schon reichen. Wenn dann per Taster einer der Ausgänge auf Low geht, bekommt der ESP seinen Low-Reset-Impuls. Bei den PIR sind zur Zeit noch 18650 dran, Laufzeit weiß ich noch nicht, im Moment Akkuspannung rund 3,9V nach 5 oder 6 Wochen, müßTe ich nachschauen. Vorerst iste "Proof-of-Concept"... Gruß aus Berlin Michael
:
Bearbeitet durch User
Arduino F. schrieb: > Der ATMega8 hat kein PCINT, Null Komma gar nicht. > Dann betrachte AVR243 als Anregung, wie man einen AVR aus dem Schlaf > holt wenn einer von 8 Pins getriggert wird... > Huch, 8 PCINT Pins... ;-) das geht doch gar nicht! ;-) Ups, PCINTX mit INTX verwechselt ... mein Fehler. Ok dann ists easy :)
Jens H. schrieb: >> Arduino F. schrieb: >>> Ein Suchwort: "AVR PCINT" > > Ja ich kenne die PCINT pins, davon sind ja aber meistens nur 1-3 > vorhanden. Nein, du kennst sie nicht. Was du kennst, sind die INTx-Pins. Davon gibt es tatsächlich nur 1-3. Aber mal abgesehen davon, dass sie oft nicht dafür geeignet sind, den AVR bei einer Spannungs flanke aus dem Tiefschlaf zu holen, waren sie auch nicht das, was Arduino F. meinte. Der meinte, was er sagte: die PCINT-Pins. Und die Dinger sind ALLE dafür gut, einen AVR aus dem Tiefschlaf zu holen. Und jeder AVR, der das Feature überhaupt besitzt, hat es für (zumindest nahezu) alle IO-Pins. Das einzige Problem ist: eher historische AVR, wie etwa der unsägliche ATmega8-Gammel, haben dieses Feature eben einfach noch nicht. Sprich: dein Wissensstand ist ziemlich von vorgestern... Wäre fast spannend, zu wissen, wie weit du der Zeit hinterherhinkst. Ich habe keine exakte Ahnung, aber 5 Jahre sind es mindestens...
Michael U. schrieb: > um wieviele Tasten geht es bei Dir? Wozu der PCF? Der ESP8266-12 hat > doch etliche I/O, die man mit Tasten belegen kann. Ich hab momentan ein Testaufbau mit 4 Tastern. Ich würde mir aber eher 8 Taster + 8 Status LED wünschen ... > Der Transistor ist mangels Basisspannung im Normalfall gesperrrt, Reset > des ESP durch dessen internen PullUp also auf High und der ESP startet > normal. > Bei mir macht er ann den WLAN-Connect und schickt eine MQTT-Message. > Danach geht er in DeepSleep und bleibt so. > Der PIR wechselt bei Akzion von Low nach High. Der Ladestrom des > Kondensators über die BE-Strecke des Transistors macht den leitend und > er zeiht Reset des ESP auf Low. Wenn sich der Kondensator weit genug > aufgeladen hat reicht der Bassstrom nicht mehr und der Transistor sperrt > und der ESP startet. Klingt (selbst für mich) plausibel. Sorry für die blöden Fragen manchmal, ich hatte E-Technik nur im Nebenfach :) > Deine RS-FF sind eigentlich eine brauchbare Lösung, die Ausgänge können > doch direkt an GPIOs vom ESP. Momentan ist mir das zu viel Lötarbeit... deswegen ja die Frage hier, ob man es einfacher hin bekommt. Aber ich denke ich baue mir bei Gelegenheit auch mal so einen PIR auf. Es wäre cool wenn man mehrer PIR sensoren Clustert und eine Bewegungsrichtung detektieren kann :D Muss man schauen ob der ESP schnell genug booten kann um das abzufragen.
@c-hater: Danke für die netten Worte, das bedeutet mir viel :*
Ok, vielen dank für die vielen hilfreichen Posts :) Ich habe jetzt 2 Lösungen die ich ausprobiere: 1) Den Interrupt vom PCF nutzen. Dazu habe ich den neuen Schaltplan nochmal dran gehängt. 2) Einen AVR mit PCINT Feature. Tatsächlich habe ich von den ATmega162 noch ein paar rumliegen :) Sind zwar riesig aber zum testen gehts. Gruß J
Hallo, der ESP schafft es bei guten WLAN-Bedingungen in weniger als 500ms zu booten, WLAN- und MQTT-Connect aufzubauen und die Message abzusetzen. Bedingung u.a.: kein DHCP sondern feste IP. Eine garntierte Reaktionszeit ist das natürlich nicht, hier sind rund 20 WLANs im Umfeld, da gibt es durchaus Ausreißer, wo es mehr als eine Sekunde dauert, ist aber recht selten. Stört dann etwas, wenn der PIR über MQTT/FHEM auf einem anderen ESP das Licht einschalten soll... Gruß aus Berlin Michael
Hi, Ich hatte mir auch mal Gedanken gemacht wie man den ESP über mehrere Taster aufwecken kann und bin auf folgende Lösung gekommen: https://github.com/8n1/esp8266-16x-smart-button Kurz: Ein MCP23017 aktiviert über seine Interrupt Leitung eine LDO mit Enable Pin. Funktioniert soweit auch super. Der eigentich einzige Nachteil ist dass der Benutzer das ganze vor dem erstmaligen benutzen über S1 initialisien muss. Super wäre gewesen wenn der MCP23017 die konfiguration über einen Reset hinaus speichern würde, tut er aber nicht. -- PIR Sensor hab ich auch einen an einem meiner ESP Breakout Adapter hängen. Allerdings nicht wie Michael am Reset Pin sondern am Enable Pin vom (on-board) LDO. Dadurch ist das einzige was im Standby aktiv ist der PIR Sensor. Weiß es nicht mehr genau aber der Stromverbrauch vom PIR(HC-SR501) selber liegt bei ca. 50µA. Hab noch keine langzeittests gemacht, 5-6 Wochen ist aber schon sehr wenig. Wie oft löst der denn aus?
Michael U. schrieb: > Hallo, > > der ESP schafft es bei guten WLAN-Bedingungen in weniger als 500ms zu > booten, WLAN- und MQTT-Connect aufzubauen und die Message abzusetzen. > Bedingung u.a.: kein DHCP sondern feste IP. Schau bitte mit Scope mit 1Ohm auf Vcc. Das Selbst-Timing des ESP ist Beschiss. Wo der 300ms misst, ist er doch 600ms aktiv.
:
Bearbeitet durch User
Hallo, ich habe nicht hemessen, wenn aber MQTTfx nach erkennbar weniger als einer halben Sekunde die Message anzeigt ging es eben so schnell. Auch das Flulicht meines Bekannten ist so schnell, da ist noch openHAB und die Philips Hue Bridge dazwischen. Die Aktiv-Zeit habe ich auch noch nicht gemessen, war ein Versuch, der nun eben schon ein paar Wochen läuft. Johannes S. (8n1): > Allerdings nicht wie Michael am Reset Pin sondern am Enable Pin > vom (on-board) LDO. warum ist mir das nicht eigefallen? ;) Enable vom ESP passt doch auch, Reduziert den Bauteilaufwand doch glatt nochmal. Gruß aus Berlin Michael
Hi, ist mir auch schon in den Sinn gekommen. :) Laut diesem Artikel beträgt der Stromverbrauch im deaktivierten Zustand(CHPD auf GND) 16µA, habs aber noch nicht selber getestet. Kannst du oder jemand das bestätigen? https://www.element14.com/community/groups/internet-of-things/blog/2014/11/19/esp8266-wi-fi-arduino-upload-to-xively Wieso eigentlich MCP1703? Für den akkubetrieb hat mir der MCP1700 aufgrund der niedrigeren Dropout Spannung mehr zugesagt. Allerdings ist mir aufgefallen dass die MCP17xx(und viele andere LDO's) einen erhöhten Stromverbrauch haben wenn sie im Dropout Bereich betrieben werden. Ich hab mit einem MCP1700 45µA bei ~3.3V gemossen. Beim MCP1702 sollen es bis zu 90µA sein wie hier jemand festgestellt und beschrieben hat: http://jeelabs.org/wp-content/uploads/2011/06/21/mcp1702-current-draw/index.html Wenn man aber die Akkuspannung überwacht und sich gegebenenfalls früh genug benachrichtigen lässt ist das eigentlich kein Problem. Falls einem eine "Batterie ist leer" Nachricht reicht braucht man dazu nichtmal einen Spannungsteiler am ADC sondern kann die Versorgungsspannung vom ESP auch intern auslesen und überwachen. Der Wert stimmt zwar nicht wirklich bleibt aber konstant und solange der ESP mit stabilen 3.3V betrieben wird ändert sich nichts am Wert. Wenn der MCP jetzt aber in den Droput bereicht kommt sinkt Vcc vom ESP und der Wert geht runter. In einem ersten (kurzen) Test war das bei etwa 3.5V der Fall. Der ESP32 soll für solche Aufgaben ja einen kleinen ULP Coprozessor onboard haben.
Hallo, Johannes S. schrieb: > Wieso eigentlich MCP1703? Für den akkubetrieb hat mir der MCP1700 > aufgrund der niedrigeren Dropout Spannung mehr zugesagt. weil der MCP1703 gerade da war... >Wenn man aber die Akkuspannung überwacht und sich gegebenenf>alls früh >genug benachrichtigen lässt ist das eigentlich kein Problem. Der ESP von den PIR schickt per MQTT soweiso nur seine Akkuspannung und geht wieder schlafen. Spannungsteiler am ADC, nein Bekannter nutzt Deine Version und läßt sich den internen Wert schicken. Die PIR stehen auf ca. 1:45m Haltezeit. Der Spannungswert wird in FHEM angezeigt und die Übertragung triggert einen 2min Watchdog in FHEM. Für Licht passt das so für mich gut, Weniger als 2 Minuten Licht an normalerweise klappt das Nachtriggern auch gut. Ich mache morgen mal einen PIR an CHPD fertig und messe mal die Ströme. Gruß aus Berlin Michael
Hi, Achso. Gut. :) War nicht sicher ob ich vielleicht was übersehen hab. Jetzt wo wir den Thread schon gekapert haben: Wie versorgst du den PIR? Da du nichts anderes erwähnt hast nehme ich an ganz normal über den Vcc Pin. Ist die Lipo Spannung dafür nicht zu niedrig? Ich übergeh den LDO(HT7133) auf dem PIR(auch HCSR501) und versorge ihn direkt mit der Lipo Spannung über den Retrigger Header. Bin gespannt auf deine Messungen.
Hier mal der Spannungsverlauf am Akku via 910kOhm+200kOhm-Spannungsteiler - zuerst am ESP8266 mit MCP1700-33 - 45µA im DeepSleep. Ziwschendurch mal HT7330 angetestet (2-3 Tage zwischen Woche 34/35), der möchte aber nicht so sparsam sein, wie das Datenblatt sagt ;) Dann auf ESP8285 umgestellt mit MCP1700-33 -25µA- (Woche 36 mit dem tiefen Knick und 100mV Verlust aufgrund kurzzeitigen Kurzschlussbetrieb des LDOs ;) ). Vor drei Tagen dann den HT7830 als LDO davorgesetzt -26µA-, nochmal 50mV verloren. Scheint dennoch ganz gut mit niedrigem Verbrauch dabei zu sein. Warte noch auf MCP1700-30. Vielleicht bringt der mehr Ersparnis aufs Brett. Zumal sich der 900mAh-14500er-LiIon-Akku Dank der 3,0V-Grenze und dem nutzbaren LiIon-Bereich von 4,2-3,0V wirklich ganz auslutschen lässt. Ich vermute, man kann im Graphen auch schon Nichtlinearitäten des ADC erkennen. Manche 5,5mV-Stufe durchläuft er deutlich zu schnell ...
:
Bearbeitet durch User
Hallo, Johannes S. schrieb: > Wie versorgst du den PIR? Da du nichts anderes erwähnt hast nehme ich an > ganz normal über den Vcc Pin. Ist die Lipo Spannung dafür nicht zu > niedrig? PIR-Regler und Diode sind runter, 3,3V von MCP. Die ganzen Sachen sind bei mir eigentlich Zeitvertreib ohne direkte Anwendung. Auch FHEM läuft eher "nur so", hat inzwischen aber einige genutzte Funktionen bekommen, die der Bequemlichkeit dienen und einfach funktionieren. Es laufen hier seit rund 6 Jahren Temperatur/Feuchte-Sensoren mit FOST02/Tiny45/RFM02. Batterielaufzeit dort mit irgendwelchen Pollin-Li-Batterien aus dem Angebot teilweise 3 Jahre. Ein Sensor im Gefrierfach sollte ein Test sein und liegt dort jetzt auch seit Jahren. CR2032 dran, ca. 9 Monate Laufzeit. Das mit den ESP ist jetzt auch erstmal Experimet, auf die Werte kommt man damit ohnehin nicht. Ich könnte auch noch ein paar RFM für PIR u.ä. nehmen, da wäre Laufzeit dann wohl kein Thema. http://www.avr.roehres-home.de/ Gruß aus Berlin Michael
Moin, hier ist mal ein neuer Versuch von mir... Ich habe den neuen Schaltplan und das erwartete Verhalten angehängt. Meint ihr das würde klappen? Der ESP braucht ja eine steigende Flanke zum Aufwachen. Über den GPIO will ich verhindern, dass Interrupts den ESP ungewollt resetten. Bei den Widerständen und der Kapazität bin ich mir unsicher .. habe jetzt mal 1MOhm und 100nF genommen ... Insgesamt sieht es ja schon viel aufgeräumter aus und müsste vom Stromverbrauch her auch super sein :) Gruß
Hallo zusammen, ich möchte keine Leichen-Fledderei betreiben (immerhin ist der letzte Beitrag von 2016), aber ich habe genau dieses Thema versucht nach zu bauen, weil ich vor dem gleichen Problem stehe: Ich brauche mehrere Taster, die den ESP aus dem Deep-Standby/Sleep aufwecken und ich muss auch wissen, welcher der Taster betätigt wurde. Neben ein paar kleineren Problemen (hebe ich mir für später auf, ich denke, ich habe da noch ein Problem mit dem lesen der Eingänge) habe ich ein paar Grundsatzfragen: Die Fragen beziehen sich alle auf den Schaltplan des Vorpostings vom 1.10.2016. 1. Müsste SDA und SCL nicht einen Pull-Up bekommen? 2. Müsste der Reset Eingang des uCs einen Pull-Up bekommen (wahrscheinlich nicht, da der Ausgang des 74LS32 immer "definiert" ist?) 3. PINs 1-3 (A0-A2) des PCF8574 müssten wohl gegen GND geschaltet werden (oder gegen Vcc, je nach gewünschter Adresse) 4. Brauchen die PINs 4-7 (P0-P3) des PCF8574 Pull-Ups oder hat der Expander interne PullUps? Das ist mir auch nach Studium des Datenblattes nicht ganz klar. Danke Sebastian
:
Bearbeitet durch User
Sebastian L. schrieb: > Ich brauche mehrere > Taster, die den ESP aus dem Deep-Standby/Sleep aufwecken und ich muss > auch wissen, welcher der Taster betätigt wurde. Sebastian L. schrieb: > Müsste SDA und SCL nicht einen Pull-Up bekommen? Ja > Müsste der Reset Eingang des uCs einen Pull-Up bekommen Nein, weil das Logikgatter einen Push-Pull AUsgang hat. > PINs 1-3 (A0-A2) des PCF8574 müssten wohl gegen GND geschaltet werden Nicht zwingend, die haben einen internen Pull-Up Widerstand. Schau Dir mal den ESP32 an, der kann das alles als 1-Chip Lösung mit seinem internen ULP Hilfsprozessor, soweit ich einen Kollegen verstanden habe.
Hallo, Danke für´s Feedback! Stefan ⛄ F. schrieb: > Sebastian L. schrieb: >> PINs 1-3 (A0-A2) des PCF8574 müssten wohl gegen GND geschaltet werden > Nicht zwingend, die haben einen internen Pull-Up Widerstand. Betrifft das dann auch P0-P3 des PCF8574, an denen die Taster angeschlossen sind (in der Schaltung oben ohne zusätzliche Pull-Ups)? > Schau Dir mal den ESP32 an, der kann das alles als 1-Chip Lösung mit > seinem internen ULP Hilfsprozessor, soweit ich einen Kollegen verstanden > habe. Habe ich gestern Abend gemacht (auf dem Sofa ;-)) - Das ist sehr interessant. Den ULP kann man wohl nur in Assembler programmieren, aber für zwei oder drei Taster sollte das wohl hin zu bekommen sein. Allerdings sitzt "mein" ESP8266 an einem ePaper Display. Deswegen würde ich bei diesem Projekt trotzdem gerne den PCF8574 verwenden. Der Hinweis was aber äusserst interessant, Danke dafür! Sebastian
Sebastian L. schrieb: > Betrifft das dann auch P0-P3 des PCF8574, an denen die Taster > angeschlossen sind Ja, alle Pins haben einen schwachen internen Pull-Up.
Stefan ⛄ F. schrieb: > Ja, alle Pins haben einen schwachen internen Pull-Up. sehr gut, das dürfte beim Stromsparen helfen ;-) Danke!
Stefan ⛄ F. schrieb: > Ja, alle Pins haben einen schwachen internen Pull-Up. Vorsicht mit hochohmige Pull-Ups und Funkmodule. Die Funksignale können bei langen Leitungen von den Tasten zu den Eingängen eingestreut werden Ich würde sicherheitshalber RC-Filter für die hochohmige Eingänge vorsehen. Diese könnten auch die Entprellung übernehmen. Kondensatoren und Widerstände, am besten in SMD ausführen und nahe bei den Eingängen plazieren. Beitrag "Re: Wo Kondensator hin?" Sind sie auf Grund eins guten Layouts nicht notwendig, dann können die Filterkondensatoren unbestückt bleiben.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.