Lazer

Voilà : Par contre c'est fait à la va-vite, je n'ai pas testé le code LUA, j'espère qu'il n'y a pas d'erreur de syntaxe. N'hésitez par à me corriger. Sinon pour @J3R3M, comme tu peux le voir, cela intrigue beaucoup de monde, exemples : https://www.domotique-fibaro.fr/topic/9055-incomprã©hension-dans-les-nethttpclient/ https://www.domotique-fibaro.fr/topic/10888-nethttpclient-contourner-lasynchrone-cest-possible/ https://www.domotique-fibaro.fr/topic/10900-comportement-du-timeout-dans-les-nethttpclient/ https://www.domotique-fibaro.fr/topic/11558-récupérer-les-données-retournées-par-nethttpclient/

Utilisation de net.HTTPClient() asynchrone - dans une scène en LUA sur HC2/HC3 - - dans un QuickApp sur HC3 - Dans les scènes, Fibaro ne nous laisse pas le choix, dès que l'on veut faire des appels HTTP, on est obligé d'utiliser la fonction asynchronse net.HTTPClient(). La fonction Net.FHTTP() synchrone utilisée dans les VD n'est pas disponible dans les scènes. Toutefois, l'avantage de net.HTTPClient() est d'accepter les connexions sécurisées HTTPS devenues majoritaires sur Internet. Exemple de code simple pour une requête de type GET local http = net.HTTPClient() http:request("http://1.2.3.4/url", { success = function(response) if response.status == 200 then print('OK, réponse : '.. response.data) else print("Erreur : status=" .. tostring(response.status)) end end, error = function(err) print("Erreur : " .. err) end, options = { method = 'GET' } }) L'exemple suivant effectue une requête de type POST permettant d'envoyer des données vers le site distant. De plus, la fonction success() récupère les données de type JSON en vue d'un traitement ultérieur (notez que les données envoyées vers le site Web et les données reçues depuis le site Web sont différentes, cela dépend de l'application qui tourne sur le site) : -- Les données à envoyer au formulaire local myJson = { "couleurs": { [1] = "bleu", [2] = "blanc", [3] = "rouge" }, "fruits": { [1] = "pomme", [2] = "banane" }, } -- Appel HTTPS local http = net.HTTPClient() http:request("https://www.domaine.com/url", { success = function(response) if response.status == 200 then if response.data and response.data ~= "" then print('Retour : '.. response.data) local jsonTable = json.decode(response.data) -- Parcours de la table JSON local k, v for k, v in pairs(jsonTable) do print("key = " .. k .. " - type(v) = " .. type(v)) end -- Ici la suite du code, exécuté en asynchrone, donc après la fin de l'exécution du code appelant http:request() -- ... else print("Error : empty response data") end else print("Erreur : status=" .. tostring(response.status)) end end, error = function(err) print("Erreur : " .. err) end, options = { method = 'POST', timeout = 5000, checkCertificate = false, headers = { ["content-type"] = 'application/x-www-form-urlencoded;', ["Authorization"] = "Basic YWRtaW46cGFzc3dvcmQ=" -- username:password encodé en Base64 (admin:password) }, data = json.encode(myJson) } }) -- Ici la suite du code, exécuté en synchrone, donc avant l'exécution du contenu de la fonction success() -- ... On remarque dans les options que l'on peut choisir les paramètres suivants : method : obligatoire : GET ou PUT ou POST ou DELETE timeout : facultatif : délai d'attente en millisecondes avant échec de la requête. Peut être utile avec certains serveurs un peu trop lents à répondre. Dans le doute, inutile d'utiliser ce paramètre. checkCertificate : facultatif : true ou false, permet d'ignorer les alertes de sécurité sur les certificats auto-signés (non reconnus pas une autorité de certification approuvée) headers : facultatif : permet de passer le(s) en-tête(s) HTTP de son choix vers le site Web distant. Si vous ne savez pas ce qu'est un Header, c'est que vous n'avez probablement pas besoin d'envoyer de header, donc ignorez ce paramètre. data : facultatif : ce sont les données à envoyer dans les formulaires POST et PUT sous forme de chaine de caractères. Donc si les données sont de type tableau JSON, il faut les encoder avec json.encode(). Asynchronisme net.HTTPClient() est asynchrone, le code dans les fonctions success() et error() appelées en callback s'exécute toujours après la fin de l'exécution du thread principal. Quand on commence à programmer en asynchrone, il ne faut plus jamais utiliser de fonctions synchrones comme sleep(), sous peine de comportement surprenant. Préférer à la place l'emploi de la fonction settimout() qui est elle-même asynchrone (chercher les exemples sur le forum) La bonne pratique quand on programme en asynchrone est la suivante : Après un appel à net.HTTPClient(), le code devrait se terminer le plus rapidement possible afin de laisser la main à la fonction success() appelée en callback de net.HTTPClient(). La suite du code se déroule donc dans la fonction success(). Celle-ci, à sont tour, peut faire d'autres appels à net.HTTPClient() ou settimeout() pour déclencher de nouveaux appels de fonctions en callback asynchrone. Etc... C'est la technique que j'ai employé dans mes scènes Watchdog et Yamaha MusicCast, partagées sur le forum. C'est une certaine gymnastique qui n'est pas évidente au début, et oblige à revoir toute la structure de son code LUA. En complément je vous invite à lire ce sujet sur la protection des requêtes http avec pcall() :

Oui maitre

C'est un sujet qui revient souvent sur le forum net.HTTPClient() est asynchrone, le code dans les fonctions appelées en callback s'exécute toujours après la fin de l'exécution du thread principal. Quand on commence à programmer en asynchrone, il ne faut plus jamais utiliser de fonctions synchrones comme sleep(), sous peine de comportement surprenant comme tu l'as constaté. Préférer à la place l'emploi de la fonction settimout() qui est elle-même asynchrone (chercher les exemples sur le forum) La bonne pratique quand on programme en asynchrone est la suivante : Après un appel à net.HTTPClient(), le code devrait se terminer le plus rapidement possible afin de laisser la main à la fonction success() appelée en callback de net.HTTPClient(). La suite du code se déroule donc dans la fonction success(). Celle-ci, à sont tour, peut faire d'autres appels à net.HTTPClient() ou settimeout() pour déclencher de nouveaux appels de fonctions en callback asynchrone. Etc... C'est la technique que j'ai employé dans mes scènes Watchdog et Yamaha MusicCast, que tu peux étudier par exemple. C'est une certaine gymnastique qui n'est pas évidente au début, et oblige à revoir toute la structure de son code LUA. Malheureusement Fibaro ne nous laisse pas le choix dans les scènes, dès que l'on veut faire des appels HTTP, on est obligé d'utiliser la fonction asynchronse net.HTTPClient(). La fonction Net.FHTTP() synchrone utilisée dans les VD n'est pas disponible dans les scènes.

oui il y a un popup qu'il faut autoriser. Essaye avec un autre navigateur.

La coupe du monde de quoi ?

Les HC2 aussi est ultra stable... ça fait 2 ou 3 mois qu'on n'a plus aucune mise à jour, pas de risque de régression Bah nous on fait de la domotique grand public de 2018 maintenant.... on a un installé le skill Bruit de pet sur Alexa ce soir.... voilà voilà.... il y en a au moins une qui a bien rigolé

J'ai failli m'étrangler :

Merci Jojo, mais c'est un phénomène assez connu sur tous les forums, la première page est rarement lue, pourtant elle est censée rassembler les infos utiles à lire en premier. Pas grave, il y a toujours une bonne âme pour répéter Heureusement que tu suis Tu reviens quand tu veux chez Fibaro

désolé c'était mal formulé Mais c'est en substance ce que te dis le message d'erreur.

euh, je crois que c'est juste ton code LUA qui est mal formaté, avec des virgules ou des accolades placées n'importe où. Je t'ai donné un exemple de code, mais désolé je n'ai pas le temps de tester du LUA, donc c'est purement théorique.... Sinon aide toi des nombreux exemples sur le forum. Par exemple le dernier code que j'ai partagé utilisant httpclient() est dans la scène sur le tuto Yamaha MusicCast. Mais ce n'est pas le seul.

C'est comme le Homepod, l'Intercom est tellement parfait qu'ils peuvent se contenter de 10% du marché mondial et peuvent ignorer les 90% restants. Parfois certaines stratégies d'entreprise m'échappent... encore que cela reste compréhensible pour le premier objet cité.

Oui ça semble OK Je ne sais pas alors.

Non pas besoin, l'intérêt de HAbridge est d'être reconnu nativement, car il emule un pont Philips Hue. Je n'ai pas encore testé, mais par contre je pense qu'on ne pourra pas dire 'ouvre' ou 'ferme'.

J'en doute, HA-Bridge sert à émuler un pont Phillips Hue, donc des lumières. Mais peut être que quelqu'un a une astuce...

OK dommage, mais tu as raison c'est ce que je craignais. Pourtant mon smartphone sait répondre à OK Google en mode avion, mais bon, il y a un vrai CPU dedans. PS : inutile de citer le message supérieur

Oui, clairement HA-Biridge permet d'aller beaucoup loin que le Skill de base. Il y a un truc qu'il faut que je teste avec HA-Birdge, c'est si ça peut fonctionner totalement cloudless... exemple : débrancher l'accès Internet, et voir si la reconnaissance vocale peut se faire en locale, et actionner HA-Birdge (qui par définition ne fonctionne qu'en local)

Oui moi j'ai tout configuré avec le smartphone, sauf le changement de langue que j'ai fait via le PC avec le lien donné plus haut par @Cmoi20 Je me suis limité aux lumières pour l'instant, de toute façon hors de question que je laisse les ouvrants sous contrôle d'un assistant vocal.

Donc si je comprends bien, mon Alexa Store est en US car j'ai dû y accéder il y a 15 jours avec mon compte Amazon pour chercher des skills, avant de commander les Echo. Bon finalement c'est pratique, car j'en profite pour installer tous les Skills non dispo en FR. Pas de chance pour Audio Station, il faut passer à DSM 6.2, et ce n'est pas encore vraiment au point sous Xpenology. Par contre ce n'est toujours pas clair pour le Skill Fibaro. Vous aussi il n'a retrouvé aucune pièce ? Donc obligé de créer tous les groupes à la main ?

Ah bon, on peut avoir plusieurs Fibaro ID associé à la HC2 ??? Je ne savais pas. Bon y'a du bien et du pas bien. Alexa parle en français, mais pour une raison inconnue, l'appli est en anglais et ne me propose que des trucs aux US (météo, radio, flash quotidien, etc) Pourtant j'ai bien mis mon adresse en France pour cet appareil et pour l'Echo. A la connexion à mon compte Amazon, elle a inversé mon nom et mon prénom. Pas très WAF... Le coté positif, c'est que je peux installer le Skill Fibaro sans modifier mon adresse (bien qu'elle soit en France), car il croit que je suis aux USA Fibaro ID a trouvé TOUS mes modules, donc pas possible de choisir la compte Il a mélangé toutes mes lumières, impossible de savoir à quelle pièce ça correspond, ça n'est pas indiqué dans le nom des devices détectés. Pas WAF.... je vais passer 2h à les renommer et les identifier une par une. Alexa a trouvé mon HABridge automatiquement, pour le coup l'émulation des Philips Hue c'est vraiment ce qui fonctionne le mieux Par contre, truc très con, je ne peux pas installer de Skill FR.... C'est pas encore trop au point la sortie en France, comprends pas pourquoi il me croit aux US.

Pour la Skill Fibaro, il vous demande le FIbaro ID ? Mais après, on peut choisir un utilisateur avec des droits limités seulement sur certains modules ? Pas envie que Alexa utilise le compte admin de mon HC2....

C'est que les utilisateurs d'iPhone qui ont un souci ? Parce que Android me propose de faire une mise à jour, mais du coup je n'ose pas.

C'est jusqu'à lundi 9h la promo Source officielle : la page d'accueil d'Amazon.fr

Oui et même en Prime, on peut avoir autant d'adresse de livraison qu'on veut Pour les volets, c'est pas une histoire genre il faut dire "allume" les volets ? (au lieu d'ouvrir)

Ton "options" est mal formaté, c'est plutôt un truc dans ce genre là : local myJson = { "event": { "cgi": "modzona", "system_number": "1", "zone_number": "4", "option": "state", "value": 0, "device_id": "5a37f4167765621039320000" } } local http = net.HTTPClient() http:request('https://airzonecloud.com/events/' .. myConsigne, { options = { method = 'PUT', data = json.encode(myJson) }, -- la suite ... }