déjà il manque une ligne car la filtration a démarré à 2h00 jusqu’à 2h06 ( je m’envoie le 0 / 1 sur telegram pour verif), ainsi que le 0 de 11h06, le 1 de 20h00…
aujourd’hui ( le 24/01) je refais un export du 23/01 en bornant sur les dates de hier
j’obtiens pas la même chose :
résultat on peut pas trop s’y fier ? Y a t’il quelque chose que je fais pas bien ?
J’en ai besoin car je voulais vérifier la formule suivante dans un virtuel pour calculer la conso journalière de ma piscine dans un virtuel qui me donne aussi quelques incohérences
(duration(#[piscine][local piscine][Etat 1]#,1,last day)/60)
j’obtiens 425 mns soit 7h08
si je me fies à mes alertes reçues sur le téléphone via téléram que je sais juste, j’obtiens 6h15
pourquoi cet écart ?
je ne sais pas ou chercher le pb, d’un coté la formule me renvoie une valeur erronée , et d’un autre coté l’export de la base me renvoie des données non fiables
si je me fies à l’historique de Jeedom , c’est encore diffèrent, et incohérent aussi avec le resultat de la formule si dessus
Les exports correspondent bien à l’historique de la commande avant et après archivage qui a juste eu pour conséquence de supprimer les répétitions de 1 finalement.
Il faudrait vérifier en temps réel quand tu reçois une alerte Telegram si la valeur est bien enregistrée dans Jeedom ?
Attention si tu veux connaitre la durée d’activation de la veille, la syntaxe avec last day n’est pas bonne car il va comparer la durée d’activation par rapport au jour précédent à la même heure :
A priori, il vaudrait mieux faire ça si tu veux la durée d’allumage de la veille :
Il compte qu’une période discontinue de 23h à 2h06, hors il ya 2 périodes une de 23h ( etat 1) à 23h06 ( état 0) idem pour 2h 00 (état 1) à 2h06 ( état 0) comme l’ateste mon telegram :
donc en fait tout calcul est complètement faussé. bug ? plugin zwave qui remonte mal les hysto ?
Merci pour la formule ,en calculant, ça se rapproche d’avantage de la réalité ( de l’historique ,j’entend ,qui lui est faux).
Petite question ; il prend en compte l’heure de l’execution ? et il prend la fourchette des 24h ?
je viens de l’exécuter à 21h par ex donc la formule calcule de hier 21h à aujourd’hui 21h ?
aujourd’hui , il n’a compté que les périodes courtes, et a zappé la longue
Les logs du plugin Zwave sont en debug ? Si non il faut redémarrer le démon après passage en debug.
Il faudrait vérifier si tu as ce genre de lignes dans les logs openzwaved ?
Error, Node#ID_DU_MODULE_ZWAVE#, ERROR: Dropping command, expected response not received after 1 attempt(s)
ça expliquerait pourquoi les valeurs ne seraient pas enregistrées par exemple… Vraisemblablement il faut creuser par là. DataExport ne fait qu’extraire les historiques Jeedom dans un fichier csv, si ces données ne sont pas présentes en historique il ne pourra pas les inventer. Idem pour le calcul durationBetween qui correspond bien aux informations en historique.
J’ai peut-être mal compris ce que tu voulais, ton calcul d’origine calculait depuis la veille à la même heure que l’heure de lancement.
(durationBetween(#[piscine][local piscine][Etat 1]#,1,yesterday,today)/60) correspond à la durée d’activation du jour précédent à minuit au jour en cours à minuit quelle que soit l’heure de lancement.
Merci pour la précision
Pour mon pb, je pense que cela vient d’un problème de retour d’état de la commande zwave du module
En effet à 11h00 , il y a un on , je reçois bien l’info et l’histo aussi
malgré l’envoi du off à 11h06, l’état de la commande ne passe pas à 0.
donc l’histo est juste.Le module fonctionne, car physiquement le moteur de ma piscine est arrêté donc le 0 se fait, et est bien reçu car je reçois l’alerte. C’est l’état de la commande qui parfois ne se met pas à jour. pourquoi ? mystère. Vais surveiller les logs ,j’ai loupé celui de 11h
oui, l’état ne change pas , il change au 2eme appuie sur la meme commande
J’ai une erreur dans les logs ,citée si dessus
2022-01-26 21:16:40.842 Error, Node020, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2022-01-26 21:16:41.539 Error, Node020, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2022-01-26 21:16:41.581 Error, Node020, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2022-01-26 21:16:41.592 Error, Node020, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2022-01-26 21:16:42.497 Error, Node020, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2022-01-26 21:16:47.127 Error, Node020, ERROR: Dropping command, expected response not received after 1 attempt(s)
en faisant des tests parfois malgré l’erreur , l’état se met à jour, parfois non. J’ai recréé les commandes mais aucun effet
Oui je l’ai fait, il y a un léger mieux, on va dire 1/3 ne passe pas contre 1/2 avant.Pat contre les commandes passent toujours, c’est sur les retour d’état le pb.
Je suis en non sécure sur le module pour info
niveau stat :
Si tu as la possibilité de positionner un module routeur sur le chemin entre ce module et le contrôleur ça peut aider à ce que tous les messages passent bien.
Sinon il faut voir ce qui pourrait générer des interférences autour de ce module en particulier ?
C’est dingue quand même , que quand je rappuie sur la même commande, l’état se fait bien.
Le plus bizarre , c’est que sur l’entrée 2 du module ( c’est mon robot piscine) , les états sont ok, quand j’envoie les on / off ,je viens de faire plusieurs tests
Le relais fonctionne, car le on / off fonctionne normalement, la filtration se met en route et s’éteint ce n’est que le retour d’état qui marche aléatoirement.
J’y avais pensé au doublement mais bon… ça abime pas le relais ou module, d’envoyer un on, sur un moteur qui tourne déjà ?
En créant la commande de refresh, ça marche. C’est bien elle qui agit souvent, j’ai mis un timing assez long avant l’exécution pour savoir.
Merci encore, le reste se régulera, à savoir le calcul de la conso, au moment que l’histo sera juste
Merci pour tout.
Bonne soirée
