Je viens d’installer Sqlite-web pour voir un peu comment optimiser ma base de données qui est énorme, je viens de m’en rendre compte, là c’est une urgence qu’elle diminue. Je ne parviens pas à le faire fonctionner.
Lorsque je fais ça :
J’ai aussi essayé via Terminal, mais ça na fonctionne pas non plus :
Vous faites comment???
Installe l’application sur un PC et copie ta DB sur le PC. Quand ta une DB trop grosse avec l’addon ca peu merder.
Plus de 17G, même ton PC va souffrir
Merci WarC0zes, j’ai pu accéder aux données, et en effet le PC a mis un temps fou !
Bonjour à tous
De base j’utilise mariaDB et j’ai constaté que la taille de la base grandissait très vite (15G0 en 5 jours). En regardant avec phpmyadmin j’ai vu que pour de nombreuses lignes, l’état était déclaré comme Unknown.
Pour comprendre ce qui se passe, j’ai installé sqllite web et la base par défaut et j’ai regardé les 20 entités les plus stockées.
En revanche, je n’y connais rien en requête Sql.
Quelqu’un saurait-il m’indiquer la requête pour identifier les entités pour lesquelles la valeur est unknow ?
En vous remerciant par avance
Bonjour @Merangle ,
Une recherche dans ce post t’aurait permis de trouver la réponse :
Salut
Unknow est un état valable dans HA… Toutes les entités dont l’état n’est pas réçu ou pas calculable est par défaut Unknown.
ça c’est bon pour la base par défaut, pas pour la base Mariadb…
Pourquoi ?!?!? De base, c’est pas indispensable et surtout un choix étonnant si tes connaissances sont limitées.
A mon avis, ça serait plus simple de revenir au sqllite par défaut et de travailler sur la contruction d’un recorder plus adapté et surtout ne pas stocker les entités dont on a pas besoin etc…
Bonjour
J’utilise mariadb pour la stabilité sur un serveur différent pour des sauvegardes séparées.
J’ai remis la base par défaut afin d’utiliser sql lite pour comprendre pourquoi elle augmente autant. J’ai constaté l’augmentation lors du passage de mariadb en add-on à mariadb sous proxmox.
Comme tu le dis, je suis donc revenu au sqllite pour comprendre ce qui ne va pas dans le recorder.
J’ai un peu de connaissances de sql. où peut-on trouver la structure de la base pour faire une requête qui me donne les valeurs des entités ?
En vous remerciant pour votre aide
A mon avis, c’est un gain bien relatif et surtout une grosse source d’ennuis ou d’admin supplémentaires :
Les requêtes dont tu as besoin sont contenus dans ce sujet (et dans la réponse de @Lesuperlolo ).
Oublie cette notion de ‹ valeur › c’est pas ce qui compte. De toute façon, tu ne peux pas dire que tu veux garder uniquement les valeurs numériques et ne pas tenir compte des unknown.
Tu dois simplement faire le tri (cohérent) entre les entités qui te servent (genre des conso électriques) et celles dont tu ne te sert pas (les heures par ex)… En laissant la durée de rétention 10j tu devrai avoir une base de taille stable et limitée… Ensuite à toi de vérifier que tu as les infos historiques (> 10J) dont tu as besoin également, s’il en manque, il faut corriger les entités pour ajouter les bonnes valeurs ‹ class ›
Quelque soit la base sqllite ou mariadb, là n’est pas le sujet.
Je constate que j’ai des lignes pour lesquels state = ‹ unknown › ou state =‹ unavailable › et d’autres ou le state est rempli avec une valeur.
Je me dis que les lignes unknown et unavailable ne sont pas normales et donc je cherche les entités listées dans le recorder à l’origine de ce problème pour corriger le recorder et ne stocker que des données valables.
Quand je regarde les données dans le recorder, je n’identifie pas de cas où elles sont unknown ou unavailable. D’où ma question.
et pour mon recorder le voici
recorder:
auto_purge: true
auto_repack: true
purge_keep_days: 10
commit_interval: 5
# db_url: !secret mariadb_url
db_url: sqlite:////config/home-assistant_v2.db
include:
domains:
- person
entity_globs:
- sensor.*_r_temperature_adjusted
- sensor.*_e_temperature*
- sensor.*_z_temperature
- sensor.*_z_humidity
- sensor.*_linkquality
- binary_sensor.*_home
- sensor.*_energy
- sensor.*_energy_adjusted
- sensor.*_energy_previous
- sensor.*_daily
- sensor.*_weekly
- sensor.index_total*
- sensor.wc_eau*
- sensor.vaisselle_eau*
- sensor.total_water*
entities:
- sensor.boulogne_temperature
- sensor.clecadia_temperature
- sensor.salon_temperature
- sensor.parents_temperature
- sensor.bureau_temperature
- sensor.xxxxxx_temperature
- sensor.yyyy_temperature
- sensor.cuisine_temperature
- sensor.sdb_temperature
- sensor.salon_power
- sensor.salonbis_power
- sensor.salontotal_power
- sensor.parents_power
- sensor.bureau_power
- sensor.xxxxxx_power
- sensor.yyyy_power
- sensor.cuisine_power
- sensor.sdb_power
- sensor.bureau_lumiere_power
- sensor.entree_lumiere_power
- sensor.cuisine_lumiere_power
- sensor.parents_lumiere_power
- sensor.chauffage_power
- sensor.services_power
- sensor.eclairage_power
- sensor.plaques_power
- sensor.prises_power
- sensor.eau_power
- sensor.cuisine_ecs_power
- sensor.ecs_power
- sensor.linge_power
- sensor.vaisselle_power
- sensor.sechante_power
- sensor.guirlande_power
- sensor.max_power
- sensor.microonde_power
- sensor.nas_power
- sensor.tv_power
- sensor.box_power
- sensor.talon_power
- sensor.salon_lampes_power
- sensor.salon1_power
- sensor.salon2_power
- sensor.salon3_power
- sensor.salon4_power
- sensor.power
- sensor.ampere
- sensor.puissance
- sensor.db_size
- sensor.compteur_nouveaux_departs
- sensor.compteur_nouveaux_entres
- sensor.compteur_presence
- input_boolean.porte_ouverte
- sensor.hp_semaine
- sensor.hp_mercredi
- sensor.hp_weekend
- sensor.hc_semaine
- sensor.hc_mercredi
- sensor.hc_weekend
- sensor.puissance_max_n
- sensor.puissance_max_n1
- sensor.tarif
- sensor.meranglepuissance
Si je comprends bien la req^te et le résultat, la requête ci-dessus ne donne pas les entités pour lesquelles la valeur est unknown ou unavailable.
mais l e nombre de ligne par entités
Pas directement, mais un peu quand même : accès /outils différents
Comme dit, plus haut, tu te trompes de piste… L’état n’a pas d’importance et est 100% normal.
Il faut juste le nom des entités pour configurer le recorder, les plus nombreuses sont les premières à supprimer (quelque soit l’état)
Ca a pris un peu de temps, pour tout bien régler, mais désormais, ma BDD tourne autour de 60 Mo pour 7 jours couverts.
Il faut se poser les questions suivantes :
Dans le recorder, tu peux fonctionner selon plusieurs modes :
Sur mon HA en production, je suis en « je retiens tout … sauf », mais j’ai viré ce dont je suis certain de ne pas avoir besoin autrement qu’en valeur en temps réel. Et j’ai aussi désactivé toute grandeur totalement inutile
Sur mes HA de test ou mes VMs, je suis en « je ne retiens rien, sauf… » … ce que je teste (très facile à mettre mettre en place)
A noter qu’il faudra plusieurs jours pour voir la BDD réduire en taille, et que ca se stabilisera une fois dépassée la période de rétention définie dans le recorder (ou la valeur par défaut : 7 jours ?).
Salut,
Je reviens sur ce fil car je vois un interrêt de pouvoir definir les périodes et intervalles d’enregistrements de différents sensors dans la base d’historique.
Par exemple, il est bien de pouvoir visualiser sur 1 mois les productions PV journalières, sur 5 ans les productions PV mensuelles, sur 10 ans les productions PV annuelles, etc …
Si je me limite à mettre 10 ans (periodes max qu’il me faut pour mes stats PV annuelles), je vais alors aussi enregistrer des données dont je n’ai pas besoin. (données journalières/mensuelles sur 10 ans!)
Et avec un include de mes quelques sensors, j’exclus automatiquement tout le reste … il y a pleins d’autres sensors qu’il me faut pour 1 semaines (et donc les 10 jours d’enregistrement par défaut) qui sont alors indisponibles à un affichage dans un chart …
Je suis nouveau sur HA (et oui je viens de Jeedom) et pour ce coup si l’historique fonctionne de cette manière sur HA c’est pas top …
Merci!
Sébastien
Salut,
Pour le stockage, à la différence de jeedom qui conserve les données en mode bourrin (en plus de faire un mélange valeur/format), sur les 10 premiers jours, les 2 applis conservent les données intactes. Par contre, sous HA le « cout » de stockage au delà de la période des 10j (les stats long terme) ne coutent pas grand chose puisque l’échantillonnage est réduit automatiquement.
Au final, garder pour 10 ans c’est quasi pareil en taille que 5 ou 1 an. Donc faire le tri toi-même n’apporte plus vraiment d’intérêt. En plus, puisque tu as moins de valeurs, les perfs d’affichage sont au RDV, alors que Jeedom souffre.
Ensuite, il faut faire la différence entre l’affichage et le stockage… Là aussi les 2 applis différents :
sous HA, ceux sont les cartes ou les dashboards qui feront le boulot d’afficher la durée de ton choix.
Donc c’est la même donnée qui permet de voir tes PV à la semaine/au mois/à l’année.. Et non 3 jeux de données différents.
Donc la gestion est plus simple :
Ce qui est important, c’est de bien comprendre que toutes les données que tu mets dans la base et dont tu ne te sert pas, coutent beaucoup sur les 10 premiers jours. Et puisqu’on a facilement des milliers d’entités, la facture en stockage grimpe… C’est là qu’il faut réfléchir à trier.
Merci pour ta réponse @Pulpy-Luke , je suis d’accord avec toi.
Du coup dans mon cas, j’historise avec un INCLUDE ce dont j’ai besoin sur 10 ans avec interval de 10 minutes par exemple et ça devrait le faire … le reste des entités j’en ai pas besoin.
J’ai donc fait ceci:
recorder:
purge_keep_days: 3650 # <-- Conserve 10 ans d'historique
commit_interval: 600 # Enregistre les changements toutes les 10 minutes
include:
entities:
- sensor.production_pv_totale
Et depuis un chart je peux faire des stats jours, mois, années comme ceci :
type: custom:apexcharts-card
graph_span: 30d
span:
end: day
header:
show: true
title: Production PV Journalière (kWh)
colorize_states: true
apex_config:
legend:
show: false
chart:
stacked: true
dataLabels:
background:
borderWidth: 0
opacity: 0
plotOptions:
bar:
borderRadius: 0
dataLabels:
position: center
series:
- entity: sensor.production_pv_totale
name: PV Totale (journalier)
type: column
group_by:
duration: 1d
func: diff
show:
datalabels: true
extremas: false
L’approche est bonne?
Merci !
Sébastien
C’est exactement l’idée.
Petite variante cependant, l’intervalle n’est pas l’intervalle de mesure, mais celui de la fréquence d’enregistrement de la base. La fréquence de mesure est à la minute (en général). Pendant 600 tout est stocké dans un tampon mémoire avant d’être enregistré
ah ok, mais comment n’enregistrer un point que toutes les 10 minutes ?
Je n’ai pas besoin de remplir la base d’historique avec un point toutes les minutes … est-ce possible d’augmenter?
Oui, tu te doutes bien que pusique cette valeur est unique (pour toutes les entités), la mettre à 10 minutes, aurait pour impact de s’appliquer partout. C’est loin d’être assez précis dans certains cas.
Pour limiter, tu peux utiliser les entrées filtres. Un bout de doc d’une des fonctions par exemple
Les autres compteurs peuvent aussi être une option.
Du coup tu vas créer 2 entités, celle de tes PV avec les valeurs brutes (à ne pas mettre en base), et une avec les données filtrées (à stocker)
Après, à toi de voir si ça vaut vraiment le coup, je ne sais pas quelle est le fréquences de remontée de tes PV, mais si c’est de l’ordre de la minute, on parle de quelques Mo
Salut,
ce n’est pas un bonne idée de mettre 10 ans dans le recorder.
Je sais que tu comptes ne garder que les entitiés que tu veux, mais tu aura des soucis de perf a un moment ou un autre.
Je base HA gère très bien les historiques à long terme (sans limite de temps).
Ca se fait tout seul… j’ai configuré la purge sur 7 jours dans le recorder, mais mes données de conso et de production sont gardées depuis plusieurs années sans config supplémentaire.