Sur toute les versions
Bonjour,
Merci pour ces échanges. Je suis sur Jeedom V3 si jamais.
Le démon s’est à nouveau planté cette nuit…
J’ai testé d’autres choses :
-
j’ai une passerelle Zennio KNX-IP autorisant 5 connexions seulement, mon installateur a suggéré de kill les connexions (reset passerelle) = redémarrage du KNX au tableau <=> toujours pareil
-
j’ai changé le type de passerelle dans le plugin en IPT (ald IPTN), le démon démarre bien mais aucune réponse du bus (tous mes équipements passent en revue et indiquent tous cette erreur)
Si ça peut aider, voici le log du plugin, le problème semble bien venir de la BD :
Bref, avec le mode « sapin de Noël » lors des mises à jour, ça semble mal barrer pour conserver mon jeedom actuel…
Y aurait-il une méthode pour reset la BD et éventuellement repartir sur du propre ?
Merci encore en tout cas !
Voila la requete :
SET FOREIGN_KEY_CHECKS=0;
Normalement ca devrait tout désactiver. Test aussi le systeme de verification de la DB voir si tout est ok
A lancer sur Configuration/_OS/DB dans la partie Administration de la bdd c’est ça ?
Testé ! Ca m’a donné ça :
En vérifiant la base de donnée, tout est ok :
Démon relancé, jeedom redémarré et pourtant, cette erreur apparait toujours… 
Ben je sais pas c’est bizarre la en gros c’est tu veux enregistrer un historique d’une commande qui n’existe pas mais je comprends pas d’où ça vient
Tu vois ça comment ?
C’est une erreur d’enregistrement passée ?
Non non c’est MTN il veut enregistrer un historique d’une commande qui existe pas
Excuse-moi, je ne suis pas très calé, j’imagine que c’est la commande que tu m’as fait lancer qui aurait du rien rendre ? Je la retenterai quand le service sera de retour pour comprendre.
Du coup, ça craint un peu j’ai l’impression…
Essayes de faire
SELECT concat('alter table ',table_schema,'.',table_name,' DROP FOREIGN KEY ',constraint_name,';')
FROM information_schema.table_constraints
WHERE constraint_type='FOREIGN KEY'
AND table_schema='jeedom';
Ça va te donner les requêtes a faire pour supprimer toute les contraintes
Bonjour @Loic,
Je me greffe sur le sujet car j’ai eu des symptômes similaires il y a 1 ou 2 semaines sur 1 Jeedom V3.3.39. Il s’agit peut-être d’un problème plus général qui touche plus de monde ?
Le plugin APC ne remontait plus les informations, je l’ai désactivé et quand je l’ai réactivé j’ai eu ce problème de contrainte sur FOREIGN KEY. Cela a perduré pendant 2 ou 3 jours et mon Jeedom consommait 30 à 40 % de processeur (VM sur Proxmox) alors qu’il est habituellement à 5%. Chez moi, l’erreur venait de l’enregistrement en historique d’une commande qui n’existait plus. A force d’insister (install, suppression, …) j’ai résolu le problème mais je ne sais pas vraiment si cela sera durable. Pour le moment je n’ai plus de problème de conso de processeur mais mon plugin APC ne fonctionne plus (je verrais plus tard).
Si j’exécute la requête voilà le résultat :
concat('alter table ',table_schema,'.',table_name,' DROP FOREIGN KEY ',constraint_name,';')
alter table jeedom.cmd DROP FOREIGN KEY fk_cmd_eqLogic1;
alter table jeedom.eqLogic DROP FOREIGN KEY fk_eqLogic_jeenode1;
alter table jeedom.eqLogic DROP FOREIGN KEY fk_eqLogic_object1;
alter table jeedom.history DROP FOREIGN KEY fk_history_cmd1;
alter table jeedom.historyArch DROP FOREIGN KEY fk_historyArch_cmd1;
alter table jeedom.object DROP FOREIGN KEY fk_object_object1;
alter table jeedom.plan DROP FOREIGN KEY fk_plan_planHeader1;
alter table jeedom.plan3d DROP FOREIGN KEY fk_plan3d_plan3dHeader1;
alter table jeedom.scenario DROP FOREIGN KEY fk_scenario_object1;
alter table jeedom.scenarioExpression DROP FOREIGN KEY fk_scenarioExpression_scenarioSubElement1;
alter table jeedom.scenarioSubElement DROP FOREIGN KEY fk_scenarioSubElement_scenarioElement1;
alter table jeedom.viewData DROP FOREIGN KEY fk_data_zone1;
alter table jeedom.viewZone DROP FOREIGN KEY fk_zone_view1;
Faut-il exécuter toutes ces requêtes pour supprimer les foreign Key ?
Merci et bonnes fêtes 
Oui faut tout faire et non pas un soucis général quand ya 2 personnes sur plusieurs dizaine de milliers qui ont le soucis. Ça vient probablement d’un soucis lors d’une mise a jour, ça ne pourra plus arriver en v4. Par sécurité en v4 je ferais une correction pour vous 2 seulement
OK super et merci pour ton retour un soir de Noël.
Encore bonnes fêtes
Joyeux Noël tout le monde !! 
Merci pour ces réponses en tout cas ! Ca fait plaisir d’entrevoir une solution via votre aide !
EIBD est reparti cette nuit ; j’ai retenté la première requête plus haut mais j’ai obtenu le même résultat, je passe pour la compréhension.
J’ai donc effectué la dernière requête, j’ai obtenu :
concat('alter table ',table_schema,'.',table_name,' DROP FOREIGN KEY ',constraint_name,';')
alter table jeedom.cmd DROP FOREIGN KEY fk_cmd_eqLogic1;
alter table jeedom.eqLogic DROP FOREIGN KEY fk_eqLogic_jeenode1;
alter table jeedom.eqLogic DROP FOREIGN KEY fk_eqLogic_object1;
alter table jeedom.history DROP FOREIGN KEY fk_history_cmd1;
alter table jeedom.historyArch DROP FOREIGN KEY fk_historyArch_cmd1;
alter table jeedom.object DROP FOREIGN KEY fk_object_object1;
alter table jeedom.plan DROP FOREIGN KEY fk_plan_planHeader1;
alter table jeedom.plan3d DROP FOREIGN KEY fk_plan3d_plan3dHeader1;
alter table jeedom.scenario DROP FOREIGN KEY fk_scenario_object1;
alter table jeedom.scenarioExpression DROP FOREIGN KEY fk_scenarioExpression_scenarioSubElement1;
alter table jeedom.scenarioSubElement DROP FOREIGN KEY fk_scenarioSubElement_scenarioElement1;
alter table jeedom.viewData DROP FOREIGN KEY fk_data_zone1;
alter table jeedom.viewZone DROP FOREIGN KEY fk_zone_view1;
Désolé pour mon ignorance, pas très à l’aise avec les lignes de commande : comment on supprime ces foreign key du coup ? Juste lancer chaque ligne individuellement ?
Du coup, ça ne reviendra pas ?
@Loic merci beaucoup pour ton aide et la correction que tu apporteras sur V4 ! Même si je n’ose pas encore passer en V4…
Il faut MTN que tu fasses
alter table jeedom.cmd DROP FOREIGN KEY fk_cmd_eqLogic1;
alter table jeedom.eqLogic DROP FOREIGN KEY fk_eqLogic_jeenode1;
alter table jeedom.eqLogic DROP FOREIGN KEY fk_eqLogic_object1;
alter table jeedom.history DROP FOREIGN KEY fk_history_cmd1;
alter table jeedom.historyArch DROP FOREIGN KEY fk_historyArch_cmd1;
alter table jeedom.object DROP FOREIGN KEY fk_object_object1;
alter table jeedom.plan DROP FOREIGN KEY fk_plan_planHeader1;
alter table jeedom.plan3d DROP FOREIGN KEY fk_plan3d_plan3dHeader1;
alter table jeedom.scenario DROP FOREIGN KEY fk_scenario_object1;
alter table jeedom.scenarioExpression DROP FOREIGN KEY fk_scenarioExpression_scenarioSubElement1;
alter table jeedom.scenarioSubElement DROP FOREIGN KEY fk_scenarioSubElement_scenarioElement1;
alter table jeedom.viewData DROP FOREIGN KEY fk_data_zone1;
alter table jeedom.viewZone DROP FOREIGN KEY fk_zone_view1;
OK, tout simplement.
C’est fait !
J’ai retenté la requête précédente :
SELECT concat('alter table ',table_schema,'.',table_name,' DROP FOREIGN KEY ',constraint_name,';')
FROM information_schema.table_constraints
WHERE constraint_type='FOREIGN KEY'
AND table_schema='jeedom';
Plus rien ne s’affiche !
Est-ce le bout du tunnel ?
En tout cas ya plus de foreign Key donc a tester
1 « J'aime »
Le démon est lancé, je vais faire tourner quelques jours pour voir si cela réapparait avant de passer sur « résolu ». Je testerai tes commandes de temps en temps.
Il me restera le problème du mode sapin de Noël lors des mises à jour mais je créerai un nouveau sujet.
Merci @Loic et @mika-nt28
Je croise les doigts pour que ce soit fini !
Passez de bonnes fêtes si jamais…
Hello !
Cela fait 2 semaines maintenant et plus aucune erreur sur la bdd ! J’ai retesté les requêtes plus haut, tout semble ok ! Je marque le sujet comme résolu et vous remercie encore.
Pour l’effet sapin de Noël lors des mises à jour, il n’y a eu aucune mise à jour à faire depuis donc je créerai un autre sujet si le problème apparait toujours.
Je n’ai pas eu d’autre requêtes sur ton deuxième problème.
C’est certainement sur ta configuration
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.