Aller au contenu

Messages recommandés

Posté(e)

Bonjour à  tous et meilleurs voeux pour cette nouvelle année,

 

J'ai cherché un peu partout (peut-être mal) des informations sur la manière d'exécuter des requêtes  HTTP depuis une scène, mais sans succès.

 

J'ai réussi à  faire des requêtes POST :

 local url = "http://domohub:8888/api/add_value";
 local http = net.HTTPClient({timeout = 1000 });

 local body = "ident="..name.."&value="..value.."&create=yes"

  http:request(url, {
  options = { method = 'POST',
                headers = {
                            ["Content-Type"] = "application/x-www-form-urlencoded",
                            ["Content-length"] = string.format("%d", body:len())
                          },
                data = body
               },
    success = function(p)
        -- Nothing to do
    end,
    error = function(err)
       fibaro:debug(err)
    end
  })

Mais je n'arrive pas à  faire des GET et récupérer le contenu ...

Je n'ai pas trouvé de doc spécifique sur ce module net.httpclient, j'ai travaillé en essais / erreurs à  partir de différents tutos.

 

J'ai vu aussi des trucs du genre :

HC2 = Net.FHttp("192.168.1.23")

Mais dans une scène cela donne :

[ERROR] 11:41:06: line 9: attempt to index global 'Net' (a nil value)

Alors que ça fonctionne dans un VD ....

 

Avez-vous des pistes à  me conseiller ?

 

Cordialement

 

Posté(e)

Net.FHttp c'est dans un VD. Normal que tu aies une erreur dans une scène.

 

Dans une scène c'est :

local http = net.HTTPClient()
http:request("http://127.0.0.1:11111/api/globalVariables", { options = { method = 'POST', data = json.encode(newVar)}}) 

Dans un VD, un exemple pour récupérer mes températures avec un GET :

local JEEDOM = Net.FHttp("192.168.0.32", 80)

--TCuisine 
local response = JEEDOM:GET("/core/api/jeeApi.php?apikey=xnbvjfhxcuul9&type=cmd&id=2335")
fibaro:setGlobal("TCuisine",response);

  • Upvote 1
Posté(e)

OK, merci, mais ce que tu réponds c'est ce que je sais faire ... :-)

 

Mais comment fait-on un GET dans une scène, par exemple pour récupérer une valeur d'une autre box ?

 

Ou comment récupère t-on des données d'un POST ? (en espérant que ce soit pareil pour les GET)

Posté(e)

ceci peut t'aider ? 

local function updateDevice(successCallback, errorCallback, device, parameter, value)
  
  local http = net.HTTPClient()
  
  http:request('http://127.0.0.1:11111/api/plugins/callUIEvent?deviceID='..device ..'&elementName='..parameter ..'&eventType=onChanged&value=' ..value ..'',
	  {
      options = {
        method = 'GET'
      },
      success = successCallback,
      error = errorCallback
  })
end
Posté(e)

Hello,

 

C'est ce à  quoi j'étais arrivé, mais dans ton exemple tu ne prends en compte qu'une requête d'envoi de valeur (ce qui devrait être un POST en toute logique, mais c'est un autre sujet).

 

Pour net.HTTPClient, la fonction successCallback reçoit un paramètre qui est la réponse. On peut tester le code HTTP dans l'attribut status mais je ne connais pas l'attribut qui contient les données.

 

Par exemple, si je veux récupérer des infos d'une IPX800, je fais un GET sur http://mon_@ip/api/xdevices.json?cmd=40 et cela me retourne un objet JSON à  parser.

 

Comment accéder à  cet objet pour, par exemple, ventiler les données dans diverses variables ou VD ?

Posté(e)

Bonjour,

 

C'est bon, j'ai trouvé, c'est p.data comme dans l'extrait ci-dessous :

  http:request(url, {
                 options = { method = 'GET' },
                 success = function(p)
                            fibaro:debug(p.status)
                             fibaro:debug(p.data)
                 end,
                 error = function(err)
                            fibaro:debug(err)
                 end
   })

Merci !

 

(comment note t-on le sujet en résolu ?)

  • Upvote 1
  • 7 mois après...
Posté(e)

Hello, je galère avec ces requêtes https, vous avez un lien qui explique les syntaxes, paramètres, j'ai ouvert un compte chez fibaro developper, ça aide un peu mais pas pour les syntaxes ?

Ça veut dire quoi le .data ou .status ?

  • 9 ans après...
Posté(e) (modifié)

Bonjour,

Je rouvre un peu le sujet parce que moi aussi j'ai du mal avec les appels url via les scenarios.

J'essaie d'avoir le statut de la serrure mais je n'y arrive j'ai une erreur "400 Bad request" et chatgpt et autres ne m'aide vraiment pas sur ce point.


Ca marche très bien via une QA mais dans un scenario ca coince. Mais j'ai pas envie de faire une QA juste pour 3 lignes... C'est pour ca que je voudrais l'integrer à un scenario.

 

Pour expliquer simplement (parce que rien n'est simple avec la domotique) :

J'ai fait un QA qui check toutes les minutes via l'api freebox si les telephones familliaux sont connecté. Si tous sont manquant depuis 10 min, l'alarme est activé et on recoit un message push (je pense que je vais rajouter si la serrure est fermé).

J'ai dificilement reussi à rajouter un callback sur la nuki bridge pour executer un scenario. C'est censé etre facile mais les callback ne supporte pas les mot de passe dans l'url... Donc j'ai fait une redirection via un nginx sur mon serveur...

Donc maintenant je sais quand le serrure change d'etat mais je ne sais pas si elle est ouverte ou fermé. D'où ce scenario. Ainsi selon que ca s'ouvre je pourrais desactiver l'alarme automatiquement.


Si besoin et si ca vous interresse, je peux faire un tuto de ce que j'ai fait pour ceux que ca interresse.

 

Merci pour votre aide !

 

J'ai ceci :

local nukiBridgeIP = "192.168.251.223"
local nukiBridgePort = "8080"
local nukiLockId = "XXXX"
local token = "XXXX"

-- local url = "http://192.168.251.223:8080/lockState?nukiId=XXXX&token=XXXX"
local url = "http://" .. nukiBridgeIP .. ":" .. nukiBridgePort .. "/lockState?nukiId=" .. nukiLockId .. "&token=" .. token

net.HTTPClient():request(url, {
    options={
        method = 'GET',
        headers = {
            ["Content-Type"] = "application/json"
        },
        timeout = 5000
    },
    success = function(response)
        fibaro.debug("NUKI TEST", "Status: " .. response.status)
        fibaro.debug("NUKI TEST", "Data: " .. json.encode(response.data))
    end,
    error = function(errorMessage)
        fibaro.debug("NUKI TEST", "Erreur: " .. errorMessage)
    end
})
Modifié par esolma
Posté(e)

je n'ai JAMAIS fait de requête http via des scénarios.

En fait je n'ai  que des QA, qui soit tournent en boucle à fréquence régulière, soitsont appelés par GEA (qui me sert, entre autre, de déclencheur pour mes QA.

Pour tes serrures Nuki, regarde dans ma signature, j'avais développé un QA pour  la v1.

 

Maintenant pour les requêtes http dans les scénarios, je sait que la syntaxe est différente que pour les QA ...

Posté(e)

Oui j'avais vu ta quickapp je l'ai meme mis chez moi. Un peu modifier pour moi mais je l'ai !!

 

Le truc c'est que j'ai pas envie de faire 12 QA 12 scenarios qui appels chacun l'un et à la fin il te faut un diagramme à la con pour ne serait-ce retrouver tes billes quand ca ne marche plus.....

A l'epoque j'avais fait je ne sais plus combien de scenarios pour les vacances : un pour les volets le matin, un autre le soir, un pour les lumieres, le chauffage etc... Et quand j'allais dans scenario plus de la moitié etaient desactivé et à chaque fois je me disais "mais pourquoi ils son desactivés ? à quoi ils servent ? je les efface ou pas ?". Aujourd'hui j'en ai plus qu'un pour le mode vacanaces et je m'en porte beaucoup mieux. Et pareil pour mes autres scenarios que j'ai fusionné.

 

Donc c'est vrai que je me complique la vie au depart mais c'est pour plus tard quand je devrais à nouveau mettre les mains dedans.

Posté(e)

En fait, plus je reflechie et plus je me dis : pourquoi ne pas reprendre ton QA et au lieu de faire un refresh toutes les 10s, faire un refresh avec les callback du bridge. Et l'appel du QA se ferait avec un parametre lock, unlock ou state et là j'aurais ce que je veux.

En meme temps ca economiserait de la batterie. Et un tas !

Posté(e)

Vu l'erreur (http 400), je doute fort que la scène ou le QA aie une quelconque influence.
C'est ta requête qui est mal formée, tu te fais jeter par le serveur Web.

Je ne connais pas l'API de Nuki, mais essaie de bien vérifier dans la doc si ça correspond à ce que tu as mis.

C'est par là qu'il faut chercher.

Posté(e)
Il y a 5 heures, esolma a dit :

En fait, plus je reflechie et plus je me dis : pourquoi ne pas reprendre ton QA et au lieu de faire un refresh toutes les 10s, faire un refresh avec les callback du bridge. Et l'appel du QA se ferait avec un parametre lock, unlock ou state et là j'aurais ce que je veux.

En meme temps ca economiserait de la batterie. Et un tas !

pourquoi, je fais une interrogation du bridge toutes les 10s (c'est le bridge qui est interrogé, pas la serrure, ,donc pas d'impact sur la durée de vie des piles de la serrure) :

Pour que si j'ouvre la serrure via un autre  moyen que la HC3, la HC3 affiche le bon statut.

J'ai essayé que le bridge envoie une requête https à la HC3 (pour éviter cette boucle de 10s) si changement, mais le bridge ne sait envoyer que du http et/ou (c'était il y a longtemps) inclure dans une requête classique les crédentials de la HC3. Maintenant, si tu sais comment, je suis preneur !

Posté(e)

Je sais pas mais chez moi le fait d'interroger le bridge toutes les 10s bouffe la batterie à vue d'oeil : 1 mois max pour la smartlock. Par contre en passant à 30s je tiens facile 3 à 4 mois sans devoir recharger. Je sais que tu interroges LE bridge mais il y a sûrement un check au niveau de la smartlock qui dois se faire sinon j'aurai pas ce comportement.

 

Lazer :

-- local url = "http://192.168.251.223:8080/lockState?nukiId=XXXX&token=XXXX"
local url = "http://" .. nukiBridgeIP .. ":" .. nukiBridgePort .. "/lockState?nukiId=" .. nukiLockId .. "&token=" .. token

 

l'url commenté est celle qui fonctionne dans un navigateur ou via curl. J'ai essayé les 2 dans le scenario mais ça marche pas. Chatgpt m'a conseillé d'encoder en base64 l'url, de rajouter toute une fonction pour encoder/decoder mais pareil marche pas non plus.

 

 

Jojo :

Pour faire court les callback n'accepte pas le https et ni les comptes/password dans l'url donc    http://admin:toto@IP_HC3/api/scenes/187/execute    ne fonctionne pas alors que dans ton navigateur ça passe nickel.

Tu dois utiliser    http://IP_HC3/api/scenes/187/execute    mais dans ce cas c'est la HC3 qui ne veut pas car il manque les credentials.

 

Comme j'ai un serveur plex à la maison avec toute une stack sonarr/raddar/delugevpn/blablabla j'ai un proxy "nginx proxy manager". Alors je l'ai utilisé pour faire une redirection simple (si on peut le dire) :

Mon callback sur le bridge devient :     http://bridge.mon-nom-de-domaine

Pour l'ajouter dans le bridge il faut mettre des % partout. Donc ça devient :     http%3A%2F%2Fbridge.mon-nom-de-domaine       (j'ai utilisé https://www.url-encode-decode.com pour le faire)

L'url complète pour ajouter le callback est donc :     http://192.168.251.223:8080/callback/add?token=XXXX&url=http%3A%2F%2Fbridge.mon-nom-de-domaine        à coller dans un navigateur

Puis dans nginx j'ai créé un nouveau host avec mon url et rajouté ces quelques lignes dans ses paramètres :

location / {
    proxy_set_header Authorization "Basic YWRtTySGF5ZXXuNjYPP5JQk";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_pass_request_body on;
    proxy_pass_request_headers on;

    proxy_pass http://192.168.1.200/api/scenes/187/execute;

    proxy_redirect off;
    proxy_buffering off;
    proxy_connect_timeout 5s;
    proxy_send_timeout 10s;
    proxy_read_timeout 10s;
}

 

L’autorisation Basic XXXX est générée en base64 avec ton admin:password que tu aurais voulu intégrer dans l'url... c'est chatgpt qui me l'a généré.

 

Et voilou : à chaque fois que mon bridge callback j'ai la scène 187 qui s’exécute. Par contre je ne sais pas si c'est ouvert ou fermé. C'est pour ça que je voudrais faire un lockstate pour avoir l’état.

 

 

Mais comme je l'ai dis : l'url que j'ai copié mot pour mot dans le scenario fonctionne dans une quickapp. Alors je réfléchi....

Mon cerveau fume un peu en ce moment mais je vais trouver la solution. Une solution simple parce que 36 QA ou scenarios ça devient ingérable et c'est pas ce que je veux.

 

 

×
×
  • Créer...