Relance systématique des scenarios suite à mise à jour du core

Je l’entends bien mais comment expliquer quand laissant certaines commandes sur automatique, nous avons une charge CPU plus importante alors quand les passant toutes à ne jamais répéter, la charge CPU revient à la normale avant la mise à jour…

Comment expliquer… en analysant (au cas par cas)

Regardez l’activité de Jeedom dans le log event et vous aurez une idée de ceux qu’ils faut explicitement mettre en [Jamais répéter].

1 « J'aime »

C’est que j’avais commencé à faire au début mais j’ai tout mis à ne jamais répéter (via le code de @naboleo) car j’avais des commandes qui n’étaient en aucun cas utilisés et « elles foutaient la m… »

Mais bon ce qui compte c’est que nos Jeedom fonctionnent après c’est un peu chaotique comme mise à jour… (avis perso !)

Hello,

Bon peut être une question con … :see_no_evil:

J’ai suivi le topic, et j’ai une remarque par rapport à ton post.

J’ai regardé dans les logs event, remarqué des choses que j’ai passé en « jamais répéter » et la charge CPU semble avoir baissé (sauf celle affichée à 1 min), donc dans mes logs event, il me reste :

T°, Humidité, Luminosité, présence du nut, etc …

On est d’accord que ces infos la doivent rester en automatique ?

Merci pour tes infos

Oui c’est que ce qui est binaire qui a été modifié. Le reste n’a pas changé de fonctionnement (non répété par défaut)

1 « J'aime »

Ok, mais par exemple pour le nut qui gère la présence, c’est binaire, mais si je le passe en « jamais répéter » est ce qu’il va encore remonter sa valeur ?

Alors si j’ai bien compris oui mais comme sa valeur n’aura pas changé il ne relancera pas l’action qui lui est « collée ».

2 « J'aime »

Ok, merci pour ta réponse.

Bon au moins cette mise à jour a eu le mérite de me faire creuser un peu le sujet,.

Je vais voir ce qui charge encore mon CPU, je n’ai jamais trop cherché à optimiser mon jeedom et je suis sur que j’ai des actions inutiles

EDIT : Merci à tous pour ce post (ceux qui râlent comme ceux qui aident) car il m’a permis de me plonger un peu plus dans l’optimisation de mon Jeedom et j’arrive à de bonne valeur au niveau du CPU maintenant ! :+1:

Sans titre

1 « J'aime »

Bonjour,

Les nut doivent effectivement être sur non répété.

2 « J'aime »

Hello
Avec la 4.1.24, comment modifier le code (Celui de @kiboost ou de @naboleo) afin de lister les commandes qui seraient en :
Répéter les valeurs identiques = Oui

Bonsoir.

Le script l’indique. true, false, auto

Bonsoir @Fabrice
Merci pour ta réponse, mais désolé, je ne comprends pas. Si je lance le scénario (modifié pour ne pas faire de modification)

$cmds = cmd::all();
foreach($cmds as $cmd)
{  
	$rep=$cmd->getConfiguration('repeatEventManagement','void');
  	if("$rep" == "auto" || "$rep" == "void") {
    	$scenario->setLog('Commande : '.$cmd->getHumanName().' '.$rep);
    }
}

J’obtient :

[2021-07-21 17:17:06][SCENARIO] Commande : [Réseau ][IPX Garage][Last Time] void
[2021-07-21 17:17:06][SCENARIO] Commande : [Réseau ][IPX Garage][Last Date] void
[2021-07-21 17:17:06][SCENARIO] Commande : [Réseau ][Eco Device][IpV4] void
[2021-07-21 17:17:06][SCENARIO] Commande : [Réseau ][Eco Device][Last IpV4] void
[2021-07-21 17:17:06][SCENARIO] Commande : [Réseau ][Eco Device][Last Time] void
[2021-07-21 17:17:06][SCENARIO] Commande : [Réseau ][Eco Device][Last Date] void
....

Les configs en base sont identiques pour ce que j’avais vu.
« Void » c’est la valeur par défaut que tu as mise, donc cela veut dire que tes commandes n’ont pas de config, ce qui veut dire « ne pas répéter » depuis la 4.1.24.

Par contre il y a un bug dans ton script, $rep ne doit pas être entre guillemets.

Effectivement, pour les guillemets, c’est évident en regardant de plus près.
Par contre, je ne comprends pas si je relance sans les guillemets, par exemple pour la commande : [Piscine][Ondilo][Niveau de la batterie]
j’obtient :

[2021-07-21 17:33:32][SCENARIO] Commande : [Piscine][Ondilo][Niveau de la batterie] void

alors que dans la conf j’ai :
image
Je pensais trouver des Oui ou des Non

Je précise que je n’ai pas de problème de relance de scénario, j’ai posté dans ce fil car je suis parti du scénario de @naboleo, alors que j’aurais du le mettre dans :

non, comme je disais:

donc ca sera toujours « always » et « never » (et heureusement), seul « auto » a disparu et « pas de config » est équivalent à « never » alors qu’avant c’était « auto »

donc tant que tu n’as jamais sauvé une commande cela sera « vide » et ensuite cela sera « always » ou « never » selon que tu avais choisis « oui » ou « non »

visible avec les outils dev:
image

Oui, c’est sur : heureusement pour la base inchangée.
Par contre pourqoui j’ai de « void » et pas des « never » ou des « always » dans les logs ?
Dans ma commande en exemple j’aurais du avoir : « never ». Non ?
Mon but est justement de vérifier si il y a des « always » afin de mieux les gérer.
Dans tous les cas, je te remercie de prendre du temps pour tenter de m’expliquer.

Sauve la config et alors ça sera never.
Tant que pas sauvé ça reste sur « vide »

Faut peut-être qu’il y ait une valeur qui change pour que le save se fasse.

Mais bref, si vide ça sera « never » donc c’est bon tu t’en fiches de ce qu’il y a réellement en base.

Dans le getconfig remplace "Void" par "never" et tu auras la liste de ce que tu cherches.

1 « J'aime »

bonjour à tous, j’ai bien relu le fil de discussion.

j’ai quand même une question :

l’article du mois d’octobre 2016 stipule :

Citation
Automatique
Commande Info/Binaire :
Idem Toujours répéter

pourquoi donc les différents scripts vus plus haut transforment les infos binaires qui sont en « Auto » en « Never » et non en « toujours répéter » ? Cela permettrait d’avoir exactement le même comportement avant de mettre à jour le core ?

Merci à vous

Non car le bug qu’il y avait dans le core c’est que justement les commandes binaires n’étaient pas toujours répétées alors qu’elles auraient du selon la config.
La correction du bug a donc fait en sorte que celle-ci soit toujours répétées comme c’était sensé être le cas mais cela a causé des comportements non voulu.

Mais de toute façon ceci n’a plus d’importance, il ne faut plus exécuter ces scripts avec la dernière version du core puisque le défaut est « non » à présent.

2 « J'aime »

Merci pour ta réponse.
Pour ma part, je suis toujours en 4.1.22 (correction du bug non appliquée du coup)
comment dois je donc m’y prendre ?
si je fais la mise à jour en 4.1.25, les « auto » vont se transformer en quoi ?
vais je retrouver le même comportement qu’avant la mise à jour ?

Merci beaucoup

1 « J'aime »