Sakkhho Posté(e) le 15 mai 2015 Auteur Signaler Posté(e) le 15 mai 2015 tout depend des paramètres de calculs. j'ai mis une limite à 3mm - chez toi il est tombé 1.8 hier donc pas suffisant et 1 aujourd'hui idem (d'ailleurs je pense qu'il faudrait les sommer quelque part) et la prevision est que de 1 donc besoin arrosage. avec les mains voila comment ca marche tu definis ce dont tu as besoin par jour et indique le nombre de jour de prevision local quantie_jour_mm = 3 local nb_jour_prevision = 2 ensuite Si la prevision est > au besoin par jour * nombre de jour (6 dans l'exemple) alors --> pluie annoncée --> arrosage NON Si sur les 5 derniers jours il a plu besoin*nombre de jour (6) * 1.5 (pour de la marge) =9 alors --> Il a beaucoup plus --> arrosage NON Si le jour meme il a plu plus que 3mm alors --> il a plu --> arrosage NON Si hier il a plus plus que 3mm alors --> il a plu hier --> arrosage NON Si sur les 5 derniers jour il a plus plus que 5mm mais que la prevision est moins de 6mm alors --> arrosage court --> arrosage Leger Sinon --> arrosage long --> arrosage important avec à chaque fois une verification si il pleut en ce moment meme. Le calcul est discutable, et je suis preneur de quelque chose de mieux si on trouve. deja je vois que dans le label Hier, il faudrait aussi prendre en compte le Jour --> car si hier il a plus 2.5mm et aujourd hui 2.5 aussi pas besoin d'arroser alors que dans ce calcul si ... pas sur que cela soit très clair :-) 1
Did Posté(e) le 15 mai 2015 Signaler Posté(e) le 15 mai 2015 Bravo @Sakkhho pour ce module qui me plait bien et merci @jojo pour les idées apportées. Mais mon problème est qu'il n'y a pas de station assez près de chez moi pour l'utiliser. Sur quoi cela agit au final pour arroser ou pas, les Id des modules commandant les électrovannes ou seulement sur le délai d'arrosage dans le panneau d'arrosage? Je tourne actuellement avec un pluviomètre Hunter que j'ai domotisé avec un FGBS mais n'ayant pas trouvé, à l'époque de moyens d'interpréter l'info et la prolonger vers les EV, je me suis rabattu sur ce que je maitrisais mieux et j'ai simplement mis un relais en sortie du FGBS qui, quand il a plu (et que le pluviomètre est bien rassasié), me coupe l'alim 24V en IN de mes FGS. Merci.
Sakkhho Posté(e) le 15 mai 2015 Auteur Signaler Posté(e) le 15 mai 2015 Bonjour Did, tu habites ou ? en suivant ce lien, il faut choisir une station avec un chiffre dans le rond violet, si pas de chiffre cela veut dire pas de pluviometre. il faut aussi faire attention car certaines stations semblent pas très bien calibré. http://french.wunderground.com/personal-weather-station/dashboard?ID=IAQUITAI78 (dezoom la carte pour te situer puis rapproche toi pour trouver la bonne station) le VD mets à jour une variable qui a 3 états, et ensuite j'utiliserai (installation en cours de réalisation) GEA pour activer l'électrovanne, suivant l'état de la variable. Suivant l'état de la variable aussi le temps d'activation de l'EV sera different. (+ ou - long) le VD aujourd'hui permet de dire si oui ou non je dois arroser en prenant en compte uniquement les mm de pluie tombées (sur une période antérieure et future) il est donc nécessaire de l'ameliorer pour qu'ils prennent en compte aussi le mm ici de l'arrosage. Car par exemple, imaginons, une période sans pluie. J'arrose longtemps le Lundi, il faut que le VD le prenne en compte pour que le Mardi il me dit que tout est ok et que l'herbe est bien verte :-) EDIT ; petit soucis, si je veux créer d'autres boutons ???? vous savez ce que c'est ? pourtant j'ai essayé avec des noms de boutons genre "wxc" pour être sur ... comprends pas
Did Posté(e) le 15 mai 2015 Signaler Posté(e) le 15 mai 2015 Limite Eure & Loir, Orne et Sarthe, la station la plus proche est à une vingtaine de kilomètre, donc pas fiable pour me baser sur ces relevés. Mon pluviomètre me convient, la pluie tombée hier midi a bien fait commuter l'état de mon FGBS mais a séché suffisamment dans l'après-midi pour autoriser l'arrosage de la fin de soirée. Le truc est que j'aimerais bien qu'il fasse la même chose sans le relais, une variable avec GEA est certainement la solution.
Sakkhho Posté(e) le 15 mai 2015 Auteur Signaler Posté(e) le 15 mai 2015 bon j'ai resolu mon probleme d'ajout de bouton :-) je vais pouvoir continuer :-) donc l'idée suivante est de faire ; si un arrosage est effectué, alors je rajoute x mm à la valeur Jour, Hier, 5jours, 10jours, par contre je sais pas encore comment faire ... je peux passer par une variable qui prendrait la valeur Precipitations + Arrosage sauf qu'il faut que je sache si c'est J1 ou J2, J3 etc... avez vous une idée comment démarrer ?
jojo Posté(e) le 15 mai 2015 Signaler Posté(e) le 15 mai 2015 idée, mais pas le code On connait les valeurs de J-1, ..., J-10 Donc dans la variable existante "Arrosage", il faudrait changer son type pour qu'elle soit "libre" et plus prédéfinie. On y stoquerait un tableau à plusieurs entrées : J-0 à J-10 et l'action à prendre. Au passage, charger les 10 derniers jours à chaque fois devient inutile, sauf la première fois, à l'initialisation du script (=si la variable arrosage est à nil). Donc à 2h06 du matin, ce qui est déjà stocké en J-1, devient J-2, et ..., et j-9 devient J-10 On ne lit que hier qu'on met à J-1 et auquel on rajoute la qté en mm qu'on a arrosé la veille (théoriquement 1 des deux valeurs est à 0) P.S. ce script ne me sert actuellement qu'à faire travailler mes neurones, car je n''ai/n'aurai pas d'arrosage automatique 2
Sakkhho Posté(e) le 15 mai 2015 Auteur Signaler Posté(e) le 15 mai 2015 Oue je te suis mais la je suis hors jeu. Incapable de faire ça. Faut faire appel au fofo !!!
jojo Posté(e) le 15 mai 2015 Signaler Posté(e) le 15 mai 2015 c'est un défit que tu me lances là Je vais voir ce que je peux faire, je devrais y arriver, mais ce n'est pas moi qui calcule le nbr de mm arrosé. On pourrait déjà commencer par voir comment stocker un tableau dans une variable.
Sakkhho Posté(e) le 15 mai 2015 Auteur Signaler Posté(e) le 15 mai 2015 calculer le nombre de mm, depend du debit de chacun au robinet, ca se mesure facilement mais oui je suis d'accord, la 1ere étape est le tableau
Sakkhho Posté(e) le 15 mai 2015 Auteur Signaler Posté(e) le 15 mai 2015 (modifié) bon je me lance .... pas taper :-) on crée une table precipitations = {} precipitation[1] = celle du jour ensuite on fait nos appels dans notre boucle avec for i =2 to previous10days (qui devrait prendre la valeur 11 alors) et donc à chaque itération on fait precipitations[i] = jsonTable.history.dailysummary[1].precipm on devrait avoir une table avec 11 valeurs. 11 valeurs que la peut sommer suivant le besoin JOUR=1 5 derniers jours c'est 1+2+3+4+5 ou 2+3+4+5+6 suivant le plus intelligent 10 derniers Jours c'est .... si j'ai fait un arrosage alors on appuie sur un bouton qui donne : precipitations[1]=precipitations[1] + "Valeur arrosage" ensuite chaque nuit on fait for i = 1 to previous10days-1 precipitation[i]= precipitation[i+1] ce qui voudrait dire que l'on fait un appel 10days 1seule fois et ensuite on fait uniquement l'appel JOUR (et prévisions) j'ai bon ou je vais me coucher ? EDIT : bon une connerie dans la derniere boucle car j'écrase les valeurs, faut partir de 9 qui devient 10, 8 qui devient 9 etc... est ce que ça ça marche ? for i =previous10days-1 to 1 precipitation[i]= precipitation[i+1] Modifié le 15 mai 2015 par Sakkhho
jojo Posté(e) le 15 mai 2015 Signaler Posté(e) le 15 mai 2015 c'est une excellente direction. donc la première entrée est précipitations du jour les entrées 2 à 11, les précipitations des 10 jours précédents je mettrais également en entrée 12 la date du dernier relevé, comme cela si pour une raison x ou y on a loupé un relevé (pas internet, ...) on peut réinitialiser tout le bazar. en entrée 13, on met l'action à prendre. Il n'y a plus qu'à voir comment stocker tout cela dans une variable globale, et le relire. P.S. : tu vois que tu peux
Sakkhho Posté(e) le 16 mai 2015 Auteur Signaler Posté(e) le 16 mai 2015 j'ai déjà le code avec la table local precipitation = {} local max_day = previous_10days + 1 for i = 2, max_day do local response ,status, err = WGROUND:GET("/api/"..cle_api.."/history_".. os.date("%Y%m%d",os.time()-(i-1)*24*3600) .."/lang:FR/q/pws:"..pws..".json") local jsonTable = json.decode(response) fibaro:debug(os.date("%Y%m%d",os.time()-(i-1)*24*3600)) fibaro:debug(jsonTable.history.dailysummary[1].precipm) if tonumber(jsonTable.history.dailysummary[1].precipm) ~= nil then precipitation[i] = jsonTable.history.dailysummary[1].precipm end end rainyesterday = precipitation[2] rain5days = rainyesterday+precipitation[3]+precipitation[4]+precipitation[5]+precipitation[6] rain10days = rain5days+ precipitation[7]+precipitation[8]+precipitation[9]+precipitation[10]+precipitation[11] fibaro:debug(" Il est tombé " .. rainyesterday .. " mm hier") fibaro:debug(" Il est tombé " .. rain5days .. " mm depuis " .. previous_5days .. " jours") fibaro:debug(" Il est tombé " .. rain10days .. " mm depuis " .. previous_10days .. " jours") ça apport pas grand chose en l'état mais c'est déjà une première pierre. 2eme pierre la boucle de la nuit - pour remonter les valeurs d'un jour; for i = previous_10days, 2, -1 do precipitation[i]= precipitation[(i-1)] end par contre comment écrire cette table dans la variable ? cf ici ? Ma variable est PRECIPITATIONS un fibaro:setGlobal("PRECIPITATIONS", precipitation) donne [ERROR] 10:04:46: line :setGlobal (arg 3), expected 'string const &' got 'table' ca à pas l'air de lui plaire de recevoir une table dans la gueule :-) faut il remettre que le setGlobal soit dans la boucle aussi ? besoin d'un expert ici !!!
jojo Posté(e) le 16 mai 2015 Signaler Posté(e) le 16 mai 2015 pour écrire la table dans une variable, j'aurais essayé ceci fibaro:setGlobal("PRECIPITATIONS", json.encode(precipitation))
Sakkhho Posté(e) le 16 mai 2015 Auteur Signaler Posté(e) le 16 mai 2015 Ca àpas l'air mal. je vais essayer de la relire ailleurs. (enfin trouver le code pour la relire d'abord:-))
CaptainIgloo Posté(e) le 16 mai 2015 Signaler Posté(e) le 16 mai 2015 Savoir qu'il n'y a pas besoin d'arroser car il a plu est une chose utile pour les nordiste. La logique dans le sud méridionale est l'inverse. Il faut savoir quand arroser. Du coup savoir quand il a plus est bien beau mais c'est pas si souvent. Ce n'est plus le facteur précipitation qui a le plus de poids., mais principalement l'humidité du sol. Qu'est-ce qui dessèche le plus le sol ? Et bien l'évaporation et par conséquences, le vent et la température. Pour rendre ce VD générique il y a donc àintégrer une autre algo dont les précipitations seront moins influençantes.
Sakkhho Posté(e) le 16 mai 2015 Auteur Signaler Posté(e) le 16 mai 2015 fait toi plaisir, c'est collaboratif :-) on peut récupérer facilement les températures, vents etc de WU, après faut écrire l'algo qui interprète ces valeurs. pour revenir à ma lecture de table, la table est bien remonté avec ton code jojo, j'ai fait un test et je vois bien [10,9,8,7,6,5,4,3,2,1,0] pour la relecture, je tentai un simple local relecturetable = fibaro:getGlobal('PRECIPITATIONS') mais ensuite si j'essai de faire des opérations avec la nouvelle table, ça bug est ce qu'il faut faire qq chose de + compliqué ? json.decode ?
CaptainIgloo Posté(e) le 16 mai 2015 Signaler Posté(e) le 16 mai 2015 @Sakkhho, Je me ferai plaisir lorsque j'aurai terminé mon VD détection d'orage dans périmètre maison. Pas de problème je maîtrise WU depuis deux ans. Mais le provisionning est moins bon qu'OWM et surtout pour les UV et la nébulosité. Donc je ferai avec OWM. Après j'espère ne pas avoir vexé car ce n'est pas mon propos.
Sakkhho Posté(e) le 16 mai 2015 Auteur Signaler Posté(e) le 16 mai 2015 non non je suis pas vexé, et je suis d'accord avec toi, que ce n'est pas suffisant mais c'est un debut et comme je me bats à chaque ligne de code ... c'est pas simple :-) je viens de gagner une bataille (enfin j'espère :-)) local RepriseTable = json.decode(fibaro:getGlobalValue("Precipitations")) 2
Sakkhho Posté(e) le 16 mai 2015 Auteur Signaler Posté(e) le 16 mai 2015 avant de tenter de coder cette nouvelle version, j'aimerai voir avec vous (enfin surtout jojo, mon partenaire sur ce VD :-)) si la logique est bonne 1 Je conserve la requête HEURE et JOUR (1 seul requête API) pour avoir quelque chose en temps reel (enfin toutes les 10mn) Pour le reste 2 il faut initialiser le module pour allez chercher les 10 derniers jours ; est ce que je garde un bouton d'appel 10days (INITIALISER) ou alors dans le code du bouton (voir si après je trouve un moyen de dire, uniquement si la table est vide alors lance la requête 10jours - le problème que je vois ici c'est que si pour une raison la table est corrompu on peut pas réinitialiser) 3 Tous les matin à 2h par exemple, on bascule dans la table je J+1 vers J+2, J+3 vers J+3 etc... et on lance un requête HIER pour avoir J+1 --> 1 appel API 4 On conserve le bouton Previsions --> 1 appel API on se retrouve donc avec 3 appel (sauf pour initialiser) donc super large. on pourrait meme encore optimiser et basculer J vers J+1 mais bon pas nécessaire je pense et plus simple pour la suite ;-) ensuite et c'est la que je sais pas trop comment faire j'aimerai tenir compte comme decrit plus haut de mm d'eau issue de l'arrosage. peut faire comme cela : - créer un variable Arrosage fait : OUI / NON - j'ai donc un couple LEGER/IMPORTANT et OUI/NON - lorsque l'arrosage sera terminé alors on passe la variable à OUI - si variable à OUI (et suivant LEGER ou IMPORTANT) je rajoute x mm à la valeur YESTERDAY après la avoir fait la requête en 3 pour ne pas écraser la valeur - on repasse la variable à NON est ce que ca vous parait bon ?
kioneoranga Posté(e) le 17 mai 2015 Signaler Posté(e) le 17 mai 2015 La version 1.5 s'est installée sans accroche, super boulot. j'ai trouvé la ville la plus proche de chez moi (3km) et comme ça je sais ce que je dois arroser ou pas. Vraiment super boulot. Félicitation.
jojo Posté(e) le 17 mai 2015 Signaler Posté(e) le 17 mai 2015 @Sakkhoo, Avec l'optimisation envisagée, je metterais tout sur 1 bouton, y compris la prévision. S'il faut faire une réinitialisation, on fait les 10 appels , puis un sleep de 1'30 (pour être sà»r) puis le reste. Et on peut ajouter un label qui affiche soit réinitialisation, soit la date du dernier appel de 2h06. On est d'accord que dans la variable on met entrée1 : précipitation du jour entrée2 à 10 : historique des précipitations entrée11 : date du dernier relevé de l'historique à 2h06 entrée12 : action à prendre Pour savoir si une réinitialisation est nécessaire on peut faire différents tests (à affiner suivant l'expérience) : si la variable est nil si la date du dernier relevé de l'historique (entrée11) n'est pas la date de jour - 1 Donc si on a une réinitialisation, tant pis pour l'historique d'arrosage. Je ne suis pas enthousiaste de créer une variable supplémentaire "Arrosage fait". Surtout si tout est automatisé, s'il est nécessaire de faire l'arrosage, il se fera. Donc quand on décale tout à 2h06 du matin, si on était sensé faire un arrosage la veille, on ajoute à l'entrée 2 la quantité correspondant à l'arrosage théorique réalisé.
jojo Posté(e) le 17 mai 2015 Signaler Posté(e) le 17 mai 2015 @Sakkhoo, Encore une idée. Génèse de l'idée : j'ai nettoyé ma piscine et ai fait un backwash de mon filtre, ce qui a fortement baissé le niveau de ma piscine. Donc savoir s'il va pleuvoir à plus que 2 jours peut être intéressant (si je sais qu'il va pleuvoir, je peut faire le backwash avant la pluie, comme ça elle se reremplit toute seule ) => dans la variable Pluviométrie, je verrais bien qu'elle stocke également les infos sur la pluviométrie des jours suivants (comme l'historique). Il faut voir comment le faire, car je sais qu'il y a moyen de nommer (au lieu de numéroter) les entrées d'une table
Sakkhho Posté(e) le 17 mai 2015 Auteur Signaler Posté(e) le 17 mai 2015 honnêtement je préfère séparer les choses, enfin c'est mon besoin. il est nécessaire je pense de rafraichir régulièrement la data HEURE et la data JOUR --> 1 bouton de meme pour la data prevision --> 1 bouton ou mieux comme la fréquence peut être la meme on rassemble tout dans 1 bouton : "Temps Réel" qui fait 2 requêtes API à la fois * 6/h * 24h = 288 /jour Ensuite j'ai un bouton "Historique" qui fait le boulot tot le matin pour basculer l'historique d'1 jour et qui récupère la data HIER : 1 requête API/jour Ensuite pour l'arrosage, comme tout il faut que cela soit semi automatique :-) donc je pense créer un bouton Long et un bouton Court Le click sur ce bouton fera local QuantiteLong = 20 local selfId = fibaro:getSelfId() local precipitation = json.decode(fibaro:getGlobalValue("Precipitations")) precipitation[12] = QuantiteLong fibaro:setGlobal("Precipitations", json.encode(precipitation)) fibaro:debug("" .. precipitation[12] .." mm d'arrosage effectué") GEA s'occupera de tout, c'est à dire si le calcul arrosage dit LONG ou COURT, alors GEA enclenche l'electrovanne le soir ou dans la nuit (c'est mieux pour l'arrosage :-)) pendant x minutes, et appuie sur le bouton LONG ou COURT, et passe la Variable Arrosage à NON. en + un bouton initialiser qui fait 10 appel est je pense aussi nécessaire. J'ai donc 5 boutons - Temps Réel - Historique / Initialiser - Court / Long 1
jojo Posté(e) le 17 mai 2015 Signaler Posté(e) le 17 mai 2015 ok, super. J'essaye néanmoins de limiter le nombre de variables globale àcréer (support, migration, ...), alors on pourrais mettre la date du dernier arrosage effectué en entrée 13 de la variable précipitation, et qui pourrait d'ailleurs être affichée dans un label du vd
Sakkhho Posté(e) le 17 mai 2015 Auteur Signaler Posté(e) le 17 mai 2015 (modifié) Hello Voilà une V2.0 - elle permet de tenir compte de l'arrosage et donc de rajouter une quantité en "mm" au data de précipitations. (vous pouvez modifier la valeurs dans les boutons LONG et COURT De plus on fait un long appel à l'API WU une seule fois. Ensuite on traite les données via une table. Donc tout ce qui est vrai pour la 1.5 reste valable (création clé API WU - Variable Arrosage à créer - Icône etc... (voir post 1) en plus il faut créer une variable "Precipitations" pour stocker la table - (pas une variable prédéfinie) - mettre 0 comme valeur; ensuite au 1er lancement il faut cliquer sur "Initialiser" (attention 10 appel API) attendez à minima 1mn et cliquer sur Rafraîchir pour avoir les données jours et previsions. Chaque nuit sur il faut appuyer sur "Traitement"pour traiter les datas. je vous propose GEA -- Arrosage GEA.add(true, 10*60, "", {{"VirtualDevice", id["CALCUL_ARROSAGE"], 2},{"Repeat"}}) -- Rafraichir les données pluie Jour Et Previsions GEA.add(true, 30, "", {{"Time", "00:06", "00:07"},{"VirtualDevice", id["CALCUL_ARROSAGE"], 14}}) -- Traitement de l'Historique Pluie ou pour le main loop pour ceux qui n'ont pas GEA ca doit être qq chose comme while true do local Var_Heure = os.date("%H:%M") local Var_Min = os.date("%M") --fibaro:debug("heure OS : " ..Var_Heure) if Var_Heure == "00:06" then fibaro:call(fibaro:getSelfId(), "pressButton", "14") fibaro:debug("heure OS : " ..Var_Heure .."Traitement des données effectué") end if Var_Min =="00" or Var_Min == "15" or Var_Min == "30" or Var_Min == "45" then fibaro:call(fibaro:getSelfId(), "pressButton", "2") fibaro:debug("heure OS : " ..Var_Heure .."Rafraichissement des données") end fibaro:sleep(60*1000) -- sleep 1 min end l'appui sur long ou court engendra l'ajout de 10 ou 20mm le lendemain de l'arrosage via la bouton Traitement et le label 'Arrosé le' prendra la date du dernier arrosage. je veux bien un beta testeur ;-) d'ailleurs qui peut me dire comment verifier la table via un fibaro:debug(print(Precipitations)) ca marche pas. merci edit : V2.1 un peu plus commentée Calcul_Arrosage V2.1.vfib Modifié le 19 mai 2015 par Sakkhho 3
Messages recommandés