j’y ai passé la nuit alors la patience j’en ai
C’est normal que tout ça ne se remonte pas seul quand on fait une restauration de jeedom ?
Bon j’y vais je commence, des nouvelles dans quelques minutes … heures …
Merci du coup de main
Oui c’est normal car ce sont des librairies installées sur le système.
Plutôt que de tout faire à la main, tu peux aussi essayer de remplacer le contenu de /var/www/html/plugin/zigbee/resources/install_apt.sh par ça et relancer les dépendances pour voir 
:
PROGRESS_FILE=/tmp/dependancy_zigbee_in_progress
if [ ! -z $1 ]; then
PROGRESS_FILE=$1
fi
touch ${PROGRESS_FILE}
echo 0 > ${PROGRESS_FILE}
echo "Launch install of zigbee dependancy"
BASEDIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
sudo apt-get clean
sudo apt-get update
echo 5 > ${PROGRESS_FILE}
sudo apt remove -y RPi.GPIO 2> /dev/null
sudo rm -rf /usr/local/lib/python3.7/dist-packages/zhaquirks
sudo rm -rf /usr/local/lib/python3.7/dist-packages/zigpy*
sudo rm -rf /usr/local/lib/python3.7/dist-packages/bellows*
sudo rm -rf /var/www/.local/lib/python3.7/site-packages/zigpy*
sudo rm -rf /var/www/.local/lib/python3.7/site-packages/bellows*
sudo apt remove -y rustc
sudo apt remove -y cargo
sudo curl -o rustup.sh -sSf https://sh.rustup.rs
sudo chmod +x rustup.sh
echo 15 > ${PROGRESS_FILE}
sudo ./rustup.sh -y
sudo rm rustup.sh
sudo ln -s /root/.cargo/bin/rustc /usr/bin/rustc
sudo ln -s /root/.cargo/bin/cargo /usr/bin/cargo
echo 50 > ${PROGRESS_FILE}
sudo pip3 install --force-reinstall --upgrade setuptools
sudo pip3 install --force-reinstall --upgrade wheel
sudo pip3 install --force-reinstall --upgrade six
sudo pip3 install --force-reinstall --upgrade pyudev
sudo pip3 install --force-reinstall --upgrade requests
sudo pip3 install --force-reinstall --upgrade pyserial
sudo pip3 install --force-reinstall --upgrade tornado
sudo pip3 install --force-reinstall --upgrade zha-quirks==0.0.80
sudo pip3 install --force-reinstall --upgrade zigpy-znp==0.8.2
sudo pip3 install --force-reinstall --upgrade zigpy-xbee==0.15.0
sudo pip3 install --force-reinstall --upgrade zigpy-deconz==0.18.1
sudo pip3 install --force-reinstall --upgrade zigpy-zigate==0.9.2
sudo pip3 install --force-reinstall --upgrade bellows==0.33.1
sudo pip3 install --force-reinstall --upgrade zigpy==0.50.3
sudo pip3 install --force-reinstall --upgrade xmodem
sudo pip3 install --force-reinstall --upgrade pycrypto
sudo pip3 install --force-reinstall --upgrade charset-normalizer==2.0.12
sudo pip3 install --force-reinstall --upgrade yarl==1.4.2
echo 90 > ${PROGRESS_FILE}
if [ $(grep gpepIncomingMessageHandler /usr/local/lib/python3.7/dist-packages/bellows/zigbee/application.py -c) -eq 0 ]; then
patch -N /usr/local/lib/python3.7/dist-packages/bellows/zigbee/application.py ${BASEDIR}/misc/zgp.bellows.application.patch
patch -N /usr/local/lib/python3.7/dist-packages/bellows/ezsp/v8/commands.py ${BASEDIR}/misc/zgp.bellows.v8.commands.patch
fi
rm ${PROGRESS_FILE}
echo "Everything is successfully installed!"
1 « J'aime »
Cela a pris du temps d’installer les dépendances et c’était plutôt rassurant,
Je suis maintenant avec les mêmes (bonnes) librairies que furax mais le demon reste Nok …
| bellows | 0.33.1 | 0.33.1 |
|---|---|---|
| pyserial | 3.5 | 3.5 |
| pyudev | 0.24 | 0.24 |
| requests | 2.28.1 | 2.28.1 |
| setuptools | 65.6.3 | 65.6.3 |
| six | 1.16.0 | 1.16.0 |
| tornado | 6.2 | 6.2 |
| wheel | 0.38.4 | 0.38.4 |
| zha-quirks | 0.0.80 | 0.0.80 |
| zigpy | 0.50.3 | 0.50.3 |
| zigpy-deconz | 0.18.1 | 0.18.1 |
| zigpy-xbee | 015.0 | 015.0 |
| zigpy-zigate | 0.9.2 | 0.9.2 |
| zigpy-znp | 0.8.2 | 0.8.2 |
Il va falloir des logs en debug maintenant, en commençant par celles des dépendances qui viennent d’être installées.
par contre // a sa copie d’écran je vois qu’il me manque.
charset-normalizer 2.0.12
et
pycrypto 2.6.1
OK ça semble plutôt bien pour ce qui n’a pas été tronqué. Et le Zigbeed_1 en debug il dit quoi en tentant de démarrer le démon ? Hésites pas à rebooter la machine éventuellement ça ne peut pas faire de mal après toutes ces manipulations
Arf ta version du plugin n’est pas en phase avec la librairie Zigpy… Le + simple serait d’installer le plugin sur une VM de tests avec un Jeedom > 4.2 et de remplacer le dossier resources de ton plugin en 4.1.28 (en le supprimant auparavant) par celui de la machine de test.
J’avais gardé une copie de mon repertoire plugin zigbee de mon installation qui marchait avant le crash, si je récupére le repertoire Ressource pour le remplacer ça peu le faire ?
Ma verion du plugin est celle du 2022-02-02 01:03:05 avec core mini 4.0
Non il faut le dossier resources qui correspond à la version de Zigpy, il faut donc télécharger le dernière version du plugin.
Tiens c’est cadeau 
: resources.zip.txt (78,3 Ko) (il faut enlever le .txt à la fin pour avoir accès au dossier zippé)
Nickel, tu peux garder la barbe blanche de Salviaf pour jouer au père Noël 
Merci, je m’en vais faire un clone de l’emmc car du coup penser sécuriser avec les sauvegardes ne suffit plus avec les évolutions.
Je prends de l’avance pour la prochaine fois alors, si tu repars d’une image de disque un jour penses bien direct à faire :
sudo apt update && sudo apt upgrade
Mais bon va falloir passer en 4.2 un jour 
1 « J'aime »
Je l’avais fait hier pourtant l’update upgrade juste après la descente de buster via balenaetcher. Je le fais systématiquement.
C’est prévu le passage en 4.3.
J’ai libéré un odroid de test pour ça et j’attends la livraison de l’emmc. D’ailleurs faut-il remettre buster ou passer directement à bulleyes (même si pas encore supporté officiellement)
1 « J'aime »
Si tu n’as pas de plugins qui nécessitent python2 pour fonctionner (il ne doit plus en rester tant que ça) go pour Debian 11 sans hésiter.
Ok entendu. Bon encore merci pour ton aide et ta patience et par avance de bonnes fêtes à tous.
2 « J'aime »
Tiens au fait une question naïve en vue de ma migration. Je voudrais en profiter pour repartir sur un jeedom « propre ».
Mon install date de la version 1 et je n’ai fais que des migrations successives qui ont surement laissé des traces y compris les plugins testés et abandonnés, sans parler des scénarios et autre virtuels qui ne servent plus.
Tu ferais comment ?
Parce qu’il est « sale » le tien ? 
Blague à part, @Mips répond régulièrement à cette demande de « repartir de 0 pour avoir un Jeedom propre » sur le forum et je ne crois pas avoir vu une seule fois un cas où c’était vraiment nécessaire.
En effet, le core intègre de + en + d’outils pour s’auto-nettoyer/réparer au fur et à mesure des mises à jour. Donc à part puger les historiques et supprimer les équipements/scénarios/etc qui ne servent pas il n’y a à priori rien de + à chercher comme optimisations à ce niveau. Au pire faire des SELECT sur les tables depuis l’administration de base de donnée en config Jeedom pour identifier concrètement des éléments qui n’y ont plus leur place déjà dans un 1er temps.
Bien je ne vais donc pas me prendre la tête et repartir d’une sauvegarde.
J’ai mis en solution et donc je clos.
Merci pour les réponses claires.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.