Keine Webseite angezeigt und kein Akkubetrieb #20
Comments
|
|
Hallo, ad 1) Der AccessPoint dürfte auch gestartet werden, ein WLAN mit der SSID "ESP32-<4- oder 6-Stellen (vermutlich) der MAC-Adresse> (nicht nur "ESP32") wird angezeigt, damit kann ich mich mit allen Testgeräten klaglos verbinden und erhalte auch 192.168.4.3 als IP-Adresse sowie 192.168.4.1 als Gateway und DNS, jedoch lässt sich mit keinem Browser die Konfigurationsseite aufrufen. Die Seite scheint einfach nicht gefunden zu werden. Ping ist möglich, Fehler wird keiner angezeigt. ad 2) Auf die Polarität hätte ich eigentlich geachtet, werde es aber nochmals verifizieren. D.h. aber, dass beim erwähnten Board keine zusätzliche Hardware-Komponente nötig ist - auch kein Software-Schalter, um einen Akku-Betrieb einsetzen zu können? Schöne Grüße |
|
|
Evtl. hilft dir ein Factory Reset. Das Gerät 7 mal über den Reset Button neu starten. Danach wird der SPIFFS Speicher formatiert. Allfällig inkorrekte Einstellungen werden dabei gelöscht. |
|
Hallo, der letzte Tipp mit dem Reset scheint eine Besserung gebracht zu haben und nun konnte ich den ESP32 mit meinem WLAN verbinden. Vielen Dank dafür! Die Sache mit der Batterie ist noch etwas seltsam die mich, die Polung ist eigentlich richtig, LED leuchtet keine, dennoch ging hin und wieder ein Ping durch, jedoch nicht immer. Einmal habe ich sogar eine einzige MQTT-Nachricht versenden lassen können, nur scheint das noch etwas launisch zu sein. Was ich mit durchgehenden Pings im Hintergrund beobachtet habe, ist, dass im Normalfall der ESP32 nicht erreichbar ist und nur bei Eintreten eines Ereignisses aufwacht, seine Arbeit verrichtet und wieder schlafen geht. Klingt soweit auch schlüssig, um Energie zu sparen. Eine Frage habe ich noch: im Artikel zum Türschild wird die Möglichkeit von OTA-Updates erwähnt. Wie sind solche möglich, wenn der ESP32 im Normalfall durchgehend schläft und damit im WLAN nicht erreichbar ist? Da in der ArduinoIDE mein ESP32 unter seinem Namen und der IP-Adresse angezeigt wird, scheint die OTA-Funktion standardmäßig aktiviert zu sein, stimmt das? Schöne Grüße |
|
Welchen Akku verwendest du genau? Kannst du bitte mal deinen Code posten, damit wir evtl. herausfinden können, warum dein ESP32 manchmal nicht in den Sleep Modus geht? Du hast recht, ein OTA ist nur möglich, wenn der ESP32 im Netz auch erreichbar ist. Da hat man sich vermutlich noch nicht richtig damit befasst. OTA kann abgestellt werden, indem folgende Definition am Anfang des Programms einträgt: |
|
Hallo, ich habe mir diese Akkus besorgt: https://www.amazon.de/gp/product/B00AIOH9VG/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1 Mit "Code" meinst du vermutlich den Türsensor-Code. Ich habe da auf das Sample in deinem Basecamp zurückgegriffen, da mir dieses als die aktuellste Version und am ausführlichsten kommentiert vorgekommen ist: https://github.com/merlinschumacher/Basecamp/blob/master/examples/doorsensor/doorsensor.ino Wie schon gesagt ist das häufigste von mir beobachtete Verhalten jenes, dass der ESP32 nicht im WLAN pingbar ist und nur bei beim auslösen eines Test-Ereignisses 1-2 Pings durchgehen und die MQTTs übertragen werden. Das Verhalten, in dem der ESP32 durchgehend im Haus-WLAN pingbar ist und damit auch empfänglich für Konfigurationsänderungen über das Webinterface (und vermutlich auch für OTA-Updates) hat gefühlsmäßig immer irgendwie mit der Reset-Taste etwas zu tun gehabt. Ehrlich gesagt habe ich deren Funktion auch nicht nicht ganz durchschaut:
Die OTA-Funktion empfände ich persönlich auch als hilfreich, denn ich habe mir erlaubt, deinen Türsensor in einen Wassersensor umzuwandeln (das Prinzip ist ja immer dasselbe, nur die Fühler/Kontakte sind andere) und wenn die Dinger dann z.B. unter der Spüle liegen, ist mir ein OTA-Update/eine OTA-Programmierung auch lieber als ein herausholen und anstecken an den PC. Es scheint aber so, als ob dies zugunsten des Energiesparens so nicht ganz praxistauglich ist, denn ich hoffe, dass der Wassersensor sein ganzes Batterie-Leben lang durch Kontaktschluss überhaupt nicht aufwacht. Was ich mir vorstellen könnte sind
Je mehr ich mich damit befasse, desto faszinierter bin ich, nochmals Danke für die "Inspiration" in der c't, so stelle ich mir c't-Artikel vor. Schöne Grüße |
|
Diese Akkus sind von der besseren Sorte. Es liegt vermutlich am Spannungsregler (ME6211) auf dem Lolin32. Der ESP32 benötigt in Spitzen zwischen 600 - 800mA. Die Batterie hat dann eine Ausgangsspannung von ca. 3.7V. Der Spannungsregler weist dabei (über den Daumen gerechnet) einen Spannungsabfall von ca. 0.8 - >1.0V auf. Vermutlich befindet sich dein ESP32 in dieser Situation genau in einem Grenzbereich. Einmal funktoiniert's und das andere mal nicht. Ich hätte dir für einen Test vorgeschlagen, zwei Batterien in Serie anzuschliessen. Leider verträgt der Spannungsregler aber max. nur 6.5V. Das Doorsensor Beispiel müsste ich mir genauer ansehen...
Das hier ist nicht mein Repository 😉
Schnell genug, damit sich das Gerät nicht mit dem WLAN verbindet.
Im Datenblatt habe ich jetzt auf die Schnelle nichts gesehen. Aber eine Millisekunde genügt schon.
Ja.
Nein. Deine anderen Anregungen lass ich mal für den Autor so stehen. 😄 |
|
Hallo, danke für den ausführlichen Kommentar zur Batterie-Thematik, nur ist mir jetzt nicht ganz klar, was ich nun machen kann. Hast du einen Vorschlag dazu? Die Akkus kann ich noch zurück schicken, wenn diese in meinem Fall ein Problem sind. Ups, ich war irgendwie der Meinung, dass ich mit dem Autor schreibe :) Danke aber trotzdem, dass du mir weiterhilfst. Schöne Grüße |
|
ich bin übrigens der Autor des Artikels. Ich wollte mich gestern auch zum Problem mal melden, habe es aber leider aus zeitlichen Gründen nicht mehr geschafft. Dass die Akkus das Problem sind ist möglich, aber ich würde vorher nochmal ein bisschen rumtesten wollen. Ich selber habe den Türsensor erfolgreich daheim im Einsatz. Mit einer relativ billigen Samsung-18650-Zelle aus China. Auch mit dem Lolin32 als Basis. Konzeptionell sollte da also kein Problem bestehen. Ich glaube der Stromverbrauch sollte kein Problem sein. Der ESP selber braucht beim WLAN-Betrieb 240mA. Selbst mit dem ganzen "Drumherum" sollte er nicht in den Bereich von 600mA kommen. Um alle Eventualitäten auszuschließen: Hat der Akku überhaupt Ladung und kann er sie halten? Liegt eventuell ein Kabelbruch in der Ladehalterung vor? Beim Lolin 32 sollte beim Laden eines angeschlossenen Akkus per USB die CHG-LED hell leuchten. Ist kein Akku angeschlossen "glimmt" sie nur. Ich würde zunächst mal Testcode vorschlagen: #include <Basecamp.hpp>
Basecamp iot;
void transmitStatus(bool sessionPresent) {
Serial.println("publishing");
iot.mqtt.publish("stat/frontdoor/status", 2, true, "Test 123" );
}
void confirmPub(uint16_t packetId) {
Serial.println("message published");
}
void setup() {
iot.begin();
iot.mqtt.onConnect(transmitStatus);
iot.mqtt.onPublish(confirmPub);
}
void loop() {
delay(5000);
if (iot.mqtt.connected() == 1) {
iot.mqtt.publish("stat/frontdoor/status", 2, true, "Test 123" );
};
}Zum OTA gibt es in diesem Repository zum Türsensors (https://github.com/merlinschumacher/ESP-Doorsensor) den Sketch doorsensor_advanced.ino. Darin ist ein Mechanismus der den Tiefschlaf des ESP stoppt, wenn er eine vorgegebene Nachricht auf einem MQTT-Kanal erhält. Das Batterieproblem kann man mit dem Timer-Wakeup (https://github.com/espressif/arduino-esp32/blob/master/libraries/ESP32/examples/DeepSleep/TimerWakeUp/TimerWakeUp.ino) umschiffen. Dadurch erwacht der ESP automatisch alle X Sekunden. Vielleicht einmal alle 12h? Er könnte dann kurz seinen Batteriestand messen und erwachen. Zum Reset: Wenn man den Reset-Knopf des ESP drückt startet er neu und bleibt so lange "hängen" bis der Knopf losgelassen wird. Erst dann startet er neu. Basecamp zählt bei jedem Neustart einen Counter hoch. Der Counter wird wieder auf 0 gesetzt, wenn ein Neustart als erfolgreich zählt. Erfolg ist eine funktionierende WLAN-Verbindung. Wenn man den Knopf im Takt von etwa einer Sekunden 5 mal drückt werden nur die WLAN-Einstellungen zurückgesetzt und der ESP öffnet seinen Access-Point. Drückt man dann noch 2 mal wird der interne Flashspeicher des ESP formatiert. Dann ist er quasi wieder auf "Werkseinstellung". Ich hoffe das bringt ein wenig Licht ins Dunkel. Mit besten Grüßen @T94T Danke fürs helfen! |
|
Hallo @merlinschumacher, in dem Fall nochmals dir Danke für den tollen Artikel und die Inspirationen und Ideen, die du damit geweckt hast. Zum Akkuproblem: Ich werde mal versuchen, den Akku in einer anderen Halterung zu betreiben. Die Sache mit einem Kabelbruch käme mir in Anbetracht der dünnen Kabel der Halterung auch nicht ganz abwegig vor. Auch werde ich den auf-ge-crimpten Molex-Stecker nochmals erneuern, vielleicht liegt es ja auch daran. Die Akkus sind geladen, das habe ich sofort nach Lieferung mit den neu bestellten Ladegerät gemacht. Ob er die Ladung hält, weiß ich momentan nicht, wie ich das beurteilen kann. Fakt ist auch, dass bei angestecktem Akku und USB-Kabel das Akku-LED nicht durchgehend leuchtet und bei nur angestecktem Akku das LED auch nicht glimmert, was auch für ein Kontakt-Problem sprechen würde oder? Beruhigend finde ich erstmal deine Vermutung, dass es wohl eher an den gekauften Akkus und deren Spannungen und Kapazitäten nicht liegen wird, denn ich hätte eigentlich darauf geachtet, eher gutes Zubehör zu kaufen, denn vor Akkus hab ich ziemlichen Respekt. Meine C-Kenntnisse muss ich erst wieder entstauben, aber gehe ich richtig in der Annahme, der Test-Code von dir beim Boot des Lolin nach Verbindungsaugbau und dann alle 5 Sekunden eine Test-Nachricht per MQTT überträgt? Ich werde das jedenfalls versuchen und bin schon gespannt. Der Punkt mit OTA und dem Beispiel doorsensor_advanced.ino mit dem integrierten Tiefschlaf-stoppen-Mechanismus ist mir glaub ich noch nicht ganz klar: ich habe mich jetzt noch nicht so intensiv in MQTT eingelesen, aber heißt das, dass die Nachrichtenzustellung quasi synchron passiert? Also ich sende eine Nachricht an den Lolin und diese wird solange quasi in der Tasche des Briefträgers aufbewahrt, bis der Lolin sich das nächste Mal im Netz als verfügbar meldet? Die Option, den ULP-Co-Prozessor des ESP mit dem lesen Sensorwerten im Deep-Sleep-Modus zu nutzen klingt jedoch aus technischer Sicht viel verlässlicher und sauberer. Wenn du das weiterverfolgst, so hast du mit mir einen Follower :) und selbstverständlich darfst du dir das Wassersensor-Beispiel "ausleihen". Solch eine Funktion würde ja sehr viele IoT-Projekte ausfallsicherer machen, worauf man sich auch eigentlich auch verlassen können muss. Danke für die Aufklärung, was den Reset-Taster betrifft, genau so eine Information habe ich gesucht. Ich sehe schon, dass wird nun doch noch ein längeres Unterfangen, bis ich den ersten Wassersensor an seinen Platz legen kann :) Danke und schöne Grüße |
|
Hallo, ich habe mit dem Multimeter die 3V-Kontakte am ESP32 gemessen und es war die erwartete Spannung messbar. Dennoch habe ich nun den Batterie-Stecker neu ge-crimpt und deinen Test-Code aufgespielt. Damit lässt sich nun gut feststellen, ob die Batterie funktioniert und das tut sie jetzt auch. Allerdings macht das LED keinerlei Anstalten, im Batterie-Betrieb auch nur den Anschein eines glimmerns oder blinkens zu zeigen - es bleibt einfach dunkel und man muss damit mit dem Türsensor-Code ein Ereignis auslösen, um zu wissen, ob der ESP32 "läuft" oder nicht. Zum Thema Batterie-Status: Ich habe mir das Sample "TimerWakeUp" angesehen und es scheint nicht übermäßig kompliziert zu sein. Ohne den Klimbim mit der Ausgabe der Wakeup-Events scheint es auf folgende Zeile anzukommen: esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR); Schöne Grüße und schönes Wochenende |
|
Hallo @beko136,
Vielen Dank! Gern geschehen!
Die LED leuchtet nur bei Versorgung per USB. Sie glimmt, wenn kein Akku angeschlossen ist und leuchtet hell, wenn ein Akku per USB geladen wird.
Exakt das sollte er tun.
Ganz genau. In der c't 6/2018 wird auch noch ein Artikel erscheinen, der genauer auf die Arbeitsweise von MQTT eingeht. Der MQTT-Broker behält Nachrichten mit bestimmten QoS-Leveln so lange auf Lager, bis der Client sie definitiv empfangen hat.
Das werde ich auf jeden Fall noch ins Heft bringen, aber die Herangehensweise ist etwas anders. Daher kommt das erst im Sommer.
Die Zeile muss direkt vor der Deep-Sleep-Anweisung eingetragen werden. Dann wacht der ESP X Sekunden nach dem letzten Wakeup auf. Für die Meldung des Batteriestands reicht das ja. |
Hallo,
ich habe mir nach lesen des c't-Artikels umgehend alle Teile besorgt, die Software eingerichtet und konnte Ihren Code auch erfolgreich auf den Lolin32 laden. Nun stehe ich jedoch vor zwei Problemen:
Ich würde mich sehr über Ihre Unterstützung freuen, denn das Projekt ist wirklich gelungen!
Schöne Grüße
The text was updated successfully, but these errors were encountered: