Bonsoir @Mips ,
J’ai quelques retours sur la mise en oeuvre de la lib jeedomdaemon 0.9.8 sur laquelle j’ai pas mal travaillé ces derniers jours.
Comme je ne peux ouvrir un nouveau sujet avec toi, tu veux que nous continuions sur ce fil ou tu m’envoies un message en MP pour partir sur un nouveau fil ?
Salut,
J’ai déplacé le message dans un nouveau sujet. Je pense qu’on peut continuer ici si ca peut être utile à quelqu’un d’autre mais s’il doit y avoir quelque chose de confidentiel dis moi et on voit en privé
Bonjour,
Donc, ta lib jeedomdaemon est maintenant intégrée à mon dernier plugin SomfyUnified et je dis de nouveau que c’est un plaisir et très facile d’implémenter un Daemon avec cet utilitaire.
Encore merci pour nous fournir cela.
/**
* SomfyUnified
*
* @author Eridani78
* @version 1.1.0 2024 06 26
*
* Credits
* dependance.lib: @Mips2648, @TiTidom-RC
* jeedomdaemon: @Mips
* pyenv.lib: @NebzHB
*
* Description: Plugin main class.
*
* File: SomfyUnified.class.php
*/
J’aimerais néanmoins faire quelques retours qui ne sont pas tous de la même importance et que je livre ici un peu en vrac:
aio_connector.py ligne 48
Le message Log envoyé systématiquement par cette ligne est certe interessant mais peut contenir parmi d’autres informations des données sensibles utilisateur (username, userpassword) qui sont transmises au démon.
Cela me pose pour le moment un soucis.
Je m’aperçois en écrivant ces lignes qu’il y a peut être moyen d’envoyer ces données sensibles sous forme d’arguments. A creuser. Ton avis ?
aio_connector.py ligne 79
Le check réalisé par cette routine conduit à la récéption par la fonction de callback du message ""
Contrairement à tous les autres messages qui sont au format JSON, celui-ci ne l’est pas et cela peut demander un traitement un peu spécifique.
Ce n’est pas très compliqué et je je gère. C’est juste pour info.
aio_connector.py ligne 92
Ce message Log level info n’est, à mon sens pas très important et pourrait être passé en level debug pour ne pas trop surcharger le fil des log Info.
C’est juste mon avis.
base_daemon.py ligne 133
Que veux tu dire par outstanding tasks ? Tu ne voulais pas dire ongoing tasks plutot ?
Et pour terminer, plus embêtant pour moi … ce message d’erreur
ERROR : Fatal error: [Errno 98] error while attempting to bind on address ('::1', 55080, 0, 0): address already in use(<class 'OSError'>) in /var/www/html/plugins/SomfyUnified/py_venv/lib/python3.11/site-packages/jeedomdaemon/base_daemon.py on line 87
J’obtiens ce message d’erreur lorsque j’active Gestion Automatique du démon.
De mon coté, il faut savoir que je synchronise mon Daemon avec le cron10 (lance la routine deamon_start() de la class SomfyUnified toutes les 10 mn).
Je suis conscient que ce n’est pas un problème directement liée à jeedomdaemon.
Mais j’avoue que j’aimerais bien l’éradiquer et je ne sais pas trop comment pour le moment. Une idée ?
Voila pour mes quelques retours.
A ta disposition si tu souhaites quelques infos complémentaires pour le point 5).
D’avance merci.
re salut,
encore merci 
après quelques années de dev de plugin à en avoir marre de copier/coller le même code partout, j’ai fait ca pour moi, encore mieux si ca sert à d’autres 
c’est l’inverse 
* dependance.lib: @NebzHB
* pyenv.lib: @Mips2648, @TiTidom-RC
c’est pas faux, et en règle générale, déformation pro, j’ai plutôt comme principe qu’on ne peut jamais log des données sensibles, il n’y a jamais aucune excuse valide pour ça
… mais ( 
) ca reste un environnement « home », en principe seule la personne autorisée voit l’info (où alors c’est déjà trop tard et l’info sera visible ailleurs) (sauf en cas de copie du log sur le forum, je reconnais) et si on doit debug on a parfois besoin de cette info
bref, si je veux suivre la bonne pratique, je devrais juste virer ce log, chaque dev est libre de faire le log qu’il veut dans le « on_message »; c’est probablement ce que je vais faire si pas d’autres solutions propres
=> je ne vois pas trop ce que tu veux dire par « envoyer ces données sensibles sous forme d’arguments »?
tu parles coté php pour le message « » ? je ne comprend pas trop ce que tu veux dire en fait
effectivement ce call là est fait en GET alors que les autres c’est du POST, c’est çà le soucis?
ce log n’apparait qu’une seule fois et permet d’avoir l’info sur la valeur de cycle plus confirmer que la tache en question est bien lancée; c’est le genre « d’info » que je laisse en info: les start/stop/load etc qui ne se répète pas en boucle => je vais le laisser comme ca celui là
c’est sémantique ici mais c’est « outstanding » dans le sens « l’encours » (peut-être qu’on ne peut pas utiliser ce mot dans un contexte IT?), les taches ne sont pas forcément « ongoing », il se peut qu’elles soient en attentes, sleep ou autre, donc c’est pas vraiment « ongoing » non plus
je peux juste modifier le log en disant « all tasks » si ca permet à tout le monde de mieux dormir 
tu dis que tu là si tu actives la gestion auto, c’est pcq alors le core va essayer de lancer le démon s’il est arrêté toutes les 5min;
mais si tu lances le démon à un autre moment, alors tu as p-e deux démons qui tournent et donc le port socket est déjà utilisé
Pour les Credits, c’est corrigé 
Durant la vie du plugin, et surtout au début, la demande des Logs est incontournable pour répondre aux multiples solicitations des utilisateurs qui rencontrent une difficulté.
En général, le username et le userpassword sont d’aucune utilité pour comprendre le problème mais ca peut géner l’envoi des logs et c’est très compréhensible, même des envois en MP comme je demande toujours.
Il me semble que laisser le dev gérer ce retour d’info est le mieux.
Oui, ca peut être en utilisant le on_message sauf si tu sait mettre un flag à cocher quelque part puisque le dev n’a pas accès au code (lib).
Oui je parles coté PHP. Je sais que le test est un GET mais la fonction de callback (en PHP) est déclenchée et reçois un message « ».
Je disais juste que le message reçu n’est pas JSON contrairement à tous les autres messages.
C’était pour soulever ce point mais ce n’est vraiement pas important.
C’est toi le boss
Je comprend mieux et de nouveau, c’est toi le boss
Un démon, c’est une machine d’état.
Si il tourne 10 mn, c’est l’éternité par rapport à une tache logiciel qui prend quelques millisecondes.
Et du coup, déformation professionnelle également, une machine d’état, ca se resynchronize régulièrement en repartant d’un état origine stable …
Quand je re-lance le démon via le cron10, il est d’abord arrêté puisque deamon_stop est une instruction au début de la routine deamon_start().
En fait, je n’ai jamais très bien compris l’utilité de cette fonction Jeedom Gestion Automatique du démon.
Je pense que je n’en ai pas besoin et j’aimerais bien la désactiver par le plugin.
Je ne sais pas encore comment mais je vais regarder.
pour le 2 typiquement j’ai ce genre de code donc je ne m’occupe pas du payload, je regarde juste si j’ai un paramètre test (après le check sur apikey):
...
if (init('test') != '') {
echo 'OK';
log::add(xxx, 'debug', 'test from daemon');
die();
}
$result = json_decode(file_get_contents("php://input"), true);
if (!is_array($result)) {
die();
} else {
...
pour conclure sur le 5, pcq effectivement c’est un peu hors sujet et je ne voulais pas lancer un débat sur ce qu’est un « démon », ca gêne de le laisser tourner?
ca correspond p-e pas à ta définition d’un démon (de nouveau sans juger si c’est mieux ou moins bien ni sans en faire un débat) mais c’est comme ca que c’est prévu sous jeedom.
et c’est p-e pas ton cas ici mais parfois, on a besoin de laisser tourner en permanence: si tu est connecté à un système distant, généralement ils n’aiment pas trop avoir des déco/reco toutes les 10mins, ca arrive qu’on atteigne des limites de nombre de requêtes etc
et pareil si tu as un websocket ouvert par exemple, déco/reco tout le temps c’est pas super
sinon pour désactiver:
$plugin = plugin::byId(xxx);
$plugin->deamon_changeAutoMode(0);
Pour conclure ce chapitre, je te remercie pour tes réponses.
Ce type d’échange aide toujours.
Du coup, je viens donc d’éditer une version aboutie de mon plugin SomfyUnified en stable qui intègre tout cela en synthèse.
Bonne soirée
Nouvelles versions 0.10.1 dispo avec les changements discutés
Il est probable que je fasse bientôt une version 1.0.0 juste pour confirmer que c’est stable mais il n’y aura pas de breaking change avec les versions 0.x
Merci du retour
Oui je pense que dans l’état, ca mérite bien le label: stable 1.0.0 
Je vais tester ça prochainement. Je voulais d’abord actualiser mon infra mais un des 3 mini-PC est HS et la carte mère est en train de voyager pour un retour sous garantie, donc ça va prendre du temps. Bref…
Si j’ai des questions/remarques je ferai un fil dédié. Ce serait d’ailleurs pas mal de demander la création d’un tag pour cette bibliothèque.
on verra si vmt besoin, ca pourrait être utile pour rechercher dans les sujets existants mais faut déjà qu’il y en ai
pour ce qui est des notifs, en principe ca va être utilisé par les devs donc si question le mieux est de poster la catégorie ici, dans Aide Programmation, et j’ai déjà mis en surveillance la catégorie donc je sera notifié de toute façon.