J’avais un vieux Jeedom en v3.3.59 (car Debian 9) que j’avais fait attention de moins toucher car j’ai un openzwave très capricieux… J’avais donc misé sur des Jeedom annexes pour reporter des plugins comme Zigbee, les plugins avec connexions cloud etc…
Or le dernier jeelink pose des soucis, et certains info/commande ne se synchronisait plus car différentiel de version. J’ai donc pris la decision de migrer mon Jeedom principal. J’ai evidemment un backup du Jeedom et un export de la conf zwave que j’ai externalisé sur une autre machine.
Le Debian est en 10, cette partie là s’est bien passée.
L’upgrade Jeedom s’est plantée avec un souci d’accès a une classe. En interface web, l’accès à l’update ne fonctionne plus car le panel d’upgrade en v4 n’apparait pas.
J’ai nettoyé les plugins qui pouvait bloquer l’upgrade en v4.
Mais l’update me dit que l’upgrade vers la 3.3.59 s’est bien passée…
Dans le dossier install/update, il y a tout ce qu’il faut mais rien pour sauter en v4.
Dans l’interface je n’ai plus accès a rien.
En command line comme indiqué, le update.php ne va pas plus haut que la 3.3.59, et me dis tout satisfait que j’ai la version correcte.
Avec la méthode standard telle que (conseil de Loic):
Encore une fois j’ai une installation Openzwave de plus de 80 modules qui a plus de 5 ans, qui est hyper instable et moins j’y touche… Si j’en arrive à tout perdre au niveau de la conf / clé, je jette toute cette partie là, je n’aurais pas le courage de re-inclure tous mes modules en demontant tout dans ma maison.
pour faire ce genre de migration de 3.3 vers 4 avec de l’openzwave, voilà comment j’ai fait sur 2 jeedoms :
backup jeedom 3 3
backup openzwave pour créer les fichiers de sauvegardes xml
installer une VM en debian 10,
installer jeedom via la commande d’install en ligne
restaurer la sauvegarde 3.3 sur le jeedom tout frais
lancer la commande de migration V3.3 → V4 intégrée
ensuite je fais un backup en V4
je réinstaller ma machine cible en debian 10 à zéro
j’installe jeedom V4 en ligne de commande
je restaure le backup en V4 fait sur la machine virtuelle
je sélectionne la clé dans openzwave s’il a pas trouvé tout seul
je vérifie que le fichier de backup openzwave est bien présent (en principe oui)
je n’ai pas eu besoin de restaurer la partie openzwave depuis le xml, il a tout repris tout seul sans souci.
pour moi il faut faire une install sur un debian propre et à zéro, toute tentative d’upgrade sur un système « upgradé » ne peut provoquer que des soucis immédiats ou a moyen terme, notamment avec d’autres trucs.
voilà donc pour cette méthode il te faut juste une machine sous windows ou un mac où installer un gestionnaire de machines virtuelles et piocher l’iso de debian 10 sur repository debian (net install de quelques Mo suffit).
J’ai un ESXi sur lequel je fais deja tourner mes jeedom satellite (dedié zigbee, cloud). Je peux monter une VM pour lancer ta procedure.
Je vois parfaitement le principe. Pendant la phase de restore de mon backup 3.3 sur cette VM temporaire, ais-je besoin d’y connecter mon dongle zwave, ou cela peut rester comme cela?
c’est top, tu peux faire ça très simplement avec un ESXi.
pas du tout et c’est justement l’avantage, la mise à jour peut se faire sans le dongle. tu n’en as pas besoin, juste à la fin pour le changer de système.
j’ai même changé de hardware au passage, de cpu et de disque ssd sur les machines de prod.
CREATE INDEX `datetime` ON `timeline` (`datetime` ASC)[END CHECK AND FIX DB]
Check jeedom package
warning: commands will be executed using /bin/sh
job 5 at Wed Mar 16 10:12:00 2022 | OK
Check jeedom database | OK
Suppression de : weather::pull() car il n'y a pas de lancement prévu
Suppression de : scenario::doIn() car il n'y a pas de lancement prévu
Check filesystem rightPHP Fatal error: Uncaught Error: Call to undefined method jeedom::cleanFileSystemRight() in /var/www/html/install/consistency.php:372
Stack trace:
#0 /var/www/html/install/update.php(277): require_once()
#1 {main}
thrown in /var/www/html/install/consistency.php on line 372
Mais après un 2ème update dessus ca passe… va comprendre.
Le restore est passé, mais l’apache de mon jeedom est irresponsive. « Delai d’attente dépassé ».
J’ai bien peur qu’il faille une installation sans mettre le backup dessus, et ca… je ne sais pas si j’ai la force de refaire tout de 0.
c’est pas très long de lancer une machine debian et de faire un snapshot avant install pour reprendre à zéro plusieurs fois, puis un autre après install de la V4 vierge
Je suis arrivé à la fin de « ta » procedure. C’est pas ca qui est long, c’est de refaire les plus de 50 scenarios que j’ai, les plus de 100 virtuels qui sont contenus dans mon backup.
Jeedom vierge il tourne, jeedom + mon backup restauré il pedale et ne donne rien au niveau interface web. Je ne vois pas les solutions que j’ai.
C’est étrange, de mon côté j’ai vraiment eu aucun problème à récupérer l’intégralité, y compris les scénarios. La seule chose quand on a installé la V4 vierge, restauré la v3, c’est de bien relancer les dépendances, car celles-ci ne sont pas installées automatiquement.
Les dépendances s’exécutent toujours seules, elles sont chaînées avec quelques secondes de pause entre les installations.
Il est uniquement nécessaire de le faire manuellement si au bout d’une heure (en fonction d la machine et du nombre de plugins nécessitant des dépendances) les installations n’auraient pas été complètement réalisées.
j’ai 300Mb de backup et plus de 1Gb de DB.
J’ai mis sur un VM dediée ma partie zwave, reliée en jeelink. Au moins je met de coté cette partie qui peclote. Mais j’ai tous mes virtuels à refaire…
Sur mon master, y a-t-il un moyen de recuperer tous mes scenarios pour éviter de refaire de 0? J’en ai plus de 50, avec master scheduler qui lance les scenarios enfants, des appels à des virtuels pour des valeurs calculées, enfin une bonne usine à gaz en fait.
Avez vous testé de vider les historiques, faire une sauvegarde et faire la restauration.
En vous assurant avant tout cela, de ne pas avoir de plugins incompatible avec les v4, comme widgets par exemple.