Bonjour, je cherche à récupérer l’état d’une DIN de ma V3 sur ma V5 pour commander un objet. Je n’y arrive pas.
Je fais un
Bonjour,
est-ce que le push GET répond bien par le JSON attendu ?
Est-ce que votre V3 est sécurisée par un login ? si oui, assurez-vous de renseigner le mode d’authentification en BASIC, puis insérez le login et le mot de passe de la V3.
Oui, le push est correct, je collecte déjà les AN et les relais. je n’ai mis pas de login/mdp .
avez-vous vérifié la structure de la réponse JSON ?
json validator
je viens de faire un test avec ma V3.
le JSON reçu est incomplet, la V3 met sans doute trop de temps à renvoyer la réponse qui est alors tronquée par la V5.
minimize activé ou non, ça ne change rien.
un message d’erreur apparaît une fraction de seconde avant de disparaitre. « ID not found »
Oui, effectivement j’ai remarqué çà ( j’ai pensé que c’était normal …). Existe t’il une commande permettant de pusher une seule entrée ?
Bonjour,
ce qui me surprend c’est que @Pat dit relever les sorties sans pb alors que la réponse contient plus de caractères…?¿?
Bogue de l’API?
Bonne journée
non, pas d’alternative sauf script externe ou box domotique en attendant un correctif…
@Jeremy_GCE, @Kevin_GCE , bonjour messieurs 
, y a t’il une solution pour interroger une V3 ? un plugin est prévu ?
Les JSON reçus par la V5 cmd=10, cmd=20 sont tronqués.
cmd=30 est correct.
cmd=40 ok
bonne journée
je pense que c’est un bogue, pas une limite avec le nombre de caractères.
Un push peut recevoir sans problème un json de 512 caractères, ce qui n’est pas le cas ici.
Quand on exécute la commande cmd=10 dans le push, il y a un message d’erreur comme dit plus haut.
Personnellement, cmd=20 renvoie également un json tronqué.
J’ai testé sur mes 2 V5. même problème.
Ma V3 est en 3.05.70
en capturant l’écran en vidéo image par image, j’ai pu isoler le message furtif
tous les champs se remplissent du message d’erreur, même l’IP
Exact @groscrabe, j’ai une réponse tronquée pour les relais aussi, j’ai du faire une commande par relais.
J’avais :
1/ api/xdevices.json?cmd=20 => ,« OUT17 »:0,« OUT18 »:0,« OUT19 »:0,« OUT20 »:0,« OUT21 »:0,« OUT22 »:0,« OUT23 »:0,« OUT24 »:0,« OUT25 »:0,« OUT26 »:0,« OUT27 »:0,« OUT28 »:0,« OUT29 »:0,« OUT30 »:0,« OUT31 »:0,« OUT32 »:0}
2/ /preset.htm?set6=1 pour requête ON et /preset.htm?set6=0 pour requête OFF sur le relais 6.
Pour les AN c’est correct :
api/xdevices.json?cmd=30 => « product »:« IPX800_V3 »,« AN1 »:0,« AN2 »:0,« AN3 »:233,« AN4 »:284,« AN5 »:0,« AN6 »:0,« AN7 »:0,« AN8 »:0,« AN9 »:0,« AN10 »:0,« AN11 »:0,« AN12 »:0,« AN13 »:0,« AN14 »:0,« AN15 »:0,« AN16 »:0}
« … in the mean time … », Je vais connecter mon entrée sur la V5 au lieu de la V3. Merci pour votre support.
Cordialement
Patrick
2 « J'aime »
Bonjour,
C’est effectivement une lenteur de la V3, elle fonctionne en 10Mb/s, la V5, elle, tourne en 100Mb/s. La V3 mets trop de temps à répondre.
Pour la rendre compatible, il faudrait ajouter un délai d’attente après la requête, le problème c’est que ce délai d’attente impacterait l’ensemble des autres clients utilisant la fonction réseau en question…
Le parser JSON de la V5 ne peut donc pas fonctionner avec certaines commandes de l’IPX800 V3.
Bonjour Kévin,
il faudrait peut-être que l’utilisateur puisse activer le délai au cas par cas (mise à dispo d’un toggle dans l’edition de l’objet push).
un plugin V3 est dans la roadmap ?
Bonjour à tous, et merci pour vos éclairages. Si je comprends bien la V3 est trop lente vs la V5. Cependant nous recevons quand même des données.
Question1 : Pour quelle raison cela n’affecte pas les AN?
Question 2 : Ne serait 'il pas possible pour la V3 d’envoyer les données dans l’ordre inverse?
On reçoit les données de la IN19 à la IN32, je peux imaginer qu’avec ce sens inversé on recevrait à peu de choses près : de IN14 à IN1… 
Ce qui ne devrait (conditionnel …) pas changer le parsing et résoudre ce souci?
les réponses concernant les Ana et les CPT sont plus courtes, plus rapides à transmettre.
la V3 ne sait pas faire de Push PUT, elle ne peut donc pas modifier une IO sur V5.
ce serait alors dommage pour ceux qui souhaiteraient interroger IN15 ou IN31 
Un ticket interne a été ouvert à l’époque à ce sujet, il a été rejeté car trop risqué pour les autres clients (MQTT, Mail, Push, etc…)
Non, pas de plugin V3 prévu.
Le parsing ne serait de toute façon pas possible car sans le début ou la fin de la réponse, il est en défaut (pas d’accolade ouvrante en début de réponse…)