jjacques68

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

ROAAAH plein le c... de ce panneau de chauffage !!!! Je viens d'envoyer un mail au ST. on verra le retour.

hello tout le monde ! ce sujet n’est pas “directement“ lié à notre HC2 adorée, mais j’ose quand même poser la question car je suis complètement sec et n’ai pas réussi à trouver de l’aide ailleurs... Je me lance : est ce que quelqu’un a déjà programmé avec des websocket ? Explication très rapide : J’ai, avec Windev, créé (il y a un moment déjà) une IHM complètement personnalisée, avec la HC2 qui envoie les mises à jour des device et autre via une socket. Il me permet aussi d’actionner ce que je veux... bref... ça marche super bien, j’ai le soft installé sur un écran tactile au mur. Le problème est que je ne peux avoir qu’un seul soft installé à la fois. (sinon obliger de faire du broadcast avec la socket) Et puis c’est biensûr inaccessible depuis le téléphone ou la tablette. Donc je veux allé plus loin et créer le même projet via une page web (sous Webdev). Ce qui réglera les problèmes cités ci-dessus. Donc pour cela j’ai créé un logiciel dit “Server de socket“ qui d’un côté reçoit les infos de la HC2 et de l’autre transmet ces infos aux clients via un site Web qui se connecte dessus via une WebSocket. ça marche très bien également. Je suis satisfait. MAIS (on y arrive...) dès que je veux sécurisé le tout avec un certificat SSL, et bien ça marche plus !!!!!! J’ai l’impression que le client et le logiciel ne se comprennent plus avec le SSL. Je vois la demande arriver sur le serveur de socket, mais impossible de lui faire accepter la connexion du client !! Je ne sais pas pourquoi !!?? si j’affiche la trame d’échange, c’est illisible. Pas réussi à trouver quelque chose de concret sur le navigateur en mode debug... Ma config : 1 PC Windows 7 PRO 64 avec : Server WEB IIS 7 Certificat SSL de type DV validé par VeriSign (il fonctionne déjà pour d’autres applications WEB) Il est installé sur le serveur IIS et je l’ai ajouté manuellement dans les certificats du PC (visible avec certmng.msc) Connexion web par HTTPS via le port 443 et pour la socket des clients via le port XXXX. Il va de soit que les ports sont bien ouverts et redirigés vers les bons device Protocole de sécurité de la WebSocket TLS1 Le firewall et l’antivirus ne change rien au problème (déjà tout désactivé pur vérifier) Version de Windev : 20, Version de Webdev : 23 Pour résumé : En HTTP et WebSocket non-sécurisée c’est tout OK En HTTPS et WebSocket sécurisée c’est tout NOK Merci à ceux qui ont eu le courage de tout lire et de peut-être m’aider !

hoplà, 2 FGK commandé, vais essayer ces histoires de fenêtre/chauffage...