Bonjour à tous
J’ai une commande info binary dans un virtuel avec un historique sur 1 mois
ca fait plusieurs années que cette commande est en place
il se trouve que j’avais besoin d’analyser un soucis et je constate que l’historique ne donne que quelques heures :
Comme si l’historique n’avait commencé se conserver que lors du passage à 1 de la prise, elle est passé à 0 dans la nuit suite à une coupure électrique partielle, je voulais vérifier l’heure.
sauriez vous pourquoi ?
Salut,
Je dirais bien que c’est parce que cet historique est purgé au bout d’un mois.
Si ta commande ne bouge presque pas (toujours à 1) il n’est pas impossible que l’info (1) soit supprimée au bout du mois et du coup tu ne commences à avoir une valeur que lors d’un changement (passage à 0).
Salut,
Tu nous montres pas le range de dates sélectionnées (par défaut une semaine?)
Le bouton « Tous » en haut à gauche reste limité par la sélection de dates.
oui ca pourrait être le cas, mais c’est très gênant, car dans ce cas, je perds l’information du passage 1 vers 0 et donc l’horodatage de la coupure
même en changeant le range, il n’y a aucune donnée avant le 04/11 02h00, toutes les périodes mois, semaines, jour sont grisées
Oui, c’est clair
Je ne pense pas qu’il soit possible de faire autrement dans le code du core. Comment laisser un passage à 0 le 04/09/2022 alors que l’historique ne doit conserver qu’un mois de données (donc jusqu’au 04/10/2022) !?
Ma fois je pense que la seule solution rapide et efficace est de changer ton paramétrage en conservant toujours l’historique pour ces commandes dont tu sais qu’elles ne bougent presque pas. Ca ne prendra pas vraiment de place dans la BDD. La suppression de l’historique au bout d’un mois n’a de sens pour moi que si les valeurs changent énormément et que l’on a pas besoin de vraiment d’antériorité (exemple : une puissance).
dans le cas présent, la coupure (passage à 0) à eu lieu le 04/11 vers 04h je pense, je suis toujours dans la plage des 1 mois, j’aurais du avoir le graph à 1 depuis 1 mois et le 04/11 de 04h a 06h30 (heure où j’ai remis le courant), voir la descente à 0
tu as raison, sur cette donnée, je pourrais ne pas mettre de purge, je vais tester ca, merci
Tu peux aussi d’essayer de stocker la date du dernier changement d’état en utilisant la fonction lastChangeStateDuration() et en la stockant dans une variable ou un virtuel.
Je pense que ça fonctionne un peu comme ça :
Disons que du 04/01 au 04/11 tu étais à 1. Comme il n’y a pas eu de passage à 0 dans le mois, cette valeur de 1 à été supprimée. Tu t’ai donc retrouvé comme dans le cas ou tu démarres une historisation c’est à dire pas de valeur et donc un affichage à 0.
Du coup le passage à zéro n’a pas eu de conséquence sur le graph … il était déjà à 0.
Tu dois avoir un « Répéter les valeurs identiques » à Non. Je pense que si tu avais mis « Oui », la valeur 0 aurait été enregistré dans l’historique.
oui, c’est surement ca, mon « répéter les valeurs identiques » est bien à NON
mais la purge de l’historique, même si il a perdu la dernière bascule 0 vers 1, lors de la purge, il devrait recréer un entrée artificielle avec la dernière valeur, pour ne pas perdre l’info
il y a aussi un autre point, j’ai une autre commande binaire qui passe à 1 quand mon frigo se coupe (Etat_frigo == 0) justement pour me signaler une coupure partielle de mon disjoncteur et cela ne pas eu lieu cette nuit, d’où ma tentative de recherche
je me demande donc, si il n’y a pas autre chose derrière cette perte d’info dans l’historique.
si le core considère dans l’historique que le valeur de l’état n’a pas changée, il fait peut-être de même dans la gestion même de l’état, et donc ma sous commande d’alerte qui surveille la commande d’état n’a pas été mise à jour.
j’ai contourné le prb en ajout une condition OU si le changeduration() de la commande ETAT est < 60, comme ca, même si c’est un passage 0 vers 1, je serais alerté
