Pas très utile, le code de jeedom v4.4.x ne va plus évoluer. Voir les échanges qui ont suivi le bug du 1er janvier. Les PR sont visibles au besoin sur le github.
Il faudrait surtout voir si elle existe en v4.5.2 en fait.
Antoine
PS: la fonction est utilisée pour une commande historisée ?
lastChangeStateDuration(commande,valeur).
Retourne la durée en secondes depuis le dernier changement d’état à la valeur passée en paramètre. Cependant, -1 = aucun historique n’existe ou la valeur n’existe pas dans l’historique et -2 = la commande n’est pas historisée.
De ma compréhension, la valeur 1 est l’état initial.
Donc, il n’y a pas encore eu de changement de cette valeur dans l’historique. D’où le -1 en retour.
Ce qui est plus dur à expliquer, c’est pourquoi il y a 2 valeurs à 0 sans passer par 1.
Sans doute une sauvegarde de l’objet comprenant la commande sans changement de l’état et donc un nouvel enregistrement dans l’historique puisque 20:15:41 - 43419s = 08:12:02.
Quel est le résultat de la commande après plusieurs changements d’état ?
@aurel, @rootard :
Hello,
Je ne suis pas expert en php mais j’aime bien les challenges.
D’après ce que je vois sur le depot pour cette fonction, il ne faut pas que la valeur cherchée soit uniquement la plus ancienne de l’historique.
Pour sortir une valeur il faut que $nextValue (qui est la valeur plus ancienne que celle en cours vu qu’on est en array_reverse) soit différente de la cible $_value.
C’est pour ca que ca ne marche pas.
Donc @rootard pas besoin de tester en 4.5.2.
A mon avis, il y a des gens qui vont dire que c’est normal, la fonction fait ce qu’elle dit puisque ce n’est pas passé d’une valeur lambda à 1 dans l’historique.
Mais en même temps, ca ne doit pas être compatible avec la fonction qui supprime des données historique après X jours ou je dis une bétise? (là c’est une supposition je ne sais pas s’il y a une sauvegarde de la valeur précédente au moment de la suppression)
Ca me semblerait plus logique de demander un correctif de la fonction.
Merci pour vos remarques
Effectivement la succession de 2 valeurs a zero est étrange.
Il s’agit de la présence d’une device BT donc ca va m’être compliqué de reproduire le même test en v4.5.2 ceci dit je viens de le faire un autre device et j’ai volontairement modifié la dernière valeur dans la DB pour que ca soit 0 pas 1:
MariaDB [jeedom]> select * from history where cmd_id = 37788;
+--------+---------------------+-------+
| cmd_id | datetime | value |
+--------+---------------------+-------+
| 37788 | 2026-01-29 19:14:18 | 1 |
| 37788 | 2026-01-29 19:16:02 | 0 |
| 37788 | 2026-01-29 19:17:52 | 0 |
+--------+---------------------+-------+
3 rows in set (0,001 sec)
Je ne me l’explique pas mais ici ca fonctionne en v4.5.2 !
[2026-01-29 19:20:58][SCENARIO] Exécution d'un bloc code
[2026-01-29 19:20:58][SCENARIO] cmd id: 37788
[2026-01-29 19:20:58][SCENARIO] durée en s: 400
[2026-01-29 19:20:58][SCENARIO] Fin correcte du scénario
Je pense que je vais en rester la je retesterai quand je passerai ma prod en v4.5
Hello,
C’est juste que la fonction prend en compte la table historyArch en plus de la table history.
Si dans l’ensemble des 2 tables il n’y a pas de valeur 0 avant ta valeur 1 (datetime inférieur), alors la fonction renverra -1. Même dans la version Jeedom 4.5.2.
Tu dois pouvoir le vérifier facilement avec la commande SQL : SELECT * FROM history WHERE cmd_id = 37788 union all SELECT * FROM historyArch WHERE cmd_id = 37888 order by datetime desc limit 10
Ce que je voulais dire c’est que non, la présence du 1 ne suffit pas même si c’est binaire, il faut qu’il y ait un 0 antérieur au 1 pour que la fonction prenne en compte la ligne avec la valeur 1 et calcule la durée. (donc avant 19h14, là tes 0 sont après)
Tu n’as qu’à supprimer le historyArch pr la commande 37788 et tu verras le résultat de la fonction par toi-même (normalement -1).
Mais donc la fonction n’a pas changé depuis Jeedom 4.4 puisque c’était la question.
