Trop de valeurs dans un historique

Bonjour,

J’ai ajouter récemment un Shelly Em et je remonte les valeurs en MQTT.
Mon soucis c’est que jeedom à beaoucoup de mal à ouvrir les courbes car les valeurs sont stockées toutes les 2/3s en moyenne.
Je suis bien à mode lissage.

Une solution pour réduire l’historisation des données?

Merci

Bonjour.

J’ai une situation identique. Avec 5 sondes qui remontent toutes les 2 secondes.
- Sur pc, aucun problème, c’est fluide, (Jeedom sur sur un pi4, 4go, 64bits).

Mais si je veux faire un zoom depuis un mobile (Snapdragon 8 gen3 16 go de RAM) l’onglet du navigateur ce fige, impossible de remettre la main dessus. Obligé de fermer cet onglet.

Les sondes en question ne sont pas paramétrables en ce qui concerne le nombre d’informations transmises. L’avantage, c’est qu’elle sont très réactive.

Idéalement, j’aurai aimer qu’il ne soit possible de faire un point d’historique dans Jeedom qu’à la minute par exemple.

1 « J'aime »

« Idéalement, j’aurai aimer qu’il soit possible de faire un point d’historique dans Jeedom qu’à la minute par exemple. »

Oui trés bonne idée d’amelioration

Hello,

Tu utilises quel plugin ?

Bonjour,
C’était le cas en 4.3 et on ma demandé de plus le faire car ca posait soucis dans les historiques. J’avais prévenu qu’il y avait un risque si une sonde est trop bavarde mais on a pas pris en compte mon avertissement. J’avoue que la je ne sais plus trop quoi faire…

1 « J'aime »

Une possibilité c’est de supprimer l’historisation de la commande, de créer une commande supplémentaire (ou un virtuel si besoin), et avec un scénario programmé de venir écrire cette dernière à fréquence voulue avec une commande event. Cela reste du contournement, mais ça doit marcher.

2 « J'aime »

Bonjour Loïc.

Est il possible de revoir cela ?

Ou le rendre optionnel si cela est possible :

Nombre de points d’historique :
- laisser faire l’équipement (défaut)
- forcer à 1 minute
- forcer à 5 minutes
Note : cette option n’aura pas d’effet si l’équipement communique ses changements au delà des 5 minutes.

Bonjour,
Oui je vais cree la demande par contre ca sera pas avant la 4.6 (si c’est selectionné)) car toute les evolutions de la 4.5 ont deja étaient selectionnées

Edit : voila l’issue [FEAT] User can sonfigure time history to prevent too much data on history · Issue #2610 · jeedom/core (github.com)

5 « J'aime »

plugin JMQTT

super, merci

Alors, tu as de la chance, il est prévu que j’implémente ce type de fonctionnalité dans jMQTT :slight_smile:
cf : Saturation apparente du broker avec Shelly - #20 par Bad

Mais je ne sais pas pour le moment si cette fonctionnalité consistera en une simple limitation de la fréquence de réception (donc tous les messages reçus dans l’interval seront purement et simplement ignorés), ou si les messages dans un certain interval autour de la dernière valeur seront ignorés pendant ce laps de temps (donc uniquement pour les commandes info/numériques).

4 « J'aime »

Bonjour,
je venais de créer un sujet à ce propos. j’ai le même souci. Ayant beaucoup de valeurs historisées et avec des plugin bavards :

  • sondes rfx com 5’ → 30s
  • jmqqt sur onduleur 5’ → 5’’
    etc.

Mon historique est en train d’exploser et l’affichage des courbes devient très difficile.
Avez-vous une solution ?

Bonjour,
Contournement en attendant : Voir la reponse de @seb821 au dessus (sorry parfois sur firefox sous ios la fonction selection / citation ne fonctionne pas, je peux pas te la mettre)

Dans le virtuel il suffit de mettre un cron / rafraîchissement à 5 minutes en manuel (ne pas laisser en auto), pas besoin d’un scénario

1 « J'aime »

Bonjour, chez moi il y avait quand meme un problème en 4.3 avec les historiques

Bonjour,

En activant le lissage à moyen sur les historiques de type numérique, il n’y a que la journée en cours qui pose un problème, car la nuit l’archivage ne conserve qu’une donnée par heure.

Exemple :

Dans cet exemple, on voit que Jeedom archive une donnée moyenne par heure une fois par jour, au moment de la tâche d’archivage.
Et on voit, que la sonde en question, très sensible, transmet à Jeedom toutes les 2 secondes et donc le moindre changement est historisé (uniquement sur une journée).
=> Donc pas d’incidence sur la taille des sauvegardes

Le problème est, que depuis un appareil mobile, je ne peux pas faire de zoom sur ces données, car il y en a trop et cela fige le navigateur.
Sur une sonde RFXCom Oregon, qui transmet toutes les 45 secondes, avec moins de sensibilité, le problème n’est pas présent.

2 « J'aime »

Ok
j’ai des données qui arrivent toutes les 2 secondes soit 150 fois plus qu’avant donc 150 jours d’avant en 1 journée.
De plus, le moyennage d’1h ne me va pas du tout. Les 5min c’était très bien.
la charge des batteries, la prod solaire, la température moyennes sur 1h ce n’est pas idéal.

1 « J'aime »

Je n’ai pas trouvé en 4.4.6 l’ajout de la période de rafraichissement, ce sera prévu ?

La solution du cron sur un virtuel ou de modifier les plugins n’est pas terrible.
Avant, les données étaient affichées en temps réel à la fréquence d’arrivée des données mais mémorisées toutes les 5’

Maintenant soit :

  • c’est affiché et mémorisé à la vitesse d’arrivée des données
  • soit on affiche toutes les 5’ et mémorisé toutes les 5’

J’ai commencé à mettre des cron sur mes virtuels et j’ai perdu l’affichage temps réel et probablement un bon moyennage.

Merci de permettre le fonctionnement d’avant : MAJ des données à l’affichage en temps réel et historisation toutes les 5’, paramétrable pour répondre à la demande : temps réel, 1min, 5min

Est ce que le signalement d’un bogue ferait avancer ? j’ai des graphiques qui ne s’affichent plus.

Une issue existe déjà et le lien est donné plus haut, as-tu lu les posts et l’issue?

Ca n’a pas de sens de demander de rétablir. Si cela a été changé c’est suite à une demande donc si on rechange le fonctionnement dans 2 versions on recommence dans l’autre sens… tu ne regardes que ton cas perso sans te soucier des autres.

Et une « issue » n’est pas un bug et perso je ne vois pas de bug ici mais un changement du comportement voulu.

Tout le monde est libre de l’implémenter à présent, le code est ouvert.

Je ne suis pas d’accord avec ta réponse et tu te comportes comme le porte parole de Jeedom.
Ici c’est un forum d’entre-aide, la référence à mon cas perso est désagréable à lire.

Ton argument qui est un pur sophisme, ça a été demandé, ça a été fait donc c’est bien n’est pas recevable.

Je ne devrais pas répondre car ça peut s’envenimer et je ne suis pas chef et le chef a toujours raison et il a des moyens que je n’ai pas.

Maintenant sur le fond :
Un affichage qui fonctionnait mais qui ne fonctionne plus n’est pas un bogue, alors je ne sais pas ce qu’est un bogue, si c’est ça, alors il n’y a plus beaucoup de bogues dans Jeedom. C’est mon gros souci.

Ma sauvegarde qui a doublé en 2 semaines, je ne cours pas à un blocage ?

Les utilisateurs n’ont pas été averti d’un changement qui a de grosses conséquences sur l’affichage et qui, pour être corrigé, nécessite des compétences expertes sur Jeedom.

Ca je n’ai pas compris « l’implémenter » c’est à dire que j’ai les moyens de revenir au fonctionnement d’avant ?

Merci pour ton plugin.
Chez moi c’est lui qui provoque la surcharge des interfaces dû au changement de fréquence mais c’est le core qui a changé et en plus sans prévenir.
Je suggère :

  • afficher en temps réel comme le faisait le core
  • sauvegarder à une certaine fréquence : temps réel, 1min, 5 min comme la suggestion ci-dessus mais avec un moyennage temporel cad une moyenne pondérée par le temps où la donnée est identique.