j’utilise ce scénario depuis des années, mais depuis quelques temps, je remarque que sur certains scénarios, le passage du message (ou d’autres tags) ne s’effectue pas entre deux scénarios.
par exemple, j’ai un scénario qui gère la filtration de la piscine (début, fin) qui génère une variable message_TTS que je passe par un tag message à un scénario qui gère l’envoi sur les tablettes en TTS via :
tts=1 message=variable(message_TTS) important=0
des fois, ça marche, j’ai le bon message ; des fois j’ai le message de l’envoi précédent qui peut avoir lui 2h avant !
par exemple, le scénario qui gère la fin ou le début de filtration lance un scénario de notification avec le tag message qui reçoit le message généré par le scénario
sauf que dans le scénario de notification, il n’y a pas le message reçu mais il a toujours l’ancien message envoyé par un autre scénario qui gère le lave-linge 1h avant…
On voit bien le message du lave linge à 16h50 et l’appel par le scénario de la piscine ensuite, sauf que le transfert du message n’a pas lieu.
La moyenne de la charge CPU parait élevé:
Le premier nombre indique la moyenne pour la minute en cours, le second pour les 5 dernières minutes et le troisième pour les 15 dernières minutes.
Mon Jeedom a plus de 8 ans (j’ai même un doute pour 10)… et j’ai pas mal d’infos que je garde en partie pour l’élec, l’eau etc.
J’ai pas mal de scénario qui tourne à la minute; faudrait que je refasse une passe à l’occasion.
Par contre, j’ai largement de quoi fournir cette puissance côté serveur. Donc pour moi ce n’est pas une question de charge. Même si je suis preneur toujours d’info, de retour ou autres
Salut,
Un truc qui me chagrine et qui ne doit pas aider à démêler le « sac de noeud »;
pourquoi utliser une variable pour ensuite la passer dans un tag pour l’envoyer dans un autre scénario.
une variable c’est globale (et les variables globales c’est à bannir, c’est interdit!)
pourquoi ne pas mettre ton message dans un tag et ne travailler que avec des tag; les tags sont toujours propre à un scénario, tu ne risques pas de télescoper 2 scénarios qui utiliserait la même variable et « se marcheraient sur les pieds »
Effectivement, bonne remarque @Mips merci !
J’ai pensé à ça, mais avant d’ouvrir le post, j’ai regardé le log pendant plusieurs jours et je n’ai jamais eu de double lancement.
Je vais déjà essayer de modifier le scénario en affectant par le tag à la volée et voir si ça marche.
A noter qu’hier, je n’ai aucun souci sur les notifications TTS.
Je connais le principe des variables globales ou locales. Mais certaines globales sont bien nécessaires pour pouvoir travailler entre plusieurs informations ou scénarios.
Par exemple, sur ce type de scénario où j’affecte la variable en fonction des conditions, je me vois mal mettre un appel à un scénario à chaque fois ; c’est lourd non ?
Il y a de fortes chances que ce soit les historiques qui prennent de la place (les tables history et historyArch) mais ça peut aussi être un plugin qui stocke beaucoup d’infos dans des tables qui lui sont propres.
Comme l’a indiqué @Bonjour le top est le script de @ngrataloup pour analyser.
Tu peux toujours déja juste lancer la requete SQL suivante pour avoir un premier état avant de rentrer dans le détail :
SELECT table_name AS `Table`, round(((data_length + index_length) / 1024 / 1024), 2) `MB`,table_rows as `Ligne` FROM information_schema.TABLES WHERE table_schema='jeedom' ORDER BY (data_length + index_length) DESC
Ca t’affichera les tables avec leur taille et le nombre de lignes qu’elles contiennent trié par la taille qu’elles occupent.
Le problème c’est que je n’ai pas forcément la main dessus.
J’ai fait un nettoyage de DB, toujours bon à prendre (et bon outil !) mais pas forcément un gros nettoyage…
A défaut, grâce au code du scénario, j’ai quelques pistes pour les informations etc. Mais pour les tables, là, je n’ai pas forcément la main. A voir si j’ouvre un sujet dédié avec le mainteneur du plugin.
Pour revenir au sujet, je vais déjà faire les modifs de scénario et voir si ça marche correctement.
Merci, bonne idée. Encore un plugin à acheter, à configurer etc. L’idée est bonne, mais on arrête jamais en 10 ans ! Il s’agit bien de « HistoLisse » ? Je vais tester, la documentation semble pas mal.
J’ai fait les modifications pour le TTS, je verrai si c’est bon. J’ai quand même quelques scénarios où je garde la variable car c’est une succession de conditions et c’est plus simple à gérer.
Par contre, j’ai tenté d’utiliser la fonction nettoyage après avoir désactivé quelques historisations que j’avais loupé et qui prenait de la place (9) mais j’ai une erreur dans le log :
5134|Remove cmd (no corresponding eqLogic found) : [Poids]
5135|PHP Fatal error: Uncaught Error: Call to a member function setStatus() on bool in /var/www/html/core/class/cmd.class.php:1128
5136|Stack trace:
5137|#0 /var/www/html/install/cleaning.php(49): cmd->remove()
5138|#1 {main}
5139|thrown in /var/www/html/core/class/cmd.class.php on line 1128
C’est pas joli joli que le plugin ait viré l’équipement logique et pas les commandes …
Perso je ferais un DELETE en SQL pour supprimer tout ça dans la base mais c’est un peu violent et pas forcément trop propre non plus. Mais bon dans ton cas ça le sera toujours plus que de laisser des commandes sans équipement associé.
Alors déja, tu peux lancer ça pour vérifier que ça te sort bien les mêmes ID de commande.
SELECT id FROM cmd WHERE eqLogic_id = 1891
Si c’est bon tu peux passer les 3 req suivantes une par une et dans cet ordre. Je te conseille de faire un backup de jeedom avant au cas où
DELETE FROM historyArch WHERE cmd_id IN (SELECT id FROM cmd WHERE eqLogic_id = 1891);
DELETE FROM history WHERE cmd_id IN (SELECT id FROM cmd WHERE eqLogic_id = 1891);
DELETE FROM cmd WHERE id IN (SELECT id FROM cmd WHERE eqLogic_id = 1891);
1ere et 2e lignes suppression de tous les cmd_id dans les tables d’historique
3e ligne suppression dans la table cmd
Je te conseille de faire un backup de jeedom avant au cas où