Je m’interroge sur le nouveau système de cache qui va être imposé avec la version 4.5 de jeedom. Dans la changelog, il est écrit ceci :
Dû au changement de moteur de cache sur cette mise à jour, tout le cache sera perdu, aucune inquiétude c’est du cache il va se reconstituer de lui-même. Le cache contient entre-autre les valeurs des commandes qui se remettront à jour automatiquement lorsque les modules remonteront leur valeur. A noter que si vous avez des virtuels à valeur fixe (ce qui n’est pas bien si ça ne change pas alors il faut utiliser les variables) alors il vous faudra resauvegarder ceux-ci pour récupérer la valeur.
Ceci signifie t-il par exemple que tous les modes (plugin mode) seront vides après la passage en 4.5, que l’état de mon chauffage sera dans un état indéterminé, idem pour l’état de mes ouvrants, etc ? … J’ai bien compris que le cache se réalimentera au fur et à mesure. Si j’ai un mode qui ne change que deux fois sur l’année par intervention humaine (période de chauffage, oui ou non), va falloir repasser sur tous les équipements. Quid des scénarios dont le déclencheur est une info devenue vide par le vidage du cache.
Voilà pour les questions qui me viennent à l’esprit.
Je cherche à préparer au mieux le passage sur la 4.5. Quelles sont les actions à mener pour éviter au max des désagréments (désactiver le moteur de scénario, passer sur tous les équipements, …)
En tous cas je comprends ton inquiétude. La dernière MAJ 4.4 qui a touché au cache (4.4.10 je crois) il y a quelques temps a été une catastrophe sur mon installation.
Tout ce qui avait un état est parti en cacahuète, des alarmes qui se déclenchent, des comportements qui ne sont plus rendus.
Il m’a fallu aller à la main dans pas mal de virtuels, plugins, pour reforcer des status et refaire partir le tout, j’ai retrouvé des restes une semaine après (une alarme inondation).
Donc il faut être super précautionneux (je parle côté utilisateur, côté dev, bien sûr qu’il faut l’être sur tout !) quand le cache est impacté, et je n’avais pas conscience d’à quel point c’était aussi sensible. C’est même probablement plus à surveiller qu’un redémarrage.
Ce que tu as vécu, on va le vivre obligatoirement avec la 4.5. Va falloir être très très prudent, car je suis confronté aux mêmes contraintes de sécurité (alarme), de confort (mon chauffage est intégralement piloté par jeedom et là c’est pas la bonne période), et plein d’autres choses. Je m’interroge sur le comment minimiser les désagréments :
_ désactiver le moteur de scénarios
_ passer sur tous les équipements (zwave, mode, …) pour forcer des refresh quand c’est possible, les modules zwave sur pile ne remontent que leur données parfois qu’après plusieurs heures, peut être obligé de les réveiller, …
_ passer sur tous les virtuels
_ …
_ redémarrer le moteur de scénarios.
Le cache est complètement supprimé et recrée avec le nouveau système qui ne marche plus du tout de la même manière justement pour éviter les soucis qu’il y a eu en 4.4.10 à l’avenir (et aussi pour améliorer les perf le gain est d’environ 20%)
Je comprends parfaitement que cette modif va dans le bon sens. Même si le changelog est clair, j’attire l’attention de tous sur le changement du système de cache qui est loin d’être anodin. Je cherche à m’y préparer le mieux possible pour éviter au maximum les effets de bords.
Je m’interroge aussi sur cette migration qui aura de gros impacts, même s’il n’y a pas de « valeur en dur » dans des virtuels :
Si le cache est purgé, les valeurs ne vont pas y revenir toutes en même temps et des dysfonctionnement en cascade vont avoir lieu tant qu’il ne seront pas tous rafraîchi.
Par exemple, un chauffage est ON avant la maj et la température de la pièce est présente, ainsi que la température extérieure. Maj 4.5 et purge du cache. La température intérieure remonte, ok il fait assez chaud, pas besoin d’alumer le chauffage (car pas de valeur vaut pour 0 ou OFF), mais dans les faits le chauffage est toujours allumé et continue de chauffer.
N’est il pas envisageable de sauvegarder toutes les valeurs en cache pour les restaurer post maj ?
Bonjour
Tu ne penses pas que si c’était possible on l’aurait fait ? Donc pour répondre non car tous les scripts sont post maj donc quand on a déjà le nouveau système de cache.
Donc oui on est conscient de l’impact énorme sur vos jeedom et du stress que ça engendre. Je vais remonter le point à jeedom sas et on annulera peut être toute cette partie. Le soucis c’est que ça laissera une lib non maintenu avec des possible faille de sécurité…. Mais c’est vous les utilisateurs donc c’est vous qui déciderez.
Mais quand on réinstalle un jeedom après un crash disque par exemple, quon’ a remis l’OS et Jeedom et qu’on restaure un backup, n’est-on pas dans le même cas avec aucune valeur de cache et devoir attendre ou forcer la mise à jour des valeurs ?
Bonjour,
Dans l’exécution de l’update du core, n’y a t’il pas toujours un backup (sauf si l’utilisateur a enlevé le check) ?
Donc le backup pourrait contenir la sauvegarde du cache. Je sais que tu m’as déjà dis ne pas savoir ce que le cache contient réellement. Il n’existe pas de fonction de recherche.
Quelles sont les infos qui vont dans la cache? Je suppose toutes les valeurs des commandes info.
Il y a aussi les valeurs que les plugin poussent dans le cache. Celles-la, on ne les connait probablement pas.
Je ne suis pas d’accord.
C’est toujours possible d’avoir 2 systèmes dans une version et de gérer une migration: on écrit dans le nouveau et on lit dans le nouveau et si pas trouvé on lit dans l’ancien.
Après quelques jours on arrête de lire dans l’ancien.
Quel serait le cout et est-ce qu’il y a volonté de le faire, rapport coût/bénéfice, c’est discutable.
J’ai l’impression que ca vaut la peine ici, l’impact risque d’être important.
Je te laisse essayer perso j’ai pas réussi rien que lister les clefs dans l’ancien système de cache c’est quasi impossible. Mais je note et je vais annuler toute cette partie pour le grand public.
Hello avant de prendre une décision de go/nogo essayons (nous la communauté) d’établir un plan de migration lié à ce changement pour voir comment indiquer aux utilisateurs « lamba » une marche à suivre.
Encore une fois la migration vers la 4.5 n’est pas obligatoire dans un court terme pour tout le monde. Debian 11 est encore en LTS jusqu’au 31 Aug 2026
Je pense que l’impact ne va rellement concerner que des utilisateurs avances de la solution qui sauront se demmerder (scenario, virtuel) et sera de courte durée, le temps que les infos remontent. Vous ne seriez pas entrain d’en faire une montagne pour rien. Perso je prefère un declenchement d’alarme intempestif et attendu (info dans le changelog) qu’une faille de secu. Vous etes sur jeedom, ca ne vous coute rien sauf du temps et c est votre choix.
Je suis pour que la solution evolue meme si je dois investir un peu de temps. Si je ne suis pas pret à ça je prends du leroy merlin ou somfy.
Il ne faut ni annuler ni lister les clés existantes:
une écriture ecrit toujours dans le nouveau
une lecture lit dans le nouveau mais si pas de résultat, on lit dans l’ancien et on écrit la valeur dans le nouveau et ca migre tout seul au fil de l’eau.
Ca va coûter 2 lectures mais au moins on ne perd pas l’info.
Après 48h/72h à définir, on arrête ce mécanisme et seul le nouveau est lu.
Je suis aussi dans cette état d’esprit mais j’ai l’impression que le gros de la communauté ne veut plus d’évolution en faite ça fait quelques années que je vois ça. Il faut des nouvelles version mais surtout que ça change rien. C’est malheureusement impossible ou alors c’est aller droit vers une mort lente de jeedom.
Vas y je t’en pris j’attend ton pr vu que ça l’air si simple. J’ai pas les compétences pour activer les deux caches en même temps perso car il rentre en confrontation et s’efface mutuellement.