Bonjour à toutes et tous,
J'utilise un Raspberry Pi 3B+ équipé d'un hat waveshare UPS_HAT 2(B) pour palier aux coupures (fréquentes chez moi) de l'alimentation EDF.
En cas de coupure EDF, le HAT prend le relais pour l'alimentation.
Pour ne pas épuiser les batteries de secours, quand celles-ci tombent à 30% de charge, un script python déclenche la mise en veille du Raspberry.
Malheureusement, même quand le Raspberry Pi est en veille, l'alimentation de secours continue d'alimenter le Raspberry PI.
En conséquence, celui-ci ne détecte pas la coupure de courant et donc ne reboot pas quand le courant est rétabli!
Je cherche une solution pour forcer le reboot au retour du courant.
Quelqu'un aurait-il une bonne idée?
Merci d'avance
Notes:
- Quand le Raspberry pi est alimenté par batteries mais en veille les pins +5V et GND du Pi sont sous tension. (on peut y alimenter autre chose ex: esp32 etc...)
- Le Hat est doté d'un interrupteur mécanique permettant de couper l'alimentation du Raspberry.
- Si la Pin libellée "PEN" (juste derrière le plot de 2 prises USB situé entre le connecteur RJ45 et l'autre plot USB) est maintenu reliée à un des pôles négatifs le Raspberry est plongé en veille profonde et consomme 10x moins qu'en veille.
- Quand la Pin libellée "PEN" est déconnectée du pôle négatif, le raspberry reboot automatiquement.
- L' UPS_Hat est alimenté en 8,4 Volts (alimentation externe).
RPI + UPS_HAT redemarrage après poweroff
Modérateur : Francois
Re: RPI + UPS_HAT redemarrage après poweroff
Bonjour,
Mon intérêt pour le mode veille a toujours été de le désactiver car il m'ennuie mais je n'ai jamais eu à rentre le Pi autonome énergétiquement parlant.
Dans votre cas, quel est l'intérêt du mode veille ?
Je comprends que vous cherchiez à protéger le Pi puisque les batteries sont à moins de 30%
Mais pourquoi choisir le mode veille et pas une extinction ?
Vous me direz, un poweroff donnerait le même résultat : Pi éteint malgré la tension aux bornes des Pins d'alimentation donc non réallumable tant que cette tension n'a pas été supprimée puis remise.
Dans les 2 cas, il faut une intervention manuelle : soit retirer puis remettre l'alimentation (si le Pi est éteint pour le réallumer)
Soit un shint temporaire sur les bornes de reset (pour le sortir de la veille)
Le PI peut peut prévenir avant de se mettre en veille ou de s'éteindre (via un mail par exemple)
Si le hat ne sait pas faire ces opérations de manière autonome (coupure, remise de courant ou shunt) , c'est mort : le pi en veille et encore moins éteint ne le fera pas.
Une option serait de réaliser son propre montage capable de faire cela
Ex : le même ensemble de batterie avec un même composant INA219 et un arduino nano (ou autre microprocesseur simpliste consommant encore moins)
L'arduino recevrait les infos de tensions de l'IN219 (et pourrait aussi les transmettre au Pi via le port série) et serait capable de mettre en veille, sortir de veille (ou extinction soft et rallumage) le Pi. Voir d'afficher en live la tension de la batterie sur un petit écran et aussi avoir des boutons d'action manuelle.
Mon intérêt pour le mode veille a toujours été de le désactiver car il m'ennuie mais je n'ai jamais eu à rentre le Pi autonome énergétiquement parlant.
Dans votre cas, quel est l'intérêt du mode veille ?
Je comprends que vous cherchiez à protéger le Pi puisque les batteries sont à moins de 30%
Mais pourquoi choisir le mode veille et pas une extinction ?
Vous me direz, un poweroff donnerait le même résultat : Pi éteint malgré la tension aux bornes des Pins d'alimentation donc non réallumable tant que cette tension n'a pas été supprimée puis remise.
Dans les 2 cas, il faut une intervention manuelle : soit retirer puis remettre l'alimentation (si le Pi est éteint pour le réallumer)
Soit un shint temporaire sur les bornes de reset (pour le sortir de la veille)
Le PI peut peut prévenir avant de se mettre en veille ou de s'éteindre (via un mail par exemple)
Si le hat ne sait pas faire ces opérations de manière autonome (coupure, remise de courant ou shunt) , c'est mort : le pi en veille et encore moins éteint ne le fera pas.
Une option serait de réaliser son propre montage capable de faire cela
Ex : le même ensemble de batterie avec un même composant INA219 et un arduino nano (ou autre microprocesseur simpliste consommant encore moins)
L'arduino recevrait les infos de tensions de l'IN219 (et pourrait aussi les transmettre au Pi via le port série) et serait capable de mettre en veille, sortir de veille (ou extinction soft et rallumage) le Pi. Voir d'afficher en live la tension de la batterie sur un petit écran et aussi avoir des boutons d'action manuelle.
3 Pi4 : Emby / Samba , Librelec, Android TV
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
Re: RPI + UPS_HAT redemarrage après poweroff
Bonjour Piper,
Merci pour votre réponse.
L’intérêt que je vois dans la mise en veille du Pi vs sont extinction est d'avoir la possibilité de le redémarrer sans avoir à couper puis rétablir la tension d'alimentation; cela en agissant sur la pin "PEN".
Ça évite d'avoir à modifier le HAT ou le Pi (pour connecter un relais par exemple).
Vous suggérez "de réaliser son propre montage capable de faire cela".
C'est en effet ce à quoi j'ai songé dès le départ, avant de poser ma question sur le forum. (d'abord sur une base d' ESP 32 Lolin Wroom qui ne consomme rien en "deep sleep", peut en sortir, (via de nombreux moyens dont la RTC) et présente l'avantage d'accueillir une batterie.
Force est de constater que le "reflex "microcontrôleur" n'est pas toujours judicieux.
Après réflexion, cette solution m'est apparue excessive pour contrôler un simple relais ou équivalent! D'autre part, comme vous le faites remarquer, cela oblige à communiquer entre le PI et l'ESP 32 ce qui tourne vite à "l'usine a gaz" que ce soit en direct i²c, RS 232, SPI, ... ou via réseau Ethernet: mail (comme vous le suggérez), MQTT, API WEB etc... Tout cela pour contrôler un simple contact!
A mon goût, les solutions les plus simples sont moins prônes aux dysfonctionnements et plus évidentes à la maintenance.
Je me suis donc dit que qq1 avait forcement rencontrer ce problème avant moi. J'avoue même être étonné que WaveShare ne l'ai pas pris en compte au développement de leur HAT version B.
Pourquoi réinventer la roue quand certains trouvent des solutions souvent géniales?
En attendant mieux; j'ai câblé un temporisateur 220 Volts, qui ne me servait plus, qui envoi une impulsion d'un quart de seconde à un relais au retour du courant. Le relais met en contacte la PIN PEN avec le GND du PI et le redémarre.
Pas classe, je vous l'accorde, mais effectif.
J'envisagerais une solution opto-couplée et "plus électronique" quand j'en aurais le temps.
Bien entendu une fois la solution définitive mise en place, je ne manquerais pas d'en faire part sur le forum. A moins que d'ici là qq1 n'apporte une solution clef en main.
Merci de votre intérêt.
Merci pour votre réponse.
L’intérêt que je vois dans la mise en veille du Pi vs sont extinction est d'avoir la possibilité de le redémarrer sans avoir à couper puis rétablir la tension d'alimentation; cela en agissant sur la pin "PEN".
Ça évite d'avoir à modifier le HAT ou le Pi (pour connecter un relais par exemple).
Vous suggérez "de réaliser son propre montage capable de faire cela".
C'est en effet ce à quoi j'ai songé dès le départ, avant de poser ma question sur le forum. (d'abord sur une base d' ESP 32 Lolin Wroom qui ne consomme rien en "deep sleep", peut en sortir, (via de nombreux moyens dont la RTC) et présente l'avantage d'accueillir une batterie.
Force est de constater que le "reflex "microcontrôleur" n'est pas toujours judicieux.
Après réflexion, cette solution m'est apparue excessive pour contrôler un simple relais ou équivalent! D'autre part, comme vous le faites remarquer, cela oblige à communiquer entre le PI et l'ESP 32 ce qui tourne vite à "l'usine a gaz" que ce soit en direct i²c, RS 232, SPI, ... ou via réseau Ethernet: mail (comme vous le suggérez), MQTT, API WEB etc... Tout cela pour contrôler un simple contact!
A mon goût, les solutions les plus simples sont moins prônes aux dysfonctionnements et plus évidentes à la maintenance.
Je me suis donc dit que qq1 avait forcement rencontrer ce problème avant moi. J'avoue même être étonné que WaveShare ne l'ai pas pris en compte au développement de leur HAT version B.
Pourquoi réinventer la roue quand certains trouvent des solutions souvent géniales?
En attendant mieux; j'ai câblé un temporisateur 220 Volts, qui ne me servait plus, qui envoi une impulsion d'un quart de seconde à un relais au retour du courant. Le relais met en contacte la PIN PEN avec le GND du PI et le redémarre.
Pas classe, je vous l'accorde, mais effectif.
J'envisagerais une solution opto-couplée et "plus électronique" quand j'en aurais le temps.
Bien entendu une fois la solution définitive mise en place, je ne manquerais pas d'en faire part sur le forum. A moins que d'ici là qq1 n'apporte une solution clef en main.
Merci de votre intérêt.
Re: RPI + UPS_HAT redemarrage après poweroff
Je partage tout à fait votre point de vue.
Moi aussi j'aurai aimé que waveshare, az-delivery ou un autre fabriquant de Hat tienne compte de cette problématique.
Sinon, j'avais bien pensé au WOL, mais on ne peut pas réveiller un Pi avec cette techno (on peut l'utiliser pour réveiller des PC mais pas dans le sens inverse).
Le WOR ne semble pas implémenté non plus.
Si vous ou un autre propose une solution électronique, je suis preneur !
Moi aussi j'aurai aimé que waveshare, az-delivery ou un autre fabriquant de Hat tienne compte de cette problématique.
Sinon, j'avais bien pensé au WOL, mais on ne peut pas réveiller un Pi avec cette techno (on peut l'utiliser pour réveiller des PC mais pas dans le sens inverse).
Le WOR ne semble pas implémenté non plus.
Si vous ou un autre propose une solution électronique, je suis preneur !
3 Pi4 : Emby / Samba , Librelec, Android TV
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
3 Pi3 : Hifiberry /OSMC, Games station, Samba / VPN / HotSpot Wifi
2 Pi2 : RFID, radio reveil (PiReveil)
1 Pi0 : traker GPS et acquisitions
1 Pi0 2W : tests divers
5 Arduinos dont 4 nanos et 1 Mega
1 ESP32
Re: RPI + UPS_HAT redemarrage après poweroff
Merci pour votre réponse Piper.
Je prends note de votre intérêt pour une solution "électronique" et ne manquerais pas de vous en faire part.
Je prends note de votre intérêt pour une solution "électronique" et ne manquerais pas de vous en faire part.