Depuis la mise à jour du 8/01/2024, mon script http ne fonctionne plus !
Il est très simple et marchait très bien:
HTTP://192.168.1.39/dateux?x=#timestamp#&tempmin1=#[Extérieur][Météo][Température Min +1]#&tempmin2=#[Extérieur][Météo][Température Min +2]#
Que puis-je faire pour le refaire fonctionner ?
Merci.
Salut,
Donner des infos…
Version de Jeedom, plugin stable ou beta ?
Ce script attaque quoi comme site et doit faire quoi
Donner un log, le plugin script doit en générer un, sinon le passer en debug
Bonjour,
J’ajoute : est-ce que cela fonctionne en ouvrant l’URL depuis ton navigateur en remplacement les commandes donc par exemple http://192.168.1.39/dateux?x=1704866118&tempmin1=5&tempmin2=8
Et qu’est ce qui s’affiche dans ce cas ?
Note : il y a un espace en trop dans ta première commande mais on va dire que c’est une erreur du au copier/coller ?
Utilise bien la balise de texte preformatée
Merci pour vos réponse.
J’utilise la version Jeedom 4.3.21 stable.
Et lorsque je tape la commande dans mon navigateur ça fonctionne correctement. J’attaque un ESP32 avec du code que j’ai développé. Le tout fonctionnait correctement avant la mise à jour du plugin.
je génère le log et je l’envoi dans un message suivant.
C’est quoi la balise de texte préformattée ?
J’ai mis le log en debug, je n’ai pas de log, ou je n’ai pas fait la bonne manip pour mettre le log en debug.
Merci pour votre aide, que puis-je faire ?
Pareil chez moi, j’ai des commandes http avec authentification pour contrôler mes stores, il ne se passe plus rien.
J’ai essayé de mettre l’authentification direct dans l’url même résultat.
Rien dans le log en debug également.
J’ai essayé de resauver les commandes et l’équipement, pas mieux…
Cela ne fonctionne plus même avec des url sans #tag#
Smart / 
Un lien avec l’api jeedom ou du plugin script?
Pour moi c’est l’update du plugin script qui a tout cassé
Bonjour
Mêmes observations ici : toutes les commandes script http et info json sont inopérantes depuis la dernière mise à jour.
L’équipement distant est un Wifipower Fil Pilote, les commandes sont de type GET http://<@IP>/F0x avec x de 0 à 5 pour les 6 ordres fil pilote. L’info d’état se récupère via la page http://<@IP>/data.json. Via un navigateur, lorsque je lance les ordres ou que j’accède à la page data.json, le fonctionnement est nominal. Les traces tcpdump que j’obtiens sont les suivantes :
10:55:04.818407 IP 192.168.0.10.65265 > 192.168.0.201.http: Flags [P.], seq 1:498, ack 1, win 65535, length 497: HTTP: GET /F04 HTTP/1.1
10:55:04.822371 IP 192.168.0.201.http > 192.168.0.10.65266: Flags [S.], seq 16822, ack 2911047615, win 5840, options [mss 1460,nop,nop,sackOK], length 0
10:55:04.822403 IP 192.168.0.10.65266 > 192.168.0.201.http: Flags [.], ack 1, win 65535, length 0
10:55:04.893894 IP 192.168.0.201.http > 192.168.0.10.65265: Flags [P.], seq 1:124, ack 498, win 5343, length 123: HTTP: HTTP/1.1 200 OK
Dès que je passe par le plugin script,
10:54:03.641607 IP 192.168.0.200.58186 > 192.168.0.201.80: Flags [P.], seq 1:169, ack 1, win 64240, length 168: HTTP: POST /F04 HTTP/1.1
10:54:03.649007 IP 192.168.0.201.80 > 192.168.0.200.58186: Flags [P.], seq 1:200, ack 169, win 5672, length 199: HTTP: HTTP/1.1 200 OK
J’ai l’impression que le plugin script envoie un POST, mais que mon équipement accepte seulement le GET pour modifier son comportement. Peut-être est-ce le même problème que @fran-jeed et @dJuL ?
il semble que nous soyons au minimum 3 personnes ayant rencontré le même problème
Pour avancer dans l’analyse de mon équipement
curl -i -X GET http://@IP/F05 a le comportement souhaité (le radiateur passe en Confort -2°), et le json de retour est bien récupérécurl -i -X POST http://@IP/F05 n’a pas le comportement souhaité (pas de changement d’état du radiateur), et les données récupérées en retour sont de la boueDans mon cas, je penche pour un changement de méthode utilisée dans la mise à jour. Un développeur du plugin pourrait-il me confirmer ce point ?
Bonjour,
J’ai bien vu le sujet l’analyse est en cours. Désolé pour la gene occasion j’ai encore du faire n’importe quoi.
c’est bien ca qui est nouveau, pour les commandes http action la requête est faite en POST à présent
cela a été fait dans le cadre du support de POST json
Bonjour,
J’ai poussé normalement une correction qui sera disponible d’ici quelques minutes (stable et beta).
Désolé encore pour le soucis et le délai de correction, je suis en vacance et donc j’ai pas regardé tout de suite les tickets et le communiste. Encore désolé.
Merci, mais pour moi, ça ne fonctionne toujours pas ! aucun changement
Je viens de regarder mais je ne comprend pas cmt ca peut fonctionner:
on créé la requête avec $request qui contient la requête de la config
$request = str_replace('#API#', config::byKey('api'), $this->getConfiguration('request'));
if (trim($request) == '') {
throw new Exception(__('La requête ne peut pas être vide : ', __FILE__) . print_r($this, true));
}
...
$request_http = new com_http($request);
jusque là logique; donc $request n’est pas vide
mais après on test si pas vide pour passer en POST; ca ne le sera pas donc on va toujours passer en POST
if ($this->getType() == 'action' && trim($request) != '') {
$request_http->setPost($request);
}
et $request ne contient pas les paramètres mais la requête donc pourquoi passer la requête dans le payload du POST?
Effectivement j’ai aucune idée de pourquoi dans le code ya ca et j’ai vraiment pas le temps de chercher a comprendre aujourd’hui… J’ai tout supprimé la partie post et vient de repousser une mise a jour
Merci, ce coup-ci ça fonctionne comme avant !
Merci, c’est bien fonctionnel comme ça.
@Loic @Mips : si le besoin d’une méthode POST est sûrement pertinent (sinon vous ne l’auriez pas codé 
), il me semble important de conserver la méthode GET dans le plugin script, des vieux objets reposent sur cette méthode seule et ne seront plus mis à jour (vive la rétro-compatibilité…).
Amicalement,
Pascal
Éventuellement une case POST (genre option checkbox) dans la commande pour le future ?
Merci pour la correction rapide en tous cas.