Ti as jetez un oeil pour cette commande directement les tables history et history_arch ?
Si tu as par exemple une valeur à 0 dans les tables, ca veut dire qu’il est passé dans la même seconde de 0 => 1 => 0, et comme l’archivage gère à la seconde, …
Le retour a 0 de la variable est a 17h18, et il y aurait dû avoir le passage à 1 vers 16h46, le boost dur 30mn et il est déclenché 5mn après que la variable de Début soit passée à 1 a 16h41
Ce n’est pas normal qu’un historique soit absent de la base ?
Il y aurait eu trop d’instruction en même temps et donc des pertes d’ajouts.
Là vous n’avez pas de perte de l’info, elles sont bien dans la base, avec quand même un décalage de temps entre le horodatage du logement et celui de la base
Dans mon cas, le passage à 1 n’est même pas présent dans la table
A 17:26:21 il manque le passage à 1 dans la table history alors qu’il y a bien les 2 valeurs dans le log du scénario.
1 seul événement par seconde dans la table history.
On est bien d’accord.
Mais c’est la limite de n’avoir du traitement qu’à la seconde et pas en dessous. Bon à la base jeedom c’est pour faire de la domotique hein, donc normalement ça correspond quand même à 99% des besoins
Tu n’a pas moyen de faire en sorte qu’il ne puisse pas y avoir de changement d’état aussi rapides ?
Je ne comprends pas toute la mécanique qui met à jour cette commande chez toi.
Je renouvelle ma question du coup, quels sont les critères qui peuvent faire changer d’état cette commande ? on en voit un sur le screen, mais ça ne reflete pas la totalité du coup
J’ai une variable info/binay : Boost_DEBUTVanneEnBesoin, elle passe à 1 suivant certaines conditions, si elle reste à 1 pendant 5mn alors elle passe la commande : Boost_Thermostat à 1
un scenario se lance avec comme déclencheur cette commande Boost_Thermostat
Il fait quelques contrôles et passe le thermostat en Boost puis lance un sous tache « dans 30mn » qui repasse la commande Boost_Thermostat à 0
ca redéclenche le même scenario qui enleve le boost du Thermostat
donc sauf si j’ai merdé quelques parts, la variable Boost_Thermostat ne fait pas de changement intenpestif d’état
et je sais que ce processus c’est bien passé, grace à l’historique, sauf l’absence du passage à 1 de la variable Boost_Thermostat
c’est peux être l’écriture de l’état d’une autre variable la même seconde qui vient se télescoper ?
Je croyais qu’avec la 4.5 il y avait eu une amélioration sur cette gestion des commandes.
Il devrait pouvoir buffeuriser les écritures pour ne pas avoir ces pertes.
Ok du coup tu ne fais pas comme dans ton screen du dessus, tu ne fais pas via un event dans un action sur valeur mais tu lances un scénario avec ce dernier ?
Et tu n’a rien observé de particulier dans les logs de ce dernier ?
Si c’est la première étape
C’est la 1er commande qui passe a 1 suivant les conditions et qui fait un event pour passer le 2eme commande a 1, celle qui n’a pas été historisée
J’ai un nouveau car, le 10/01 avec le même phénomène, le boost s’est bien passé mais dans l’historique, il manque le passage à 1 de la variable Boost_thermostat, alors que son retour à 0 est bien historisé
j’ai regardé les historiques à la même minute où aurait du se trouver le passage à 1, puisque cela est fait depuis une commande event quand la commande Boost_DEBUTVanneEnBesoin est à 1 pendant 5mn.
