J’en profite pour mettre a dispo la dernière version de mon code (V7.6). Cette version corrige un bug d’initialisation en cas de coupure générale de courant (avant il fallait attendre au maximum 24 heures pour avoir l’heure correcte permettant l’automatisation des volets) .
Bien sur ce code ne passe ni par Alexa, ni Google ni par aucun système du commerce.
Au niveau sécurité, pour ceux qui ont peur du WIFI, il suffit de désactiver la fonction server web dans la procédure « loop ». En faisant cela, les volets ne sont plus programmables que par l’interface série sur le port USB de l’esp.
// requetes web
server.handleClient(); <== a commenter pour ne pas avoir la fonction server Web en WIFI.
Le WIFI doit tout de même être actif sur l’ESP afin de récupérer l’heure sur les serveurs NTP mais il n’est plus possible de commander ou de configurer les volets par le WEB.
Perso, j’ai créé des routines. Quand je lui dis « Monte les volets », elle passe l’interrupteur fauxmo sur On (ou Off, chéplus)
Et les ouvrir/fermer partiellement ne me semble pas insurmontable mais doit falloir créer un skill, émuler une lumière dimmable ou avoir une box domotique
Bonsoir,
J ai réussi à controler les volets de mon voisin avec ok google depuis l autre coté de la rue juste en criant bien fort.(avec son accord)
J ai lu qu avec des ultra son ça marche aussi.
Sympas pour les voleurs.
Je souhaite bien du plaisir à ceux qui investissent aujourd’hui dans des systèmes domotiques. Vu le niveau de protection de pas mal d’installations et matériels du type « Castoramisé », ça va pas être triste quand les petits cambrioleurs de base auront compris comment il faut faire. Ça commence déjà avec les voitures soi disant protégées électroniquement !!! Du gros foutage de gueule
Bonjour a tous, J’ai encore besoin de votre aide. Je suis entrain de passer mes volets sur un Pi car l’ESP est à court de mémoire et j’ai des tas d’idée pour améliorer (en fait pour me faire plaisir).
Pour ce faire j’ai créé une commande OS qui fonctionne a partir d’un shell du style :volet_somfy (@ du volet) (Rolling) (quelques paramètres) up ou down ou stop et qui fait appel à la librairie GPIO de PI. Cette commande est censée être lancé à partir d’un serveur (apache dans le futur mais pour le moment django tant que ca developpe)
Si je lance mon serveur Django en interactif avec l’utilisateur ‹ pi ›, ça marche, le serveur récupère bien la requête, exécute la commande OS et touti bene.
maintenant si je lance mon serveur au boot (et tout ce que je sais faire c’est de le lancer a partir du rc.local avec la commande :
su -s /bin/bash -c « cd (mon repertoire de lancement);/usr/bin/python3 (mon repertoire)/manage.py runserver 0.0.0.0:8080 &>> ~pi/log/log_serveur » -g pi pi&
qui est censée me lancer le même serveur avec le même utilisateur je me plante a l’exécution de la commande OS que j’ai créé avec le message :
wiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: Permission denied.
Aborting your program because if it can not access the GPIO
d’ou mes questions:
quelle est la différence entre lancer le serveur en interactif avec l’utilisateur pi et le lancer en batch avec le même utilisateur à partir du rc.local.
Y a t il une méthode + sioux pour démarrer le serveur django au boot?
Au pire dans mon jeune temps, en BSD 4.2 (je vous parle du siècle dernier) on pouvait activer le « sticky-bit » avec la commande chmod YXXX fichier. Le Y permettait d’élever les privilèges du process au niveau root juste pendant l’exécution et de revenir aux privilèges normaux lorsque la commande était terminée. Je n’ai rien trouvé de documenté dans le man chmod sur le pi. Est ce qu’un mécanisme équivalent existe sous raspbian?
Remarque: Le fait que mon serveur django lancé par le rc.local tourne avec l’utilisateur pi est confirme par le fait que les fichiers log appartiennent bien à « pi ».
quelle est la différence entre lancer le serveur en interactif avec l’utilisateur pi et le lancer en batch avec le même utilisateur à partir du rc.local.
Il y en a plusieurs, les plus notables sont :
il n’y a pas de terminal associé (tty), donc certains programmes interactifs peuvent ne pas fonctionner s’ils en ont besoin. Mais ça ne devrait pas te poser de problème ici.
les variables d’environnement peuvent être différentes (dont PATH). Pour avoir les variables à ce moment là tu peux ajouter un env >/tmp/rc_local_env dans ta commande. Mais ça ne devrait pas être ton problème ici non plus car ça parle de « permission denied ».
Je pense que ton problème ici c’est le paramètre -g pi que tu as donné à su et qui dit de lancer la commande sous le groupe pi. Je n’ai jamais utilisé ce paramètre car par défaut il prend les groupes de l’utilisateur mentionné avec -u. Je viens de tester et quand on précise un groupe comme ça, il ne met que ce groupe là, et il enlève les groupes supplémentaires (que tu peux voir avec id). Je pense que c’est à cause de ça que tu as un permission denied car sans les groupes supplémentaires tu n’as probablement pas accès à /dev/mem ou /dev/gpiomem.
Pour tester sans avoir à redémarrer à chaque fois tu dois pouvoir obtenir le même comportement en lançant la commande depuis un shell root (sudo -s).
Y a t il une méthode + sioux pour démarrer le serveur django au boot?
Oui une méthode plus propre sur les distributions récentes c’est d’utiliser systemd. T’as une doc succinte pour le pi ici : https://www.raspberrypi.org/documentation/linux/usage/systemd.md, et beaucoup d’autres sur le net. Ça permet notamment que le système relance le programme s’il s’arrête tout seul (avec le Restart=always).
Ils ne précisent pas où sont enregistré les logs. Normalement tu peux les consulter avec journalctl -u <le nom du service>. Sinon tu peux aussi changer StandardOutput=inherit et StandardError=inherit (doc).
Au pire dans mon jeune temps, en BSD 4.2 (je vous parle du siècle dernier) on pouvait activer le « sticky-bit » avec la commande chmod YXXX fichier. Le Y permettait d’élever les privilèges du process au niveau root juste pendant l’exécution et de revenir aux privilèges normaux lorsque la commande était terminée. Je n’ai rien trouvé de documenté dans le man chmod sur le pi. Est ce qu’un mécanisme équivalent existe sous raspbian?
Oui le sticky-bit existe aussi sous Linux, mais il ne fait pas ce que tu dis. Il y a le « setuid flag » qui fait ce que tu décris, mais ça ne fonctionne pas sur les programmes interprétés, car il faudrait que ce soit l’interpréteur (python3 dans ton cas) qui ait le flag « setuid ». Les 2 sont décrits dans le man chmod d’une raspbian que j’ai testée, c’est bizarre qu’ils n’y soient pas chez toi.
Merci mike pour ta reponse. super. pour le setuid flag ( et non le sticky bit tu as raison) ça devrait marcher car je le mettrais sur la commande volet_somfy qui est un exécutable autonome écrit en C. Pour le moment je suis assesseur pour les élections mais j’essayerai toute tes solutions ASAP.
