jjacques68

J'ai pas compris !

oui tu peux biensûr le faire ! dans ce cas c'est simple...

aussi oui...

ok alors en effet il faut que tu l'as convertisse en seconde... pour le +1 et le -1 ou alors : Tu modifies dans l'action qui est déclenchée si le nombre e jour est dépassé...

elle est super partique

elle est rempli comment cette VG ?

l'écart est en seconde, dans ta VG "WArrosage_J_avant" il y a quoi comme valeur ?

oui tout à fait. on travaille avec les date /heure en format timestamp (donc un nombre entier), c'est beaucoupp plus simple... par contre on utilise os.date("%d/%m/%Y - %H:%M:%S",____un_timestamp____) pour l'affichage...

les messages se croisent

mouai je sais pas quelle est la ligne 160... essaye de remplacer cette ligne : local date_derniere_pluie = tonumber(fibaro:getGlobal("time_last_rain")) par local date_derniere_pluie = tonumber(fibaro:getGlobalValue("time_last_rain"))

tu peux faire un print de "date_derniere_pluie" ?

attention !! dans difftime, faut inverser les 2 :

alors je ferais ça : if (startSource["type"]~="autostart") then local date = os.date("%d/%m/%Y %H:%M:%S", os.time()) -- check actuator status and count only when turned on if (getActuatorStatus(mavariable1)) then fibaro:debug("il ne pleut plus depuis <font color=\"green\">"..date.."</font>") fibaro:setGlobal('time_last_rain', os.time()) --on enregistre la date et l'heure de la fin de derniere pluie else fibaro:debug("il pleut depuis <font color=\"red\">"..date.."</font>") end end ensuite dans le difftime : -- ========================================================== -- "time_last_rain" variable qui contient la date de la dernière pluie format "16/04/2020 22:21" -- "WArrosage_J_avant" variable qui contient un nombre (exemple 3) qui sera le nombre de jour après lequel on pourra déclencher l'arrosage print ("date derniere pluie") local date_derniere_pluie = tonumber(fibaro:getGlobal("time_last_rain")) fibaro:debug(os.date("%d/%m/%Y - %H:%M:%S",date_derniere_pluie)) print ("date actuelle") local date_actuelle = os.time() fibaro:debug(os.date("%d/%m/%Y - %H:%M:%S",date_actuelle)) print ("diff_des_2_dates") local diff_des_2_dates = os.difftime (date_derniere_pluie, date_actuelle) fibaro:debug(diff_des_2_dates.." seconde(s)")

mouai alors la fonction difftime demande des valeur sous forme de timestamp (heure en nombre de secondes) et non de chaine de caractère sous la forme : pour l'une c'est facile : "date_actuelle", tu remplaces par : os.difftime (date_derniere_pluie, os.time()) pour "date_derniere_pluie", ça se complique. Le plus simple aurait été de stocker dans la VG "time_last_rain" la date sous le format nombre entier et non chaine de caractère. est ce que tu peux afficher le code qui rempli la VG "time_last_rain" ??

pourtant os.difftime fonctionne très bien ! je l'utilise souvent ! tu peux poster le code que tu as essayé ?

tu peux modifier les heures pour tester maintenant

alors j'ai pas l'habitue d'utiliser les scènes par bloc, mais je pense que ce que tu veux faire n'est pas possible dans une seule scène... il en faut une qui allume, et une autre qui éteint. Je ne pense pas que les profiles ont un rôle à jouer pour ça... La scène que tu as créé, semble vouloir dire ça : déclenchement si : il est 7:00 ET que le WallPlug est allumé ET qu'il est 17:00 ET que le wallplug soit éteint c'est pas possible ! tu mets le device (WallPlug) que tu souhaites piloter dans les conditions ! alors que c'est l'action ! ensuite, on peut pas être à 7:00 ET à 19:00 en même temps un exemple comme je le comprends : 1ère scène pour allumer : 2ème scène pour éteindre : Tu as donc 2 scènes séparées, que tu peux enregistrer par exemple avec le nom : "allumer bureau" et la seconde : "éteindre bureau" essaye, ça devrait marcher...

je pense que tu as un problème d'authentification. car tu utilises admin:admin !!! l'erreur que tu as vient du fait, je pense, que tu cherches à afficher une erreur "err" alors que cette valeur est une table et non une chaîne de caractères comme le dit ton message d'erreur. et tu verras que tu auras un truc du genre accès interdit...

c'est laquelle la ligne 12 ?

ah zut ! jamais fais gaffe ! quel âne !!! et bien heureusement que je stocke ça dans une VG ! parce que s'il fallait me retaper tous les script... et bien figures toi que ça je l'avais déjà corrigé car, en effet je faisais un envoi de mail sur le téléphone... et biensûr ça marchait pas... mais pour le push si... bref je modifie ça demain

Tien c'est marrant, chez moi je fais les push vers l'ID du téléphone ! et non vers l'ID du user !

ligne 14 c'est la ligne de la fonction error ?$ essaye avec fibaro:debug("Erreur : "..json.encode(err))

Petit complément au sujet du READ : j'ai rencontré quelques effet de bord avec la fonction TCPSocket:read() en effet, j'utilise comme marqueur de fin, dans l'application qui communique avec la socket, le "CR", caract(13). et la HC3, visiblement interprétait mal ce marqueur de fin. c'est à dire qu'elle trouvait la trame, mais j'avais également un "r" qui était interprété comme une 2ème trame !! du coup avec la fonction TCPSocket:readUntil(delimiter) et en lui précisant bien le marqueur de fin : dans mon exemple : "\r", il n'y a plus de soucis. function QuickApp:waitForResponseFunction() self.sock:readUntil("\r", { success = function(data) self:updateView("LBL_Receive", "text", "RECEIVE : "..data) ... ... fibaro.setTimeout(5, function() self:waitForResponseFunction() end) end, error = function(err) QuickApp:warning("READ ERROR - "..err) self:CloseSocket() fibaro.setTimeout(1000, function() self:OpenSocket() end) end }) end

non non pas du tout !! t'inquiète pas !! ça m'intéresse de comprendre un peu plus en profondeur les choses ! Les avis, connaissances, conseils sont toujours bon à prendre...

Comme tu dis, j'ai 1 QA qui envoi les données en base. Et plusieurs autres (enfin 2) qui utilisent justement CE QA. ça fonctionne bien ! (de ce que je constate) Ensuite faut pas oublier que je passe par une variable de type tableau qui me sert de tampon... Mes 2 QA ne font que remplir cette variable tableau. LE QA de gestion de la socket s'occupe juste d'envoyer le contenu de ce tableau ! Je sais pas, y a rien qui me choque ! ça devrait ?? Maintenant côté performance, capabilité de la box, je m'y connais pas assez pour de dire si c'est bon ou pas... A mon niveau, ça à l'air d'allé... pour info : j'ai franchi un autre cap avec les socket, où j'utilise maintenant le READ (toujours dans le même QA de gestion de la socket). en effet depuis mon soft IHM, au lieu d'envoyer les ordres par requête HTTP à la HC3 pour actionner les device, je transmet l'ordre au QA via la socket. Et c'est lui qui fait les actions sur les device. Je sais pas si je me suis fait comprendre... Et bien je trouve que je gagne en réactivité par rapport aux requêtes HTTP. Donc CE QA fait l'envoi et la lecture simultanément, comme des thread... il a l'air d'encaisser Honnêtement c'était pour le fun... Et ça marche super c'est bien. c'est nickel pour comprendre pourquoi tel ou tel truc c'est mal passé. J'ai déjà plus que divisé par 2 les informations stockées en filtrant à la source (sur la HC3).