DHT22 ESP-01/01S + ESP8266 + deep sleep: probleem GPIO2 en oplossing GPIO0

De combinatie van het sensor boord en ESP8266 werkt op zich prima, totdat ik het zo wilde instellen dat de ESP8266 in 'deep sleep' gaat en na een interval weer opstart, meet, data verstuurt en weer gaat slapen. Aangesloten op de USB poort werkte het, maar eenmaal op 3x1.5V batterijen niet meer. Speurwerk op internet leidde uiteindelijk tot een oplossing die ik niet zo eerder zag en daarom post ik dit. Mogelijk helpt het anderen.

Als de ESP8266 uit deep sleep komt, wordt een boot log verstuurd over GPIO2 die de DHT22 in de war brengt. Als dan in de sketch (of library) de sensor wordt aangestuurd om gegevens te versturen, reageert het niet.

De essentie van de oplossing is dat de DHT22 niet meer verbonden wordt met GPIO2 van de ESP8266, maar met GPIO0. In de bijlage is dit te zien. Op het sensor boord is de tunnel tussen de sensor en GPIO2 doorgekrast en is een draadverbinding gesoldeerd naar GPIO0. In de sketch kan nu het pinnummer worden veranderd van 2 naar 0. Zodoende zal de boot log de sensor niet meer in de war brengen en gewoon functioneren. Dit leidde in mijn geval eindelijk tot de gewenste werking.

2de post en al een oplossing :slight_smile:
Karma ++

Het plaatje, compleet met beschrijvende tekst:

Na enige tijd bleken de metingen een onverwacht gedrag te vertonen. De ESP01 zou elke 10 minuten 1x moeten meten, maar bleek dat soms veel vaker achter elkaar te doen. De deep sleep werd verstoord.


Hierbij het verslag hoe met een transistor het nu is opgelost.

DHT22 lijkt op de DHT11 en kan ook onder 0 meten. Het boardje kan gekoppeld worden en werkt zonder problemen zonder deep sleep. Maar met deep sleep treden problemen op.

Nadat de DHT met ESP01 opstart, werkt alles prima tot en met de deep sleep. Na het ontwaken treden er problemen op. De oorzaak ligt er hoofdzakelijk in dat de ESP01 tijdens het booten een boot log uitzendt via de communicatie pinnen. Hierdoor raakt de DHT22 in de war en wordt soms zelfs onbereikbaar.

De eerste poging om dit op te lossen was om geen gebruik te maken van de communicatie pin GPIO2 voor data communicatie met de DHT22, omdat GPIO2 serial output is van de ESP01. De DHT22 datapin staat default HIGH zodat een verstoring daarvan ertoe leidt dat de DHT22 gaat reageren, terwijl het systeem nog boot. Als alternatief werd GPIO0 aangehouden. In eerste instantie leek dit een goede oplossing, maar na enige tijd begonnen de metingen onbetrouwbaar te worden. In plaats van GPIO0 zijn ook de andere pinnen geprobeerd, maar geen enkele leidde tot betrouwbare metingen. Er is nog meer aan de hand.

Een zoektocht op internet (“DHT22 deepsleep”) laat zien dat er veel problemen zijn met de DHT22 en de ESP01 in deep sleep. Velen hebben deze combi daarom niet meer in gebruik.

Een tweede poging was om de DHT22 als het ware 'uit' te zetten tijdens het booten en na het booten 'aan' te zetten en dan te meten. De sensor zou zodoende niet in de war raken. De poging was dus om de Vcc van de DHT22 te verbinden met een pin van de ESP01 en die dan naar wens HIGH te geven. Deze setup leidde ook tot het in de war raken van zowel de ESP01 en de DHT22. Het toevoegen van een diode leidde ertoe dat het allemaal wel opstartte, maar dat de DHT22, zoals te verwachten viel, te weinig spanning kreeg (minder dan 3.3 V).

De 3e en uiteindelijk geslaagde poging was het gebruik van een transistor om bovenstaande filosofie te gebruiken en het tekort van spanning bij te leggen door een verbinding met een hoger voltage, direct vanaf de batterij toe te staan.

In dit geval wordt GPIO2 gebruikt als base voor de transistor. Alhoewel deze dus leidt aan de boot log perikelen, wordt na de boot de de stroom op de DHT22 volledig uitgezet. Op het moment dat de sensor gebruikt moet gaan worden en de ESP01 al volledig stabiel is opgestart, wordt GPIO2 HIGH gezet en start de DHT22 schoon op. Na 2 seconden kan vervolgens een perfecte meting worden uitgelezen. Uiteraard had ook GPIO0 gebruikt kunnen worden, maar het principe blijft hetzelfde.

In deep sleep wordt 80 ÎĽA gebruikt, wat ok is voor batterij gebruik. Het geheel is aangesloten met 3 AA batterijen en de metingen lijken nu zeer stabiel te verlopen.

1 Like

Hoi.

Heel mooi dat je hier de oplossing laat zien, vaak word dat vergeten.
Dus dank daarvoor.

Maar de tekst gaat ineens van Nederlands naar het Engels.
Heb jij deze aanpak uitgewerkt en in het Engels opgeschreven (zodat je het op meerdere plaatsen kunt publiceren bijvoorbeeld), of komt de informatie ergens anders vandaan ?
Want wanneer de informatie ergens anders vandaan komt, is het wel zo netjes om de bron te benoemen en het werk van die andere persoon te erkennen.
In de Engelse tekst (voor het geval dat wel jouw tekst is), staan nog wel wat dingen die niet helemaal kloppen naar mijn idee.
Ten eerste is er een typefoutje want oplossing 3 bestaat eerst uit een weerstand (resistor), maar dan ineens uit een transistor en das natuurlijk een vergissing die men in het Engels snel maakt tijdens het typen.
En in de laatste zin staat measering in plaats van measuring, nog een typefoutje.

Maar ik zie ook staan dat ineens toch GPIO 2 gebruikt kan worden terwijl dat voorheen funest was.
Komt de bootlog nu ineens niet meer door GPIO2, of kan die transistor er niets mee ?
Of schakelt de transistor dan nog steeds, maar zo kort dat de voeding van de DHT geen tijd heeft om stabiel te starten ?
In het laatste geval zal het vast wel werken, maar verdient het zeer zeker niet de hoofdprijs, en kun je naar mijn mening niet volhouden dat alles stabiel werkt.

Dank voor de reactie. Oprechte punten!

De bevindingen houd ik bij in een Engelstalig logboek, vandaar dat het Engels was. Ik hoop dat de Nederlandse vertaling wat duidelijker is. Overigens is dit geen plagiaat maar eigen bevinding. Het heeft geen zin om andermans verhaal te herhalen.

Helemaal goed, en ook dat je dit alles relatief snel uit hebt kunnen vinden.
Karma +1