Je suis actuellement sur RPI3b+. J’ai démarré JEEDOM il y a environ 1 an … J’ai conservé tout ce temps ma carte SD.
Conscient du risque de fiabilité que présente ce type de support , je souhaite migrer sur SSD.
J’ai déjà fait un essai de cette opération globalement très satisfaisante sauf que pour le plug-in Deconz ça ne repart pas. DAEMON KO
J’ai essayé divers manip(s) :
Relancer les dépendances
Relancer le Daemon après …
Je ne parviens pas accéder à la page de config. en appuyant sur le raccourci (entouré en rouge)
Bonjour,
De quelle façon as-tu procédé à la migration?
Normalement, quitte à migrer, fais une sauvegarde de ta Jeedom que tu stockes sur un support externe.
Ensuite, tu fais une fresh install buster en suivant le tuto sur ce site. Installation Jeedom puis restauration de ta sauvegarde.
Il ne te reste plus qu’à relancer les dépendances et ça devrait être bon.
Au vu des informations sur ton profil tu es au moins en Debian Stretch (V9 donc) et en Jeedom V4…
La méthode la plus simple pour migrer de SD vers SSD (en supposant que tu aies déjà fait la programmation de l’OTP de ton RPI pour pouvoir booter sur un SSD USB) est la suivante :
clone de ta SD sur le SSD : utilitaire rpi-clone -disponible ici : https://github.com/billw2/rpi-clone) avec la commande : sudo rpi-clone xxx (remplacer les xxx par le résultat de la commande sudo lsblk qui doit afficher le disque cible parmi les volumes montés)
redémarre le RPI en ayant pris soin de retirer la SD avant et d’avoir laissé le SSD branché sur son port USB
et puis c’est tout, ça devrait fonctionner. Bien sur le SSD risque de consommer un peu de courant donc il faut penser à l’alimenter par ailleurs que depuis le RPI
Si sur ton SSD tiu veux fonctionner avec une version Debian plus récente que celle de ta SD alors suis les recommandations de @mich0111 càd :
installe la version Debian up to date sur ton SSD
installe Jeedom à partir de zéro
récupérer la sauvegarde Jeedom de ta SD sur ton SSD depuis Jeedom.
Toute autre méthode va conduire à de gros pbs de cohérence des paquets python voire d’autres paquets.
Salut,
J’ai lu que dans peu de temps, il sera quasi imposé de devoir être sous buster, sinon tu auras des warning en permanence.
Alors, autant le faire d’ores et déjà.
Bien d’accord. cependant il y a quelques plug ins qui ne fonctionnent pas (encore) sous Buster (pour ce qui me concerne Yamaha Musiccast) et avant de passer sous Buster il peut ainsi tester que son installation actuelle fonctionne aussi sur SSD (théorie du « je ne change qu’un paramètre à chaque étape pour mieux identifier quand et où ça bug en cas de problème »).
Une fois l’étape intermédiaire validée il pourra reprendre à zéro la procédure Buster tout en ayant sous la main une configuration fonctionnelle en cas de pépin de migration.
Il sera nécessaire d’être sous Debian 10 Buster pour accéder aux futures mises à jour du core. Un message vous en informera dans le centre de mise à jour.
Nous vous recommandons de procéder à une nouvelle installation plutôt qu’à une mise à niveau de l’environnement en lignes de commandes. Vous pouvez vous aider des images Debian 10 Buster + Jeedom pour Raspberry ou X86-64 mises à disposition par l’équipe en suivant la documentation d’installation spécifique à votre matériel. Il ne restera plus qu’à restaurer une sauvegarde récente préalablement mise de côté.
es-tu sur que c’est ton plugin deconz qui ne fonctionne pas ? n’est-ce pas plutôt la clé ?
pour ma part, j’ai eu beaucoup de pbs sur une migration quasi identique jusqu’à ce que je mette en place une « rallonge USB » pour ma clé CONBEE II (sur les conseils de @Yves19 je crois !).
En effet, il semble y avoir beaucoup d’interférences entre la clé et le disque SSD en USB3 (pb que tu n’avais pas avec une carte SD)
Qu’une rallonge améliore la réception par une diminution des interférences, certainement, mais je ne vois pas le rapport avec la migration SD->SSD.
Ce qui marche avec l’une marchera avec l’autre.
Si la clé n’est pas abîmée, ce qui est toujours possible, il faut plutôt voir du côté de la migration logicielle.
sur le fond, je suis d’accord, et il est assez incomprehensible d’avoir de tels effets de bord, mais dans les faits, j’ai effectivement déjà eu ce pb :
Je vous fais un retour… Bon ça tourne c’est fonctionnel.
J’ai dû dans le plug-in relancer les dépendances.
CLiquer sur >>
Ensuite l’accès à l’interface Deconz est devenu possible en cliquant ici >>
MEs devices n’étaient plus présent dans Deconz alors que sous Jeedom oui. J’ai donc du refaire l’inclusion 1 par de mes devices depuis Deconz en cliquant ici >>
En suite j’ai synchronisé dan Jeedom & la com. a été rétablie . C’est de nouveau fonctionnel. Pas simple tout ça … Encore une fois Clé Conbee II / Deconz + matériel Xiaomi Aqara c’est très perfectible !
Merci @ngrataloup ; @Yves19 ; @mich0111 pour vos différents conseils qui profiteront à ceux qui passent par là .
Tes réinclusions ont été rendues obligatoires si tu n’as effectivement pa srécupéré une sauvegarde de la base ZigBee au préalable. Cette sauvegarde peut se faire sous Phoscon puis la restauration ensuite aussi sous Phoscon.
Tu devrais faire ce type de sauvegarde à chaque changement de la topologie de ton réseau (ajout ou suppression d’un équipement). Sinon en cas de portage ou de réinstallation tu devras refaire tous les appairages. Mais ça c’est niConBee2 ni Aqara c’est simplement Zigbee. C’est un peu comme si tu installais Win10 depuis zéro sur un PC sans avoir sauvegardé au préalable tes fichiers documents; après l’installation il faudrait … les recréer.
Très juste remarque. J’ai bien vu à posteriori dans l’interface Phoscon la possibilité de Back-up que j’aurais dû réaliser avant evolution ( SD vers SSD) ; elle m’aurait permis de faire la restauration après pour éviter de refaire les onclusions individuelles de mes équipements.
Ben, le plugin DeConz fait automatiquement un backup de la clé tous les jours ; chez moi, à 7h10.
Ca se trouve dans /var/www/html/plugins/deconz/data, c’est un fichier d’extension .tar.gz
Il est possible de restaurer avec phoscon
