ok.
dans ton premier log, on dirait que tu n’as que 2 commandes info… le plugin fait ca correctement et liste toutes les commandes info dans ton equipement, ensuite pour chacune, il assigne la valeur… on voit bien que la valeur est là
[2020-01-26 12:39:38][DEBUG] : Get information key STATUS with value ONLINE
par contre après on ne voit pas :
Update command status
donc la commande n’existe pas à cet instant.
Ouais c’est ça. Sauf que les commandes sont bien là dans l’équipement.
Ça rejoint ce que je disais plus haut :
D’après le code du plugin ça me semble impossible que les commandes soient là… la fonction vient du core et liste bien toutes les commandes chez moi…
Je soupçonne un second problème comme ton premier… bref ton système… donc difficile de t’aider dans ces conditions …
Réinstalle , repart de zéro probablement car tu as des problèmes de fond…
Oui c’est ce que je pensais aussi du coup j’ai complétement réinstallé. Sauf que j’ai le même problème.
J’avais pas de problème avec ce plugin en V3 et sur RPi3. Je vais tenter sur un autre matériel pour voir même si je n’y crois pas trop.
@nebz Comment as-tu utilisé ce plugin avec ton onduleur ?
Installation du plugin, Création de l’équipement, Branchement de l’onduleur
OU
Installation du plugin, Branchement de l’onduleur, Création de l’équipement
?
Oh je ne me rappelle plus, ça tourne depuis tellement longtemps… j’ai même deux jeedom qui via apcupsd communiquent avec le même onduleur via le réseau donc c’est super fonctionnel !!!
Le seul problème que j’ai déjà eu c’est l’ups qui deconne et j’ai du vider la batterie pour qu’il s’éteigne et puis redémarrer tout et c’est repassé
Après de nouveaux tests, je réponds à ma question. C’est forcément : Installation, branchement de l’onduleur et création sinon tu as un message d’erreur du plugin qui renvoie :
Je vais essayer de refaire un GIF du problème.
Dans tous tes tests, ce qui ne change jamais c’est ton rpi… t’as rien d’autre sous le coude ?
Et sinon mon autre proposition, viser l’ups
Bref là je suis à bout d’idées… ce qui fonctionne chez moi ne fonctionne pas chez toi malgré que le code soit le même (et que j’ai verifie Son fonctionnement qui est parfait)… c’est forcément qqch chez toi… ou sur ton système… quand tu as reinstallé, tu as restauré une image jeedom je suppose, donc tu as pu restaurer ton problème…
Ce qui ne varie pas c’est mon Intel NUC et l’UPS
J’ai quand même les bonnes infos avec la commande sous Linux
Non justement j’ai pas restauré j’ai fait sur une installation neuve, nouvelle ISO debian, pas de restauration, juste ce plugin.
Oui moi aussi je suis à court d’idées, c’est pour çà que je vais passer par un script maison et un virtuel en attendant. Ça ne remet pas en question le plugin de @lunarok qui est top comme le reste de ses plugins 
Mais je semble être le seul à avoir ce problème donc ça doit venir de ma config.
Voilà j’ai fait une nouvelle vidéo du problème (voir ci-dessous).
Lors de ce test, l’onduleur est branché en USB sur la machine (Intel NUC) Jeedom v4.
J’ai désinstallé le plugin et désinstallé l’outil apcupsd avant la vidéo.
Dans la vidéo j’installe le plugin puis les dépendances. Je vérifie la communication de l’onduleur via la commande Linux, c’est OK. Je créé l’équipement, j’ai une première erreur « L'adresse ne peut être vide ». Je sauvegarde l’équipement, j’ai alors un Timeout (la roue tourne pendant 2 minutes) puis une nouvelle erreur « 500 : Internal Server Error ». Dans le http.error on voit l’erreur de mémoire liée au Timeout. Dans le log apcups on voit bien que les infos remontent mais que les Updates ne se font pas correctement. Je vais vérifier l’équipement et les commandes. On voit que ce n’est pas fonctionnel. Je test en SSH, la commande renvoie bien les bonnes valeurs.
Rafraichissement, on voit que l’équipement est créé, les commandes aussi. Test des commandes de l’équipement = NOK
Vidéo lorsque le plugin est non fonctionnel :
@lunarok @nebz J’ai trouvé une très bonne piste sur l’ancien forum :
https://forum.jeedom.com/viewtopic.php?f=144&t=6598&start=760#p747783
Et effectivement en commentant la ligne (205) $this->updateCommands(); de la fonction postSave()
dans le fichier apcups.class.php je n’ai plus le problème. Au contraire tout est rentré dans l’ordre.
Du coup après avoir commenté la ligne il faut désactiver / réactiver le plugin. Relancer l’installation des dépendances. Supprimer l’équipement onduleur et en recréer un. Attendre que le CRON s’effectue et là tout est OK. Voir vidéo ci-dessous.
Vidéo lorsque le plugin est fonctionnel :
Enfin, un détail mais la date de dernière installation des dépendances reste toujours à « Inconnue ».
Voilà je pense avoir donné toutes les informations concernant mon problème. Qui visiblement a été rencontré par d’autres.
A dispo pour d’autres tests si nécessaire.
Voilà, j’ai effectué le dernier test que je voulais faire. J’ai installé une Raspbian Stretch sur un RPi3 avec Jeedom v4 tout neuf.
J’ai testé le plugin avec mon onduleur APC Back-UPS ES - BE700G-FR et j’ai les mêmes problèmes que sur ma machine Intel NUC.
A ce stade j’ai terminé tous les tests que je voulais faire et mon hypothèse est la suivante : mon modèle d’onduleur à un problème de compatibilité avec le plugin. Je m’explique, le plugin fonctionne parfaitement pour certains mais pour d’autres dont moi on rencontre les mêmes problèmes (cf. [Plugin Tiers][Sujet Principal] APC-UPS - Page 39 - Forum Communauté Jeedom). La solution à nos problèmes est de commenter la ligne (205) $this->updateCommands(); de la fonction postSave() dans le fichier apcups.class.php. Cette ligne semble provoquer chez nous une boucle infinie, d’où le TimeOut que j’ai à la sauvegarde de l’équipement, suivi de l’erreur 500.
Au début j’avais pensé à un problème de communication avec mon onduleur mais cela a vite été écarté puisque la commande Linux /sbin/apcaccess status 127.0.0.1:3551 renvoie toujours de bonnes valeurs y compris quand le plugin est non fonctionnel. D’ailleurs dans les logs Debug du plugin on voit bien que la commande renvoie les bonnes valeurs mais que l’Update ne se fait pas correctement.
@lunarok : à l’occasion si tu as le temps, peux-tu nous donner ton analyse sur notre bidouille qui consiste à supprimer la ligne $this->updateCommands(); pour régler nos problèmes. J’aimerai bien ne pas avoir à bidouiller ton plugin à chacune de ses mises à jour. D’avance merci.
@nebz : Je ne sais pas si tu as fait des tests de ton côté suite à mon post, mais si c’est le cas, as-tu supprimé et recréé un équipement de type onduleur USB pour voir si tu avais le problème ?
Je reste dispo si vous souhaitez me faire tester des choses. Et merci @nebz d’avoir pris le temps
Non pas fait plus de tests, c’est sur ma prod j’y touche pas
Après avoir lu le code je ne comprends pas que commenter cette ligne résolve ton problème…
Oui moi non plus et pourtant tout fonctionne parfaitement après. J’ai essayé de tout montrer dans les vidéos pour être exhaustif et que ce soit plus factuel.
Bonjour,
@lunarok je pense avoir trouvé:
Donc on a déjà tous vu que lors du postSave il lance le updateCommands.
Cette fonction exécute (selon le if) un $this->batteryStatus($value); ligne 301.
Hors, depuis la 3.3.24 du core (https://jeedom.github.io/core/fr_FR/changelog#tocAnchor-1-17), lors d’une mise à jours de la batterie, le core met à jour la date de charge (sous conditions);
fonction eqlogic->batteryStatus, ligne 1099
if($_pourcent > 90 && $_pourcent > ($this->getStatus('battery',0)*1.1)){
$this->setConfiguration('batterytime',date('Y-m-d H:i:s'));
$this->save();
}
Et bien sur le $this->save(); déclenche le postSave
On pourrait croire qu’au pire cela ne le fera que 2 fois mais ca boucle parce que la condition sur le getStatus reste valide les fois d’après car le setStatus est fait à la dernière ligne de cette fonction, ligne 1163.
Comme c’est un « nouveau » comportement du core, voilà pourquoi cela ne se produit que pour les nouvelles install!
mais en théorie cela se produirait aussi sur une install existante si l’onduleur était déchargé et rechargé très rapidement: 10% de charge en moins d’une minute, ce qui est peu probable.
Alors pour fixer cela, c’est pas si simple, car c’est le serpent qui se mange la queue.
Soit @loic on fixe dans eqLogic:
setstatus)setstatus on stock l’ancienne valeur de 'battery' dans une variablegetstatus, ca évitera la boucle, au tour suivant la batterie aura déjà été mise à jours.Soit @lunarok dans le plugin:
updateCommands mais sans mise à jour de la batterie si on vient du postsave (argument a rajouter dans la fonction)updatecommands du postsave et tout le monde n’a qu’à attendre le run du premier cron… cette dernière solution étant la plus simple, acceptable à mes yeux mais pas structurelles: d’autres plugin vont rencontrer le même problème.Les propositions ci-dessus ne sont là que dans un but constructif d’apporter des solutions, il y en a certainement d’autres.
Bonjour,
Ca sera corrigé dans les prochaine version stable de jeedom (la correction est en alpha,beta,release). merci pour l’analyse et la remonté du soucis
Merci, j’avais loupé la possibilité du direct dans le save 
Merci @Mips pour ton analyse et merci à @Loic pour la future modif.
Ça me rassure j’ai pas fumé la moquette et c’est pas le père noël non plus
Je vous confirme que suite aux MAJ du Core en 4.0.40 je n’ai plus le problème. Merci.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.