Utilisation des filtres dans l'API v5

Cartes Ethernet IPX800
1

Bonjour à tous,
Dans la documentation de l’API, il est indiqué qu’il est possible d’ajouter des filtres aux requêtes GET :
image

Je n’ai trouvé aucune information, ni exemple, sur l’utilisation de ces filtres.

Par exemple, j’aimerai récupérer tous les IO (ou les ANA) dont le Link0 à la valeur 9437184 (identifiant de l’ipx).
Autre Exemple : récupérer tous les IO ou ANA ou STR dont le nom contient [IPX] ou [WEATHER]…

Est-ce possible ? Quelle est la syntaxe ?

Bonne journée

2

Bonjour @Michel94 ,

j’opterais ds votre exemple pour qqc du genre (non testé):

  • requete en GET
  • local_V5_url/api/core/io?option=filter_config&ApiKey=API Key
  • body Json : [ { « link0 »: 9437184, } ]

Pour vous aider, avez-vous télécharger et installé POSTMAN puis importé ds POSTMAN les lib exemples de GCE que l’on trouve ici rubrique download?

image
image1068×907 67.4 KB

3

Bonjour @Jweb,
Merci pour la réponse.
Je viens de reprendre l’installation de postman que j’avais abandonné. J’étais parti sur l’utilisation web, et je ne souhaitait pas tester une config locale sur un réseau publique.
Je viens d’installer l’agent local postman ce qui me parait plus convenable.

Avec cet agent, j’ai réalisé des tests avec les filtres et j’arrive à la conclusion qu’ils ne sont pas paramétrables :

  • adresseIp/api/core/io?option=filter_state&ApiKey=API Key : ne renvoie que l’Id et la valeur
  • adresseIp/api/core/io?option=filter_config&ApiKey=API Key : renvoie l’Id, link0, link1et virtual
  • adresseIp/api/core/io?option=filter_name&ApiKey=API Key : ne renvoie que l’Id et le nom
    Cela permet de réduire le volume d’échange, surtout pour la récupération des états, mais pas de réaliser les sélections que je souhaitais.

Bonne journée

4

Bonjour,
En poursuivant mes tests, j’ai découvert la réponse à une question posée sur le forum qui n’avait pas reçu de réponse :
à quoi sert la case à cocher Filter ID sur API Deck ?

Cette option ajoute « &option=filter_id » à la requête GET. Le réponse porte sur les identifiants des variables au lieu de leurs valeurs.

Cette option est opérationnelle sur toutes les requêtes GET, à l’exception bien sûr des requêtes GET portant sur les variables (IO, ANA et STR.)

Exemple pour une requête GET api/system/ipx
Sans l’option :

{
  "_id": 9437184,
  "errorStatus": 0,
  "ioDInput": [
    "off",
    "off",
    "on",
    "on",
    "on",
    "off",
    "off",
    "on"
  ],

Avec l’option : api/system/ipx?option=filter_id

{
  "_id": 9437184,
  "errorStatus": 0,
  "ioDInput_id": [
    65552,
    65553,
    65554,
    65555,
    65556,
    65557,
    65558,
    65559
  ],
2 « J'aime »
5

Bonjour,
J’ai noté un problème avec le GET All analog utilisé avec le filtre « filter_state ».

Sans utilisation de filtre, la réponse à {{baseUrl}}/api/core/str est de la forme :

[{"_id":196608,"link0":9437184,"link1":0,"name":"[DIAG]NB CONNECTIONS RUNNING","unit":"RAW","nbdecimal":0,"virtual":false,"value":0},{"_id":196609,....

Avec le filtre, la réponse à {{baseUrl}}/api/core/ana?option=filter_state est de la forme :

[{"_id" :196608,"value":0},{"_id" :196609,"value":3},{"_id" :196610,"value":0},...

On note la présence d’un espace entre « _id » et le caractère « : »

Ce défaut n’existe pas lors de l’utilisation des 2 autres filtres, filter_name et filter_config avec core/ana
Ce défaut n’existe pas non plus avec core/io ni avec core/str

Est-il possible d’ouvrir un ticket ? (je ne connais pas la procédure d’ouverture d’un ticket)

Bonne journée

6

Bonjour Michel94,

C’est fait :wink:

Bonne journée

7

Bonjour Michel94
Quelle incidence a cet espace sur le fonctionnement côté IPX ?
bonne journée

8

Bonjour,

L’ipx retourne une réponse au format json et les deux résultats avec ou sans espace sont identiques dans ce format.

Ces trois lignes sont équivalentes:

"_id":196608
"_id" :196608
"_id"   :   196608

Vous pouvez retrouver la définition du format json ici JSON
Un « whitespace » peut être rien, un espace, deux espaces, etc…(trop de combinaisons possibles)

9

Bonjour,
Merci à @grocrabe pour l’ouverture du ticket. En fait, ce n’est pas un seul espace qui est inséré mais 2.
Merci à @jbbeauf pour le lien avec la norme json

Je ne pense pas qu’il y ait d’incidence au niveau de l’ipx .

Comme il est répété à longueur de forum, beaucoup d’utilisateurs sont dans le DIY. Certains périphériques sont réalisés avec peu de moyen, peu d’espace de codage, peu de mémoire. Certes la norme est tolérante mais c’est pas très cool d’avoir à interpréter les différents cas de figure.

Actuellement, à de fin de tests, je réalise un petit outil de présentation de la configuration des ressources et des liens sur Excel. La correction a été facile à réaliser, on n’est pas, dans cet environnement, à quelques lignes de codes près.

Par contre, j’ai un Arduino qui sert actuellement d’interface entre une vieille centrale alarme filaire et un ipx800 v4. Le passage en v5 sera plus complexe. Il serait préférable que le format soit constant.

Bonne journée.

10

Bonjour,

Qu’on soit dans le DIY ou pas ça ne change rien: la réponse de l’ipx est valide.
C’est à vous d’utiliser un parseur json qui prenne en charge correctement ce format, ça doit se trouver sur étagère pour Excel ou Arduino.

11

en espérant que GCE soit moins intransigeant que @jbbeauf :upside_down_face:

2 « J'aime »