Réveiller ESP32-CAM

Bon
petit point d’étape

Réveiller l’esp32-cam par interruption, ce n’est déjà pas simple , mais l’on y arrive 8)
en revanche demander à l’esp32 lorsqu’il est actif ET génere le flux vidéo de s’occuper d’autres chose est une autre paire de manches .

Le programme webcamserver utilise à priori une API basée sur du SDK RTOS pour gerer le flux , donc pas de possibilité pour l’instant de décoder/agir avec de l’entrée basique
j’ai essayé de faire de l’entrée irremote ou par UART histoire de voir , mais Nada 8)

Sans m’avouer complètement vaincu, je ne suis pas assez bon codeur, pour rentrer profondément dans le code du programme , pour voir si il y aurait possibilité d’intervenir qq part.

Comme le besoin/demande initial ne me concerne pas (ou pas encore :grin: )

je vais classer çà pour l’instant dans la gestion du temps avec cette

Fiche de travail :
-Test esp32-cam reveil : essayé !, pas pu ! :smiley: , temps passé 3 heures 8)

Bonjour Artouste,

Tout d'abort un grand merci d'avoir passer du temps pour mon problème, c'est très sympa ;D

De mon côté je continu à chercher, et je suis sur une piste, par encore débroussaillée :confused:

J'ai avancé, et changé un peu mon optique

Soit :

  1. vue du streaming sur le smartphone

  2. sortir du streaming, ce qui couperait la communication entre wifi point d'accès et le smartphone et dans ce cas, l'esp32-cam se mettrait en sommeil profond (si pas de client wifi, se mettre en sommeil profond)

if (!client.connected()) { // si wifi n'est pas connecté
    //digitalWrite(PIN_LED_LED, HIGH); // led juste pour essai !!!!!!!!!!!
    esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0); // Prévision du reveil GPIO sur position bas normalement (0)
    esp_deep_sleep_start(); // Sommeil profond
  }
  1. Réveiller l'esp32-cam par une impulsion sur le TSOP à l'aide d'une télécommande

J'ai essayé (à la place future de la mise en sommeil) avec un allumage et une extinction du flash, et cela fonctionne bien

Je viens d’essayer avec la mise en sommeil, cela fonctionne mais se reveille de suite, je penses que c'est l'emplacement de la commande de sommeil qui doit être mise ailleurs :slight_smile:

Ou alors,il faut que je mettre une variable Boolean en mémoire 1 ou 0
A voir, mais je garde espoir, "je l'aurai un jour, je l'aurai" :smiley:

Merci encore

Bonjour

proposition de piste (juste entrevue et pas testée !!) pour mettre en veille l'ESP32-CAM

L'exemple CameraWebServer arrivant avec l'estension ESP32 pour Arduino semble servir une page proposant au visiteur sur la gauche de la page divers paramétrages
interaction.png

Pourquoi ne pas tenter d'exploiter cette possibilité d'interactivité pour déclencher la mise en veille ?

Bouton Stop Stream , voire Face recogition ou Face Detect si ces fonctions ne sont pas utilsiées
ça implique une bonne compréhension du code de ap_httpd.cpp là où sont traitées les actions de l'utilisateur (autour des lignes 488 à 540)

  1. sortir du streaming, ce qui couperait la communication entre wifi point d'accès et le smartphone et dans ce cas, l'esp32-cam se mettrait en sommeil profond (si pas de client wifi, se mettre en sommeil profond)
    Code: [Select]
if (!client.connected()) { // si wifi n'est pas connecté

//digitalWrite(PIN_LED_LED, HIGH); // led juste pour essai !!!!!!!!!!!
    esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0); // Prévision du reveil GPIO sur position bas normalement (0)
    esp_deep_sleep_start(); // Sommeil profond
  }

Cette solution ne convient pas car elle ne correspond pas à la déconnection du client mais à l'absence de client, ce qui est le cas au démarrage de la carte avant la connection d'un client

interaction.png

al1fch:
Bonjour

proposition de piste (juste entrevue et pas testée !!) pour mettre en veille l’ESP32-CAM

Bonjour Al1
suggestion à priori trés intéressante pour endormir “proprement” l’esp32 à partir du code existant :grin:

“on” va laisser arduicool faire des essais :grin:

Bonjour

ESP32-CAM enfin déballé et mis sous tension !!

mise en sommeil profond par l'interface WEB : OK (comme proposé ci dessus)
réveil par niveau bas sur GPIO13 : OK

mais ..... 'mauvais réveil' pour la caméra que le programme ne reconnait plus au réveil
On voit ci dessous le démarrage initiale à la mise sous tension de la carte, les passages dans loop(), la mise en sommeil profond , le réveil (içi un BP sur GPIO13) et la non reconnaissance de la camera

.....
WiFi connected
Starting web server on port: '80'
Starting stream server on port: '81'
Camera Ready! Use 'http://192.168.1.3' to connect
loop
loop
loop
loop
loop
mise en sommeil profond


ets Jun  8 2016 00:22:57
rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6352
entry 0x400806b8

[E][camera.c:1049] camera_probe(): Detected camera not supported.
[E][camera.c:1249] esp_camera_init(): Camera probe failed with error 0x20004

Hypothèse : la camera aurait besoin d'un RESET or sur cette carte (si le schéma trouvé est le bon) RST_CAM est produit par un réseau RC et n'est pas sous contrôle de l'ESP32 >:(
cam reset.png

Vue la taille des composants pas facile de souder un fil au point de jonction de R16 et C12 pour amener par exemple le GPIO13 dont le niveau bas sert a réveiller l'ESP32.

Peut être une piste logicielle en 'trompant' la fonction camera probe() mais ça ne suffira peut être pas à éviter un vrai Reset physique !!!

N.B L'ESP32 gère par ailleurs le signal CAM_PWR qui valide les sorties d'alimentation 2,8V et 1,2V mais ça ne fait pas un reset pour la camera

cam reset.png

L'hyporhèse suggée ci-dessus n'est pas valide !!

En effet lors d'un appui bref sur le bouton Reset une carte ESP32-CAM , en veille ou pas, redémarre correctement , la camera est reconnue bien qu'elle 'ait pas eu de reset physique (CAM_RST)

Il en ressort une solution simlple et évidente pour réveiller correctement , (sans recours à un GPIO) une carte ESP32-CAM en sommeil profond : appliquer un bref niveau bas sur l'entrée Reset du module contenant l'ESP32

Ce signal n'étant pas accessible sur les côtés de la carte :confused: souder un fil içi !
piste Reset.pngReset ESP32.png

piste Reset.png

Reset ESP32.png

al1fch:
Bonjour

ESP32-CAM enfin déballé et mis sous tension !!

mise en sommeil profond par l'interface WEB : OK (comme proposé ci dessus)
réveil par niveau bas sur GPIO13 : OK

mais ..... 'mauvais réveil' pour la caméra que le programme ne reconnait plus au réveil

...
Peut être une piste logicielle en 'trompant' la fonction camera probe() mais ça ne suffira peut être pas à éviter un vrai Reset physique !!!
...
N.B L'ESP32 gère par ailleurs le signal CAM_PWR qui valide les sorties d'alimentation 2,8V et 1,2V mais ça ne fait pas un reset pour la camera

Bonjour Al1
:grin:

Bon , je vois que tu a aussi fini par mettre tes mains dans le cambouis :smiley:

Qq petits relevés à l'analyseur logique devrait permettre surement d'investiguer plus loin

compte tenu des dimensions des points possibles de relevés , il faut AMHA utiliser du banc de prise avec petit "pogo pin" (lesept 8) )

Je verrais dans le milieu de semaine prochaine pour éventuellement monter une petite manip

Je sais que j'ai réceptionné une autre esp32-cam avec capteur video sur connecteur flexible long et optique différente (+/- genre fish eye ) c'est pas encore déballé

je regarderais si c'est la même base esp32

Bon , tant que l'on progresse , on ne régresse pas ! :grin:

edit : je viens de voir que tu avais rédigé une réponse pendant que je répondais
je lis plus tard

Bonjour Artouste

Plus de mauvais réveil s’il est appelé par le reset ESP32 :slight_smile: ( jai édité mes derniers messages)

  • mise en sommeil par l’interface Web OK
  • réveil (d’un bon pied) par un bref niveau bas sur le reset de 'l’ESP32 OK

Pour info , consommations approxmatives (ordres de grandeur), l
carte ESP32-CAM alimentée en 5V, LED Flash non activée

  • connectée au réseau sans flux vidéo activé : 100 mA en moyenne
  • avec flux vidéo : pointes à 400mA pendant l’envoi des données
  • deep sleep : 5mA

Je joins les deux fichiers de l’exemple CameraWebServer modifiés :

  • CameraWebServerPub : ajout d’un drapeau de demande de mise en sommeil et traitement dans Loop() de ce drapeau. Drapeau abaissée au redémarage (reveil)
  • app-httpd.cpp : une action sur le bouton “Face detection” de l’interface web lève le drapeau de demande de mise en sommeil profond

CameraWebServerSleepPub.ino (3.18 KB)

app_httpd.cpp (21.5 KB)

al1fch:
Bonjour Artouste

Plus de mauvais réveil s'il est appelé par le reset ESP32 :slight_smile: ( jai édité mes derniers messages)

  • mise en sommeil par l'interface Web OK
  • réveil (d'un bon pied) par un bref niveau bas sur le reset de 'l'ESP32 OK

Pour info , consommations approxmatives (ordres de grandeur), l
carte ESP32-CAM alimentée en 5V, LED Flash non activée

  • connectée au réseau sans flux vidéo activé : 100 mAen moyenne
  • avec flux vidéo : pointes à 400mA pendant l'envoi des données
  • deep sleep : 5mA

Je joins les deux fichiers de l'exemple CameraWebServer modifiés :

  • CameraWebServerPub : ajout d'un drapeau de demande de mise en sommeil et traitement dans Loop() de ce drapeau. Drapeau abaissée au redémarage (reveil)
  • app-httpd.cpp : une action sur le bouton "Face detection" de l'interface web lève le drapeau de demande de mise en sommeil profond

ok Al1 , je vais enregistrer çà
Oui dommage qu'il n'y ai pas de pin rset de resssorti , mais bon çà reste du simple simple à repiquer .
donc çà régle le probléme d'arduicool pour faire un reveil avec une telco IR et un TSOP connecté sur le reset.

Il n'y aura pas de possibilité de décodage de trame IR , mais çà fonctionnera pour du réveil simple , à verifier peut etre ce que cela donne au niveau de l'esp32 qui va donc recevoir "rapidement" plusieurs reset pour une action sur une touche de la telco et à voir peut etre aussi quel est le niveau délivré par le TSOP "non sollicité"
Mais bon c'est toujours mieux que rien :grin:

Pour du plus "sérieux" avec décodage sur de la mise en sommeil et reveil par Telco iR un petit ATtiny85 devrait faire l'affaire (à voir sa conso propre)

To be continued

Bonsoir

Dans cet exemple le réveil de la carte par GPIO st réputé fonctionner correctement

Reste donc comprendre pourquoi j'ai eu systématiquement des 'mauvais réveils' (camera non reconnue) avec mon code (message #64)

EDIT Je réalise que dans mes tests avec un pull -up externe sur GPIO13 je l'ai connecté à +5V et non +3,3V !!
Si i l'ESP32 supporte aussi bien les mauvais traitements que l'ESP8266 mon GPIO13 est peut être toujours en bon état !! ("mauvais traitements" = ce qui excède les valeurs lilimites présentent dans la notice)

Bonsoir al1fch et Artouste

Un grand merci al1fch d’avoir fait ce travail qui sera une bonne finale à beaucoup d’efforts et de recherches, pour vous deux et pour moi aussi… :confused:

Bon j’ai essayé vite fait, mais je n’ai pas pu voir le WiFi de mon esp32-cam sur mon smartphone, il n’y avais pas assez d’amperages, je ne sais pas pourquoi.

Pour info, j’avais sur le “chargeur doctor” 180mA, et d’après mes multiples branchements, c’est à 190mA que je pouvais voir L’ESP et donc me connecter…

Peut être que L’ESP est fatigué, ou le chargeur tél. fatigué aussi, je ne sais pas…

Demain j’essayerai plus calmement.

Donc j’ai téléchargé tes deux programmes et j’y ai bien sûr ajouté les deux autres de l’exemple original dans le même dossier.

J’ai televersé dans l’ESP32-CAM, tout à bien été bien sûr :smiley:

À part que je n’ai pas pu l’essayer pour la raison précédemment expliqué.

Demain je vais televerser le programme exemple original et voir si cela se passe bien, ensuite je recommencerai avec le tiens.

Bonne soirée et merci encore, c’est très sympa ;D

al1fch:
Bonsoir

Dans cet exemple le réveil de la carte par GPIO st réputé fonctionner correctement

ESP32-CAM PIR Motion Detector with Photo Capture | Random Nerd Tutorials

Reste donc comprendre pourquoi j'ai eu systématiquement des 'mauvais réveils' (camera non reconnue) avec mon code (message #64)

EDIT Je réalise que dans mes tests avec un pull -up externe sur GPIO13 je l'ai connecté à +5V et non +3,3V !!
Si i l'ESP32 supporte aussi bien les mauvais traitements que l'ESP8266 mon GPIO13 est peut être toujours en bon état !! ("mauvais traitements" = ce qui excède les valeurs lilimites présentent dans la notice)

:-[
Personne n'est jamais à l'abri de ce genre d’inattention/ mauvaise manip , surtout dans dans les cas où comme là , où il est facile d'enchainer les combinaison de niveau de pin , encore plus lorsque sur un meme module trainent proche l'un de l'autre du 5V et 3.3V d'alim
Avec un pu de bol , l'esp32 (GPIO13) n'aura rien senti :grin:

Un test que vais faire dans la semaine c'est de regarder quel est le niveau dispo sur le pin ChipPu sur le module esp32 lui meme avant et aprés l'endormissement par soft.

ce pin permet selon le niveau appliqué dessus soit le ON ESP32 (niveau HAUT) soit le deep sleep profond (niveau Bas)

il est bien noté que ce pin ne doit jamais etre laissé flottant , c'est plus par curiosité qu'autres choses :smiley:

"CHIP_PU" c'est le nom donné par Espressif au Reset de la puce ESP32 (cf data sheet)

Sur la carte ESP32_CAM il est relié au BP de Reset avec une résistance de pull up de 10Kreset .png

Quand CHIP_PU est maintenu à l'état bas la puce consomme en principe moins qu'en deep_sleep , cela correspond peut être à l'hibernation décrite dans cet intéressant article :

reset .png

al1fch:
"CHIP_PU" c'est le nom donné par Espressif au Reset de la puce ESP32 (cf data sheet)

Sur la carte ESP32_CAM il est relié au BP de Reset avec une résistance de pull up de 10Kreset .png

Quand CHIP_PU est maintenu à l'état bas la puce consomme en principe moins qu'en deep_sleep , cela correspond peut être à l'hibernation décrite dans cet intéressant article :

oui c'est ce que j'évoquais avec notion de "deep sleep profond"

Ce que je veux regarder c'est le niveau dispo sur ce pin en fonction du niveau d'endormissement généré par soft
Il n'y aura peut etre rien à en tirer d'ailleurs ! :grin:

bon j'ai avion premier vol demain matin pour la ville rose , donc je ne vais pas tarder à "mettre la viande dans le torchon" ;D

to be continued

Bonsoir ArduiCool

Bon j'ai essayé vite fait, mais je n'ai pas pu voir le WiFi de mon esp32-cam sur mon smartphone.....

Atention : l'exemple CameraWebServer se connecte à un point d'accès (box..) c'est une 'Station' WiFI, pas un 'Point d'accès'. Normal qu'on ne le voie pas avec un scan WiFi.
Je n'ai pas cherché à changer ce comportement
Une fois la carte ESP32-CAM connectée à ma box je lance un navigateur avec l'adresse ip de la carte, adresse ip attribuée par la Box

Courant :

Pour info, j'avais sur le "chargeur doctor" 180mA, et d'après mes multiples branchements, c'est à 190mA que je pouvais voir L'ESP et donc me connecter...

Je fait aujourd'hui des mesures sommaires avec un multimetre moyennement rapide qui montre une partie des fluctuations du courant , les modules USB lissent parfois trop les choses et cachent les 'creux' et les 'bosses'.

Pour voir mesurer les brefs pics de courant (pointes vers 400mA en WiFi) , petite résistance série et oscilloscope.
L'alim doit pouvoir 'assurer' ces brefs pics de courant qu'un 'charger doctor' ou même un multimètre , trop lents, ne peuvent montrer.

Bonjour

petit retour sur les pb rencontrés au reveil par GPIO (camera souvent non reconnue)

Pb réglé an ajoutant un condensateur de 470µF sur la ligne 5V, il s'agisait à première vue d'une diificulté de l'alim à fournir la pointe de courant...

Le code publié au message #65 ayant déjà pinMode(13, INPUT_PULLUP); trace d'un essai antérieur
j'ai juste ça dans loop() pour permettre le réveil par GPIO13 après mise en sommeil

  if (demande_sommeil) {
    Serial.println("mise en sommeil profond");
    esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0);
    esp_deep_sleep_start();
  }

NB : mon GPIO13 a survécu au pull up sur 5V infligé par mégarde auparavant
De la à déduire, contre l'avis du fabriquant, que l'ESP32 tolère le 5V sur ses entrées.....je ne franchis pas le pas !!

bonjour al1fch

Atention : l'exemple CameraWebServer se connecte à un point d'accès (box..) c'est une 'Station' WiFI, pas un 'Point d'accès'. Normal qu'on ne le voie pas avec un scan WiFi.
Je n'ai pas cherché à changer ce comportement

Oui, désolé, j'avais été trop vite...
J'ai modifié ton prog pour me mettre au point d’accès (sans internet) avec donc 192.168.4.1, et je retrouve ce point d’accès sur mon smartphone bien sûr :confused:

Donc en glissant "Face Detection" sur la droite, l'ESP32-cam se met bien en veille, mais je n'arrive pas à le réveiller avec le TSOP, ni même avec un bouton externe.
Deep Sleep.png

Mon branchement TSOP :
TSOP 1838.jpg

OU pour le bouton externe :

1 "patte" sur GNG
L'autre "patte" sur GPIO13 OU GPIO0, avec OU sans une résistance de 10k sur VCC

Je dois faire une bêtise ?

Deep Sleep.png

TSOP 1838.jpg

-Le code testé gère-t-il le réveil par GPIO13 ? (ce n'est pas le cas du code du message #65)
-Que donne le réveil par appui bref sur le bouton Reset de la carte ESP32-CAM ?

Pour y accéder j'ai mis la carte sur des 'échasses'
réveils.png
Depuis le réveil içi est OK que ce soit :
-par le Reset de la carte ou le bouton Reset déporté (au premier plan)
-par appui bref sur un BP relié à GPIO13 (au second plan)

pas testé de récepteur IR (pas sous la main) sur GPIO13 pour tenter de réveiller sur le premier front descendant
Je réserve GPIO0 au déclenchement du bootloader et ne souhaite pas lui donner deux röles même si cela est possible !

réveils.png

-Le code testé gère-t-il le réveil par GPIO13 ?

non

Que donne le réveil par appui bref sur le bouton Reset de la carte ESP32-CAM ?

l'esp redémarre bien par appuie bref le petit bouton qui est dessous l'esp (reset)


Pour le reste je vais essayer de faire le même montage physique que toi au niveau de l'esp, puis je te dis

OK , mais tu veux pouvoir réveiller l'ESP32 par autre chose que le Reset il faut le déclarer avant la mise en sommeil, exemple pour réveiller par mise à zéro de GPIO13 :

esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0);

cette ligne est absente du code présenté au message #65 parce que ce code est prévu pour un réveil par action sur le bouton Reset et que dans ce cas particulier il n'y a rien à déclarer comme 'source de réveil'