Pertes de datas sur RPI4 après redémarrage

Apres un arrêt jeedom puis remise sous tension, je me suis retrouvé avec des data vides !

Ce qui donne dans le testeur d’expression ex #[Chambre][Volets Matin][Heure]# = ‘‘ (guillemets vides) soit valeur 0, comparé à #time# = #[Chambre][Volets Matin][Heure]#, ça m’a provoqué dans le scénario une ouverture des volets de la chambre a Minuit !

J’ai eu aussi qq widgets on/off repassé à zéro (soit off)

Du coup tout est devenu instable. :unamused_face:

je précise que je viens de passer en 4.6.1 (je suis toujours en debian 11.11)

Bonjour

Cela est normal quand on redémarre, j’ai le même comportement que toi et j’ai trouvé une solution.

En créant un scénario suite à un redémarrage afin de repasser certaine cde en fonction de mes

besoins et éviter des comportements aléatoires ou des ruptures domotique.

Les datas comme tu dis sont vides donc il faut forcément et réactiver soit 0 soit 1, voici je que j’ai fait en automatique via scénario, attention moi je suis en débian 12 jeedom 4.6.1, mais si tu t’aide de gémini par exemple, tu devrais t’en sortir, tout est imaginable.

maintenant mes codes

Le premier sert à vérifier depuis combien de temps le raspeberry à démarrer pour ne pas lancer le scénario quand jeedom fait une mise à jour ou un rédémarrage système. pour le restes tu vas vite comprendre. Un pour les infos, un pour les actions à faire (replacer les datas) et après je relance mes scénarios que j’ai besoin.

// Lecture directe du fichier /proc/uptime via PHP
$uptimeContent = file_get_contents('/proc/uptime');
$uptimeArray = explode(' ', $uptimeContent);

// On récupère le premier nombre (secondes) converti en nombre entier
$uptimeSeconds = intval($uptimeArray[0]);

// Affectation du tag pour les bloc(s) du scénario
$tags = $scenario->getTags();
$tags['#uptime_seconds#'] = $uptimeSeconds;
$scenario->setTags($tags);
// Saisissez ici les IDs info de tous les virtuels que vous voulez réinitialiser
// Séparés par des virgules
$ids_des_virtuels = array(446, 435, 438, 436, 434,449, 450, 454, 447, 448, 452, 453, 459, 460, 463, 465, 461, 462, 464, 466, 485, 584, 613, 587, 586, 583, 582, 548, 551, 552, 553, 554, 555, 556, 557, 381, 382, 383, 241, 456);

// Boucle sur chaque virtuel de la liste
foreach ($ids_des_virtuels as $id_virtuel) {
    $eqLogic = eqLogic::byId($id_virtuel);
    
    if (is_object($eqLogic)) {
        $scenario->setLog("--- Début RAZ Virtuel : " . $eqLogic->getName() . " (ID: " . $id_virtuel . ") ---");
        
        // Récupération de toutes les commandes du virtuel en cours
        $cmds = $eqLogic->getCmd();
        
        foreach ($cmds as $cmd) {
            // On ne cible que les commandes de type "Info"
            if ($cmd->getType() == 'info') {
                $cmd->event(0);
                $scenario->setLog("  -> Info [" . $cmd->getName() . "] remise à 0.");
            }
        }
    } else {
        $scenario->setLog("Erreur : Impossible de trouver l'équipement Virtuel avec l'ID " . $id_virtuel);
    }
}
// 1. Liste des IDs des commandes ACTION à exécuter
// Vous pouvez ajouter ou supprimer des IDs ici, séparés par des virgules
$ids_actions = array(8050, 8079, 8086, 8093, 8100, 8114, 8121, 8107, 9962);

// 2. Boucle pour exécuter chaque commande action
foreach ($ids_actions as $id) {
    try {
        // Récupération de l'objet commande par son ID
        $cmd = cmd::byId($id);
        
        if (is_object($cmd)) {
            // On vérifie bien que c'est une commande de type "action" avant de l'exécuter
            if ($cmd->getType() == 'action') {
                // On exécute l'action
                $cmd->execute();
                $scenario->setLog("Action ID " . $id . " [" . $cmd->getHumanName() . "] exécutée avec succès.");
            } else {
                $scenario->setLog("ID " . $id . " : Erreur, cette commande n'est pas de type 'action' (c'est une " . $cmd->getType() . ").");
            }
        } else {
            $scenario->setLog("ID " . $id . " : Erreur, l'ID n'existe pas.");
        }
    } catch (Exception $e) {
        $scenario->setLog("ID " . $id . " : Erreur lors de l'exécution : " . $e->getMessage());
    }
}

J’ai fait pas mal de scénario pour la maintenance automatique ou manuel via ma tablette design afin de ne pas ouvrir l’ordi à chaque fois, et aujourd’hui je suis de moins en moins dépendant de l’ordi même quand je redémarre mon raspberry pour un dépoussiérage.

Evidemment cela demande un peu de taf, mais une fois fais, c’est un régal.

Demande à gémini de vérifier les codes et de les corriger en fonction de ta version.

Pour arriver à cela, un conseil, prend un papier et un crayon et note ce que tu veux en automatique

et les ids concernés, les actions à faire, bref un cahier des charges et dès qu’il te semble que tu

n’aura rien oublié au bout d’une paire de jours, tu pourras œuvrer, car tu risque de perdre du temps et de ne plus savoir ce que tu voulais faire ou ne pas faire.

Bonne journée

Bonjour,

Je ne suis pas d’accord : un simple redémarrage n’est pas sensé entraîner des pertes et/ou des modifications d’informations, que celles-ci soient mémorisées dans des variables ou dans des virtuels (petite précision au passage : les widgets type infos ne font que recopier l’état d’une information, en soi ils ne modifient rien, et les widgets action n’agissent que sur une commande identifiée).
Ce comportement n’est donc pas normal, et la solution proposée, si elle fonctionne, n’est finalement qu’un pis-aller.
Mieux vaudrait plutôt s’attaquer à la cause (qui, peut-être, pourra être réglé facilement) qu’aux conséquences (où là c’est sûr qu’il faudra construire, avec l’aide éventuelle d’une IA, une usine à gaz pour remettre tout d’aplomb à chaque reboot…).

@mick37
Une piste à explorer en priorité : avez-vous vérifié l’intégrité de la BDD ?
Cela se passe ici (Réglages, Système, Configuration, onglet >_OS/DB):


(n’hésitez pas à passer tout en revue…)

Bonjour

Oui dac avec toi, mais

Il y avait quelques mois de ça, j’avais déjà posé la question mais j’ai pas eu de réponse satisfaisante et surtout on m’a fait faire une manip qui m’a fait perdre beaucoup de choses et paniqué, donc là je touche plus à rien, en attendant qu’il y ait une solution bien expliqué car même dans la doc jeedom je n’ai rien trouvé qui explique ce phénomène de perte de data. J’avais posé la question, était de savoir si c’était possible de récupérer un fichier des datas ou de la position de chaque commande ou scénario etc et de pouvoir le réinjecter en cas de réinstallation, de redémarrage si des phénomènes bizarres venaient apparaître après la remise en route.

Je te rassure je n’en veux à personne car sur un système comme ça on comprend bien qu’il faut bien mettre les mains dans le cambouis, et que la meilleure solution c’est celle que l’on adopte et il y en a tellement des solutions :smiley:

En attendant je vais suivre ce poste avec une grande attention.

Merci

Ok…Vu comme ça, je comprend effectivement la démarche.
Mais, surtout avec un système en DIY comme le RPi4, et dans la mesure où ce comportement reste quand même anormal (pour une raison qui resterait donc à identifier), le plus simple, le plus efficace et surtout le plus rapide ne serait pas d’effectuer une réinstallation complète suivi d’une réinjection de la dernière sauvegarde (si cela n’a pas déjà été tenté) ?
En repartant sur une base saine, il y a quand même de grandes chances de résoudre ce problème qui peut-être très pénalisant, mais qui effectivement ne permettra pas d’identifier avec certitude la cause qui en était à l’origine…

Rien de flagrant dans l’analyse DB

> \[START CONSISTENCY\]
> \[START CHECK AND FIX DB\]
> \[END CHECK AND FIX DB\]
> Check jeedom package…OK
> Check jeedom database…OK
> Check crons…
>
> Check filesystem right…OK
> Check jeedom object…OK
> Check jeedom cmd…    OK
> Set cache hour…OK
> Check composer…OK
> Check nodejs…npm warn using --force Recommended protections disabled.
> Hit:1 http://deb.debian.org/debian bullseye InRelease
> Hit:2 http://deb.debian.org/debian bullseye-updates InRelease
> Hit:3 http://security.debian.org/debian-security bullseye-security InRelease
> Hit:4 http://archive.raspberrypi.org/debian bullseye InRelease
> Hit:5 https://deb.nodesource.com/node_22.x nodistro InRelease
> Reading package lists…
> Reading package lists…
> Building dependency tree…
> Reading state information…
> apt-utils is already the newest version (2.2.4).
> build-essential is already the newest version (12.9).
> lsb-release is already the newest version (11.1.0).
> git is already the newest version (1:2.30.2-1+deb11u5).
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> \[Check Version NodeJS actuelle : v22.23.1 : \[  OK  \]
> \[Check Prefix : /usr and sudo prefix : /usr and www-data prefix : /usr : \[  OK  \]
> Clean npm cache
> OK
> Check apache security file…\[END CONSISTENCY\] 

Python, fasteners, futur → incompatible

Python 3 → OK

Pas de sauvegarde du cache … ?

Je n’ai pas vu de tache cache::persiste présent dans mes Taches

Ça par contre, ce n’est pas normal et expliquerai aussi ces pertes de données…

Il faut en effet que la tâche cache.persist soit présente et programmée dans le moteur de tâches pour résoudre ce problème :

image

1 « J'aime »

Je regarde la santé jeedom assez souvent ! Pour moi c’est nouveau, je ne sais pas si c’est lié récemment a mon passage en 4.6 ou à un mauvais mise hors tension / redémarrage ?

Quoi qu’il en soit j’ai pas trouvé sur le forum pour réinstaller cette tache ou réparer jeedom…

Pourtant la procédure est indiqué dans la bulle d’aide (et la demande est assez fréquente sur community).
Donc lisez la bulle info et si vous ne comprenez pas une partie, demandez

j’ai ajouté la tache manuellement avec les infos de la copie écran de @DanielJ Merci à lui :folded_hands:.

Le défaut santé persistance est redevenu Ok :slightly_smiling_face:, reste a voir si je continue à perdre des datas sur un arrêt / redémarrage.

C’est tout bon plus de pertes de données après mise hors tension !

Oui en effet je l’ai déjà fait il y a 4 mois à peu près et ça n’a pas forcément résolu le problème donc je sais que je devrais tout reprendre pour faire propre surtout que j’ai évolué sur débian 12 depuis 6 mois qui a marché du premier coup mais je pense que c’est ma sauvegarde qui est un peu polluée car j’ai fait pas mal de choses avec pour la découverte et que j’ai eu la flemme de reprendre du début, le seul truc qui a été positif c’est les mises à jour des plugins etc qui se passe très bien, à condition de bien respecter la procédure qui est donnée dans les les changes log ou dans la notice.

Mais quand tu dis que si jamais on redémarre que ça soit matériel ou système normalement on devrait garder les data ou la position des scénarios d’un point de vue domotique ?

Oui, tout à fait côté data (rien ne devrait être modifié), côté scénario je pense que oui bien que je serai moins affirmatif, ne l’ayant jamais testé par moi-même.
Ceci dit, avec un arrêt propre, aucun soucis (les tâches sont stoppées dans leur environement), et sur un arrêt matériel, il peut y avoir des loupés (rien n’est sûr à 100%), mais de ma propre expérience, les systèmes (Debian) étant de plus en plus résistants par rapport à ce type de problèmes, cela n’a jamais posé plus de soucis que ça non plus…

Très possible en effet, il faut regarder du côté de certains plugins (en particulier les plus anciens plus très à jour…) qui peuvent interférer.

C’est déjà mieux…
A voir dans quelques jours, et ne pas hésiter à redémarrer le RPi4 par exemple pour en être sûr aussi.

Bonjour

@mick37 : En général on commence un message comme cela, surtout quand on vient demander de l’aide. Ici on parle entre humains pas avec une IA :wink:

@Marcp30 Ben non ce n’est pas normal et ça fait penser à un problème de cache.

Bon les autres messages sont allés dans ce sens mais il faut savoir comment jeedom fonctionne :

  • Le paramétage des commandes est présent dans la DB et est persistant
  • Les historiques des commandes est présent dans la DB et est persistant
  • La valeur actuelle d’une commande (qu’elle soit historisée ou non) est stockée dans le cache.

Ce cache est normalement sauvegardé à intervalle régulier et est restauré lorsque jeedom redémarre.

Ca venait d’une bonne intention de partager ton scénario mais pour moi c’est une usine à gaz la où il vaut mieux comprendre pourquoi le cache ne marche pas :wink:

Bonjour

Alors en fait c’était un fil de discussion et au tout début j’ai bien dit bonjour mais bon il fallait suivre du début toi tu l’as pris en cours de route je comprends.:smiley:

Quand tu dis quand on redémarre jeedom c’est ce que j’avais au tout début que j’ai commencé l’aventure sauf que maintenant je pense qu’à force j’ai fait dérailler mon système mais par contre quand je redémarrer matériel en parlant donc mon raspberry j’avais des comportements bizarres parce que certaines commandes info n’avait aucune valeur, donc oui je suis d’accord avec toi comme la plupart qui me le disent on peut penser que c’est une usine à gaz mais bon ça fonctionne je mets beaucoup moins les mains dans le cambouis quand je le redémarre à distance pour x raisons, mais là avec tout ce que j’ai vu sur ce fil de discussion je vais chercher à comprendre car je n’ai à priori aucun pb même coté vérifications système. Suggéré plus haut peut-être un problème de plugin qui sont un peu obsolète là je sais que j’en ai un comme free sms il commence à ne plus supporter le PHP actuel mais qui fonctionne très bien malgré tout et j’ai des pistes pour le remplacer. De mon côté j’ai un client qui m’accompagne quand je suis chez lui et qui était développeur chez jeedom bon il est passé chez ha car il l’utilise pour son boulot donc la prochaine fois quand je le verrai je lui poserai quelques questions.

Merci

Salut, je m’adressais a @mick37 pas a toi dans cette partie du message

Hello,

Juste pour vous dire que j’ai fait plusieurs mise hors tension depuis le dépôt de solution, je n’ai plus de pertes de datas. J’espère que le retour d’expérience de ce fil pourra aider la communauté.

Bonne journée et merci ceux qui on fait avancé le sujet.

2 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.