Depuis le passage de Jeedom beta 4.4.8 vers 4.4.10 j’ai une erreur « Unsupported operand types: string + string » avec la fonction jeedom::evaluateExpression dans solcast
Le but étant d’additionner les valeurs de 2 commandes par exemple #1615# + #2756#, il faut s’y prendre comment maintenant ?
Doit avoir un truc en Debian 12 php 8 et Jeedom 4.4.10 je reproduis pas. Tu es sur des commandes ? Le seul truc que je vois c’est commande qui n’est pas un chiffre.
Ah purée … c’est parce que j’ai testé le nouveau système de cache et redémarré Jeedom. Il n’y avait plus rien dans l’état de ces commandes virtuelles.
Je pense que l’on va avoir pas mal de problème / questions qui vont résulter du changement lié au cache des commandes ou alors j’ai rien compris ?
Ce virtuel était là depuis un bon moment, l’état aurait du passer en DB depuis longtemps. Je ne comprends pas le fonctionnement, c’est normal alors qu’après changement de la méthode de cache et le reboot les commandes virtuelles n’avaient plus de valeurs (c’était des valeurs fixes pour tester comme tu as pu le voir sur la capture) ?
Je pensais que les valeurs en cache étaient stockés en bdd au bout de x minutes et qu’après reboot la db populait le cache avec les valeurs.
Et bien donc je confirme, va falloir que l’on explique sans doute pas mal de fois ce principe parce que je suis pratiquement sûr que ce que je viens d’expérimenter va arriver à pas mal de monde ayant des valeurs « fixes » dans des commandes virtuelles.
Le nouveau cache est supposé passer stable en 4.5 si j’ai bien lu ta note c’est ça ?
Oui 4.5 vu que c’est une version majeur ça sera plus simple à faire passer. Il n’y a de toute façon pas le choix la lib de l’ancien cache est plus maintenue et le cache maison qu’on a fait est 20 a 30% plus rapide ce qui n’est pas négligeable
Bonjour,
Ne peut on pas envisager une migration du cache lors de l’upgrade vers 4.5.
Lots du lancement de l’upgrade, jeedom est toujours en version pre-4.5 avec l’ancien module de cache. Il doit donc etre possible de lire le contenu du cache et de le placer dans un fichier plat type json ou autre.
L’upgrade vers 4.5 s’effectue.
A la fin de celui-ci, on relis le fichier plat pour remplir le nouveau cache.
Ne serais ce pas une solution pour eviter d’embeter tous les utilisateurs.
Si c’était si simple ne penses tu pas que je l’aurais fait ? Je n’ai pas avec l’ancien système de cache moyen de savoir ce qu’il y a dedans sans connaitre exactement la clef (en gros j’ai pas de all()). Donc pour certain truc je pourrais regarder si la clef existe et le transférer mais ca rendrait le cache inconsistant.
En plus je rappels c’est du cache c’est donc bien dit dans son nom que c’est pas éternel. Normalement sur un Jeedom bien programmé meme si le cache se vide il va se remplir de lui meme au bout de quelques minutes/heures au pire.
Dans le cas de figure que j’ai présenté (des valeurs numériques fixent sur des commandes infos virtuelles), visiblement ça ne sera jamais rempli et il va falloir forcer la sauvegarde des équipements.
Je suis prêt à parier que l’on aura pas mal de questions sur des scénarios qui ne marchent plus où même des erreurs dans des certains plugins.
Enfin bon si c’est pas possible de faire sans un système de transition vers le nouveau cache il faudra blinder la documentation / le changelog pour bien expliquer et sur community on s’occupera de régler les soucis et d’expliquer à ceux qui n’auront pas compris l’impact de l’affaire
Si ton virtuel a une valeur qui ne change jamais alors le virtuel était pas le bon choix fallait faire une variable (la c’est en base donc jamais perdu).
Et oui je sais ça va raler je vais m’en prendre plein la tête pour changer mais clairement je peux pas laisser une lib qui n’est plus maintenu depuis presque 2ans maintenant. D’un point de vue risque pour la sécurité c’est pas terrible
