J’ai un IPX 800 v4 (FW 4.00.30) sur lequel je bute sur un problème de configuration de source de données.
Je souhaite récupérer les infos de ma VMC Helios, qui est capable de me les fournir via modbus tcp. Pour cela j’ai donc hébergé sur un Raspberry un script python sachant dialoguer et récupérer en modbus tcp les infos de la vmc et les formatte en JSON, puis j’appelle ce script Python dans un script PHP pour retourner le JSON. C’est donc ce dernier qui doit être la source de l’IPX.
Concrêtement, voici ce que ca donne:
Quand on regarde la ligne en question, deux chose m’étonnent:
cela semble utiliser un POST alors c’est un GET qui a été configuré au niveau de la source de données
cela semble concaténer une extension « .json » à l’URL => forcément de l’autre coté ca va bloquer puisqu’il n’y a pas de fichier .json sur le serveur web, juste un fichier PHP.
Je ne pense pas que ce soit la fonction qui s’occuper de pinger les sources de données car quand j’ajoute une source de donnée en GET, je vois bien des GET dans la console (onglet Network).
A noter que je n’ai pas le warning sous IE (mais le probleme persiste cependant).
Tres interessant ton idée de timeout, car effectivement, mon script python qui dialogue en modbus TCP avec la VMC met bien 4 à 5 secondes à me retourner les infos.
Donc à quelques ms près c’est le temps global que met mon script PHP à retourner les infos…
Je n’ai pas de Wireshark à dispo dans l’immédiat, mais je tenterais bien d’écouter les flux entre l’IPX et le Raspberry pour voir si l’IPX ne serait pas à l’initiative de la cloture de la session TCP. Qu’en penses tu?
Autre chose que je vais tenter (ce WE, en semaine je n’ai pas le temps): je vais alléger mon script en faisant juste un echo des infos indiquées dans ma copie d’écran ci-dessus (sans polling des infos aupres de la VMC pour supprimer la latence): si ca marche ce sera bien un probleme de timeout.
Je vous tiens informés du résultat de ces tests. Merci!
Mike
Comme convenu, j’ai fait ce WE le test suivant: j’ai commenté tout mon script PHP et il ne fait plus qu’un echo du JSON (sans aller donc récupérer les infos de la VMC qui met 5 secondes à les retourner) => Ca marche!
Cela veut donc dire que l’IPX a probablement un timeout inférieur à 5 secondes sur la récupération des données.
Du coup, je vais changer mon script: je vais le mettre en cron de mon Raspberry de façon à ce qu’il récupère toutes les 15 mins les infos de la VMC et va les stocker dans un fichier JSON. L’IPX viendra lui récupérer ce JSON qui sera donc toujours présent et surtout très rapide à retourner. Ainsi, je passerai le requetage de la VMC en asynchrone et non plus en synchrone.
Merci Teebex de m’avoir orienté, car ton feeling était le bon!
Mike
Je me réponds à moi-même pour éclairer d’autres qui pourraient avoir le meme soucis que moi.
En fait, ce n’était pas du tout un problème de timeout: l’IPX sait bien etre « patient » et attendre plus de 5 secondes pouru la récupération d’une source de données.
Mon problème venait d’une erreur dans la lecture des registres de la VMC, qui poussait un caractère ‹ 0x00 › dans une température. Ce caractère était automatiquement supprimé par mon browser quand je tentais la récupération du JSON depuis ce dernier donc je ne le voyais pas, mais l’IPX lui le voyait bien et bloquait sa lecture de la source de donnée…
Une fois corrigée, et bien que le script mette plus de 5 secondes avant de retourner le JSON, l’IPX récupère très bien le JSON.
Mike
Hello Teebex,
Je viens de faire le test: oui. Meme en attente du retour du GET, l’IPX sait depuis une autre connexion TCP d’un client exécuter ses ordres (pour ce qui me concerne, pendant qu’il attendait le JSON, j’ai demandé depuis un autre client à activer un relais qui déclenche ma porte de garage).
Mike
Depuis que je suis passé en béta 4 , les sources de données correspondantes à L’ECO DEVICES et ECO DEVICES RT ne se réactualisent plus.
Par contre pour les sources de données météo et IPX800 cela fonctionne.
mais je peux éliminer certaines pistes d’erreurs.