Bonjour
Raspberry PI4 Bullseye - derniere version de Jeedom
J’utilise un script python parfaitement fonctionnel sous bullseye que j’appelle depuis un scenario bloc code (il va lire des données d’une carte electronique UPS : voltage, capacité batterie,…).
Sur une autre installation jeedom sous Bookworm ce même script fonctionne tres bien des lors que je l’execute en manuel depuis le scenario. Par contre en mode programmation (execution toutes x minutes) ou provoqué le script me renvoie des valeurs vides.
Apres multes recherches et manipulations du scenario je n’ai pas trouvé la cause de cette anomalie.
Peut être l’un d’entre vous pourra m’aiguiller sur un début de solution, ou bien dois je tout simplement attendre l’évolution de jeedom.
Merci de votre aide
Bonjour,
Sans ledit script ni le scénario, si une personne arrive à vous aider avec sa première réponse alors cette personne est très douée ou dotée d’un don très particulier.
À+
Michel
Bonjour
Je reviens sur le probleme exposé.
Sous debian11 mon scenario fonctionne parfaitement en mode programmé et provoqué.
Sous debian12 mon scenario fonctionne uniquement en execution manuelle. En mode programmé ou provoqué il fonctionne la 1ère fois et ensuite il me renvoie des valeurs vides.
Voici le scenario :
Merci de votre aide
Bonsoir,
Tu peux taper which python3 et récupérer ce qu’il indique, style /usr/bin/python3 et utiliser cette commande à place de juste python3 sur ta ligne 7
Dans le chemin, ligne 3, il faudrait aussi idéalement retirer le / à la fin pour éviter d’avoir un double / dans le chemin complet
Et si ça ne marche toujours pas, j’ai déjà lu un truc avec l’extension du script mais pas sûr que ça aide ici. Tu peux essayer d’utiliser un script qui a une extension .PY et non .py ?
Si ma PR de cet été sur le plugin script était mergée, cet appel fonctionnerait. Mais bon ça ne bouge pas… J’ai relancé en commentaire sur la PR et en MP à Aurélien, rien ne bouge.
Je n’insiste plus. Tanpis pour les utilisateurs de Jeedom.
PS : la PR contient même la mise à jour de la documentation
edit: en fait le plugin script n’est pas du tout utilisé…
Ils vont peut être avoir plus de temps d’ici 2 ou 3 semaines maintenant que la 4.5 est publiée en stable.
J’avais aussi fait une PR sur le core mais je crois que je vais la cancel et recommencer parce qu’entre temps on a fait évolué ça
Sur la machine Debian 12, dans un shell, est-ce que le script retourne ce qu’il doit retourner à chaque appel ?
Bonjour
Merci de vos remarques dont j’ai tenu compte mais le problème persiste.
En fait mon scenario fonctionne parfaitement lorsque je clique sur « executer » avec ma souris.
Le scenario appelle un programme python qui lit des données GPIO.
Mais au démarrage par le bloc « DANS » il me renvoie des données vides.
Si je clique à nouveau sur « executer » le scenario me renvoie bien les données attendues.
Ce même scenrio fonctionne parfaitement sous debian 11.
Ca vient du remove_inat, je pense.
J’imagine que le scénario ne se lance pas lui-même puisqu’il est arrêté avant ?
Postez une capture de la configuration du déclenchement SVP
Bonjour
J’ai enlevé le remove_inat et cela ne change rien.
Par contre j’ai transféré le recueil des données dans le programme python (requests + post dans virtuel) et je l’ai bien sur retiré du bloc code.
Le scenario fonctionne désormais parfaitement.
Il y a donc un problème entre le core jeedom et debian 12.
Postez une capture du nouveau scénario, j’ai pas compris votre modification.
Postez une capture des virtuels.
Voici les captures:
Et j’ai rajouté ces lignes à mon programme python :
URL = « http://192.168.XX.XX/core/api/jeeApi.php »
API_KEY = « XXXXXXXXXXXXXXXXXXXXXXXXXX »
DATA1={‹ apikey › : API_KEY , ‹ type › : ‹ cmd › , ‹ id › : ‹ 8210 ›, ‹ value › : (vout) }
response = requests.post(URL, params=DATA1)
DATA2={‹ apikey › : API_KEY , ‹ type › : ‹ cmd › , ‹ id › : ‹ 8211 ›, ‹ value › : (batcap) }
response = requests.post(URL, params=DATA2)
DATA3={‹ apikey › : API_KEY , ‹ type › : ‹ cmd › , ‹ id › : ‹ 8212 ›, ‹ value › : (value) }
response = requests.post(URL, params=DATA3)
Dans la version qui ne marcjhe pas et où j’utilise le bloc code la variable $response est vide au second demarrage puis aux suivants.
Mais le log est généré ?
NB : c’est mieux d’utiliser les balises de texte préformaté pour les log et le code :
edit : et comme on n’a pas le script initial, pas moyen de savoir ce que vous avez fait dans le script.
Merci de votre demande de log car je réalise que le probleme vient de la ligne « import RPi.GPIO as GPIO » de mon script.
Je l’ai supprimé puisque je ne fais que de la lecture de ports et tout semble fonctionner
Voici l’extrait de log :
FileNotFoundError: [Errno 2] No such file or directory: ‹ .lgd-nfy-3 ›
CreatePipe: Can’t set permissions (436) for /var/www/.lgd-nfy0, No such file or directory
Traceback (most recent call last):
File « /var/www/html/plugins/script/data/UPS_monitor.py », line 5, in
import RPi.GPIO as GPIO
File « /usr/lib/python3/dist-packages/RPi/GPIO/init.py », line 14, in
import lgpio
File « /usr/lib/python3/dist-packages/lgpio.py », line 562, in
_notify_thread = _callback_thread()
ça donne un truc comme ça, dans lequel on voit les " et les ' sans mise en forme par discourse
Vous avez raison. Mais j’ai un peu de mal à tout maitriser.
et on n’a toujours pas :
- le script
- les log
- le déclencheur du scénario
- la mise en forme demandée
c’est sans doute volontaire de votre part de ne pas partager tout ça, mais ça ne nous permet pas de vous aider au mieux. prenez le temps de bien documenter, step by step
Je corrige votre propos car c’est vraiment involontaire de ma part.
En voulant aller à l’essentiel j’ai fait preuve de retenue pour ne pas inonder le forum de données inutiles et fastidieuses.
Et mea culpa j’ai découvert qu’il y avait un log trop tardivement. Si j’en avais pris connaissance au départ je n’aurais pas ouvert ce sujet sur le forum.
Merci de votre aide et de votre appel à plus de rigueur
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.