jjacques68

oui alors en fait tu peux pas l‘exécuter manuellement ! il faut que le PIR déclenche lui-même la scène !

ah attend ... je regarde (j‘ai fais un copié collé...)

complètement d‘accord, je défends cette méthode aussi Mais là j‘ai eu un bug

moi j‘utilise ça : Le principe est que tant qu‘il voit l’œil est à 1, elle boucle sur elle-même. Il faut bien rapamétrer l’œil car c’est lui qui : - va déterminer la durée où la lumière est allumée : paramètre 6 - Alarme cancellation delay (le temps que tu veux en secondes) - autorise une nouvelle détection après la précédente : paramètre 2 - blind time (2 secondes dans mon cas) J’ai toute la maison qui fonctionne comme ça. Marche nickel. Cette scène peut être utilisée pour plusieurs pièces (j’en ai une pour toute la maison) Il suffit d‘ajouter : - l‘ID du capteur dans les trigger (XXX value). - une ligne dans la liste “Device“ pour connaître le l‘ID du FGD ou autre. Et mettre le nombre d‘instance de la scène au maximum (10). Je pense pas que 10 capteurs vont passer à 1 simultanément, donc on est tranquille --[[ %% properties XXX value YYY value --]] local Device = { --[ID_PIR] = {ID = ID_Actuator, NAME = "Room Name"} [XXX] = {ID = zzz, NAME = "Pièce 1"}, [YYY] = {ID = www, NAME = "Pièce 2"}, } local Trigger = fibaro:getSourceTrigger() --si PIR = ON if tonumber(fibaro:getValue(Trigger.deviceID, "value")) == 1 then print("PIR", Trigger.deviceID, " = ON") --allumage fibaro:call(Device[Trigger.deviceID].ID, "turnOn") --boucle tant qu'il y a de l'activité (ça rajoute max 3 secondes au temps du paramètre 6) while tonumber(fibaro:getValue(Trigger.deviceID, "value")) == 1 do fibaro:sleep(3*1000) end --extinction fibaro:call(Device[Trigger.deviceID].ID, "turnOff") print("PIR", Trigger.deviceID, " = OFF") end Possibilité de rajouter une marche forcée gérée par un VD et une VG par pièce.

j‘avais ça aussi... Et une LED rouge était allumée à l‘intérieur... en fait elle ne s’éteignait pas ! Je devais rester longtemps sur le bouton POWER (quelques secondes) pour lui forcer son arrêt (comme un PC) ensuite, attendre quelques secondes avant de rappuyer dessus pour la redémarrer. Là elle partait sans soucis. Depuis que j‘ai changé la pile du bios, j‘ai plus ce soucis.

@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 !!