Transmettre un ordre à un programme Python

[pierbout]

Bonjour,

J’ai deux Raspberry:
-un hébergeant Jeedom
-un autre commandant ma piscine (et collectant les sondes)

Celui commandant la piscine est autonome. Un programme python tourne en permanance dessus, faisant tout le boulot. Le Jeedom me sert donc juste actuellement à monitorer les informations de la piscine.

Je voudrai toutefois pouvoir envoyer un ordre à mon programme python depuis Jeedom, et je cherche la méthode la plus propre. Je pensais pour cela passer par un fichier de flag: Jeedom envoie à l’autre raspberry un fichier dont le nom ou le contenu indique l’action à faire, et une fonction dans une boucle infinie du programme python test toutes les secondes si le fichier en question a ete créé, et si oui, déclenche une fonction

Autre solution possible: faire dans ma boucle python un request get, récupérant la valeur d’une variable Jeedom, mais ca ne me plait pas car nombreux échanges réseau pour une action que je ne déclencherai que rarement.

Avis aux experts: une idée à proposer?

Merci d’avance

(pour info je me débrouille en Python mais débute avec Jeedom…)

[Mips]

Le mieux est que ton programme python ouvre un port et écoute (fasse serveur donc)
Tu peux ouvrir on simple socket tcp et envoyer ce que tu veux dessus depuis jeedom

[pierbout]

Merci MIPS

Ce n’est pas la solution la plus simple, mais c’est en effet une idée. Je vais y réfléchir…

[Mips]

C’est le plus simple et surtout la plus convenable… une communication par fichier

Et tu as un squelette tout fait sur le plugin template de jeedom si tu n’as jamais fait cela:

reprend ce dossier et sous dossier (tu n’as pas besoin du reste)

plugin-template/resources/demond at master · jeedom/plugin-template

ton code existant tu le mets à coté (autre fichier), tu l’importes dans ce démon
ou il tient en une method et tu peux juste la rajouter dans le fichier demond.py
et tu lances un thread par exemple (ligne 120):

try:
	jeedom_utils.write_pid(str(_pidfile))
	jeedom_socket = jeedom_socket(port=_socket_port,address=_socket_host)
        ### section to adapt 
	myThread = threading.Thread(name="myThread", target=myMethodToExecute,  args=(, ))
	myThread.setDaemon(True)
	myThread.start()
        ### end section
	listen()
except Exception,e:
	logging.error('Fatal error : '+str(e))
	shutdown()

Avec ca, regarde les lignes 80 à 100 c’est assez intuitif je pense, tu verras comment cela fonctionne pour la config du port etc.
ton code existant sera exécuté dans le thread séparé et avec la méthode ‹ listen() › il écoutera sur le port configuré un peu plus haut.

Dans la méthode def read_socket(): (ligne 35) tu dois coder les actions que tu veux réaliser lors de la réception d’un message (et tu peux en avoir plusieurs pour plusieurs actions); tu gardes le check sur l’apikey ou pas selon le niv de sécu que tu veux et tu adaptes le code dans le try (à la place du print ‹ read ›):

		try:
			print 'read'
		except Exception, e:
			logging.error('Send command to demon error : '+str(e))

Il n’y aura plus qu’à avoir un script sur ton jeedom qui s’y connecte et envoi l’ordre que tu veux.

[pierbout]

Merci!

[naboleo]

Sinon, jeedom de chaque coté, jeelink pour faire le lien entre les deux et le plugin script coté piscine…
L’avantage, ça permet de faire plein d’autres choses, comme par exemple recupérer aussi les informations et pas seulement déclencher une action à distance.
Par contre, c’est pas forcement plus léger

[pierbout]

Merci Naboleo

Mais à ce compte là, autant tout regrouper sur un seul Raspberry
Pour le moment, je suis sur une architecture en 2 raspberry, ce qui me permet de me contenter d’un Pi Zero dans le local technique (chauffe beaucoup moins que le Pi4 de Jeedom, ce qui me semble préférable dans un caisson étanche, mais insuffisant semble t’il pour Jeedom)

Mais peut-être ferais-je machine arrière au final…

[naboleo]

Oui comme je le disais cette solution n’est pas forcement la plus légère…
Cependant, quelques précisions :

• vu le faible nombre de plugin, un pi0 peut probablement s’en sortir. En tout cas, c’est pas indispensable de monter jusqu’au pi4… un 2 ou 3 feront l’affaire.
• « Graphiquement parlant » c’est effectivement comme si tu n’avais qu’un seul système… mais à la différence de la centralisation sur seul pi, ça te dispense de refaire ton câblage (toutes tes sondes de collecte). ça dépend surtout de ton organisation mais si le local technique est à l’autre bout du jardin, c’est pas pareil que dans la pièce voisine.
• Si aujourd’hui ton besoin est d’1 seule action, admettons… A partir de 2 ou plus la question se pose nettement plus sérieusement, car ça présente l’avantage de ne rien avoir à coder…

[Mips]

Il va quand meme devoir coder ses actions dans un script sur son 2eme jeedom.
Je ne comprend pas ou est le gain j’avoue (a part que ok, c’est plus simple d’installer un jeedom que de coder son « démon »)

[Patrick57]

Bonjour,
Dans mon programme Python (RPI 3), toutes les minutes j’interroge Jeedom (RPI 4) avec le code ci-dessous, puis je l’envoi vers mon automate Siemens (gestion des volets en filaire).
Pour ce genre de commande je ne suis pas pressé.
payload = {‹ plugin ›: ‹ virtual ›, ‹ apikey ›: "xxxxxxx , ‹ type ›: ‹ cmd ›, ‹ id › : 686 }
r = requests.get(« http://192.168.1.11/core/api/jeeApi.php », params=payload)
if r.text == ‹ 1 ›: Auto_Manu_Volets=1
else: Auto_Manu_Volets=0

• j’attends le plugin Mymodbus pour faire un essai et éventuellement passer directement de Jeedom à Siemens en TCP IP.
  @Bebel27

[naboleo]

@Mips
Dans les 2 cas, il va falloir coder les actions… Par contre lancer un script python (localement) depuis jeedom c’est 15 secondes à configurer…
Et en terme d’ouverture et de fonctionnement, ça n’a rien à voir… ça reste indépendant… Ton jeedom principal se casse la gueule (ou ton wifi), ben le système de ta piscine peut encore fonctionner. Si tes actions sont déclenchées par ton unique jeedom il ne se passera rien…

[pierbout]

En tout cas je vois que le sujet fait débat!

Merci à vous deux d’être aussi réactifs

[naboleo]

Oui, débat car c’est un choix fonctionnel… mais pour le coup, il n’y a que toi qui sait exactement ce dont tu as besoin

[pierbout]

Merci Patrick. Ca correspond à la seconde solution que j’évoquais, en effet.

[pierbout]

Mon besoin:

• simple, stable, et qui ne demande pas 5 jours de mise en place .
• que mon raspberry coté piscine ne soit pas sur-sollicité (car ca fait chauffer)
• que ma piscine fonctionne même si j’ai une coupure réseau
• c’est pour un usage privé
• Un temps de latence de quelques secondes est parfaitement acceptable.

Toutes ces solutions mènent, je pense, au résultat escompté. Le socket me plait bien, même si c’est surdimentionné pour l’usage que je vais en faire (je n’ai pas besoin d’un dialogue en temps réel…)

Le fichier de flag serait suffisant mais pas élégant

Je creuse…

[naboleo]

Oui… Allez, une solution de plus pour remettre 100€ dans la machine… :
-Ton jeedom, exécute le python à distance à travers ssh par exemple…
Pour le fun, voilà comment je mets à jour un octopi chez moi

sshpass -p "password" ssh pi@192.168.1.xx 'sudo apt-get -y update && sudo apt-get -y upgrade && sudo apt-get -y dist-upgrade && sudo apt-get -y auto-clean && sudo apt-get -y autoremove &&exit'

Coté PI0 ça rajoute rien de supplémentaire que le strict nécessaire…

[pierbout]

@Naboleo : Si je te suis, le script reste sur le piZéro mais est exécuté depuis le Pi4, via ssh. C’est ca?

Si oui, ca permet de relancer le script s’il plante, mais pour le sujet actuel (envoi d’un ordre), je ne vois pas ce que ca apporte (mais je suis peut-être à coté de la plaque…)

Pour info, mon programme python tourne en permanance (dès démarrage du piZéro)

[naboleo]

@pierbout

@Naboleo : Si je te suis, le script reste sur le piZéro mais est exécuté depuis le Pi4, via ssh. C’est ca?

Oui c’est le principe… Il faut juste comprendre qu’une fois le lien coupé, les processus fils disparaissent.

Après sans connaitre ton script, c’est difficile de proposer la solution clé en main, mais les possibilités sont quasi infinies.
Si on reprends l’idée d’un flag fichier : tu fais (à la place du « sudo … »)

touch /home/pi/monfichier && exit

Si tu veux arrêter le script python en cours, le lancer avec d’autres paramétres. Tu enchaines un kill, un lancement (avec nohup si besoin d’une persistence) et exit…

Bref… tout ce que tu ferai manuellement depuis ta console ssh, est faisable automatiquement
Dans le cas du fichier, tu peux aussi te servir d’un bête « scp » (aka copie à distance)

[pierbout]

@naboleo : un touch via ssh, c’est ce à quoi je pensais en première instance. Pas beau mais efficace.

[naboleo]

c’est vrai que le touch c’est moche (de toute façon le flag fichier c’est moche à la base), autant faire un scp
mais bon, pas besoin de réinventer la roue…

Comme ça tu as toutes la panoplie des solutions de la 2CV à la Rolls