Si, le cache fait partie des sauvegardes. En gros, la DB est là pour conserver des données persistantes qui bougent peu. Le cache plus là pour conserver des informations qui seraient probablement conservées dans des variables internes si jeedom n’était une application WEB mais un service tourne en en tâche de fond.
En PHP, il faut un moyen de conserver certainent information entre deux exécutions d’un instance de classe. Le cache est là pour ça. L’utilisation de la DB pour cet usage serait beaucoup trop lourd.
Exact ! Je viens de regarder le code concernant la sauvegarde et le cache est bien conservé…
Si j’appelle la fonction checkAndUpdateCmd, je vais mettre à jour ma commande dans la DB et ceci toutes les x secondes si besoin.
Le cache est présent pour accélérer l’accès aux données car un cache filesystem/mémoire sera toujours plus rapide qu’accéder à une base de données et il s’agit de Doctrine :
Tu peux tout à fait utiliser ce cache pour stocker des informations entre deux exécutions d’une instance de classe mais je ne vois pas le lien avec la question initiale qui concerne les informations d’un capteur Z-wave donc normalement stockées dans la DB si tu souhaite conserver l’historique.
Si tu tiens vraiment à stoker les infos alleurs, il y a des config dans jeedom qui indique à Doctrine de mettre le cache en file system. Tu peux modifier la config pour, par exemple, utiliser une base mongoDB ou SQLLite…
Au vu du message de kankamuso qui indique qu’il s’agit d’un système de surveillance qui doit conserver les données pendant deux ans afin de pouvoir les analyser ultérieurement, j’ai implicitement pensé qu’il historise chaque commande… et les données seront donc dans la DB.
J’suis d’accord que je n’ai pas été assez précis mais j’avais en tête le contexte de kankamuso.
Tu as tout à fait raison qu’un simple appel à la fonction checkAndUpdateCmd va uniquement stocker les données dans le cache
On s’éloigne du sujet initial mais intéressant comme échange
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 ?
C’est ce que j’en déduit à la lecture du code + tests.
Pour en être sur à 100%, je pense que des développeurs chevronnés de Jeedom pourraient le confirmer/infirmer…
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.
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.
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
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.
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.
Donc, en copiant les données du cache sur un autre ordinateur, ne devrait-il pas afficher toutes les données de l’historique ? Ou bien les noms ou la structure des fichiers changent-ils d’un ordinateur à l’autre, même si le dispositif porte le même nom ? Comment savoir quel fichier correspond à quel appareil ? (un exemple serait bienvenu :-))
En ese caso, tendré que desarrollar algo así, pero para eso necesitaría conocimiento más profundo de la estructura y metodología de jeedom. Hasta ahora he hecho lo siguiente:
Volcar datos a InfluxDB en el gateway.
Cada X tiempo, replico la base de datos InfluxDB al equipo remoto en la nube.
Con esto ya casi me valdría porque con Grafana podría visualizar y analizar datos. Pero me gustaría poder tener todo más homogéneo e integrado.
Por lo tanto, me faltaría una forma de poder importar lecturas de un sensor en otro sensor a partir de InfluxDB y que todo el historial del sensor remoto se muestre en el sistema local. Pensaba que sería más directo!
La otra opción que me han planteado en otro foro es usar Export con CSV cada cierto tiempo, pero no sabría automatizar, una vez más el Import. ¿HAy alguna forma programática de invocar el método import del plugin?
Par expérience, je ne te conseil pas de baser ton interface sur un accès a la base de données.
D’abord parce que comme l’on dit les autres : tout n’y est pas (le cache). et ensuite, parce que tu vas devoir redévelopper des règles fonctionnelles de Jeedom selon les cas.
Le plus sur est d’attaquer jeedom par son API.
