Je viens de mettre en place la mise à jour pour le plugin. Content de voir tout le travail intégré, j’apprécie.
Du coup, je me suis séparé du plugin Piscine car l’utilisation des possibilités d’Iopool me semble plus adapté à mon utilisation.
Toutefois, j’avais quelques remarques :
il serait intéressant d’ajouter une condition qui autorise ou non la filtration : heures creuses, heures pleines, niveau de l’eau suffisant, production photovoltaique suffisante … un simple binaire serait génial aux niveaux des possibilités. J’utilise une remise à zéro en cas de problème pour ma part, mais je n’ai pas assez de recul sur la répétition des commandes du plugin (qui va peut être chercher à faire des ON si je repasse volontairement à OFF ?)
je me suis rendu compte que les champs avancés (min/max/hiver) ne peuvent être remplis avec des variables (plus pratique à gérer dans la configuration).
je présume que le plugin va lancer à l’heure définie (min) et calculer « comme un grand » l’heure d’arrêt en fonction des 2 plages et des durées min/max. Du coup, est-il possible d’avoir la durée de filtration & l’heure min/max sous forme d’une information ? (pour notifier, informer le matin du cycle. C’est pratique pour la famille pour savoir quand la filtration doit démarrer, mettre les produits etc).
il me semble avoir compris que la notification n’intervient qu’en fin de filtration. Une au début sera très utile aussi pour indiquer justement l’heure de fin, le cycle prévu, s’il est capé par le min ou le max ou s’il est calculé …
Je vais réfléchir au meilleur moyen de gérer cela.
De ta vision, une commande info binaire qui pourrait être modifier par un event dans un scenario ? Mais quid du retour à la normale du changement ? L’utilisateur gère lui même l’activation/désactivation dans le scenario ?
J’ai un peu peur que ça perturbe les utilisateurs d’avoir cette commande et la checkbox d’activation. Éventuellement je pourrais ajouter une commande action qui active/désactive la checkbox de filtration
Non. Et je suis même pas certain qu’une configuration d’eqlogic puisse prendre une variable Jeedom. Et globalement c’est pas des paramètres qui ont vocation à changer régulièrement donc peu d’intérêt à utiliser une variable
En effet le plugin lance à l’heure définie (start) la filtration. Mais dans les 15mn précédente l’heure de début configurer pour la période 1, un fichier de cache est génèré pour calculer les heures de début et fin de chaque période à partir de la configuration.
Ce cache est visible directement dans l’équipement. Il est aussi possible de supprimer et forcer la création du cache.
La durée de filtration recommandée par iopool est déjà dispo en info, idem si il y a une recommandation (ajout de produit). L’heure min c’est toi qui l’a configuré donc tu dois la connaître.
Je préfère éviter de créer trop de commande pour éviter de complexifier le plugin. L’objectif est de ne plus avoir à se préoccuper de sa filtration.Toutefois si plusieurs utilisateurs m’exprime le besoin je verrais.
En effet c’est en fin de filtration pour identifier si le temps de filtration à faire à bien était fait afin de détecter un potentiel souci.
Même réponse que précédemment l’objectif c’est de rester sur un truc simple mais si d’autres utilisateurs remontent le besoin je regarderais
faire simple selon moi. Tu autorises le ON que si le booléen est vrai. C’est à l’utilisateur de gérer les conditions de ce booléen (par l’agrégation d’autres indicateurs). Par contre, effectivement, il faut que le plugin soit réactif à ce booléen (au-delà d’un cron par exemple) ? Je ne pense qu’il faille activer/désactiver la filtration mais bien autoriser ou non le ON que si les conditions sont remplies.
d’ailleurs, une question. Que se passe t’il si l’état de la pompe passe à 0 par une condition extérieure et qu’elle tournait, comment réagit le plugin ? (pour l’heure, je fais ça, si le niveau d’eau passe à 0, alors je fais un off de la filtration. Donc le plugin devrait voir le relais passer à 0.
non, pour les variables, j’utilise cela pour beaucoup de plugins et ça tourne (dernier exemple en date, l’eau chaude). Après, c’est pour avoir des notifications qui utilisent bien mes paramètres.
effectivement ce soir j’ai reçu une notification :
" … bassin filtré 7h … sur 10h prévue"
mais du coup, le 10h c’est la préco iopool ? Car personnellement, je n’ai jamais respecté les règles de filtration et c’est tout l’intérêt de ton update avec le min et le max. Je te mets ce que j’avais fait, mais je n’ai pas reçu la notification ce soir :
en gros si hivernage, respect du délai d’hiver,
si saison, si supérieur au max, alors tant mieux (exemple délestage photovoltaique etc)
si saison, si compris entre min et max, donc dans l’acceptable,
l’intérêt est de savoir que la filtration démarre, stop. Au lieu d’ajouter des notifications hors plugin. (case à cocher ?)
par contre les notifications pour warning/critique etc sont un peu illisibles je trouve :
CRITIQUE : GLOBAL vient de passer …
ATTENTION : GLOBAL vient de passer dans le seuil attention
etc.
Je vais pour l’heure, dans mon cas, désactiver les notifications et m’appuyer sur le ON/OFF avec action de notification pour prévenir du ON/OFF.
Alors ajouter une commande pour cela, je ne suis pas chaud. Ca ferait une commande de plus pour un besoin qui reste TRES TRES limité dans l’usage.
Eventuellement créer une options avancés dans les commandes pour permettre d’avoir une commande binaire a spécifié qui permettrait de bypasser la filtration du plugin. Si la commande retourne 1, alors pas de filtration.
Pas besoin d’être réactif au changement, dans aucun cas ce type de feature, en cours de filtration viendrait couper la filtration si la valeur passée à 0. Elle serait là uniquement pour bloquer le lancement de filtration, donc il suffirait simplement de tester la valeur avant démarrage. Si 0 ou pas de commande configurée, alors on lance la filtration.
Il ne se passe volontairement rien. Il y a plein de raison qui peut nécessiter l’arrêt de la pompe pendant la filtration automatisé. Il ne faut donc pas que le plugin relance la filtration tout seul.
Le plugin est donc développé de façon à gérer le démarrage et l’arrêt automatisé de la filtration mais si pour une raison quelconque le statut de filtration change, le plugin ne fait rien. Techniquement, il ne le détecte meme pas car il n’a pas de raison de le savoir.
Cette fonctionnalité dans le plugin, est là uniquement pour permettre de gérer le temps de filtration selon les recommandations iopool (même si on a un peu de latitude sur les temps) de façon automatisé.
On parle bien de variable au sens Jeedom et non pas de commande ? Tu peux me faire un screen d’exemple de l’utilisation de variable dans un des plugin que tu utilises ?
Personnellement, je ne vois pas l’interêt d’ajouter de la complexité à la gestion par l’utilisation de variable. Et à part toi, je doute que d’autres on le besoin mais si je me trompe, que les autres utilisateurs se montrent.
Et si vraiment c’est essentiel pour toi, tu peux toujours utiliser un bloc code dans un scenario pour mettre à jour les valeurs dans le plugin.
Les 10h correspondent au temps de filtration calculé par le plugin. Donc dépendant du temps de filtration recommandé par iopool ET les temps min,max qui peuvent avoir était configuré.
Si je reprend tes cas, voici ce que le plugin fait :
Si la sonde est en mode hivernage, le plugin retourne le temps de filtration recommandé lors de l’hivernage. Si aucun temps configuré, pas de filtration.
Si la recommandation iopool est supérieur au max configuré, alors le temps calculé retournera le temps maximum
Si la recommandation iopool est entre le min et max configuré, alors le temps calculé retournera le temps recommandé par iopool
Si la recommandation iopool est inférieur au min configuré, alors le temps calculé retournera le temps minimum
J’ajoute dans la roadmap potentielle.
J’ai 2 liste de roadmap, les roadmap validés (seront développé) et les roadmap potentielle (seront développé UNIQUEMENT si plusieurs utilisateurs la demande).
Je ne peux pas developper les fonctionnalitée qui arrange chacun pour leur usage unique. Sinon le plugin va devenir très complexe et ce n’est vraiment pas l’objectif du plugin. Il doit rester simple d’usage. Pour les besoins plus complexe, le plugin piscine est surement le meilleur choix.
Pourquoi ? Tu peux détailler plus ?
Moi je trouve que c’est assez lisible au premier coup d’oeil.
Pour le premier point, c’est déjà suffisant et cela me va. Je suis sûr qu’à l’utilisation certains vont se réveiller. Il y a plein d’intérêt d’avoir ce booléen : autoconsommation, production PV suffisante, niveau d’eau etc.
Bein, justement le problème est là. Par exemple, en ce moment, j’ai des travaux électriques dans mon quartier. Il coupe le courant quelques secondes/minutes et du coup, la piscine ne démarre pas. Le problème c’est que je n’ai aucun moyen d’utiliser le plugin pour relancer la filtration. Un cron de répétition est intéressant. Et tu comprends maintenant la difficulté s’il existe des conditions « externes » pour stopper la mise en marche. Bon, je vais gérer différemment pour l’heure. Le ON fera un scénario qui se répète toutes les 5 min et sur conditions autorisées. Idem pour le OFF.
Pour le troisième point, je serai intéressé, comment fais-tu ça ? (par bloc code). Pas de problème, c’était surtout que j’ai été étonné de ne pas pouvoir le faire. Je fais comme ça pour pas mal de choses : thermostat, eau chaude par exemple.
Et si vraiment c’est essentiel pour toi, tu peux toujours utiliser un bloc code dans un scenario pour mettre à jour les valeurs dans le plugin.
Pour les notifications, c’est juste un avis. Aucun problème, si cela te convient. Personnellement, madame trouve ça illisible et moi avec mon cerveau, je comprends mais je préfère des notifications plus « friendly ». J’ai mis en place 2 scénarios en début/fin de filtration ; ça me suffit. Pour le reste ça remonte sur mes designs et sur notifications TTS.
Une chose est sûre est que ce plugin permet une super intégration dans les designs et la vie « domotique ».
Par contre, ce serait super que le plugin passe l’info de l’heure de début, de fin, de la durée calculée. Je ne sais pas si c’est facilement « sortable ». C’est très pratique pour le suivi, la notification des personnes dans la maison quand on arrive par exemple etc.
Si au travers des commandes start et stop de ta pompe, c’est leur rôle.
Le plugin est là pour gérer l’automatisme de démarrage/arrêt de la pompe par rapport au temps de filtration. Si elle est arrêté pour une raison normal (tu l’as décidé) ou anormal (dans le cas d’un souci électrique par exemple). Le plugin n’a pas vocation a remplacer la gestion complete de ton equipement Jeedom qui pilote la pompe. Il se sert uniquement de cet equipement pour faire ce qu’il a besoin de faire.
Comment veux-tu que le plugin différencie un arrêt normal de la pompe par rapport à un anormal. Par exemple, je coupe la pompe pour faire un backwash du filtre, puis je sors le tuyau de backwash ce qui peut prendre quelques minutes. Je veux pas que la pompe reparte sans que je l’ai décidé.
Certain coupe surement la pompe électriquement pour faire ce genre de manipulation, comment les différentier d’une coupure electrique ?
C’est trop compliqué à gérer et rendrait clairement le plugin beaucoup trop aléatoire dans son fonctionnement pour un cas d’usage qui représente qu’une infime parti de l’utilisation de la filtration du plugin.
En regardant de plus près, je sais pourquoi cela ne fonctionne pas. Je vérifie le contenu des choix pour valider que ce qui est rentré correspond bien à ce qui est attendu.
Ces champs attendent donc des nombres avec un maximum de 1440.
Et clairement je ne vais pas modifier cela, cela provoquerais de potentiels erreurs sur les contenus pour d’autres utilisateurs qui pourrait être tête en l’air, surtout pour un usage faible.
Pour interagir avec ces champs, il suffit d’aller modifier avec un bloc code via un setConfiguration de l’eqlogic. Toutefois, si tu fais mal, tu peux corrompre la configuration de l’équipement dans Jeedom car cela passe outre toutes les verifications que le plugin fait.
Comme indiqué dans mon précédent message, je le trouve lisible mais tu peux toujours me faire une proposition de contenu sachant que ces notifications ont juste le rôle d’indiquer si il y a un changement du « Flag » global et/ou d’une des « couleurs » associés aux indicateurs (warning ou critique).
Actuellement, l’alerte me semble parlante car elle indique
le statut (OK/ATTENTION/CRITIQUE - soit vert, orange, rouge)
l’indicateur qui est concerné (orp, ph, temp, global)
Mais fait moi des propositions. Si je les trouve pertinentes, je ferais la modification si elle ne nécessite pas l’integration d’indication qui n’ont pas leur place dans cette notification
Merci
Comme dit précédent, l’ambition est d’avoir un système qui permet de ne pas s’en préoccuper mais tout de même avoir confirmation en fin de cycle quotidien, que tout le temps de filtration prévu c’est bien passé et détecter ainsi manque de filtration sur une journée et pouvoir lancer rapidement un boost pour compléter au besoin.
Qui dit ne pas s’en préoccuper, dit pas de besoin de connaitre les informations.
Mais par chance pour toi, là encore un bloc code peut te permettre de récuperer le contenu du cache qui contient les informations.
Voici un exemple qui récupère les informations et les ajoutes dans un tag du scénario
Bon je reste sur tes propositions, j’ai déjà tout ce qui marche.
Je vais utiliser ton bloc code pour récupérer les informations de la filtration du jour.
Par contre, j’ai un souci.
J’avais activé la notification et j’ai laissé uniquement pour savoir si obsolète.
Et je continue à recevoir : global, etc et critique/warning etc alors que j’ai désactivé :
Je ne vais pas me presser à l’acheter car la piscine est fermée et je ne remettrai une sonde que dans 7 mois donc inutile d’acheter une batterie d’ici là qui va se décharger alors qu’iopool garantie seulement 2 ans sa batterie (soit 25% de la durée de vie).
Du coup, je ne peux pas passer la sonde en hivernage. Le support m’a confirmé que ce n’était pas possible car c’est une opération à faire en local et Bluetooth.
Dans un premier temps, j’ai créé un virtuel tampon pour avoir un mode WINTER et que Jeedom gère tout seul les filtrations, température, remontées d’informations. J’ai aussi « triché » sur les durées de filtration pour passer à 1h.
Une idée serait d’avoir un mode dégradé quand les données sont OUTDATED : soit une durée de filtration « standard », soit une entrée de température etc.
Pour ma part, j’ai une Raspberry qui me remonte température d’eau, niveau d’eau etc toute l’année.
Tu es dans un cas très particulier car ta problématique est d’activer la filtration hivernage sans pouvoir mettre ta sonde en hivernage.
Le souci c’est que le plugin par du principe que tu récupère l’information d’hivernage de la sonde.
Se baser sur les informations obsolète n’est pour moi pas bon car si par exemple, tu pars en vacance plein été et que ton relais iopool perd le wifi, dans ce cas au bout de 24h tes donnés sont obsolète mais pour autant très loin de vouloir réduire ton temps de filtration.
J’ai volontairement rien voulu faire sur les données obsolète en dehors de la notification car obsolète ne veut pas dire qu’on doit changer de comportement, juste que les données ne sont plus reçu par le cloud iopool.
Une solution serait d’avoir un autre paramètre qui indiquerais qu’on passe en hivernage et non plus se baser sur l’info de la sonde, mais ça rend obligatoire le switch manuel ce qui n’est pas mon parti pris.
Comme ton contexte est particulier, je pense que le mieux est de faire un scénario qui a chaque changement du mode de la sonde (à chaque refresh), change le mode pour passer en WINTER ou ACTIVE_WINTER si tu veux la filtration hivernage.
OK, c’est ce que j’ai déjà fait, merci.
Je trouve dommage de rester sur un comportement « faux » quand les données sont obsolètes.
Après, c’est ton plugin, donc je respecte.
C’est là que nos visions diffèrent. Le comportement n’est pas « faux » quand les données sont obsoletes, le comportement correspond bien aux dernières informations acquises, qui certes sont plus vieilles que 24h mais sont les dernières en possession du plugin.
Il n’y a aucune information permettant de définir que le comportement devrait être changé ou non. Donc par conséquent pas de changement.
Si tu as une ampoule connectée qui te remonte dans Jeedom que son dernier état connu (et remonté par l’ampoule) est allumé alors que tu la vois bien éteinte, tu peux pas demander au plugin de prendre en compte le fait que l’ampoule est éteinte alors qu’il ne le sais pas. Il sait juste qu’il n’a pas reçu d’information depuis quelques temps.
C’est pareil pour iopool. Si je mettait en place un changement de comportement sur les données obsolete, alors que tout marche bien sauf le cloud iopool, le changement de comportement (temps de filtration) impacterais tout le monde, alors qu’en soit, aucun changement n’existe réellement sur les sondes.
Je comprend que tu souhaites que je modifie cela pour gérer ton cas, mais une modification pour gérer ce cas (qui je pense est très minoritairement rencontré) impactera bien plus fortement tout les utilisateurs en cas de problème avec les serveurs iopool.
Ce sont les raisons pour lesquels je ne souhaite pas modifier comme tu le souhaites.
D’ailleurs le sujet serait plutôt coté iopool. Pour gérer ce cas, il devrait pouvoir de leur coté, forcer une sonde dans leurs serveurs en hivernage ou hivernage actif. La sonde ne communiquant plus, ce ne serait pas un souci
