Hallo zusammen,
ich hätte gerne ein paar "Amazon Dash-Button"-ähnliche WiFi-Buttons.
Statt Original Amazon Dash-Buttons zu verwenden und zu hacken, möchte
ich dafür allerdings lieber eine eigene Schaltung/Platine auf
ESP8266-Basis entwickeln, aus folgenden Gründen:
- Es ist zwar durchaus möglich, Amazon Dash-Buttons durch irgendwelche
Hacks zweckzuentfremden; aber diese Hacks sind entweder unnötig
umständlich, wenn sie nicht auf Firmware-Ebene ansetzen (da wird dann
das Netzwerk permanent auf bestimmte Pakete gemonitored), oder, wenn sie
tatsächlich mal auf Firmware-Ebene ansetzen, (zumindest meinem
bisherigen Eindruck nach) noch immer nicht sonderlich weit
fortgeschritten, sondern meist auf "eine LED blinken lassen"-Niveau
- Ein Dash-Button ähnlicher WiFi-Button auf ESP8266-Basis sollte
grundsätzlich auch günstiger herzustellen sein als die Amazon-Hardware
- Amazon Dash-Buttons gibt es hierzulande regulär nur für Amazon
Prime-Kunden zu kaufen; wer nicht Prime-Kunde ist, kommt nur auf Umwegen
an Dash-Buttons heran (oder muss die AWS-Versionen benutzen, die gleich
20 Euro pro Stück kosten)
- Es ist nicht vorgesehen, das Dash-Button-Gehäuse zu öffnen, um bspw.
die Batterie auszutauschen; es ist schwer bis unmöglich, das Gehäuse zu
öffnen ohne es zu beschädigen
Mein persönlicher Eindruck ist, dass es da draussen etliche Leute wie
mich gibt, die an einem besonders günstigen, Dash-Button ähnlichen
WiFi-Button grundsätzlich Interesse hätten - weniger, um irgendwas auf
Knopfdruck zu bestellen, sondern für die ganz unterschiedlichsten
Anwendungsszenarien.
Ich wollte daher einfach mal anfragen, wer hier an so etwas ebenfalls
Interesse hätte, entweder...
- als Mitstreiter, der bereit wäre mitzuhelfen so eine
Schaltung/Platinenlayout zu entwickeln und (bei genug Nachfrage) später
herzustellen
oder
- als reiner Interessent, der sagt: Wenn ihr es schafft, eine
funktionsfähige Platine für soundsoviel Euro herzustellen, dann würde
ich vermutlich soundsoviel Exemplare abnehmen
Ich habe bereits mal angefangen, eine entsprechende Schaltung zu
entwerfen - ausser einem ESP12-F-Modul (bei Aliexpress ab ca. 1,50 Euro
zu kaufen) besteht sie bislang nur aus fünf Widerständen, einer Diode
und einem Taster (siehe Anlage - ist erst mal nur der relevante Teil der
Schaltung, das eigentliche ESP-12-F-Modul und die Batterie selbst sind
auf der Grafik nicht zu sehen).
In einem ersten Test hat diese Schaltung auch scheinbar korrekt
funktioniert - aber ich bin einfach ein kompletter Anfänger was
Elektronik und Schaltungsentwurf betrifft, daher ist die Schaltung im
jetzigen Zustand garantiert noch reichlich suboptimal (um nicht zu
sagen: vermutlich ziemlicher Schrott).
Am wichtigsten erscheint mir die Frage, wie man es schafft, dass die
Schaltung im inaktiven Zustand möglichst wenig Strom verbraucht. In
meinem angehängten ersten Schaltungs-Versuch habe ich versucht, das
einzig und alleine über die CH_PD/Chip enable-Leitung zu machen; Diese
Lösung benötigt fast keine Bauteile und verbraucht vglw. wenig Strom
(mein Multimeter zeigte 2 µA im inaktiven Zustand an) - aber ich nehme
mal an, das ist immer noch zu viel, und man sollte da lieber eine Lösung
benutzen, wo man direkt die VCC-Zuleitung schaltet...
Hallo,
warum nicht den ESP in DeepSleep schicken und den Taster einfach an
Reset?
Er sendet dann eben nach loslassen des Tasters und geht dann wieder
schlafen.
Problem ist eher die Stromversorgung, was willst Du da nehmen?
Gruß aus Berlin
Michael
Michael U. schrieb:> warum nicht den ESP in DeepSleep schicken und den Taster einfach an> Reset?
Yo
> Er sendet dann eben nach loslassen des Tasters und geht dann wieder> schlafen.
Yo
> Problem ist eher die Stromversorgung, was willst Du da nehmen?
Ne, siehst du da ein Problem?
So macht man es:
http://battery-life.of-things.de/battery-life-calculator.phphttps://www.youtube.com/watch?v=IYuYTfO6iOs
"If it transmits every 2 minutes, it ran 26 hours on a small LIR2450
button cell. If it would transmit each hour, it would last for 17 days
and on 2 AA batteries 425 days."
Der kleine Mann macht das so.
Hallo,
kleiner_mann schrieb:>> Problem ist eher die Stromversorgung, was willst Du da nehmen?>> Ne, siehst du da ein Problem?
Jaein. Die LIR2450 hat wohl um 100mAh Kapazität. Spannung ist bei 0,2C,
also 20mA mit 3,7V angegeben, komplettes Datenblatt habe ich noch nicht
gesucht.
Der ESP will aktiv rund 100mA, er macht ja außer senden nicht viel.
Li-IO erfordern einen Spannungsregler auf 3,3V. Preise sind auch nicht
so toll.
Kommt ja auch darauf an, wie groß ein "Dash-Button" werden soll.
Der ESP läuft von 3,0-3,6V, vermutlich bei üblicher Raumtemperatur auch
noch etwas unter 3V. Eine Li-Primärzelle würde also auch passen,
vermutlich dürfte ein dicker Elko (Baugröße, Reststrom) die Spitzen
abfangen müssen.
Ansonsten könnte man auch einfach die BT-China-Schlüsselfinder für 1€
nehmen, meine liegen hier noch ungetestet rum...
Ich hätte bei solche einem "Gerät" wenig Lust, daß der Akku leer ist,
wenn ich es benutzen will oder ich noch was hätte, wo mir FHEM eine Mail
schicken muß, weil mein Button keinen Strom mehr hat. ;)
Ich werde am Wochennede mal meine nächste Variante der
ESP8266-PIR-Sensoren testen. Vielleicht experimentiere ich da mal mit
Li-Zelle, wenn ich was geeignetes zur Hand habe.
An den beiden in Betrieb befindlichen ist jeweils eine 18650 dran, war
eben gerade zur Hand. Die laufen schon etliche Wochen, vermutlich 10-20x
am Tag ausgelöst. Akkuspannung zur Zeit gut 3.9V.
Gruß aus Berlin
Michael
> Ansonsten könnte man auch einfach die BT-China-Schlüsselfinder für 1€> nehmen, meine liegen hier noch ungetestet rum...
Von denen habe ich hier selbst noch ca. ein halbes Dutzend rumliegen.
Zwei oder drei verschiedene Modelle mit der Bezeichnung "iTag", die von
Verpackung etc. ununterscheidbar sind. Die verbaute Platine
unterscheidet sich aber gewaltig - das eine Modell hat irgendeinen Bug
und funktioniert überhaupt nicht richtig; das andere Modell funktioniert
zwar grundsätzlich, die Knopfzelle hält aber gerade mal 1-2 Tage -
völlig unbrauchbar.
Falls Du Deine mal testest und damit zufrieden bist, wäre ich wirklich
interessiert, wo genau Du Deine Exemplare her hast.
Grundsätzlich scheinen mir solche BT-Schlüsselfinder allerdings eh nur
bedingt als Ersatz für WLAN-Buttons zu taugen, denn schliesslich braucht
man dann immer noch ein weiteres, BT 4.0-fähiges Gerät als Gegenstelle.
Michael U. schrieb:> Hallo,>> warum nicht den ESP in DeepSleep schicken und den Taster einfach an> Reset?> Er sendet dann eben nach loslassen des Tasters und geht dann wieder> schlafen.>> Problem ist eher die Stromversorgung, was willst Du da nehmen?
Deep Sleep hatte ich ehrlich gesagt (zu voreilig?) ausgeschlossen, weil
ich nach Lesen dieser Tabelle:
http://bbs.espressif.com/viewtopic.php?t=133
(bzw.
http://bbs.espressif.com/download/file.php?id=177&sid=3fd5178a2ee330505ec0d3fdbc03640d)
vermutete, dass dieser Modus einfach zuviel Strom verbraucht. Dort wird
für den "Deep Sleep"-Zustand nämlich (immerhin) 10µA angegeben - für den
"Power Off"-Zustand hingegen nur 0.5µA.
Als Stromversorgung hatte ich ursprünglich, der Einfachkeit halber, an
zwei in Reihe geschaltete AA oder AAA-Batterien gedacht - das hatte ich
schon in mehreren ESP8266-Projekten gesehen, das scheint grundsätzlich
also zu funktionieren. Da Batterien Einweg-Artikel sind und ein
Dash-Button sich 99,9% der Zeit ja im inaktiven Zustand befindet, bin
ich davon ausgegangen, dass 10µA für Deep Sleep schlicht zuviel sind,
weil bei ca. 2µA im inaktiven Zustand wie bei meiner Schaltung die
Batterien dann ja fast fünfmal so lange halten sollten. Bzw., mit einer
besseren/stromsparenderen Schaltung, hoffentlich nochmal ein Vielfaches
davon.
Im Eröffnungsposting dieses Threads hier:
https://forum.makehackvoid.com/t/esp8266-operating-voltage-range-and-sleep-current/286
hat übrigens Jemand mal versucht zu testen, bis zu welcher
Minimalspannung der ESP8266 noch stabil läuft. Er schätzt ungefähr 2.5V.
Der Umwelt etc. zuliebe wäre eine Stromversorgung mit LiPos aber
vermutlich sinnvoller, das sehe ich ein. Ideal wäre vermutlich, dass man
für die Stromversorgung einfach die Wahl hat zwischen zwei in Reihe
geschalteten AA/AAA-Batterien und einer LiPo-Zelle...
Hallo,
so, mal ein Schnellschuß...
Die 2,5V kann ich zumindest für meinen ESP8266-03 etwa bestätigen, 2,42V
war der gemeldete neidrigste Wert von ESP.getVcc().
3x AAA o.ä. sollten also auch länger kein Problem sein.
Strommessung in Ruhe habe ich noch nicht, da muß ich anders messen. Der
Spannungsabfall am Multimeter ist schon im 20mA Bereich so hoch, daß der
ESP nicht mehr sauber startet.
Bei üblichen AAA wären 20µA in Ruhe rechnerisch rund 5 Jahre...
Laufzeit ist knapp unter einer Sekunde mit ca. 120mA nach Tastendruck.
Der Strom steigt allerdings schon beim Drücken von Reset auf ca. 15mA
an, der Taster sollte also besser nicht klemmen. ;)
Mit 1s wären es also rund 0,033mAh. 10x drücken am Tag also 0,3mAh.
Ich würde da also auf möglichst übliche Primärzellen setzen.
Schnell gewechselt und preiswert.
Preiswerte Li-Zellen, wären fotobatterien wie z.B. die CR123A.
Hier noch der Testsketch, nicht wundern, daß PIR drin ist...
MQTT ist bei mir für solche Sachen generell das Protokoll der Wahl.
kleiner_mann schrieb:> So macht man es:>> http://battery-life.of-things.de/battery-life-calculator.php
Danke für den Link, genau sowas habe ich eh mal gesucht. Schade nur,
dass es da nur um LiPo-Zellen geht, hätte gerne auch mal entsprechende
Werte für 2 AA/AAA-Zellen in Reihe gesehen.
Jedenfalls habe ich diesen Battery Life Calculator eben mal testweise
ausprobiert, mit folgenden angenommenen Werten:
Inaktiver Zustand: 2µA Stromverbrauch
Aktiver Zustand: 170mAh Stromverbrauch, 5 Sekunden lang; Button wird
einmal täglich aktiviert (86400 Sekunden).
Stromversorgung durch eine einzige 14500er LiPo-Zelle mit 600mAh.
Für diese Zahlen berechnet der Calculator, dass die LiPo-Zelle 1705
Tage, also über 4,5 Jahre hält. Bei 10µA im inaktiven Zustand wären es
immerhin auch noch 1036 Tage.
Sofern ich da bei der Berechnung nicht einfach einen Denkfehler hatte(?)
erscheinen mir das absolut akzeptable Werte zu sein.
Wenn man eine LiPo-Zelle benutzt, braucht man aber auch noch zwingend
einen 3.3V-Spannungsregler, oder? Wie stark steigt dadurch der
Stromverbrauch im inaktiven Zustand an, kann man das ungefähr
abschätzen?
Hallo,
Deine Rechnungen sollten schon soweit passen.
Was macht Dein ESP8266 5s lang mit 170mA?
WLAN-Connect, MQTT-Connect, absetzen der Message dauert keine Sekunde.
Mit QoS auf 1, wenn man die Bestätigung des Brokers haben will, etwas
länger.
Stromverbrauch ist ca. 85mA mit WLAN aktiv ohne was zu machen, ca. 120mA
im Durchschnitt hier, wo in der Wachzeit nur WLAN beschäftigt ist.
Regler bei meinen PIR ist z.Z. der MCP1703 weil er gerade da war.
Ruhestrom ist mit 2µA angegeben.
Ich zumindest werde mal den Li-Fotobatterien nachgehen, habe nur keine
hier rumliegen.
Gruß aus Berlin
Michael
Michael U. schrieb:> [...]
Super, Michael, da bin ich ja echt schon mal begeistert! :)
Was genau hast Du da jetzt für eine Schaltung benutzt? Einfach 2
AAA-Batterien zur Stromversorgung, 1 ELKO als Stützkondensator, und ein
Taster zwischen GND und RESET? Sind die nötigen Pullups/Pulldowns für
GPIO0, GPIO2 und GPIO15 bereits auf dem ESP8266-03-Modul enthalten, oder
sieht man die einfach auf dem Bild nicht?
Ich frage mich ja noch immer, ob es (aus Stromverbrauchs-Sicht) wirklich
genügt, den ESP in den Deep Sleep zu schicken. Das würde das Ganze
natürlich wirklich nochmal vereinfachen, und hätte natürlich auch den
Vorteil, dass sich der ESP dann selbst aufwecken könnte... Wobei mir bei
einem Dash-Button zumindest auf Anhieb keine wirklich sinnvolle
Anwendung einfällt, wofür das praktisch wäre (Und die den damit
verbundenen erhöhten Stromverbrauch rechtfertigen würde).
Aber ein anderer Gedanke, der mir eben noch kommt: Wenn man Deep Sleep
benutzt, den Tester also mit dem Reset-Pin verbindet - dann ist es aber
auch nicht mehr möglich, den Taster während des Betriebs nochmal zur
Eingabe zu benutzen, weil man dann sofort wieder einen Reset auslösen
würde, oder?
> Was macht Dein ESP8266 5s lang mit 170mA?> WLAN-Connect, MQTT-Connect, absetzen der Message dauert keine Sekunde.> Mit QoS auf 1, wenn man die Bestätigung des Brokers haben will, etwas> länger.> Stromverbrauch ist ca. 85mA mit WLAN aktiv ohne was zu machen, ca. 120mA> im Durchschnitt hier, wo in der Wachzeit nur WLAN beschäftigt ist.
Was die 170mA betrifft: Da habe ich einfach mal den maximalen Wert aus
der oben verlinkten Tabelle genommen, es ging mir eh nur um einen
Schätzwert.
Ähnlich bei den 5 Sekunden: Das war einfach eine grobe Schätzung, wie
lange mein ESP8266 ungefähr für WLAN-Connect, Zuweisung einer IP per
DHCP, MQTT-Connect und Absetzen einer MQTT-Message mit QOS braucht. Ich
habe zwar nie die Zeit gestoppt, aber das war schon mehr als eine
Sekunde. Daher habe ich mit 5 Sekunden einfach mal einen grosszügigen
Worst Case-Schätzwert benutzt.
Hallo,
GPIO15 hat hinten einen 15k gegen GND rangelötet bekommen, die anderen
(wichtigen) incl. Reset haben vom ESP generell interne aktive PullUps
zur Bootzeit.
Ruhestrom messe ich am Wochenende mal. Der ist mir auch nur in Grenzen
wichtig, ob eine Batterie 5 Jahre, 3 Jahre oder nur 1,5 Jahr hält, ist
mir relativ egal. Ich will nur nicht alle paar Wochen Batterien wechseln
oder Akku laden.
DHCP kostet etliche Zeit, der Router muß ja erstmal antworten.
Ohne DHCP mit fester IP geht es wesenlich schneller.
MQTT-Broker läuft hier auf einem RasPi mit FHEM, der reagiert sehr
schnell.
Taster als Eingabe geht da natürlich so nicht, das hätte ich da aber
auch im Moment nicht vor.
Ich habe jetzt mal den PIR rangehängt, allerdings an Enable wegen des da
passenden Pegels.
Macht auch, was er soll, beim PIR (HC-SR501) natürlich Spannungsregelr
runter und die Diode gebrückt, so daß er auch mit den 3V läuft.
Da kann ich dann wenigstens in FHEM mal schnell schauen, wann er sich
das letzte Mal mit welcher Spannung gemeldet hat.
Gruß aus Berlin
Michael
Michael U. schrieb:> GPIO15 hat hinten einen 15k gegen GND rangelötet bekommen, die anderen> (wichtigen) incl. Reset haben vom ESP generell interne aktive PullUps> zur Bootzeit.
Wie, der ESP8266 braucht gar keine externen Pullups für GPIO0 und GPIO2,
um von Flash zu booten?!?
> Ruhestrom messe ich am Wochenende mal. Der ist mir auch nur in Grenzen> wichtig, ob eine Batterie 5 Jahre, 3 Jahre oder nur 1,5 Jahr hält, ist> mir relativ egal. Ich will nur nicht alle paar Wochen Batterien wechseln> oder Akku laden.>> DHCP kostet etliche Zeit, der Router muß ja erstmal antworten.> Ohne DHCP mit fester IP geht es wesenlich schneller.> MQTT-Broker läuft hier auf einem RasPi mit FHEM, der reagiert sehr> schnell.
Bei den Anwendungsfällen, die ich persönlich momentan im Kopf habe, ist
es etwas anders, denn in denen wird der Dash-Button teilweise nur sehr
selten betätigt.
Beispielsweise möchte ich meinem pflegebedürftigen Vater einen
WiFi-Button als Notruf-Taster um den Hals hängen, der mich und andere
Angehörige informieren kann. Wenn der mal wieder in der Wohnung stürzt,
dann kommt er nicht mehr hoch - das passiert, wenn's hochkommt, aber
Gott sei Dank maximal einmal im Monat.
Daher lag mein Augenmerk bislang vor Allem auf dem Stromverbrauch im
inaktiven Zustand...
> Taster als Eingabe geht da natürlich so nicht, das hätte ich da aber> auch im Moment nicht vor.
Kann man sicher auch drauf verzichten, erschien mir einfach als
potentiell recht nützliches Feature - schon deshalb, weil man dann mit
einem einzigen Button zwischen mehreren Aktionen wählen könnte.
Hallo,
Oyoyo schrieb:> Wie, der ESP8266 braucht gar keine externen Pullups für GPIO0 und GPIO2,> um von Flash zu booten?!?
ich müßte jetzt Datenblatt- oder Bestückungsstudien betreiben, um sicher
zu gehen.
Die von mir bisher benutzten Module (ESP8266-01, -03, -07, -12E und -12F
jedenfall brauchen extern keine.
Gruß aus Berlin
Michael
Michael U. schrieb:> ich müßte jetzt Datenblatt- oder Bestückungsstudien betreiben, um sicher> zu gehen.> Die von mir bisher benutzten Module (ESP8266-01, -03, -07, -12E und -12F> jedenfall brauchen extern keine.
Interessant, muss ich bei Gelegenheit doch mal ausprobieren...
Habe eben mal den Schaltplan des ESP-12F-Moduls angeschaut - da sind
zumindest keine integrierten Pullups für diese Pins zu sehen, die werden
offenbar 1:1 vom ESP8266EX nach aussen durchgeleitet.
Andere Frage: Wie gross sollte der Stützkondensator bei
Akku/Batterie-Betrieb wohl dimensioniert sein, kann man das
ausrechnen/abschätzen?
kleiner_mann schrieb:> HT7333 voltage regulator> Beispiel:> http://www.aliexpress.com/item/10PCS-HT7333-A-SOT89-HT7333-1-SOT-89-HT7333A-1-7333-1-SMD-7333A-1-new/32531141419.html>> Datenblatt studieren und in die ( guter Ansatz ) Rechnung mit einbauen.
Danke für den Hinweis. Preislich ist das ja echt okay, zumindest wenn
man bei Ali bestellt.
Als 3.3V Spannungsregler habe ich bislang immer LD1117/AMS1117 benutzt -
meine aber irgendwo gelesen zu haben, dass die für Batteriebetrieb eher
ungeeignet sind, weil sie im Leerlauf vglw. viel Strom verbraten würden,
und es da bessere Alternativen gäbe. Gilt der von Dir verlinkte
Spannungsregler als so eine gut geeignete Alternative?
Eine andere Lösung, die ich irgendwo gesehen habe: Da hat Jemand einfach
den Spannungsabfall einer Diode benutzt. Das erschien mir auf Anhieb
recht clever, weil eine LiPo-Zelle ja 3,7V Nennspannung und eine
Ladeschlussspannung von 4,2V hat. Bei einer Diode mit 0,7V
Spannungsabfall käme man damit auf 4,2 - 0,7 = 3,5V Spannung im voll
geladenen Zustand, und 3,7 - 0,7 = 3,0V Spannung wenn die Spannung der
LiPo-Zelle auf Nennspannung abgesackt ist. Das scheint mir ziemlich
perfekt zur empfohlenen Betriebsspannung des ESP8266 zu passen, die in
den Datenblättern (wie ich mittlerweile nachgeschaut habe) mit 3,0V -
3,6V angegeben wird...
Diese Lösung erscheint mir auf den ersten Blick auch den Vorteil zu
haben, dass man über die Abfrage der VCC-Spannung per Software
vermutlich den aktuellen Ladezustand des Akkus besser einschätzen kann -
denn ein 3.3V-Spannungsregler wird ja vermutlich die ganze Zeit 3.3V
melden, und erst wenn der Akku schon fast leer ist, unter 3.3V absinken,
oder?
Der ESP32 soll doch bald kommen.
Bezüglich Stromsparen kann der einiges mehr soviel ich gelesen habe.
Du könntest dir auch mal die Selbstabschaltung vom Transistortester
anschauen.
Bei meinem hält der 9V Block nun schon 3 Jahre.
Grundsätzlich bin ich allerdings der Meinung solche Knöpfe
müssen ihre eigene Energie erzeugen um brauchbar zu sein.
Mich nerven schon ständig die Rauchmelder.
Der HT73xx war nicht so der Knaller.
Zum Stromsparen aus der Praxis mal hier:
http://blog.koepi.info/2016/08/further-improving-powersaving-with.html
Die unterschiedlichen LDOs angetestet hier:
http://blog.koepi.info/2016/09/power-supply-for-cs-via-ldos.html
Der HT78xx war schon besser, aber bislang bleibt der MCP1700
nonplusultra.
Die 3,0V-Varianten funktionieren hervorragend und lassen die Nutzung des
vollen LiIon-Spannungsbereiches (3,0-4,2V) zu.
Der Quatsch mit der Diode ist hier im konkreten Fall ebensolcher -
Quatsch. Der Spannungsabfall ist lastabhängig. Im DeepSleep beträgt der
nur noch 0,3V statt 0,7V. Du verschenkst zudem ordentlich Kapazität
durch "Ende" bei 3,7V - da ist der LiIon noch halbvoll. Mach' es richtig
mit sparsamen LDO. Der LM/AMS1117 verbrät im Leerlauf schon 5mA+. Da
sind die 1-2µA der ordentlichen Regler deutlich besser für den
Batteriebetrieb.
Moin,
man könnte ja auch "Hardware deep stand by" machen.
Batterie -> P-Fet -> Regler (o.sonst was) -> ESP
Der ESP hält per GPIO den Fet on (solange er was zu tun hat), der Taster
überbrückt zum starten nur kurz den Fet.
Das verbraucht dann überhaupt keine Energie mehr im stand by.
Oyoyo schrieb:> Autor:>> Oyoyo (Gast)
Melde dich mal an. Deine Grundidee ist richtig gut.
Ich habe nur einen anderen Ansatz dazu.
Da ließe sich richtig Geld mit verdienen.
Oder melde dich mal per PN.
Würde mich heute Abend melden.
@TO
Muss für deinen Zweck der ESP "deepend sleep" Aufgaben erledigen?
Du brauchst eigentlich überhaupt kein Deep Sleep.
Mach doch einfach ein Brückenglied mit Selbsthaltung über ein GPIO in
deine Schaltung, die den ESP dann mit Power versorgt. Sobald die Aufgabe
erledigt ist, "switched" der GPIO zurück und das Brückenglied ( Reseter,
HoldOnRelaise, oder was auch immer deine Vorzüge sind "Brückenglied"
steht hier für alles mögliche ) trennt die ganze Schaltung vom Supply.
Dein Dash Button ist dann "Einschalter" und "SendButton" zugleich.
Taster gedrückt:
-> der ESP startet
-> Connect Wifi Router Internet
-> setzt seinen Vorkonf. Button Click ab
-> schaltet über GPIO das Brückenglied wieder zurück
-> der ESP ist aus und bleibt aus bis zum nächsten Click
Es wird nur Strom verbraucht, wenn der ESP startet,
sobald er sich wieder ausschaltet, ist die Schaltung auch
ohne Verbrauch. Es gibt keinen Standby.
Du drückst und stösst damit den "Firmware" Prozess an und lässt den
Prozess einfach selber seinen Lauf, auch das Ausschalten folgt
automatisch.
Stell dir das einfach vor:
Power an , der ESP läuft
Power aus, der ESP ist aus, kein Deep Sleep, kein Standby.
Du schaltest also nicht nur den Power EN sondern auch den Vcc.
Nur den Power En zu schalten wäre wieder Standby, DeepSleep,
Hintergrundaktivitäten und somit "Stromverbrauch".
Für einen "Dash Button" braucht es keinen Deep Sleep, es sei denn, du
brauchst RTC.
Toralf W. schrieb:> Moin,>> man könnte ja auch "Hardware deep stand by" machen.> Batterie -> P-Fet -> Regler (o.sonst was) -> ESP> Der ESP hält per GPIO den Fet on (solange er was zu tun hat), der Taster> überbrückt zum starten nur kurz den Fet.>> Das verbraucht dann überhaupt keine Energie mehr im stand by.
Sry - Oh - den Beitrag habe ich übersehen.
Genau so.
Michael U. schrieb:> Hallo,>> warum nicht den ESP in DeepSleep schicken und den Taster einfach an> Reset?> Er sendet dann eben nach loslassen des Tasters und geht dann wieder> schlafen.
Warum nicht mit dem Taster die Versorgung des ESP einschalten, und über
eine Selbsthaltung vom ESP so lange den Taster überbrücken, bis er seine
Arbeit getan hat, und dann schaltet er sich selbst wieder ab.
Grüße
DeepSleep ist getestet und erprobt. Man kann Daten im RTC-Speicher
ablegen und nach dem Aufwachen wiederverwenden. Verbindungsaufbau im
WLAN so deutlich fixer als aus dem Kaltstart (selbst mit statischer IP
sind das >2,5s vs 600ms). Dafür kann ich seeehr lange DeepSleep machen.
Selbsthaltung könnte etwas frickelig werden, da der ESP so 100-150ms zu
aufwachen braucht - und da wäre der FET dann im Zweifel wieder "zu".
Nicht unlösbar.
@Dirk Kam mir in den Sinn, weil ich das schon für dieverse kleine Geräte
so realisiert hab. Aber ok, wenn du das schon durchgerechnet hast, dann
ist in deisem Falle halt nicht brauchbar.
Danke.
Toralf W. schrieb:> Moin,>> man könnte ja auch "Hardware deep stand by" machen.> Batterie -> P-Fet -> Regler (o.sonst was) -> ESP> Der ESP hält per GPIO den Fet on (solange er was zu tun hat), der Taster> überbrückt zum starten nur kurz den Fet.>> Das verbraucht dann überhaupt keine Energie mehr im stand by.
Genau so etwas erscheint mir instinktiv auch die letztlich ideale Lösung
zu sein, im Sinne der Minimierung des Stromverbrauchs im inaktiven
Zustand.
Nur leider sind jegliche Transistor-, FET- etc. -Schaltungen für mich
immer noch ein Buch mit sieben Siegeln - die Schaltung im
Eröffnungsposting war im Grunde mein Versuch einer "poor
man's"-Umsetzung des gleichen Grundgedankens, ohne tatsächlich eine
Transistor-/FET-Schaltung einsetzen zu müssen, von der ich keine Ahnung
habe ;-) .
@kleiner_mann:
Die von Dir geposteten Links zu vergleichbaren Projekten scheinen fast
alle die gleiche Schaltung zu beschreiben, nämlich die hier:
https://github.com/DeqingSun/ESP8266-Dash-Button
Das ist aber auch wirklich ein sehr interessantes Projekt, das meinen
Vorstellungen schon sehr nahe kommt. In diesem Projekt wird, soweit ich
das beurteilen kann, auch tatsächlich so eine oben erwähnte Schaltung
benutzt, um den Stromverbrauch im inaktiven Zustand zu minimieren.
In der Anlage dieses Postings findet sich eine Grafik mit der dort
verwendeten "Selbsterhaltungsschaltung"; über GPIO12 wird offenbar die
Selbsterhaltung gesteuert, über GPIO14 wiederum kann offenbar der
Zustand des Tasters abgefragt werden, wenn ich das richtig sehe?. Nur,
wie das Ganze im Detail funktioniert, die Funktion jedes einzelnen
Bauteils etc., verstehe ich einfach nicht 100%ig... :-(
@Alle:
Mich würde ja übrigens mal interessieren, was für persönliche
Feature-Wünsche/-Ideen andere Leute an die Hardware so eines
WiFi-Buttons hätten.
Bei mir z.B. wäre das:
- Taster ist während des Betriebes auch als Eingabegerät verwendbar
(z.B. um in einen "Konfigurationsmodus" zu schalten oder um zwischen
mehreren Aktionen zu wählen)
- eine RGB-LED zur Anzeige (praktisch für visuelles Feedback etc., und
bspw. eine 5050 RGB LED gibt's bei Aliexpress für unter 2 Cent pro
Stück)
- evtl. noch ein Photowiderstand oder etwas ähnliches (zur besonders
einfachen Konfiguration bspw. der WLAN-Zugangsdaten, ähnlich, wie der
Original Amazon Dash-Button über sein integriertes Mikrofon konfiguriert
werden kann. Der WiFi-Button könnte dann z.B. umkonfiguriert werden,
indem man ihn an einen Computer-/Smartphone-Bildschirm hält, der die zu
konfigurierenden Daten als "Blink-Folge" kodiert ausgibt. Erscheint mir
als potentiell sehr nützliches, und gleichzeitig sehr günstig
umzusetzendes Feature, denn Photowiderstände gibts bei Aliexpress schon
für unter 3 Cent das Stück)
Na das ist ja ein super Projekt!
Ich würde gerne 20 Teile (oder mehr) -zu einem leistbaren Betrag-
nehmen.
Meine Vorstellung wäre, je Produkt einen Datensatz an einen Raspberry Pi
zu senden, um eine Einkaufsliste zusammen zu stellen.
Die Idee von Amazon finde ich gut, aber ich kann Amazon nicht leiden und
hätte gerne eine Enkaufsliste, wo ich mir den Laden selbst ausuchen
kann.
Gruß
Ludwig
Was ich an der Schaltung nicht verstehe:
Wenn der Schalter gedrückt wird, schaltet Q1 durch und Vcc == Vbat.
Damit Q1 nicht wieder sperrt, muss der uC schnell genug Q2 durchschalten
um das Gate von Q1 auf GND zu halten.
Wenn man nun zu schnell/kurzt drückt, dürfte das nicht funktionieren,
oder?
345gtdg schrieb:> Was ich an der Schaltung nicht verstehe:> Wenn der Schalter gedrückt wird, schaltet Q1 durch und Vcc == Vbat.> Damit Q1 nicht wieder sperrt, muss der uC schnell genug Q2 durchschalten> um das Gate von Q1 auf GND zu halten.>> Wenn man nun zu schnell/kurzt drückt, dürfte das nicht funktionieren,> oder?
Ich schätze ja, der Taster muss bei dieser Schaltung wohl zumindest so
lange gedrückt werden, wie der ESP8266 vom Anlegen der Betriebsspannung
bis zur Codeausführung braucht.
Müsste man wirklich mal in der Praxis testen, instinktiv würde ich aber
vermuten dass das kein sooo grosses Problem darstellt:
- letztlich dauert das nicht allzu lange, und die Betätigung des Tasters
braucht ja auch eine gewisse Zeit
- In der Regel wird man ja über eine LED Feedback geben - sobald die
Code-Ausführung beginnt und die Stromzufuhr per Software aktiviert
wurde, lässt man eine Status-LED aufleuchten - dann weiss man, dass man
loslassen kann
Falls man dieses Problem vglw. einfach reduzieren oder gar eliminieren
kann (z.B. mit einem zusätzlichen Kondensator oder so?), wäre es aber
sicherlich sinnvoll, das auch zu tun.
Hallo,
Oyoyo schrieb:> - In der Regel wird man ja über eine LED Feedback geben - sobald die> Code-Ausführung beginnt und die Stromzufuhr per Software aktiviert> wurde, lässt man eine Status-LED aufleuchten - dann weiss man, dass man> loslassen kann
dann braucht es auch keinen zusätzlichen Aufwand. Taster in die
Betriebsspannungsleitung und LED + Vorwiderstand an einen GPIO.
Taste drücken und festhalten bis die LED angeht und fertig.
Gruß aus Berlin
Michael
Michael U. schrieb:> dann braucht es auch keinen zusätzlichen Aufwand. Taster in die> Betriebsspannungsleitung und LED + Vorwiderstand an einen GPIO.> Taste drücken und festhalten bis die LED angeht und fertig.
Das ist für mich keine Option, weil ich wie gesagt die Möglichkeit haben
möchte, den Taster während des Betriebes zur Eingabe benutzen zu können;
bspw. um zwischen mehreren Aktionen zu wählen.
Das Projekt macht Fortschritte, ich habe mittlerweile mal den ersten
Prototypen einer Platine entworfen (siehe Anlage).
Nun bin ich aber auf ein Phänomen gestossen, dass ich mir momentan nicht
erklären kann. Die Schaltung im Eröffnungsposting verhält sich nämlich
in der Praxis leicht anders, als man es instinktiv erwarten würde:
Es war zumindest bei meinem Breadboard-Testaufbau gar nicht nötig, den
Button zumindest so lange gedrückt zu halten, bis nach dem Booten GPIO12
auf high-Level gesetzt und so die Selbsthalte-Funktion aktiviert wird.
Selbst, wenn ich ganz bewusst versucht habe, den Button so kurz wie nur
irgend möglich zu betätigen, und GPIO12 zum Zeitpunkt des Loslassen
definitiv noch nicht aktiviert war, schaltete sich die Schaltung nicht
sofort wieder ab, sondern funktionierte jedes Mal tadellos - keine
Ahnung, warum!?!
Als ich die Schaltung jedoch wie in der angehängten Grafik erweitert
habe (mit den Intention, den High-Pegel von GPIO12 gleichzeitig als
Spannungsquelle für einen Spannungsteiler am ADC zu nutzen), veränderte
sich das Verhalten: Wenn man den Button zu kurz betätigt, und zum
Zeitpunkt des Loslassens der Bootvorgang noch nicht so weit
fortgeschritten ist, dass die Selbsthaltefunktion aktiviert wurde,
zeigte sich das eigentlich erwartete Verhalten und der ESP schaltete
sich sofort/vorzeitig ab.
Kann sich das irgendwer erklären? Und weiss vielleicht sogar eine
leichte Lösung, wieder das unerwartete (aber letztlich noch
vorteilhaftere) Verhalten zu erhalten?
Wenn ich als Spannungsquelle für die ADC-Schaltung einfach einen anderen
GPIO-Pin nehme, dann funktioniert es wieder. Aber da GPIO12 durch die
Selbsthaltefunktion ja eh permanent auf high-Level ist, würde ich
ungerne noch einen weiteren GPIO-Pin verbraten, falls es sich vglw.
einfach vermeiden lässt.
Und noch eine Frage, die ich eben leider vergessen habe:
An GPIO15 schliesst man ja üblicherweise einen Pulldown-Widerstand an,
damit der ESP8266 bei Start vom Flash bootet.
Wenn GPIO15 in der Schaltung sonst aber gar nicht benutzt wird - könnte
man GPIO15 dann alternativ auch einfach direkt mit GND verbinden, oder
gibt es dann irgendwelche Probleme/Nachteile?
Hallo,
hast Du Dir das Verhalten von GPIO13 und GPIO12 zur Bootzeit mal
angeschaut?
GPIO12/13/14 und 15 sind der Hardware-SPI des ESP. Vermutlich wirst Du
tief in das SDK einsteigen müssen, um rauszufinden, was der ESP da
treibt...
Damit ist auch die Frage zu GPIO15 beantwortet; wenn Du sicher bist, daß
GPIO15 beim Booten nicht zeitweise auf Output High gesetzt wird, kannst
Du ihn direkt auf GND legen.
Bisher habe ich nur GPIO4 und 5 als unbeeinflußt beim Booten gefunden.
Alle anderen haben entweder aktive Zusatzfunktionen für den Bootmode
oder wackeln zumindest mal mit den Pegeln.
Ansonsten bleibt meine Anmerkung: ich habe GPIO0 und 2 noch nie mit
externen PullUp beschaltet, bei keinem Modul.
Gruß aus Berlin
Michael
Michael U. schrieb:> Damit ist auch die Frage zu GPIO15 beantwortet; wenn Du sicher bist, daß> GPIO15 beim Booten nicht zeitweise auf Output High gesetzt wird, kannst> Du ihn direkt auf GND legen.
GPIO15 hat noch diverse andere Funktionen, ich werde da auf Anhieb nicht
so richtig schlau draus. Aber der Tipp war trotzdem hilfreich, ich
schliesse einfach mal ein Oszi an und schaue ob sich beim Booten was auf
GPIO15 tut...
Und in noch einer Hinsicht hast Du mich damit auf eine interessante Idee
gebracht: Ich werde morgen mal ausprobieren, zum Steuern der
Selbsterhaltungs-Funktion GPIO16 statt GPIO12 zu benutzen. Deep Sleep
plane ich ja eh nicht zu benutzen, und GPIO16 unterscheidet sich meines
Wissens nach ja von allen anderen GPIOs dadurch, dass es standardmässig
und auch schon direkt beim Booten auf Output high steht. Damit müsste
es, falls ich nicht gerade einen Denkfehler habe, ja eigentlich perfekt
zum Steuern der Selbsterhaltungsfunktion sein...
> Ansonsten bleibt meine Anmerkung: ich habe GPIO0 und 2 noch nie mit> externen PullUp beschaltet, bei keinem Modul.
Das habe ich dank Deines Posting dann auch gleich mal an meinem Design
geändert. Vielen Dank dafür, das hat mir im vorliegenden Fall echt
geholfen.
Auch den Pullup am RESET-Pin lasse ich seitdem weg und lasse den
Reset-Pin momentan einfach komplett unbeschaltet. Funktioniert bisher
auch tadellos.
Kann es sein, daß die GPIOs beim Reset erstmal auf "weak pull-up" gehen
anstatt komplett hochohmig zu werden? Das würde erklären, warum GPIO12
ohne weitere Beschaltung genug H-Pegel liefert, mit dem Photowiderstand
dran aber nicht mehr (bzw. nur noch im Dunkeln).
Nosnibor schrieb:> Kann es sein, daß die GPIOs beim Reset erstmal auf "weak pull-up"> gehen> anstatt komplett hochohmig zu werden? Das würde erklären, warum GPIO12> ohne weitere Beschaltung genug H-Pegel liefert, mit dem Photowiderstand> dran aber nicht mehr (bzw. nur noch im Dunkeln).
Das klingt in der Tat plausibel - und jetzt, wo Du's sagst, meine ich
auch, mal etwas in der Richtung gelesen zu haben... Danke für den guten
Hinweis!
esp8266_dash_button_schematic_v1.png
(3,6 KB)
