je viens de l’univers Jeedom (pour le moment j’ai les 2 solutions en //) et donc je suis habitué à MySQL pour gérer ma domotique. Je dispose de près de 100 capteurs en tout genre, de panneau solaire (donc power user de la gestion de l’énergie) et j’aime bien garder de l’historique longtemps (genre comparer la température de ma piscine cette année VS il y a 1 an).
Du coup, je me pose la question de la pertinence de migrer soit tout home assistant sous MySQL, soit que les historiques ?
Dans HA, le type de base n’a absolument aucune importance sur la durée des historiques.
C’est le fait d’avoir les bonnes classes sur les entités qui fait que c’est prugé après X jours (le recorder) ou conservé à vie.
La phylosophie est à mon sens bien plus simple que jeedom, où certes, tu as plein de choix mais qui rends la gestion complexe.
Pour comparaison d’une année à l’autre (ou mois/semaine), il faut travailler avec les cartes « explorer history » par exemple. Et ça marche tout seul.
Puisque tu risques d’avoir quelques données en quantité, je t’invites à faire un tour des innombrables sujets autour du recorder ici, tu trouveras plein de bonnes idées et pratiques
J’utilise mariadb mais pour faire des extractions pour analyser mes consommations plus finement.
J’ai un historique de 1 an de valeurs.
Rien ne t’empêche de garder les paramètres de base recorder et de mettre du trigger pour ne garder que le timestamp, le metadata_id et la valeur pour l’envoyer dans une autre bdd mariadb.
La table values contient un nombre de champs beaucoup trop grand.
En plus, tu gardes tes datas indépendamment de HA. Tu peux réinjecter tes conso jeedom dans cette bdd vu que c’est toi qui gère le format et les query.
Tu peux même faire du traitement périodiques et même en utilisant l’intégration SQL le récupérer dans HA.
Bon, ça c’est pas une utilisation courante. Juste pour les curieux et débrouillard.
L’historique HA sait le faire aussi (infini même), nativement, avec reduction de la donnée, sans mariadb et sans avoir besoin de bidouiller des triggers, des calculs, la gestion et le debug de tout ça.
même si la table d’origine contient des champs en trop, de toute façon, le fait de créer une base à coté, c’est de toute façon du stockage en plus. Et c’est sans compter les ressources CPU/RAM que ça demande en plus aussi.
Le seul intéret que ça peut avoir, c’est l’ajout des données non HA (mais c’est pas l’objet ici), mais pour ça c’est influxdb/grafana qu’à mon avis il vaut mieux prendre. Et encore, on parlait hier d’un addon qui permet d’injecter un historique sur une entité HA à partir d’un fichier excel… Un fois fois fait, on reste dans une mécanique ultra simple et fiable.
Ha mais si on peut injecter un historique depuis un csv ou excel, ça change beaucoup de choses.
Ça n’était pas le cas à l’époque où j’ai utilisé ma méthode.
Mais pour répondre à ta question, je gère moi même mon propre format de bdd et reste indépendant de ha qui a déjà merdé suite a mise a jour. Et a l’époque, je testais les différents type d’installation de ha (haos, etc) et je ne pouvais pas réimporter mes enregistrements. Donc j’ai décidé de gérer mon historique et j’ai pu en profiter pour faire du traitement en tout genre. Principalement la partie conso élec.
Après, je ne suis pas représentatif des utilisateurs. C’est mon métier de gérer ce genre de données et j’ai des outils qui ont fait leur preuve depuis 10 ans sur des installations bien plus grosses que des maisons. Disons que certains aiment le foot/mécanique/courir/picoler/… Moi c’est ça.
Purement pour HA, il n’y a pas trop d’intérêt à passer sur MySQL, SQLite c’est largement assez performant.
Un des intérêts de rester avec la base par défaut c’est que tout est là pour la sauvegarde et la base aura le même format que la version de HA sauvegardée.
Si tu passes en MySQL, surtout sur une machine externe, tu auras toujours un risque d’avoir un état de désynchro de versions, HA aime bien optimiser la base de données en changeant la structure plusieurs fois par an. Il faut aussi s’assurer que la sauvegarde de la base soit faite correctement.
Ceci étant dit, je garde aussi une base SQL uniquement pour mon historique « agnostique » perso que j’ai alimenté à partir de 2 anciens systèmes domotiques et maintenant de HA pour avoir un historique, principalement, Électricité, Solaire, Chauffage, Température, a base de 1 entrée par Jour. C’est là-dedans aussi que je gère l’évolution des prix de l’électricité.
J’arrive à 10 ans d’historique. Et si un jour je devais quitter HA pour autre chose, elle sera toujours remplie par la nouvelle plateforme…
C’est pas parce que mariadb c’est plus éprouvé (quand on parle de vrais sgbd, on parle PG ou Oracle) mais parce que c’est plus facile quand on connait…
Et je reste persuadé aussi que si la base est maitrisée depuis le début, ça limite les plantages HA (encore plus quand on reste sur le fonctionnement de base).
Avoir ses données sur 10 ans, c’est bien mais réellement on s’en sert 1 fois tous les ans pour comparer le cout. Dans le plus extrêmes des cas, on fait la corrélation T extérieure/Conso … Mais pas beaucoup plus.
Et donc j’ai quand même l’impression que ça demande toujours vachement plus de boulot au quotidien que de regrouper les bases à la fin dans influxDB/Grafana, voir au pire faire une extraction dans un format plat. Et il y a tellement plus à faire avec HA au début ^^
.
