jjacques68

@pepite bon ben j'ai testé, et ça fonctionne aussi pourquoi chercher compliqué !!!

meilleurs vœux pour cette nouvelle année !!!

par contre le prix, lui, continue de monter... ça ce devenir un réel problème...

nan c’est une blague ? bon là je peux pas le tester mais, je te dirais ..l

j’ai changé de manière faire. j’ai une boucle qui tourne par un setTimeout. dans cette boucle y a une condition qui peut me faire un kill de la scène. tout simplement. au lieu de déclencher une action par un setTimeout qui m’empêche de tuer la scène. roah c’est du chinois dis comme ça

voisin, nan ça je pense pas

@nico: même pas en rêve... Sauf si vraiment plus le choix... Envoyé de mon iPhone en utilisant Tapatalk Pro

sinon moi j'utilise ça dans une scène : local TousLesModules = api.get("/devices/") local IdEnd = TousLesModules[#TousLesModules].id print("Nombres de modules : " ..#TousLesModules) print("Dernier ID : "..IdEnd) for i,v in ipairs(TousLesModules) do local Nom = TousLesModules[i].name local id = TousLesModules[i].id local type = TousLesModules[i].type print("Id = "..id.." ; Nom = "..Nom.." ; Type = "..type) end

j’ai jamais utilisé GEA... disons qu’avec mes analyses des derniers jours, je me rend compte que le panneau de chauffage fonctionne parfaitement bien ! c’est qu’en fait il y a quelque chose qui transmet une consigne manuelle à une vanne, aléatoirement ! j’insiste sur le fait que la consigne manuelle ne vient pas du panneau de chauffage !!! Mais bien d’un setTime ou setTargetLevel de la vanne même ! Et le plus dingue c’est que le seul moyen, à ma connaissance, pour reproduire le phénomène c’est de passer par des requêtes POST... Le panneau de chauffage dans ces cas reste totalement intact et juste. est-ce que ça vient de parasites radio interprétés par les vannes ? bug de la HC2 ? autre ? faudrait pouvoir sniffer les trames z-wave... pour voir ce qu’il passe !

tu me diras, pas de soucis... elle est pas compliquée. enfin depuis que @Lazer m’a simplifié la requête POST... mais c’est étrange j’ai l’impression d’être le seul à avoir ce soucis... après si vous n’avez pas de notifications sur la propriété Value ou TargetValue des vannes, il est pas possible de se rendre compte...

la solution 2 marche nickel. lors d’une ouverture de la fenêtre, je mémorise les paramètres du panneau de chauffage dans une VG. je passe la zone en vacation à 4 °C (le minimum) quand les fenêtres de là pièces sont fermées je rebalance les paramètres de la VG dans le panneau. c’est nickel !

oui en effet, en fait je touche pas au panneau de chauffage, mais plutôt au device qui pose problème... ça semble fonctionner...

finalement j’ai fait autrement.

oh punaise bien joué !!! des heures que je suis dessus !! merciiiii ! va me simplifier le code ça...

Ben j'ai essayé toutes les syntaxe possible que je connaissais... J'ai rien trouvé qui fonctionne. Ton exemple me donne : [DEBUG] 12:32:37: 2019-12-29 12:32:37.512313 [ fatal] Unknown exception: /opt/fibaro/scenes/299.lua:7: unexpected symbol near '['

Suite et j'espère fin... alors ... de ce que je comprends : Le pilotage des vannes via cette interface, n'a aucun impacte sur le panneau de chauffage. La consigne de température est envoyée à la vanne uniquement via une requête HTTP avec la commande SetTargetLevel et le temps via SetTime. Et pourquoi, ça je n'en sais absolument rien !! de temps en temps une consigne à la c** lui est transmise (voir mon premier post de ce topic). Donc cette consigne à la c** se compose d'une température bidon et d'une durée de 2 ou 3 heures. Donc J'ai créé une scène qui intercepte la consigne de température bidon et force une nouvelle durée à 0 minutes avec le SetTime, Ainsi que le "currentTemperature" de la pièce définit dans le panneau de chauffage. Donc au final, j'ai max un retard = au temps de réveil (10 min chez moi) de la vanne et plus 2h ou 3h comme avant... Compliqué mais semble fonctionner !!!

bien ! mais les VD sous IOS plantent toujours l'application

J'ai trouvé !! (merci @nigao - j'ai utilisé Advanced Rest de Google Chrome) alors là l'ancienne ça donne : local http = net.HTTPClient(); http:request("http://127.0.0.1:11111/api/devices/40/action/setTime", { options = { method = "POST", headers = { ["Authorization"] = "Basic blablabla", ["Content-Type"] = "application/x-www-form-urlencoded" }, data = '{"args": [0]}' }, success = function(response) print(response.data) end, failure = function(err) print("Error : "..err) end }) cela me remet à 0 le la consigne de temps donné par "erreur" à la vanne Danfoss

je sais pas trop... le fait d’ouvrir les fenêtres est psychologique

bon ben la solution 2 c’est fait. ça marche super nickel !! en effet ça va me couter cher... 38 € par fenêtres... Remarque pour la solution 1 : oui en effet les vannes Danfoss ont ce système. Mais si tu laisses ouvert trop longtemps (+ 1/4 d’heures) elles chauffent quand même !!

nan mais attend, ce panneau de chauffage commence à me sortir par les tous les trous !!! je pense que si j’arrive à faire marcher ce api.post, j’aurai réglé ce problème... mais je pense que c’est l’argument qui pose problème, doit être mal formaté, et je vois pas comment le faire...

ben je devrais voir alors "en attente de réveil" dans sa fenêtre ! et là y a rien ??

Hello tout le monde, je cherche à envoyer une consigne de temps à une vanne Danfoss LC13 comme si je cliquait dans l'IHM du device. En cherchant dans le debug du navigateur, j'ai vu passer ça : et donc dans une scène, j'essaye de reproduire cette action : api.post("/devices/40/action/setTime",os.time()) J'ai pas de messages d'erreur, mais je ne constate pas de changement non plus ??? Vous avez une idée ? Merci d'avance !!

Je prends la solution 2 Suis entrain de la mette en place Envoyé de mon iPhone en utilisant Tapatalk Pro

Hello ! On peut pas tuer une scène qui a un setTimeout en cours ???? Voici un exemple ultra simplifié : function MaFonction() print("execution de MaFonction") end if fibaro:countScenes() = 1 then print("1er lancement") setTimeout(MaFonction, 10*1000) else print("2ème lancement") fibaro:killScenes(296) end Voici le debug pour 1 instance : - tout à fait logique... [DEBUG] 12:08:21: 1er lancement [DEBUG] 12:08:31: execution de MaFonction voici le debug pour la 2ème instance - lancée immédiatement après la 1ère : ?? [DEBUG] 12:05:32: 1er lancement [DEBUG] 12:05:33: 2ème lancement Et clairement, la 2ème ligne du debug n'est pas apparu 1 seconde après, comme on peut le lire, mais bien 10 secondes après !! j'ai chronométré !! Merci pour vos lumières !!