SQL Structure des données

[Bad]

Bonjour,

@kankamuso

où sont stockées toutes les lectures générées par chacun des capteurs ?

Dans la table SQL history tu as toutes les données d’historique « à court terme » et dans la table historyArch toutes les données « archivées ».
Par exemple, pour consulter les données de la commande 7397, il y a la requête :
SELECT * FROM history WHERE cmd_id = 7397 (court terme) ou
SELECT * FROM historyArch WHERE cmd_id = 7397 (archivées, donc >24h)

Mais c’est une TRES TRES mauvaise idée de manipuler directement ces données. C’est pour ça qu’il y a du code autour de la base de données : afin de toujours valider les données avant d’y toucher.

@ktn

L’état de commandes de type info (retour de capteurs par exemple) n’est pas enregistré dans le base de données mais dans le cache.

En fait, si
L’usage du cache peut sembler assez étrange dans Jeedom, mais disons juste qu’il contient « toutes les dernières valeurs ». Normalement on devrait pouvoir vider le cache à tout moment et Jeedom devrait à nouveau le remplir, mais ce n’est pas tout à fait vrai.

@pifou

En gros donc, les infos ne sont conservées que dans le cache, sauf si la commande est historisée, dans ce cas la, il y bien persistance des données dans la bdd, vrai ?

Oui, « toutes les dernières valeurs » sont stockées dans le cache, mais si le cache vient à disparaitre, Jeedom ne remettra une valeur en cache que lorsqu’une nouvelle valeur sera envoyée sur cette commande. Jeedom ne sait pas chercher une dernière valeur en BDD, même pour un équipement historisé. Le cache n’est qu’une vue à un instant T de l’état de Jeedom, pas d’historique là dedans.

Vous avez certainement aussi déjà fait une « Vidange du cache » de Jeedom « pour voir » ?
Et bien le système n’a plus les dernières valeurs, il devient « inconsistant » le temps que de nouvelles valeurs viennent replacer le vide créé par la suppression du cache.

Donc en passant, pas touche au cache non plus

@thanaus

Pourquoi ne pas simplement configurer une réplication de la base MySQL Jeedom si juste pour consultation ?

Je suis d’accord, il faut trouver une autre solution pour répondre au besoin et ta solution est certainement la plus adaptée pour conserver l’historique à la déconnexion et le récupérer à la reconnexion.
Mais encore une fois, il est question de manipuler la BDD et il va falloir créer un système (code) pour consulter les infos en base, les rendre exploitable pour une analyse, les maintenir au gré des changements du format de BDD par Jeedom, etc.

@Accès au cloud ? Réplication de la passerelle?

J’ai une passerelle dans un endroit éloigné qui, de temps en temps, perd la connectivité. Cependant, je veux pouvoir continuer à consulter les données reçues avant la date limite. Pour cela, j’ai réfléchi aux points suivants : Un serveur en nuage avec Jeedom. Répliquez la base de données MySQL de la passerelle

Si ton besoin c’est :

• 2 ans de données d’historique sur le système source/distant,
• toutes les données avant la coupure sur un système local,
• pas besoin de récupérer l’historique sur le système local à la reconnexion,

Alors JeeLink semble de très loin être la meilleure option.

Mais, si tu dois absolument récupérer tout l’historique sur le système local (en plus du système distant) après la coupure, alors ça va être compliqué, car il n’existe ni mécanisme de réplication synchrone, ni système de haute disponibilité dans Jeedom, ça reste une solution domotique grand publique, pas un système de surveillance professionnel et encore moins industriel.