IPX800 - API - conflit de 2 appels GET au même moment

Bonjour,

J’utilise home assistant et je rencontre un souci avec les API de l’IPX800.
Home assistant est paramétré pour réaliser 2 appels REST toutes les 15 secondes :

  • Le premier pour récupérer l’état des volets : /api/xdevices.json?key=toto&Get=VR
  • Le second pour récupérer l’état des XTHL : /api/xdevices.json?key=toto&Get=XTHL

Lorsque les deux appels sont réalisés en même temps, les deux API retournent la même réponse. Ainsi j’ai une réponse avec les valeurs de l’XTHL pour l’URL /api/xdevices.json?key=toto&Get=VR.

Je pensais que cela venait de Home assistant, je suis donc passé par un script python qui s’occupe de faire les appels REST à l’IPX 800, ainsi je peux logger la réponse de l’IPX 800.

Voici ce que j’obtiens dans l’ordre d’execution :

Exemple1 : Les réponses sont mélangées

//Cette trace correspond au déclenchement de la méthode pour faire l'appel REST vers les X4VR
{"log":"[2021-01-29 11:01:55 +0000] [8] [INFO] Call 
getX4VRTestValues\n","stream":"stderr","time":"2021-01-29T11:01:55.425104845Z"}

//Cette trace correspond au déclenchement de la méthode pour faire l'appel REST vers les XTHL
{"log":"[2021-01-29 11:01:55 +0000] [8] [INFO] Call 
getXTHLTestValues\n","stream":"stderr","time":"2021-01-29T11:01:55.42574315Z"}

//Cette trace correspond au retour de l'appel REST vers les X4VR
{"log":"[2021-01-29 11:01:55 +0000] [8] [INFO] X4VR response :{\"product\": \"IPX800_V4\", 
\"status\": \"Success\", \"VR1-1\": 0, \"VR1-2\": 0, \"VR1-3\": 0, \"THL2-TEMP\": 20.71, \"THL2-HUM\": 
52.62, \"THL2-LUM\": 197, \"THL3-TEMP\": 20.05, \"THL3-HUM\": 58.94, \"THL3-LUM\": 69, \"THL4- 
TEMP\": 24.44, \"THL4-HUM\": 51.48, \"THL4-LUM\": 208, \"THL5-TEMP\": 28.73, \"THL5-HUM\": 
38.92, \"THL5-LUM\": 0, \"THL6-TEMP\": 20.24, \"THL6-HUM\": 65.74, \"THL6-LUM\": 596, \"THL7- 
TEMP\": 19.52, \"THL7-HUM\": 58.62, \"THL7-LUM\": 322, \"THL8-TEMP\": 19.34, \"THL8-HUM\": 
59.13, \"THL8-LUM\": 17, \"THL9-TEMP\": -46.85, \"THL9-HUM\": -6.0, \"THL9-LUM\": 0, \"THL10- 
TEMP\": -46.85, \"THL10-HUM\": -6.0, \"THL10-LUM\": 0, \"THL11-TEMP\": -46.85, \"THL11-HUM\": 
-6.0, \"THL11-LUM\": 0, \"THL12-TEMP\": -46.85, \"THL12-HUM\": -6.0, \"THL12-LUM\": 0, \"THL13- 
TEMP\": -46.85, \"THL13-HUM\": -6.0, \"THL13-LUM\": 0, \"THL14-TEMP\": -46.85, \"THL14-HUM\": 
-6.0, \"THL14-LUM\": 0}\n","stream":"stderr","time":"2021-01-29T11:01:55.438777682Z"}

//Cette trace correspond au retour de l'appel REST vers les XTHL
{"log":"[2021-01-29 11:01:55 +0000] [8] [INFO] XTHL response :{\"product\": \"IPX800_V4\", 
\"status\": \"Error\", \"THL1-TEMP\": 21.05, \"THL1-HUM\": 49.12, \"THL1-LUM\": 954, \"THL2- 
 TEMP\": 20.71, \"THL2-HUM\": 52.62, \"THL2-LUM\": 197, \"THL3-TEMP\": 20.05, \"THL3-HUM\": 
58.94, \"THL3-LUM\": 69, \"THL4-TEMP\": 24.44, \"THL4-HUM\": 51.48, \"THL4-LUM\": 208, \"THL5- 
 TEMP\": 28.73, \"THL5-HUM\": 38.92, \"THL5-LUM\": 0, \"THL6-TEMP\": 20.24, \"THL6-HUM\": 
 65.74, \"THL6-LUM\": 596, \"THL7-TEMP\": 19.52, \"THL7-HUM\": 58.62, \"THL7-LUM\": 322, 
\"THL8-TEMP\": 19.34, \"THL8-HUM\": 59.13, \"THL8-LUM\": 17, \"THL9-TEMP\": -46.85, \"THL9- 
HUM\": -6.0, \"THL9-LUM\": 0, \"THL10-TEMP\": -46.85, \"THL10-HUM\": -6.0, \"THL10-LUM\": 0, \ 
"THL11-TEMP\": -46.85, \"THL11-HUM\": -6.0, \"THL11-LUM\": 0, \"THL12-TEMP\": -46.85, \"THL12- 
HUM\": -6.0, \"THL12-LUM\": 0, \"THL13-TEMP\": -46.85, \"THL13-HUM\": 
-6.0}\n","stream":"stderr","time":"2021-01-29T11:01:55.440479043Z"}

Exemple2 : Les réponses ne sont pas mélangées, mais on a le retour des X4VR pour les XTHL

{"log":"[2021-01-29 11:04:25 +0000] [8] [INFO] Call 
getX4VRTestValues\n","stream":"stderr","time":"2021-01-29T11:04:25.434594758Z"}

{"log":"[2021-01-29 11:04:25 +0000] [9] [INFO] Call 
getXTHLTestValues\n","stream":"stderr","time":"2021-01-29T11:04:25.4351626Z"}

{"log":"[2021-01-29 11:04:25 +0000] [9] [INFO] XTHL response :{\"product\": \"IPX800_V4\", 
\"status\": \"Success\", \"VR1-1\": 0, \"VR1-2\": 0, \"VR1-4\": 0, \"VR2-2\": 0, \"VR2-4\": 100, \"VR3-2\": 
0, \"VR3-4\": 100, \"VR4-2\": 0, \"VR4-4\": 0, \"VR5-2\": 0, \"VR5-4\": 0, \"VR6-2\": 0, \"VR6-4\": 0, 
\"VR7-2\": 0, \"VR7-4\": 0, \"VR8-2\": 0, \"VR8-4\": 0}\n","stream":"stderr","time":"2021-01- 
29T11:04:25.445700865Z"}

{"log":"[2021-01-29 11:04:25 +0000] [8] [INFO] X4VR response :{\"product\": \"IPX800_V4\", 
\"status\": \"Error\", \"VR1-1\": 0, \"VR1-3\": 0, \"VR2-1\": 0, \"VR2-3\": 100, \"VR3-1\": 0, \"VR3-3\": 
100, \"VR4-1\": 0, \"VR4-3\": 0, \"VR5-1\": 0, \"VR5-3\": 0, \"VR6-1\": 0, \"VR6-3\": 0, \"VR7-1\": 0, 
\"VR7-3\": 0, \"VR8-1\": 0, \"VR8-3\": 0}\n","stream":"stderr","time":"2021-01- 
29T11:04:25.446528245Z"}

Je comprendrais que pour une API en particulier, s’il elle est appelée deux fois en même temps il n’y ait qu’un retour par exemple, mais ce mélange entre API ne me parait pas normal?

Quelqu’un a déjà rencontré ce problème?

Merci par avance.

Re, bonjour,

J’ai supprimé les intermédiaires pour m’assurer d’être au plus prêt de l’IPX800.
J’ai créé un simple script bash qui s’occupe de faire 2 appels en simultané vers l’IPX800. (2 curl)
Le résultat est identique : mélange des réponses.

Le script :

#!/bin/bash

curl -X GET \
  'http://192.168.1.61/api/xdevices.json?key=apikey&Get=VR' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/x-www-form-urlencoded' \
  -o testvr.txt & 

curl -X GET \
  'http://192.168.1.61/api/xdevices.json?key=apikey&Get=XTHL' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/x-www-form-urlencoded' \
  -o testxthl.txt &

La dernière ligne de chaque commande permet de stocker le résultat dans un fichier et de lancer la commande en asynchrone.

Le résultat :

testvr.txt :
{
"product": "IPX800_V4",
"status": "Success",
"VR1-1": 0,
"VR1-3": 32,
"VR2-1": 0,
"VR2-3": 100,
"VR3-1": 0,
"VR3-3": 100,
"VR4-1": 0,
"VR4-3": 0,
"VR5-1": 0,
"VR5-3": 0,
"VR6-1": 0,
"VR6-3": 0,
"VR7-1": 0,
"VR7-3": 0,
"VR8-1": 0,
"VR8-3": 0,
"status": "Error"
}

testxthl.txt :
{
"product": "IPX800_V4",
"status": "Success",
"THL1-TEMP": 21.05,
"VR9-1": 255,
"VR1-2": 0,
"VR1-4": 0,
"VR2-2": 0,
"VR2-4": 100,
"VR3-2": 0,
"VR3-4": 100,
"VR4-2": 0,
"VR4-4": 0,
"VR5-2": 0,
"VR5-4": 0,
"VR6-2": 0,
"VR6-4": 0,
"VR7-2": 0,
"VR7-4": 0,
"VR8-2": 0,
"VR8-4": 0

}

@GCE, auriez-vous des éléments à ce sujet? S’agit-il d’un bug et je dois ouvrir un ticket au support ou d’un comportement attendu et dans ce cas est-il possible d’avoir quelques informations?

Merci par avance.

Bonjour à tous,

Après avoir contacté le support, je post ici la réponse (condensée) apportée par GCE qui pourrait servir à certain :

"L’ipx800 V4 ne peut emettre qu’une seule réponse à la fois, ainsi, si deux commandes sont émises en même temps, la secondes commande reçue écrasera la réponse de la première avant son émission.
Pour contourner le problème, vous pouvez soit émettre la commande Get=all afin de récupérer l’ensemble des états de l’IPX800 V4 et de ses extensions, ou bien utiliser le fichier status.xml.

Théoriquement, le problème ne peut se poser que lors d’une commande Get car les deux requêtes sont bien traitées mais un seul buffer est utilisé, ainsi, la réponse au premier Get est écrasé avant l’émission et du coup, la même réponse est émise deux fois.
Lors d’une commande Set par exemple, la réponse pourra être écrasée mais l’ordre sera correctement exécuté.

Un ticket sera ouvert auprès des développers tout de même mais il ne sera pas prioritaire par rapport à l’IPX800 V5"

Personnellement, après quelques heures de recherche voila la solution que j’ai mise en place. J’ai installé sur un server : HAproxy qui s’occupe de faire la passerelle entre home assistant et l’ipx800. Toutes les commandes envoyées via GET à l’ipx800 depuis home assistant passe par HAproxy qui s’occupe de transmettre la requête à l’ipx800. La plue value de HAproxy et qu’il permet de limiter à une connexion simultanée les appels vers l’ipx800. Un système de queue permet de faire patienter les requêtes jusqu’à ce que la connexion se libère. Ainsi il n’y a plus de conflit.

En espérant que cela pourra servir d’autre.