Bonjour,
Je viens de faire 3 modifications lourde en alpha/beta (pour l’avoir il faut forcer une mise à jour de jeedom meme si il ne vous propose rien).
La première au niveau de la gestion de l’archivage de l’historique, avant tout le lissage était fait en php (donc 12 calcul par commande avec un lissage sur 2h soit 36 requêtes en database [1 recuperation de la valeur,1 insertion dans l’autre table, 1 suppression des valeurs inutile), ça consommer pas mal de ram d’après certain retour utilisateur. Maintenant c’est 2 requêtes en tout (1 calcul puis écriture dans l’autre table, 1 suppression des anciennes valeur). Chez moi ca semble ok la seule conséquence c’est que les points ne sont plus a heure fixe mais dépendent du datetime de la 1er valeur a lisser (je pense pas que ça soit gênant surtout comparé au gain)
la deuxieme est liée a ce sujet : Retro-programmation avec un bloc A - #7 par Loic. J’ai expliqué dedans la modification, ce qu’il faut surveiller c’est les scénarios qui utilise des calcul. Je peux absolument pas connaitre les conséquences (trop d’implication). Donc mettez a jour et surveillez
la 3eme dans la configuration de jeedom partie OS/DB dans databases sur le nettoyage maintenant ça nettoie les commandes ayant des historiques qui n’existent plus ou ne devraient plus être historisées
Merci a tout ceux qui prendront le temps de mettre a jour et de tester
J’ai mis à jour et je crois que ca impacte la fonction value() dans les scénarios. Elles donnent un résultat vide sur mes scénarios interrupteur loxone, juste avant c’était bon j’avais la valeur de la commande.
Salut,
Merci pour le retour je me demande si c’est pas le même soucis que ludo m’a remonté (une histoire de quote automatique). Je viens de pousser une correction en alpha/beta si tu peux tester.
@Loic en fait non c’est pas bon toujours, effectivement le ‹ › a disaparu, mais du coup ca me garde les anciennes valeurs des variables
Pour que ce soit plus parlant, voilà ce que j’ai en entete de scénario :
(je fais ca car j’ai le meme scénario pour toutes les pièces, ca m’évite de mettre le nom de chaque interrupteur dans les scénarios et le garder générique en récupérant le trigger puis sa valeur. Pareil en test direct le value(#trigger#) ne marche pas, mais ca bien avant ta modif, juste c’est pour ca que mon scénario est comme ca
Il a toujours été vide, du moins depuis décembre que je bascule mes interrupteurs Loxone dans Jeedom pour gérer via des scénarios toutes les possibilités.
value(#trigger#) → vide, du coup je fais cet entete ou je met le nom du trigger en variable triggerN, puis je fais un value(interrN) et ca ca marche ca me retourne la valeur de ma commande qui a déclenché le scénario.
Avec ton changement hier, la variable interr retournait « » (dernier screen, on voit "Affectation de la variable interr => « » = « »). Puis elle était testé à « » == … Donc contenant toujours le double quote.
(dernier screen)
Aujourd’hui elle est affecté à vide, puis quand je la teste elle donne la dernière valeur « correcte » (d’hier j’ai l’impression).
(avant dernier screen, on voit une affectation interr => =, alors qu’après le test variable(interr) == 11, dans le log est vu comme 30 == 11)
Normalement elle prend pour valeur 31, 12, 21 … la valeur de mon interrupteur. Côté log Loxone j’ai bien les events avec les bonnes valeurs. Et le log du scénario par exemple est bien déclenché une fois par pression de l’inter.
Exemple :
Côté plugin je recois mon evenement, je fait le checkandupdatecmd avec en valeur 31 (pour info, c’est des commandes infos de types numériques). Ca c’est bon dans le plugin.
Le scénario est bien déclenché à ce moment là oui, donc l’event est vu.
Mais dans le scénario, quand je vois le log du set variable, il me dit "=> = ", donc vide
Et après lors des tests avec cette variable, il prend 30 en valeur, ce qui est la dernière valeur hier avant modif je pense.
Peut importe la valeur que je déclenche avec mon interrupteur (ca va de 10 à 52), la variable n’est plus setté correctement et donc les tests derrière sont foireux
Ok je vois avant yavait une double évaluation ce n’est plus le cas maintenant. Par contre je comprend pas pourquoi tu veux faire un value(#trigger#) qui pour moi ne doit pas marcher alors que tu peux sois utiliser :
triggerValue() (documenté ca)
#trigger_value# (non documenté mais je viens de corrigé en alpha/beta)
J’étais passé à côté de triggerValue() et #trigger_value#.
Par contre, j’ai mis à jour, et essayer les 2, ca raccourci mon scénario et plus d’utilisation de variable mais il fait toujours n’importe quoi.
Si j’appuie sur mon inter, bouton haut gauche en simple clic, Loxone m’envoit 11, puis 10 (retour à 0 en gros)
Dans les logs du plugin, j’ai bien ca :
Mais, dans le scénario, les 2 déclenchements à cette occasion … il me dit que c’était 10 et 10
Premier (qui devrait etre 11) :
Deuxième (qui devrait etre 10, donc lui est ok) :
Tu peux le voir au timestamp, les actions ont que 2s d’écart.
Quand je regarde mon historique, pour les appuis fait à l’instant, il me fait des moyennes ???
Genre là je trouve très peu de points alors qu’il y a eu beaucoup d’appuis (tests obligent). Et les points sont forcément des moyennes car l’interrupteur m’envoit forcément des entiers :
Ok en faite c’est trop rapide le changement d’état la le temps qu’il lance le scénario et regarde la valeur de la commande tu es déjà repassé a 10… Tu peux essayer de le mettre en mode scénario rapide peut être que ça aidera
Pour l’historique c’est normal a moins d’être en mode sans lissage il est forcément moyenné sur 5min pour les valeurs numériques
------------------------------------
[2020-01-17 12:39:27][SCENARIO] Start : Lancement provoqué par le scénario : [Scénario][X Tests][tmp1]. Tags : {"#msg#":"\"toto 1239\""}
[2020-01-17 12:39:27][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-01-17 12:39:27][SCENARIO] Affectation de la variable toto => ici "toto 1239" = ici "toto 1239"
[2020-01-17 12:39:27][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-01-17 12:39:27][SCENARIO] Evaluation de la condition : ["ici "toto 1239"==""] = "ici "toto 1239"==""
[2020-01-17 12:39:27][SCENARIO] Expression non valide : "ici "toto 1239"==""
[2020-01-17 12:39:27][SCENARIO] Fin correcte du scénario
Ce genre de scénario ne posait pas de souci avant…
@Loic Oui je trouve que ta correction va dans le bon sens. Par contre, la version précédente masquait autre chose encore à mon avis… Je ne vois pas comment en partant de deux chaines ici et « toto 1239 » (avec 2 " si j’en crois la log) on arrive à une valeur avec un nombre impaire de quote … : "ici « toto 1239 »
Donc forcément l’évaluation dans le scénario est perdue
Il n’y a pas encore une concaténation forcée avec une " au début de chaîne quelque part ?
Si si ca tu peux le desactiver en desactivant les quote automatique dans la configuration de jeedom. Pas sur que ca vienne de la mais ca se test. Attention aux impacts a coté.
ça ressemble bien à ça puisque j’ai bien mes 2 " seulement…
------------------------------------
[2020-01-17 16:18:28][SCENARIO] Start : Lancement provoqué par le scénario : [Scénario][X Tests][tmp1]. Tags : {"#msg#":"\"toto 1618\""}
[2020-01-17 16:18:28][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-01-17 16:18:28][SCENARIO] Affectation de la variable toto => ici "toto 1618" = ici "toto 1618"
[2020-01-17 16:18:28][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-01-17 16:18:28][SCENARIO] Evaluation de la condition : [ici "toto 1618"==""] = ici "toto 1618"==""
[2020-01-17 16:18:28][SCENARIO] Expression non valide : ici "toto 1618"==""
[2020-01-17 16:18:28][SCENARIO] Fin correcte du scénario
L’effet négatif c’est qu’ai des alertes partout ailleurs… notamment avec les regex sur matches par exemple Expression non valide [#4447# == "Off" AND #4426# == 1 AND #4309# matches "/.*Présence*|.*Retour.*/i"] trouvée dans le scénario : [Scénario][Volets - Fonctions][Canicule Auto], résultat : == "Off" AND 0 == 1 AND Retour matches "/.*Présence*|.*Retour.*/i"
Solution (pas belle), ajouter dans le quotage automatique de quoi compter le nombre " et compléter pour avoir un nombre paire ?
