[RESOLU] Cron - History Archive - Nut Blea - perte à 5h du matin

[TaG]

Bonjour,

Je viens vers vous en esperant poster au bon endroit.

J'ai une surveillance de la présence de mes nuts (plugins blea) qui m'indique, quand je suis rentré, ou quand je suis partit de la maison.

Il s'avère que tous les jours, on est considéré comme étant revenu à la maison à 05h du matin.

C'est assez sournois à comprendre, je vais tenter de m'expliquer le mieux possible.

Je suis présent chez moi par exemple depuis le soir d'avant, disons 20h00, le matin quand je pars, disons 08h00, je devrais avoir un message telegram qui me dit que je le nut a disparu, il était présent depuis 12h
Sauf que j'aurais un message me disant : le nut a disparu, il était présent depuis 03h (08h-05h du matin)

Je n'ai rien dans le log blea expliquant ce phénomène à 05h du matin
Je n'ai rien dans les logs des plugins utilisant une connexion USB (z-wave / APC-UPS / Téléinfo) à 05h du matin
J'ai regardé également à 04 et 06h au cas ou il y ait un quelconque décalage horaire, bien que ma VM soit à l'heure.

Voici le scénario concernant la surveillance de mon nut par exemple :




La ligne de calcul :
Calcul numéro 1 : lastChangeStateDuration(#[Monitoring][Nut-P-Y][Present]#,0)/3600
Calcul numéro 2 : lastChangeStateDuration(#[Monitoring][Nut-P-Y][Present]#,1)/3600


Le nut n'est pas considéré absent dans l'historique jeedom à 05h du matin :


Dans le cron, j'ai trouvé ceci :


Je ne sais pas à quoi sert exactement cette tâche, mais ce qui est sur, c'est qu'elle avait bien tournée ce matin à 05h.

J'ai donc tenté le test suivant, les heures sont modifiés pour plus de simplicité.
Mon nut est présent depuis 11h58
12h20 je lance le cron

12h22 je fais disparaitre mon nut, ça prend un peu de temps (moins de 3 minutes) avant qu'il soit considéré comme non présent par le plugin blea, ça c'est normal.
12h24 je reçois sur telegram un message m'indiquant que mon nut est absent depuis : 0.43heures, donc plutôt logique, ça fait un peu moins de 30 minutes (0.5h pour 30 minutes)

Donc, malgrès le cron lancé manuellement, l'état de mon nut est bon, sont historique aussi.

Mais je n'arrive pas à trouver pourquoi pile poil à 05h du matin sa valeur d'historique est supprimée.


J'ai eu un phénomène surprenant avec un autre nut (il me permet d'ouvrir mon portail sur des conditions bien précises) ce nut n'avait pas bougé depuis la restauration de mon dernier backup il y a quelques jours.
En lancant le cron manuellement, ce nut a été considéré comme présent. pourtant le cron avait tourné cette nuit...


Je ne sais pas si le fait de l'avoir lancé à la main va aider ou non.

Je verrai le comportement demain matin, si mes nuts sont considérés comme absent depuis le soir d'avant c'est parfait, si ça n'est pas le cas, je ne sais pas ou je chercher. et aimerait votre aide si possible.


Car j'ai fais le tour de ce que je peux imaginer.

Configuration de l'historique (je n'ai rien touché de mon coté)



L'options qui me reste en tête est la suivante :
Vider le cache, ou nettoyer le cache, mais je ne sais pas du tout les impacts /effets sur jeedom :


Merci d'avance pour votre aide

[TaG]

Hello,

Même cas ce matin...

Je n'arrive vraiment pas à voir d'où ça peut venir.

J'ai en l'état, désactivé le cron history archive. Je verrai ainsi demain, si j'ai le même comportement.
- Si ce n'est pas le cas, ça mettra un point sur le fait que c'est dans le cron history qu'il se passe quelque chose.
- Si c'est le même comportement, je chercherai donc ailleurs.

Si une ame dévoué avec un nut pouvait tester mon scénario ça serait top .

Merci d'avance si vous avez une autre idée ou rencontrez le même phénomène ?

TaG

[tomdom]

Bonjour,

En testant la fonction lastChangeStateDuration sur l'état de mes sondes de T°, j'ai le même comportement que toi sauf pour une sonde. Sur cette sonde, j'avais laissé la gestion de la répétition des valeurs à automatique, alors que sur les autres j'ai mis à ne jamais répété. C'est la seule différence de configuration que j'ai trouvé.

Par contre la fonction lastStateDuration n'est pas affecté par le problème

[tomdom]

Bonjour,

En décortiquant la requête faite lors de l'appel de cette fonction, il y a bien un souci. C'est

Code : Tout sélectionner

$sql = 'select min(`datetime`) as lastCmdDuration ....

et non

Code : Tout sélectionner

$sql = 'select max(`datetime`) as lastCmdDuration ...

qui doit être fait.

Édiit : Cette correction n'est pas bonne. Elle ne tient pas compte des changement fait après 5h00 du matin.

@TaG ton analyse est bonne, ma correction nom

[TaG]

Salut tomdom,

Merci pour ton retour. De mon coté, les nuts sont en automatique pour la répétition de la valeur.

J'ai mis un nut dans le doute sur Toujours répété, mais c'est le comportement par défaut de mémoire sur les nuts.

Je verrai ce que ça donne demain.
Soit j'ai tout niquel, et on peut envisager que ça soit le cron history archive.
Soit j'ai que mon nut et ça serait la répétition de valeur
Soit j'ai toujours le problème et c'est autre chose

Je vous tiendrais au courant de la suite !

[TaG]

Bonjour,

En décortiquant la requête faite lors de l'appel de cette fonction, il y a bien un souci. C'est

Code : Tout sélectionner

$sql = 'select min(`datetime`) as lastCmdDuration ....

et non

Code : Tout sélectionner

$sql = 'select max(`datetime`) as lastCmdDuration ...

qui doit être fait.

Édiit : Cette correction n'est pas bonne. Elle ne tient pas compte des changement fait après 5h00 du matin.

@TaG ton analyse est bonne, ma correction nom

je n'avais pas vu ton message, j'ai commencé à répondre, et ensuite j'ai eu une perturbation de type enfants à gérer .

Mon analyse est bonne et pas ta correction ? qu'entends-tu par là ?

j'ai un peu de mal à comprendre pour le coup.

Merci

[tomdom]

Bonjour,


D'après mes tests, c'est bien l'history Archive.

Je pense avoir ce coup-ci la bonne correction (j'ai testé avec des valeurs qui ont changé depuis ce matin et des valeurs qui n'ont pas changé depuis plusieurs jour)

Pour les développeurs du core

COALESCE pour trouver l'état précédent de l'état actuel pose problème car si il n'y a pas eu de changement d'état depuis le passage d'history Archive dans la table history , ça retourne quand même une valeur et masque donc la valeur de la table historyArch.

J'ai remplacé :

Code : Tout sélectionner

$sql = 'select max(`datetime`) as lastCmdDuration
                from (
                        select min(`datetime`) as datetime
                        from `history`
                        where `cmd_id`=:cmd_id and `value`=:value and
                        `datetime` > COALESCE((select max(`datetime`) from `history` where `value`!=:value and `cmd_id`=:cmd_id and `datetime` < (select max(`datetime`) from history where `cmd_id`=:cmd_id and `value` =:value)),1) and
                        `datetime` <= COALESCE((select max(`datetime`) from history where `cmd_id`=:cmd_id and `value` =:value),now())
                        union all
                        select min(`datetime`) as datetime from `historyArch`
                        where `cmd_id`=:cmd_id and `value`=:value and
                        `datetime` > COALESCE((select max(`datetime`) from `historyArch` where `value`!=:value and `cmd_id`=:cmd_id and `datetime` < (select max(`datetime`) from historyArch where `cmd_id`=:cmd_id and `value` =:value)),1) and
                        `datetime` <= COALESCE((select max(`datetime`) from `historyArch` where `cmd_id`=:cmd_id and `value`=:value),now())
                        ) as t';

par

Code : Tout sélectionner

$sql = 'select max(`datetime`) as lastCmdDuration
                from (
                        select min(`datetime`) as datetime
                        from `history`
                        where `cmd_id`=:cmd_id and `value`=:value and
                        `datetime` > (select max(`datetime`) from `history` where `value`!=:value and `cmd_id`=:cmd_id and `datetime` < (select max(`datetime`) from history where `cmd_id`=:cmd_id and `value` =:value)) and
                        `datetime` <= COALESCE((select max(`datetime`) from history where `cmd_id`=:cmd_id and `value` =:value),now())
                        union all
                        select min(`datetime`) as datetime from `historyArch`
                        where `cmd_id`=:cmd_id and `value`=:value and
                        `datetime` > (select max(`datetime`) from `historyArch` where `value`!=:value and `cmd_id`=:cmd_id and `datetime` < (select max(`datetime`) from historyArch where `cmd_id`=:cmd_id and `value` =:value)) and
                        `datetime` <= COALESCE((select max(`datetime`) from `historyArch` where `cmd_id`=:cmd_id and `value`=:value),now())
                        ) as t';

[TaG]

J'aime ton post, je comprends les grandes lignes . Mais c'est tout

je me renseigne sur ou proposer ce push
si tu peux me dire quel fichier tu as modifié ? comme ça je pourrai dans le github de jeedom aller proposer le push
et voir si il n'y a pas de contre indications

En tout cas, je n'étais donc pas fou, si c'est bien validé par Jeedom, et que ça ne met pas de soucis ailleurs, ce dont je doute quand même vu la table qui est appelée.

[tomdom]

Bonjour,

C'est la méthode lastChangeStateDuration (donc les effets sont limités à l'appel de cette fonction) du fichier history.class.php

Par contre la correction précédente peut avoir pour effet que si la valeur n'a jamais changé, la fonction retourne une date erronée.

J'en propose donc une autre (c'est la dernière ) qui elle ne posera problème que les premières 24h d'historisation (si il n'y a pas de changement de valeur, jusqu'au passage du premier history archive)

Code : Tout sélectionner

$sql = 'select max(`datetime`) as lastCmdDuration
                from (
                        select min(`datetime`) as datetime
                        from `history`
                        where `cmd_id`=:cmd_id and `value`=:value and
                        `datetime` > (select max(`datetime`) from `history` where `value`!=:value and `cmd_id`=:cmd_id and `datetime` < (select max(`datetime`) from history where `cmd_id`=:cmd_id and `value` =:value)) and
                        `datetime` <= COALESCE((select max(`datetime`) from history where `cmd_id`=:cmd_id and `value` =:value),now())
                        union all
                        select min(`datetime`) as datetime from `historyArch`
                        where `cmd_id`=:cmd_id and `value`=:value and
                        `datetime` > COALESCE((select max(`datetime`) from `historyArch` where `value`!=:value and `cmd_id`=:cmd_id and `datetime` < (select max(`datetime`) from historyArch where `cmd_id`=:cmd_id and `value` =:value)),1) and
                        `datetime` <= COALESCE((select max(`datetime`) from `historyArch` where `cmd_id`=:cmd_id and `value`=:value),now())
                        ) as t';

[TaG]

Oki doki

Merci pour ton aide, je vais l'appliquer chez moi, remettre le cron en route, remettre la répétition de valeur à automatique sur mon nut.
J'aurais l'information demain

[Bosquetia]

@tomdom tu peux pousser cela sur le github ?
ici cela risque de ne pas être vu

[TaG]

je peux m'en occuper si tu veux tomdom, tu as déjà fait le boulot, je peux le finir, comme tu le sens, même si tu es 1 000 fois meilleur que moi sur github je pense ,
j'ai mon tuto au chaud pour les push

[tomdom]

Je veux bien que tu t'en occupes @TaG. Git ça va, par contre Github non (j'ai vu ton tuto, mais je ne l'ai pas encore mis en oeuvre. C'est dans ma todo )

Merci

[TaG]

ok, je m'en occupe

[TaG]

Re,

C'est fait : https://github.com/jeedom/core/pull/835

J'en ai profité pour pousser ce tuto également : viewtopic.php?f=57&t=9057&p=540968#p540968

Merci encore pour ton aide tomdom !!!

[TaG]

Loic à fait le merge sur le PR.

Un énorme merci . je sais que ça sera que dans la prochaine release ou celle d'après, mais c'est super cool .

Si tu me lis, merci Loic

[TaG]

Hello

Merci tomdom !!!!!

Ce matin, le nut est bien indiqué comme ayant été présent plus de 12 et plus de 14h00 !!! Ce qui colle parfaitement avec les heures de retour d'hier et de départ !!!!


Merci merci merci

[tomdom]

Bonjour,

Tu n'as pas fait un PR pour rien

[TaG]

Non, mais tu n'as pas trouvé le correctif du code pour rien non plus.

Pousser un PR était simple, corrigé et comprendre le code, moins

[Bosquetia]

Hello,

Super... il faudra donc penser à le passer en [Résolu] si vous êtes d'accord