Retour béta test histolisse

Phpvarious · Juin 23, 2025, 4:03

@Pax24, je vais dédier un thread pour le test pour éviter de polluer le thread de présentation du plugin

PHP Notice

Résolu (2025-06-23 20:10:11)

~~Pour une commande numérique nouvellement ajouter, lorsque je vais sur la modale de réglage et que je « configure » cette nouvelle cmd (pas encore de lissage car nouvellement ajouter) :~~

0016|[23-Jun-2025 19:07:46 Europe/Brussels] PHP Notice:  Undefined index: arrondi in /var/www/html/plugins/histolisse/desktop/modal/cmd_reglages.php on line 190
0017|[23-Jun-2025 19:07:46 Europe/Brussels] PHP Notice:  Undefined index: arrondi in /var/www/html/plugins/histolisse/desktop/modal/cmd_reglages.php on line 223
0018|[23-Jun-2025 19:07:46 Europe/Brussels] PHP Notice:  Undefined index: arrondi in /var/www/html/plugins/histolisse/desktop/modal/cmd_reglages.php on line 249
0019|[23-Jun-2025 19:07:46 Europe/Brussels] PHP Notice:  Undefined index: arrondi in /var/www/html/plugins/histolisse/desktop/modal/cmd_reglages.php on line 279

VISUEL :

JS :

Résolu (2025-06-23 20:10:11)

Lorsqu’on ouvre la modale « réglages des commandes » puis qu’on clic sur « Configurer » d’une commande, on a bien accès a une nouvelle modale plus détaillé de la dite commande.
Par contre lorsque je ferme cette modale et que je veut reconfigurer la même commande le bouton reste inactif.

Amélioration :

Edit : Laisse tombé, je comprend pk, tu peux avoir plusieurs type de lissage

Possible de masquer les croix, cela porte a confusion, on a l’impression qu’on a mal configuré quelque chose, et vu qu’il y aura plus de place, remplacer les lettres pas le type de lissage complet ( J → Journalier ), a la limite laisser 1 croix si l’user n’a sélectionné aucun mode de lissage :

Informations Jeedom

Core : 4.4.19 (master)
DNS Jeedom : oui

Plugin : HistoLisse
Version : 2025-06-23 16:42:59 (beta)

Pax24 · Juin 23, 2025, 4:05

Oh vicieux le garçon ! J’aime ça ! Alors où précisément est-il perturbé parce que je cherche et ne trouve pas.

Phpvarious · Juin 23, 2025, 4:13

Sur le bouton Configuration :

où ici mais c’est moins méchant :

Pax24 · Juin 23, 2025, 4:17

Ces 2 éléments n’ont aucun « label » et dans la console aucun style issu de histolisse.css pourtant.

Phpvarious · Juin 23, 2025, 4:21

Pax24 · Juin 23, 2025, 4:33

Ah là oui ! un léger changement de couleur, un peu plus noir.

Pax24 · Juin 23, 2025, 5:08

Effectivement l’idée c’est de voir rapidement les lissages actifs (et on peut trier/filtrer). La croix c’est un peu violent mais un simple « - » n’est pas lisible.

Ahhhh c’est nouveau ça ! 'tin tu répares un truc ça en casse un autre ! Je vais regarder ça.

Phpvarious · Juin 23, 2025, 5:45

J’ai du mal a saisir cette partie du réglage :

en gros si je laisse 5mn, tu prends des paquets de 5 min et tu applique le mode dessus ? donc si je met moyenne, j’aurais un point histo toutes les 5 min ?
et « Doit être supérieur ou égal à l’intervalle précédent » je ne comprend pas non plus, quel intervalle ?

Pax24 · Juin 23, 2025, 6:14

Corrigé.

Corrigé.
Tout ça à jour sur le market.

Ca tombe bien j’ai du mal à l’expliquer (cela dit Age des données c’est pas mal non plus !)
Oui effectivement ce sont les points retenus donc si tu choisis 5 minutes :

on prend tous les points existants entre hh:00 et hh:05, par ex y’en à 10, et on fait la moyenne (mode) pour n’avoir plus qu’1 point au lieu des 10 sur cette période de 5mn
idem ensuite entre hh:05 et hh:10 etc…
Autrement dit c’est donc l’intervalle que tu auras en minutes entre 2 enregistrements après le lissage.
Ou encore ça te permet d’appréhender le nombre d’enregistrements qui seront stockés (5mn=12 par heure => 288 par jour => 105120 par an)

« Doit être supérieur ou égal à l’intervalle précédent » = si Horaire est en 5mn alors Journalier ne peut pas être en 1mn (on ne peut pas inventer des points, enfin si mais c’est pas le but) donc chaque intervalle doit être = ou > à celui du lissage d’avant horaire/journalier/hebdo/mensuel

Je me tâte à renommer les lissage en heure/jour/semaine/mois ce sera peut-être plus direct.

Phpvarious · Juin 23, 2025, 7:50

Je confirme les 2 corrections

Le core dans sa config, si je ne me trompe pas, l’appelle Délai avant archivage

A oui, j’avais pas pensé, encore , a l’utilisation multiple du lissage.

Pour cet exemple, tu insert quelle datetime dans la table ? hh:05 ?

Pax24 · Juin 23, 2025, 11:37

Oui mais je ne trouve pas ça très clair, délai de quoi ?
En fait je préfère âge (minimum) des données pour être lissées/archivées

C’est un des intérêts majeurs de ce plugin : la granularité des lissages via leur enchainement. Jeedom traite du général, il peux te lisser sur le jour en cours les données toutes les 1, 5 ou 10mn mais ensuite, à l’archivage, ce sera 1h sans autre choix.
Pourtant tu peux vouloir garder plus de précision pendant quelques jours (ex 5mn) pour par exemple comparer avec la veille ou le début de semaine, peut-être voudras-tu garder encore une relative précision pour le mois en cours (ex 15mn) mais ensuite tu ne veux qu’une info indicative (ex 6h d’intervalle). Ben avec ce plugin c’est possible.

Pour les datetime SQL a ses limites si on ne veut pas faire une usine à gaz, et puis il faut faire des choix, j’ai choisi de faire un floor donc d’indiquer le départ de période.
J’avais simplifier pour l’exemple mais pour être précis : avec un intervalle 5mn sur hh:00>hh:05 il va te créer 2 points en fait :
hh:00 Regroupe les données de hh:00:00 à hh:04:59
hh:05 Regroupe les données de hh:05:00 à hh:09:59

C’est pour ça que sur un lissage horaire à 22h qui va traiter l’heure 21 par exemple je fais une requête de 21:00:00 à 21:59:59 = si tu es en 5mn tes nouveaux points iront de 21h00 à 21h55 (qui couvre de fait les données entre 21h55 et 22h) et non pas 22h pour le dernier point, ce qui est cohérent avec le lissage demandé pour l’heure 21.

Phpvarious · Juin 24, 2025, 1:00

Je n’aurai pas le temps de tout tester, il faudrait effectivement d’autre béta testeur.

Cependant mes 1er essais sont très concluants,
Je trouve que c’est un plugins très intéressant avec un très grand choix de configuration possible.

Une page diagnostic au top avec un résumé qui permet de cibler instantanément les volumes, des logs très bien pensés… Bref Félicitation.

Est-ce que tu as déja imaginé pouvoir traiter les données déja archivées ? sur un one shot par exemple ?
Et est-ce que tu as déja testé sur Deb12 ?

Aurel · Juin 24, 2025, 1:03

Techniquement repasser dans le non archivé des valeurs qui sont déjà dans l’archivé ça peut se faire en 2 requêtes SQL.

Aurel · Juin 24, 2025, 1:06

Je le faisais déja mais avec un script perso

Effectivement sur des capteurs de température, ça m’arrive de regarder l’histo précis sur les derniers jours mais j’ai pas besoin de savoir quelle température il faisait à 11h32 le 12/06/2024. Donc je gardais des moyennes pour suivre l’évolution « grosse maille » de la température sans avoir besoin de précision.

Interessant qu’un plugin puisse permettre ça, j’avoue que mon script reste un peu de la bricole mais correspond bien à mon besoin

Phpvarious · Juin 24, 2025, 1:07

L’idée c’est de traiter les données déja archivé et les laisser dans la table historyArch, en gros faire comme si le plugin était là depuis le début de l’archivage de la cmd.

Aurel · Juin 24, 2025, 1:09

Oui j’entends mais bon au pire si le plugin (que je ne connais pas encore bien) ne travaille que sur le non archivé, il doit pouvoir remouliner les datas et l’archivage de la nuit suivante remettra ces données la dans l’archivé.

Phpvarious · Juin 24, 2025, 1:13

Effectivement, je n’avais pas bien saisi ton message

Pax24 · Juin 24, 2025, 4:10

On traite déjà les « archivées » avec les lissages ! (ex: mensuel qui traite sur 30j)
Mais oui je réfléchis à un mode plus large, annuel par ex, qui va traiter sur 365 jours ou bien un mode « expert » avec dates libres et sans obligation d’avoir la commande sous gestion HistoLisse au lieu de Jeedom, mais évidemment les « risques » sont plus grands donc faut border le truc. Même si le seul vrai risque c’est de perdre des données historisées parce qu’on a mis par erreur un intervalle de 1000mn au lieu de 10 ou qu’on a fait un mode maximum au lieu d’une moyenne.

Non pour la deb12 mais je ne vois pas ce qui pourrait vraiment coincer, ce n’est que du php et js.

Phpvarious · Juin 24, 2025, 5:17

C’est dans le debug, en commentant les lignes 1 a 1, l’erreur ce situe ligne 104 de histolisse.php :

echo ($cache=cache::byKey('histolisse::gestion')) ? '<br>HLgestion-> ' . $cache->getValue()['historizedCmds'][0]['display_name'] . ' date=' . substr($cache->getDateTime(), 5, 11) : null;

J’ai remplacé par

$cache = cache::byKey('histolisse::gestion'); echo (is_array($cache->getValue())) ? '<br>HLgestion-> ' . $cache->getValue()['historizedCmds'][0]['display_name'] . ' date=' . substr($cache->getDateTime(), 5, 11) : null;

et sa passe maintenant.

C’est sans doute lié a la 4.5 qui ajoute des traces du throw new Exception ligne 8 de la modale reglages.php

peut importe OS :

Faudrait masquer les cmd désactivé, en l’occurrence, pour mon exemple c’est le plugin qui est désactivé.

Pax24 · Juin 24, 2025, 7:03

Je n’ai pas testé sur des versions qui ne sont pas en prod.
Tous les trucs autour du cache ne sont qu’en beta pas en stable, de fait je m’en soucie moins.
Le truc autour de gestion des commandes m’interroge plus, mais si tu as désactivé le plugin ça me semble logique d’avoir des erreurs en voulant l’utiliser ensuite.
Cela dit là tu ouvres une fenêtre Jeedom (config de commande) donc je suppose que sur cette version il y aura une modif de son fonctionnement. Ou bien je n’ai pas compris ton message.