RE: je doit compresser le fichier Deb en ZIP car le Blog me le refuse dans son état brut.

Je vous renvoie ce fichier Install_Serveur_Http_Vetronic_2.1.deb dans une archive ZIP Install_Serveur_Http_Vetronic_2.1.zip que vous devez décomprésser pour trouver le fichier Deb.

Bonjour pascalduvar,

C’est pas sympa, vous ne respectez pas trop mes directives ! Je plaisante !

Mais c’est vrai que  je vous ai demandé soit de supprimer le fichier root du crontab que vous trouvez dans /var/spool/cron/crontabs/ ou au pire si vous ne pouviez pas alors voir à retirer totalement la ligne de lancement du Serveur Python du fichier crontab et NON de  mettre en commentaire cette ligne ! Le mieux est de supprimer ce fichier root si vous pouvez le faire.

Merci pour tous vos Retour et votre Archive. Je Vérifie la correspondance entre mes fichiers et ceux de votre archive et vous renvoie un fichier DEB qui fera l’installation Global.

D’ailleurs Je m’apprêtais à vous envoyer un fichier de MAJ DEB que j’avais préparé pour mettre à jour votre Install Vetronic avec mes Modifs sur mes propre fichiers Vetronic, pensant que vous étiez absent.

Je vérifie rapidement la correspondance des indices entre mes fichiers et le votre et vous transmet je pense d’ici 13h ce fichier d’installation e la MAJ Globale.

Pensez vous être dispo cet après midi ou en début de soirée pour tester cette MAJ ?

Juste pour information, j’ai installé votre projet Vetronic pour mes tests, dans un Raspberri PY ZERO. Il est un peu plus lent qu’un Raspberry Pi 3 ou 4 mais les temps d’Init du WIFI doivent plus ou moins correspondre lors d’un BOOT du RASP.

J’ai calculé, qu’il se passe au moins 2 minutes entre le début du redémarrage du RASP et l’Init du WIFI avec ma BOX en fin de Boot. Dans cette phase de 2 minutes le Serveur HTTP Python ne peut pas démarrer car il lui faut une IP pour s’initialiser. Cela explique vos PB.

Donc en attente de mes dernière Modifs, si vous avez à redémarrer votre RASP, vous devez attendre au moins 1 minute par sécurité une fois que le RASP refonctionne après un BOOT, pour être plus ou moins sûr que le WIFI du RASP est initialisé et pouvoir lancer le Serveur Python.

Le WIFI du RASP ne s’initialise qu’une fois l’ensemble des Programmes du RASP fonctionne rn fin de BOOT, donc bien après la phase de BOOT. Le fichier /etc/rc/local lui est lancé en cour de BOOT bien en amont de la phase d’init du WIFI, donc mon Serveur ne peut pas se lancer au Boot depuis le rc.local sans mes Modifs à venir.

Déjà l’Init du WIFI avec la BOX prend un temps Long, d’autant plus si la distance entre les équipements sont un peu éloignés entre eux. Dans ce cas les signaux WIFI sont faibles, donc cela provoque plus d’erreurs dans les transactions donc cela Ramer d’avantage !!!

A toute.

Cdt

Re: Désolé, cela fait un moment que je n’ai pas joué et testé les requêtes Vetronic. J’avais oublié, mais les Requêtes pour le Vetronic son préfixé par : /pvetronic$/

h ttp://192.168.1.81:9200/pvetronic$/votre-requête-vetronic

Donc je résume, pour tester uniquement le Serveur Python depuis le navigateur:

h ttp://192.168.1.81:9200/test

Pour toutes les autres requêtes à destination du Vetronic depuis le navigateur  il faut rajouter /pvetronic$/suivi-de-votre-requête-Vetronic

exemple : demander le menu d’aide du Vetronic :

h ttp://192.168.1.81:9200/pvetronic$/help 

Je pense que vous le saviez car vous vous en servez tous les jours via EEdomus!

Cdt

Bonjour pascalduvar,

Finalement après des tests chez moi, il est préférable de conserver le fichier /etc/rc.local pour lancer le serveur Python au BOOT. J’ai modifié les Fichiers Python afin que le Serveur HTTP ne démarre que s’il y a une IP IPv4 valide soit via RJ45 ou via WIFI.

J’attends vos 2 fichiers Python pour retranscrire mes modifs dans vos fichiers.

Par contre réactiver dans le fichier /etc/rc.local uniquement le Script qui lance le Serveur Python. mais ne réactivez pas le Script Ping. La fin du rc.local doit se terminer ainsi

sudo nohup /usr/bin/python3 /var/www/http_serv/serveur_http.py &

exit 0

Si vous aviez gardé et mis ce Script Python en commentaire, vous le décommentez et vous rajouter juste le terme nohup après le sudo. 

Laissez en commentaire ou supprimer la ligne du Script Ping : # ping -c 4 127.0.0.1 > nul

S’il n’est pas trop tard, ne rentrez pas le script dans le fichier crontab.

S’il est trop tard, vous pourrez supprimer votre Script depuis le dossier /var/spool/cron/crontabs/ et vous supprimez le root qui est visible. (faut être logguer en ROOT)

Ensuite vous vérifiez avec la commande SSH : crontab -l que votre modif n’existe plus.

Au pire si vous n’arrivez pas à supprimer ce fichier root, vous relancer la Cde : crontab -e  ensuite ENTER après le 1er message, vous retrouvez le contenu du fichier crontab. Vous supprimez la ligne que vous aviez rajouté et ensuite CTRL+O puis ENTER et CTRL+X pour sortir

J’attends vos deux fichiers :

/var/www/http_serv/serveur_http.py

/var/www/http_serv/driven/utils.py

Je les modifies et je vous les renverrais pour que vous remplaciez vos propres fichiers.

En attendant, vous lancez le script Python manuellement comme spécifié dans mon Post précédent si le Serveur Python n’est pas encore lancé: sudo nohup /usr/bin/python3 /var/www/http_serv/serveur_http.py &

Cdt

Bonjour pascalduvar,

Pour Info, normalement tous les Scripts qui sont entré dans le fichier /etc/rc.local, sont lancés au BOOT du Linux du Rasp.

Les Scripts que j’avais mis dans ce fichier rc.local, comprennent 3 lignes :

# sudo /home/pi/.local/bin/python3 -m http.server &
ping -c 4 127.0.0.1 > nul
sudo /usr/bin/python3 /var/www/http_serv/serveur_http.py &

La 1ere ligne est juste un commentaire
la 2eme ligne lance un Ping et test si la CNX réseau fonctionne au bout de 4 tests
la 3eme ligne est censée lancer le Serveur Python.

Le Serveur Python à besoin pour se lancer, que la CNX Réseau soit établie avec le RASP.

Hors vous avez une Cnx Wifi et j’avais pensé que vous étiez en Cnx Lan RJ45.
Comme une Cnx WIFI n’est établit que lorsque le RASP à démarré, C’est pourquoi le Serveur Python ne se lance pas juste au BOOT,  car la Cnx Wifi n’est pas encore initialisée avec le RASP lorsque le /etc/rc.local demande de lancer cette instance Python.

Donc vous faites bien, il faut bien retirer ces 3 lignes du fichier /etc.rc.local qui ne servent à rien.

Par contre dans le ConTab, je vous ai demandé de rentrer qu’Une Seule ligne,
celle qui lance le serveur Python : @reboot sudo /usr/bin/python3 /var/www/http_serv/serveur_http.py &

Il ne faut pas rentrer dans le fichier crontab le Script qui lance le Ping !

Que lisez vous depuis une Console avec cette commande : crontab -l
Normalement vous devriez lire quelque chose comme ci-dessous et voir et lui Seul votre Script Python en fin du fichier sans le Script Ping:

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use ‘*’ in these fields (for ‘any’).
#
# Notice that tasks will be started based on the cron’s system
# daemon’s notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

@reboot sudo /usr/bin/python3 /var/www/http_serv/serveur_http.py &

Si vous ne voyez pas votre Script Python en fin de fichier, c’est que vous n’avez pas validé l’enregistrement du Script lors de votre saisie.
C’est peut être de ma Faute ! j’ai oublié de vous demander de faire ENTER après le CTRL+O , car on vous demande de confirmer votre enregistrement par un OUI !!!

Donc si à la Fin du fichier crontab, votre Script python n’est pas présent, ou bien vous y voyez aussi en plus de votre Script Python, le Script du PING, alors vous recommencez les Cde suivante : contab -e + ENTER

On vous affiche :
Select an editor.  To change later, run ‘select-editor’.
  1. /bin/nano        <—- easiest
  2. /usr/bin/vim.tiny
  3. /usr/bin/code-insiders
  4. /usr/bin/code
Choose 1-4 [1]:

Vous taper juste : ENTER

On vous affiche le contenu du fichier crontab avec du texte en commentaire au début.
Vous descendez en fin du fichier.

Soit vous voyez vos 2 Scripts, alors il faut retirer la Ligne avec le PING et laissez uniquement le Script de votre Python qui doit commencer par @reboot.

Si vous ne voyez aucun Script après les commentaires,  alors en fin des commentaires vous taper 2 fois ENTER puis vous rentrer en début de ligne exactement le Script suivant (ajout de nohup) suivi d’un ENTER en fin de la ligne :

@reboot sudo nohup /usr/bin/python3 /var/www/http_serv/serveur_http.py &

Ensuite vous tapez : CTRL+O suivi d’un ENTER et ensuite CTRL+X

Vous vous retrouver sur la console. Vérifiez que votre Script à bien été enregistré dans le fichier crontab par la commande : crontab -l

Si vous ne voyez pas votre Script vous recommencez, ne pas oublier de taper ENTER après le CTRL+O (O comme OUI) sinon vous sortez de crontab par CTRL+X

Après vos modifs, vous devez Rebooter votre RASP.

Ensuite vous tester pour voir si le serveur à démarré : sudo pgrep -a python
Vous devriez voir une instance de votre Serveur Python lancée :

« xxxx /usr/bin/python3 /var/www/http_serv/serveur_http.py »

Si le Serveur n’est toujours pas lancé vous m’en faite Part, cela signifie qu’il faut rajouter une TEMPO dans le Script avant de lancer le Serveur Python car le WIFI du RASP ne serait pas encore activé au lancement de la Tache Cron.

Donc si le Serveur n’est Pas Encore Lancé, vous le lancez vous même et une seule fois (y compris avec le nohup) : sudo nohup /usr/bin/python3 /var/www/http_serv/serveur_http.py &

Dans le future rajouter ce terme nohup dans vos commandes pour lancez le serveur Python.

Oubliez pour l’instant l’interface EEdomus, vous allez tester le Serveur Python uniquement depuis votre navigateur.

Lancez la requête suivante depuis votre navigateur : http://192.168.1.81:9200/test
Le serveur Python devrez vous répondre : Le Serveur Fonctionne Bien

Si vous avez une erreur avec le navigateur, alors que la commande SSH : sudo pgrep -a python vous affiche bien une instance du serveur Python lancée :

« xxxx /usr/bin/python3 /var/www/http_serv/serveur_http.py »

c’est que vous n’avez pas fixé l’IP WIFI du RASP :192.168.1.81 en mode Static dans l’Admin de votre BOX.

Cela sous entend que votre BOX peut fournir dans ce cas et suivant sa volonté une IP Wifi autre que 192.168.1.81 à votre RASP comme l’IP 192.168.1.53 que vous avez eu un moment donné !

Cela expliquerer que parfois le Serveur Pyhon ne fonctionne pas avec EEdomus après avoir lancé le Serveur Python manuellement.

Il faut dans ce cas forcer l’IP du RASP  192.168.1.81 en Static dans votre Box en lien avec le l’Adresse Mac du Rasp, depuis l’Admin de votre Box. Bien sur si c’est bien l’IP 192.168.1.81 qui doit être attribuée à votre Rasp et que vous avez bien sur déclaré cette IP dans EEDOMUS.

Après si vous avez toujours des Pb avec EEdomus, déconnectez votre prise USB/Serial du RASP puis vous la reconnectez. Cela va réinitialiser le Port COM RS232.

A part ces cas de figure cela devrait fonctionner.

Faite moi un retour

Cordialement
Christian

RE: pour pascalduvar,

Si vous avez une erreur en tapant la commande : pkill -9 -f  ‘/usr/bin/python3 /var/www/http_serv/serveur_http.py’ alors rajouter sudo devant la liagne :

sudo pkill -9 -f  ‘/usr/bin/python3 /var/www/http_serv/serveur_http.py’

cdt

Bonjour Misterden,

J’ai encore apporté une modification sur le Programme INO. Comme je n’ai pas de Borne Vetronic, je ne peux que faire des simulations en rebouclant la liaison Série TX et RX.

J’ai oublié le cas ou le Vetronic ne répond pas ! (Pb Cnx RS232 ou autres …). J’ai rajouté une tempo de TimeOut de 1 seconde pour pallier à ce PB.

Trouver encore une autre Archive modifiée, la 4eme ! Désolé !!!.

Concernant l’Interface Série entre le ESP32 et le Vetronic, vous devez passer par un convertisseur Série TTL / RS232.

La différence entre une liaison série TTL et série RS232 est le format du signal envoyé.

La liaison série TTL fonctionne avec un niveau TTL, à savoir : Un 0 logique est idéalement à 0 volt, et un 1 logique à 5 volts. Le dispositif récepteur doit donc tester si le signal à un instant donné est à 0 ou 5 volts, afin de dire s’il reçoit un 0 binaire ou un 1 binaire.

Pour une liaison série RS232, le 0 logique est idéalement représenté par -12 volts et un 1 logique est représenté par +12 volts. Cela offre une plus grande sécurité des données car la différence de signal de données est de -12v à +12v soit 24 volts. la spécification autorise -5 à -15V et +5 à +15V.

C’est pourquoi il faut connecter entre le ESP32 et le Vetronic un Adaptateur Série TTL <> RS232 et le module MAX3232 fait correctement ce travail.

Toutefois il faudra voir s’il n’y a pas un PB avec le niveau RX côté réception RS232 du Vetronic vu que le Module MAX3232 sera alimenté en 3.3V au lieu de 5Vdepuis le ESP32.

On utilise le 3.3V pour alimenter ce module MAX3232, afin de respecter la tension Input/Output des GPIO Tx/Rx du ESP32. Une solution existe pour palier à ce Pb s’il existe, via deux MOSFET BS170 et 4 résistances de 4.7K 1/4w.

Faites attention, plusieurs modèles d’adaptateurs TTL/RS232 existe sur la Toile. Achetez bien le module MAX3232 et vérifier qu’il ressemble à celui présenté dans mon Schéma de câblage. Achetez aussi l’Adaptateur DB9 qui permet de connecter vos fils de la liaison Série. Ces modules ne coûte pas cher, en général moins de 5€ (Faites attention aux profiteur !!!)

Vous pouvez déjà charger le programme INO dans un ESP32 et reboucler les PINS 15 et 4 du ESP32. Ensuite vous pouvez envoyez vos requêtes depuis un navigateur pour voir si le ESP32 répond par Echo sur la liaison Série.

Si vous rencontrez des PBs trouvez mon eMail dans l’entête du fichier INO.

Cdt