Bonjour, alors oui je n’ai pas tout suivi mais malgré les maj j’ai moi aussi l’erreur
Erreur sur Monitoring::pull() : Class ‹ phpseclib\Net\SSH2 › not found.
je vois qu’il y a une nouvelle maj mais j’hésite à la faire si le résulat est pire
pour le moment le désactive ce plugin (j 'étais en version stable 2023-10-17)
Je suis d’accord et cest pr cela que je testz sur une vm avec une restaure de prod.
Apres on ne peut pas demander a touq les beta testeurs dacheter tous les plugins.
Enfin pour qui a un pc ou un mac, creer un vm, installer debian, jeedom restaurer un backup et participer a cette communauté est tellement facile que je ne comprends pas plus de monde ne s’investit pas, ca leur ferait en plus une pre prod.
Si Jeedom SAS veux des bêtas testeurs ils pourraient acheter les plugins à ceux-ci pour que les bêtas testeurs puissent avoir un gros panel de plugins 
4 « J'aime »
Moi je comprends bien pourquoi y a pas beaucoup de gens qui s’investissent … surtout quand je regarde rien que le parcours du combattant que je dois faire ici pour avoir au salon beta testeurs … 2 mois et toujours pas en ordre … pffff … t’installes ta beta, tu vois des trucs qui doivent être fixés, mais t’as pas le droit de poster pour dire qu’il y a un soucis … malgré que t’as le profil commu « Beta Testeur » … oké quoi … logique que le feedback vient pas 
Après, des fois aussi, je vois que des gens rapportent sur la communauté des observations de choses qu’ils pensent etre des bugs ou des défauts, et ils se font houspiller comme des malpropres par des mecs qui pensent être issus de la cuisse de Jupiter … faut le reconnaitre, ça met pas spécialement l’ambiance …
Après moi je dis ça …
2 « J'aime »
ca part de nouveau hors sujet ici…
mais bref, je vois pas le rapport avec le salon beta-testeurs, ok ca serait « mieux » mais rien n’empêche de créer un post dans le salon « public » au pire si vmt il y a des choses à dire
donc y a moyen de « moins » dire et « plus » faire (oui, je houspille)
Dc on va allonger le temps de beta test pour etre sur de couvrir tt les cas et ainsi limiter au max les soucis lors d update de nouvelles versions stables.
Mais du coup on va voir d autres users hurler que ca ne bougent pas pr le fix d’un petit bug qu il faut attendre des plombes.
Question débile probablement, mais je me lance.
Je suis pas expert en Linux, dans mes souvenirs de mes classes (y a 15 ans), je me souviens que c’était pas possible de faire cohabiter deux versions de dépendences en //.
C’est toujours le cas à l’heure actuelle ?
Autre truc que je me demande, ces dépendances, on saurait pas les résoudre d’une autre manière ? Genre un peu comme c’est fait en .NET avec les packages Nuget. Chaque assembly embarque sa propre version des dépendances … je dirais que ça règlerait le problème … après, aucune idée en environnement Linux si c’est possible, et je suis pas assez calé en PHP pour oser affirmer quoi que ce soit.
Bonsoir.
L’auteur de plugin est bien présent sur le forum avec un autre pseudo.
Bien qu’il y ai effectivement des successions de problèmes récemment, l’auteur est bien actif sur son dépôt. On le voit avec les tentatives de correction en cours. Je pense qu’il est inutile de lui mettre la pression.
Respect à lui.
Le vrai problème est le manque de branche bêta et de personnes volontaires, comme toi, pour réaliser les tests
C’est une bonne nouvelle alors.
Courage à lui.
Ah je ne le blame pas.
Loun de moi lidee de mettre une pression
Bonsoir,
On aurait commencé par cette information on aurait gagné du temps et évité de s’invectiver entre nous 
Alors je ne sais pas qui c’est mais je suis à sa dispo pour tester dans la mesure de mes compétences donc en très grand béta testeur 
et je ne connais rien au codage.
J’ai une jeedom de test avec monitoring et nut free,
2 « J'aime »
Un des trucs qu’on m’a appris pendant mes études d’ingénierie logicielle : le temps n’est jamais une excuse pour livrer un truc qui ne fonctionne pas.
Vu le feedback ci dessus, crois moi que les gens préfèreraient ne pas se demander si ils vont passer la nuit à réparer leur setup suite à l’installation d’une version foireuse quelconque.
Sans trop donner de détails, je bosse au gouvernement sur tout le backend qui gère les pensions en Belgique … je peux te dire qu’ils préfèrent rester avec des minor bug pendant deux semaines de plus plutot qu’on aille foirer le setup et tout mettre à plat ou perdre les données … t’imagines le bazar … ah tkt ça serait dans les journaux.
Je vois pas trop non plus en quoi c’est complexe d’avoir une plateforme qu’on déploie à l’issue d’un build / release et qu’on Sanity Check juste pour déjà voir si des Smoke Tests basiques passent.
Exemple : déploiement, lancement du test, reboot jeedom, lancement du test → si tu te ramasses erreur 500 à la webrequest suivante, je crois que la release devrait pas atteindre le stable … peut-être meme pas dépasser le stade de l’alpha …maintenant de ce que j’en ai vu quand je me suis intéressé dans le DEV de plugin ici, y a pas d’environnement de prestaging genre alpha qui est prévu pour les plugins tiers dans le but de faire des smoke tests … je me trompe peut être
1 « J'aime »
Bonsoir,
Je penses que ca part dans tous les sens.
Quand Nut_free a été corrigé la première fois, et que les utilisateurs de Monitoring ont intégré la même solution, il n’y a jamais eu de problèmes.
Donc dire aujourd’hui que d’utiliser la même manière dans le code est un problème, c’est prématuré. Le problème vient des mises à jour de monitoring, mais faut tracer quoi exactement.
Sur ma prod aujourd’hui encore les deux plugins ont le même code et je n’ai pas de problèmes.
Pour moi il y a un autre sujet.
Et si le sujet est debian 12,il faut une machine par versions de debian, avec tous les plugins… Pour pouvoir valider!
Et si on reprend le post ici: SSH KO vers machine en debian 12 (algorithme ssh du plugin trop faible) - #36 par benj29
Et le code posté était aussi:
Ca fonctionne!
Ensuite comment tester vue qu’il y a des plugin payants? Que perso je n’utilise pas.
Cordialement,
Stéphane.
La dessus 100% d’accord. Je vois pas comment vérifier autrement, pour l’instant en tous cas, si y a des clash entre plugins ou des soucis de dépendances.
1 « J'aime »
Bonsoir à tous,
je suis désolé de ne pas comprendre ce qui apporte autant de problème :
- tout allait bien, jusqu’à avant la version antérieure du plugin ‹ Monitoring ›
- et depuis ce changement, il y a des problèmes de plusieurs sortent avec ou pas d’autres plugins
Je ne suis pas développeur (bien au contraire 
) mais sauf erreur, la source des problèmes est ‹ uniquement › sur les lignes de programme qui ont été ajoutés/modifiés/supprimés.
C’est peut être ce qu’a dit @Stel74 
Je vois qu’il y a beaucoup de compétences et de personnes impliquées dans les différents échanges et à priori, aussi un problème d’accès au salon beta-testeurs.
En attendant que l’épisode salon beta-testeurs ne soit résolue (de ce que je comprends , ce serait aussi nécessaire), et comme le propose @Mips , peut être que l’auteur des changes pourrait partager - sur ce fil par exemple - sur les modifications apportées pour rendre ce plugin compatible debian 12 
Cà pourrait j’espère permettre d’amener des idées / conseil… de la part de la communauté des développeurs pleine de bonne volonté 
Pour ma part, l’objectif général est de préserver les utilisateurs lambda que je suis de plantages de leur Jeedom (surtout sur une version stable).
Nota: comme l’a aussi écrit @fleproust, il serait effectivement souhaitable de retirer cette mise à jour du stable avant que d’autres utilisateurs actuels du plugin et aussi futurs (nouveau téléchargement du plugin stable) se retrouvent avec des difficultés qu’ils ne sauront pas forcément traiter.
En vous remerciant de penser à la communauté Jeedom
J’ai pas regardé ce qui est en stable.
Mais sur le github:
Sur la version du 13 octobre c’etait bon!
Mais le 16 il a modifié! et paf!
Et le 17 retour en arrière:
…
Je viens de jouer!
J’avais la version du 13 octobre et je viens de passer à celle du 18 octobre. La dernière version stable.
0 problèmes. Donc pourquoi enlever la dernière version?
J’ai sauté la version du 16! Qui elle est foireuse! Enlever la dernière version stable veut dire revenir à la version du 16, celle qui fait tout planter! Heuuuuuuuu Non!
Stef.
Bonjour,
Il semble y avoir une confusion persistante au sujet de Debian 12, en dépit des rappels de @Mips.
La mise à jour de monitoring n’était pas pour que le plugin fonctionne sur une Debian 12 (Jeedom n’est pas pour le moment considéré comme compatible Debian 12). Mais plutôt pour que le plugin puisse monitorer des systèmes sous Debian 12 (Proxmox 8 par exemple).
Voir la demande initiale de cette modification ici :
1 « J'aime »
Oui c’est bien cela. Merci de le rappeler apres Mips car a priori ce n’est pas encore percu de tous.
Quant a la compatibilité du plugin avec deb12, mes premiers tests avec le core alpha 4.4 n’avaient pas mis en evidence un comportement anormal
Dc c’est pas la peine de s’emballer.
Perso qd j’ai debuté, je mettai a jour plusieurs jours apres en vherchant pr voir si y avaient des soucis. Je laissais les autres essuyer les plâtres.
Certains a la domotique sensible devraient faire de meme
