Sorry, hab schon wieder ne Frage bzw. bräuchte eure Meinung zu einer Sache:
Ich möchte folgendes realisieren:
Ich habe zwei ESP32: einer soll Sender und einer Empfänger sein.
Am Empfänger hängt ein kleiner Servomotor.
Wenn der Empfänger ein kurzes Signal vom Sender bekommt, soll er den Servo eine Umdrehung machen lassen. Nicht mehr und nicht weniger. Im Moment mach ich das über das ESP-Now Protokoll, funktioniert prima. Denkbar wäre auch per Funk-Modul (RC 433 mhz), wie bei einer Zentralverriegelung am Auto...so was ähnliches soll es auch werden (nur für den Hasenstall ).
Problem: Der Empfänger-ESP soll mit einem Akku betrieben werden und möglichst lange halten (also am besten Wochen...).
Gibt es eine Möglichkeit, sowas akkusparend umzusetzen?
Ich vermute mal mit meinem aktuellen Setup wird der Akku in ein paar Stunden leer sein, oder?
Der ESP muss ja quasi immer auf Standby bleiben und überwachen, ob eine Nachricht reinkommt, d.h. deepsleep ist nicht, korrekt?
Habt ihr da ein paar Ideen für mich? Gibt es z.B. eine Stufe vor deepsleep, in der der ESP weniger verbraucht aber noch ESP-NOW läuft? Oder irgendne andere Möglichkeit, um über Wochen mit Akku den Servo zu bertreiben.
Ich gehe von ca. 3 oder vier Servo-Umdrehungen pro Tag aus, den Rest "wartet" der ESP quasi nur auf seinen Einsatz.
eine 1S LiPo-Batterie und einen festen, effizienten Boost-Regler auf 5V
einen allgemeinen Ein-Aus-Schalter zwischen der Batterie und dem Boost-Regler
andere Ausgabegeräte (Motor, Ton)
Die Funktionsweise ist folgendermaßen: Wenn ich den Ein-Aus-Schalter benutze, wird das gesamte System mit Strom versorgt. Der Arduino startet und schaltet den Power Switch aus, konfiguriert Serial und den HC-12 und versetzt sich in den Niedrigstrommodus (FU2-Modus, Leerlaufstrom von etwa 80uA) und aktiviert Pin Change Interrupts für Pin D0 (Rx). Dann geht er in den Tiefschlafmodus über (unter Verwendung von SLEEP_FOREVER in LowPower.powerDown()).
Auf der Master-Seite habe ich einen passenden HC-12. Wenn ich auf der Slave-Seite etwas tun möchte, sendet der Master-HC-12 ein Weckbyte. Dieses Byte wird am Rx-Port des Slave-Arduinos ankommen, was den PC-Interrupt auslöst und den Slave-Arduino aufweckt. Der Slave-Arduino schaltet den Pololu Power Switch ein, um Strom für meine Subsysteme bereitzustellen, und wenn alles bereit ist, sendet er ein ACK-Kommando an den Master, der dann das eigentliche Kommando senden kann. Der Slave-Arduino empfängt das Kommando, verarbeitet es, bestätigt es dem Master und geht dann wieder in den vollständigen Niedrigstrommodus, bis das nächste Kommando eintrifft.
In meinem System verwendet der Master keinen Niedrigstrombetrieb, sondern wird von einer Steckdose mit einer 5V-Stromversorgung versorgt. Sie könnten sich jedoch auch ein System vorstellen, bei dem ein Pololu Power Switch den Master aufweckt und die Befehle sendet.
Mit ESP32 wird das nix. ESP-NOW braucht genauso wie WiFi akiviertes WLAN.
Und das ist der Stromfresser.
Du könntest höchstens ein Funkmodul an den ESP32 anschließen und damit den ESP32 aus dem deepsleep aufwecken. Aber dann kann man auch einen anderen µC nehmen.
Wenn das ein Continiuos Rotation-Servo ist wird das nicht funktionieren, weil du keine Rückmeldung darüber hast ob das Servo genau eine Umdrehung gemacht hat.
Dir schwebt wahrscheinlich vor, die Ansteuerzeit so lange anzupassen bis es genau eine Umdrehung ist.
Nun ... wenn die Spannung niedriger wird oder irgendwas wegen Wind oder sonst irgendwas schwergängiger ist dann läuft der Motor langsamer und dann passt die Zeit nicht mehr.
Nimm einen kleinen Getriebemotor mit Encoder dann hast du die Rückmeldung über die Position.
vermutlich gar keiner. Das HC-12 Funkmodul ist quasi eine wireless serielle Schnittstelle
Die superbillich-Module kriegen das bitbanging einer seriellen Schnittstelle nicht gebacken. Die reichen wirklich nur um ein Schaltsignal zu übertragen.
haaach ! Und schon wieder bei Amazon gekauft.
Amazon ist weder der günstigste Anbieter noch bietet Amazon ausführliche technische Informationen und Datenblätter die man eigentlich immer braucht schon gar nicht.
Ein Beispiel:
jetzt zeige mir einen Amazon-Anbieter der das Wemos D1 mini für unter 3 Euro anbietet.
Also gut, überredet.
Ich streich Amazon künftig bzgl. Elektronikteilen von meiner Liste.
By the way:
Bleibt nur noch die Frage, ob ich als Microcontroller für den Sender einen ESP32 und als Empfänger einen Nano oder auch einen ESP32 nehme.
Für den Betrieb mit dem HC12 sollten die ja beide gleich gut herhalten. Der Empfänger als ESP32 lässt sich ja genauso gut per HC 12 aus dem Deepsleep erwecken, aber der ESP verbraucht im Deepsleep soweit ich weiß weniger Strom als der Nano, korrekt? Oder gibt's da noch ne bessere Wahl?
Wir gesagt: der Controller muss per HC12 geweckt werden, einen Impuls an einen Motor geben und dann wieder schlafen.
Am Empfänger Brauch ich auch kein WiFi, jedoch am Sender (wegen ner anderen Funktion).
D.h. zweimal ESP32 jeweils mit HC-12 und der Tag ist mein Freund, gell?
Die Wahl des HC12 erfolgte aufgrund seines geringen Stromverbrauchs von 80 µA und seiner Funktion als serieller Port. Dadurch können Sie seinen Tx-Pin verwenden, um das Arduino aufzuwecken
Ich habe nachgeprüft und es handelte sich um einen Pro Mini mit 16 MHz (kein Arduino Micro), bei dem ich die LED und den Regler entfernt hatte. Der Stromverbrauch im Tiefschlaf beträgt etwa 3 µA (Einige Boards haben eine Jumper-Option, die Sie abschneiden können, um dies zu erreichen). Mit einem ESP32 erreichen Sie in der Regel keinen so geringen Stromverbrauch. Bei den besten ESP32-Modulen kann der Stromverbrauch eher bei etwa 10 µA liegen.
Und Wenn Sie weder WiFi noch Bluetooth benötigen, warum sollten Sie dann ein Arduino-Board wählen, das diese Fähigkeiten bietet?
Ich will mir beim Sender die Möglichkeit offen halten, Updates per Http aufzuspielen und evtl. ein paar Parameter einstellbar machen über ein Webinterface. D.h. ich werde wohl als Sender die Kombi ESP32 und HC12 und als Empfänger dann z.b. einen etwas sparsameren Microcontroller wählen.
Der Sender befindet sich doch in deiner Nähe, warum dann per HTTP Updates überspielen ?
Das macht doch beim Empfänger eher Sinn, da dieser wohl nicht unmittelbar in der Nähe ist.
Deine Module
lassen sich auch verwenden, haben allerdings eine geringere Reichweite und eine andere Ansteuerung. Das geht z.B. mit der Library RCSwitch oder RadioHead. Auch sind die nicht sehr zuverlässig.
Und aus Erfahrung macht es Sinn, die "Teile" per OTA oder HTTP anzupassen, die entfernt montiert sind.
Aus dem Grund habe ich bei mir alle externen "AVRs" durch ESPs ersetzt.
So kann ich diese leicht per OTA optimieren. Und die restlichen folgen nach und nach.
Da gebe ich dir Recht. Das kann in den meisten Fällen helfen.
Da ich aber für "fast" alle meiner Projekte hier noch eine Testumgebung liegen habe, mache ich das zuvor "meist" auf dieser Umgebung. Wenn es dann läuft, geht's in die Luft.
bzw. bräuchte eure Meinung zu einer Sache:
).
