Utilisation de switch REST pour piloter un IPX800

Bonjour,

Je souhaite piloter les relais de mon IPX800. J’ai vu que quelques personnes utilisent un switch de type command_line, mais cela ne me semble pas la meilleur solution. D’autant que je dois passer le mots de passe.
Utiliser une automatisation est possible mais lourd.

Je souhaiterai donc plutôt utiliser le switch de type restfull.

J’ai donc créé cette entrée dans config.yaml

switch:
  - platform: rest
    name: ipx800_RLY7
    resource: "http://192.168.5.25/preset.htm?"
    body_on: "led7=1"
    body_off: "led7=0"
    username: xxxxxx
    password: xxxxxx

Le fichier de configuration est donné comme bon, mais aucune entité n’est crée, donc je ne peux l’utiliser dans lovelace. Une idée ? Merci.

Vu les exemples avec le command_line, il s’agit d’une API utilisant GET et pas POST. Pour une raison que j’ignore l’intégration switch RESTful ne fait que du POST pour actionner le switch.
Je me demande si ceci n’explique pas cela…
Je ne connais pas les IPX, ce n’est donc qu’une supposition.
Je me suis déjà fait avoir avec le switch REST et la limite du POST…

Merci pour le retour !! Appréciable d’avoir une réponse aussi rapide.

Oui cela semble être un get. Mais post ou get, je n’arrive pas à comprendre pourquoi aucune entité n’est créée. Une entité devrait être créé n’est ce pas ? Pas juste un service ou autre chose ?

Autrement, je viens de faire un essai avec command_ligne et cela fonctionne bien. :

switch:
  - platform: command_line
    switches:
      ipx800:
        command_on: 'curl "http://192.168.5.25/preset.htm?led7=1"'
        command_off: 'curl "http://192.168.5.25/preset.htm?led7=0"'

Mais cela me pique les yeux d’appeler une ligne de commande. Je suis tout nouveau sur HAS et je souhaite essayer de faire marcher l’appel REST avec le switch qui va bien (et comprendre les concepts de HAS…).

As tu essayé avec le Service plutôt que le switch si tu ne veux pas rester en command_line, car le service gère le get,post,etc.?

Ensuite, rien ne t’empêche de te créer un switch personnalisé appelant ces services (on/off)

Je n’ai pas regardé pourquoi ton entité n’était pas créée :roll_eyes:.

Merci pour le retour.
Assez incompréhensible : l’entité pour le RESTfull a finalement été créé lors du dernier essai. Mais effectivement, l’IPX800 a besoin d’un get et le switch ne semble gérer qu’un post. Ne marche donc pas.

J’ai essayé de créer 2 services en mettant ce code:

rest_command:
  ipx800_7_on:
    url: 'http://192.168.5.25/preset.htm?led7=1'
  ipx800_7_off:
    url: 'http://192.168.5.25/preset.htm?led7=0'

J’ai essayé d’appeler avec un bouton créé dans lovelace et cela fonctionne. Etait-ce qu’il fallait faire et ce que tu conseilles ?
Je vais essayer de créer un switch template pour appeler le service… Et je ne sais pas encore garder l’état sur le bouton… Je viens de eedomus et interface bien plus belle, mais tout est bien plus compliqué ici… :slight_smile:

Pour conserver l’état il faut jouer avec des automatisations pour un truc robuste, sinon de base, le serveur se « souvient » de la dernière commande (mode optimistic) mais le perd suite à un redémarrage…

Tu sais faire ?

1 « J'aime »

Bon j’ai maintenant essayé de créer le template switch qui utilise les 2 services RESTFull avec ce code :

rest_command
  ipx800_7_on:
    url: 'http://192.168.5.25/preset.htm?led7=1'
  ipx800_7_off:
    url: 'http://192.168.5.25/preset.htm?led7=0'

switch
  - platform: template
    switches:
      ipx800:
        turn_on:
          service: rest_command.ipx800_7_on
        turn_off:
          service: rest_command.ipx800_7_off

Cela fonctionne bien. L’entité ipx800 est bien créée et utilisable dans l’UI. Merci Golfvert ! Juste gêné d’avoir la définition du composant de mon switch sur l’IPX800 avec un bout dans la section rest_command, un bout dans la section switch, un bout dans le GUI. La maintenance de tout cela ne va pas être aisée si on ventile autant les implémentations.

Pour la sauvegarde de l’état, merci pour la proposition, Clemalex. Quelle est la meilleur pratique pour sauvegarder l’état de manière robuste ? Oui je suis preneur si il y a un lien à ce sujet. J’ai essayé de redémarrer HAS et l’état est pourtant bien gardé (?).

Après, je me dit qu’il serait pertinent d’avoir un état du switch qui est vraiment celui du serveur IPX800. Plutôt que sauvegarder l’ancien état, on peut aussi relire l’état sur l’IPX800. Cela doit être possible avec un value_template sur le switch, non ?

Ah bah tant mieux ! :wink:

C’est ça. Il te faut connaître comment récupérer l’état et tu cales le code dans cette balise.

Je ne sais pas quelle configuration tu utilises donc je t’invite à lire Organisation du fichier configuration.yaml.

Et de regarder la configuration appelée package pour avoir la définition au même endroits.

Après, avoir un bout dans la plateforme restful puis un autre bout dans la plateforme switch, c’est pour moi le gros plus de HA et cela permet de faire tout ce que j’ai voulu jusqu’ici. Maisbce n’est que mon avis car je ne suis pas partisan des gros bloc contenant tout… mais c’est sûr, faut être organisé derrière (d’où la méthode package).

Pour un de ces premiers message @Argonaute aura eu la totale :slight_smile: Yaml, Jinja2 et packages c’est (presque) du bizutage.
Mais, c’est vrai que tous les outils sont maintenant en place pour faire des trucs propres (séparé en différents fichiers) et puissants -mais quand même un peu crypté- avec le jinja2.

En ce qui me concerne ça fait un an que ca tourne en CLI. Et ce qui fonctionne me va bien.

Par contre en google un peu j’ai vu que d’autres le font en rest, voici quelques liens, voire même une intégration que je n’ai pas essayée car je tourne avec une vieille v2

Merci à tous pour vos réponses. Quelle réactivité et quelle bienveillance !

Effectivement, package est aussi très intéressant et répondrait à ma demande. Séparer en fichiers par plateforme semble la bonne pratique. J’imagine qu’il y a des bonnes pratiques et je vais regarder ce que font les gens.

Bon j’ai approfondi le templating aujourd’hui du coup. Connaissant python, pas trop dépaysé. Vraiment plein de possibilité. C’est cool. Le bizut doit travailler mais apprécie :blush:

Merci d’avoir aussi répondu. Au passage, je suis un adepte de ton excellent blog ! Bravo.
J’ai un IP800 V3, qui a la même API que le V2 que tu as. Comme toi, pas convaincu pour en racheter un comme simple « boite à relai ». L’API V4 est très différente et difficile de l’exploiter pour la V3. Je suis preneur pour savoir comment tu gères le fait que l’appel REST a échoué ou pas, et mettre à jour ou non le switch. Je n’ai pas réussi avec le code du switch template précédent qui appelle un service.
As tu réussi à gérer cela ? A gérer la reprise de l’état quand on redémarre le serveur HA ?

Dernier point, j’ai aussi essayé de changer l’icone du bouton (avec une condition dans la section icone_template du switch template). Cela me semble étrange si il faut gérer des icones dans la partie entité et non l’API. Peut être y a t’il d’autres moyens plus simple de changer l’icone quand on fait un ON-OFF sur un bouton ?

Si l’IPX800 a un intérêt utilisée seule, avec HA une simple carte relais de chez Ali fera le job pour une trentaines d’euros… Surtout que j’ai des contacteurs de puissance derrière…

Voici ce que j’ai dans mon switch.yaml et qui fonctionne bien :

- platform: command_line
  switches:

# IPX800 v2
    ipx800_1_sejour:
      command_on: 'curl "http://192.168.210.31/preset.htm?led1=1" >/dev/null'
      command_off: 'curl "http://192.168.210.31/preset.htm?led1=0" >/dev/null'
      command_state: 'curl "http://192.168.210.31/status.xml"'
      value_template: '{% set status = value | regex_findall_index("<led0>(.*)</led0>") %} {% if status == "1" %} true {%- endif -%}'
      friendly_name: 'Convecteur : Séjour'

    ipx800_2_marie:
      command_on: 'curl "http://192.168.210.31/preset.htm?led2=1" >/dev/null'
      command_off: 'curl "http://192.168.210.31/preset.htm?led2=0" >/dev/null'
      command_state: 'curl "http://192.168.210.31/status.xml"'
      value_template: '{% set status = value | regex_findall_index("<led1>(.*)</led1>") %} {% if status == "1" %} true {%- endif -%}'
      friendly_name: 'Convecteur : Chambre Marie'

Si l’API te renvoi une icone autant l’utiliser et t’en servir comme retour d’état également.

Que la définition de l’entité HA se fasse côté HA ne me semble pas du tout étrange.

Comme le dit @mycanaletto utiliser CLI ou REST est affaire de goût je pense si la finalité et la mise en œuvre sont identique.

Il y a plusieurs façons d’avoir des icones qui changent selon l’état, cela se règle au niveau de la classe d’une entité, un binary par exemple :

On peu aussi avec des tempates et des intégrations Lovelace particulières (je n’ai plus en tête) afficher un peu ce que l’on veut.

Après je ne suis pas un fan des tableaux de bord de centrale atomique. Lovelac c’est pour l’admin et parfois une version très réduite pour les utilisateurs, mais globalement mon point de vue est qu’une bonne domotique doit se faire oublier…

Un grand merci @mycanaletto !
J’ai rapidement repris les tests et tout fonctionne. J’ai aussi suivi ton conseil et testé un binary sensor si je veux changer le logo à l’activation. La lecture des données de l’IPX800 peut par contre bien se faire sur un sensor rest (testé avec une sonde de température sur l’IPX800).
Cela reste étonnant que le switch rest n’accepte par les put. Peut être faut t’il ouvrir un ticket auprès de l’équipe HA (?)

Juste pour info, mon code :

switch:
  - platform: command_line
    switches:
      ipx800_7:
        command_on: 'curl http://usr:pwd@192.168.50.250/preset.htm?led7=1 >/dev/null'
        command_off: 'curl http://usr:pwd@192.168.50.250/preset.htm?led7=0 >/dev/null'
        command_state: 'curl http://usr:pwd@192.168.50.250/status.xml'
        value_template: '{% set status = value | regex_findall_index("<led6>(.*)</led6>") %} {% if status == "1" %} true {%- endif -%}'
        friendly_name: 'Piscine : IPX800 7'

binary_sensor:
  - platform: template
    sensors:
      pompe:
        device_class: power
        value_template: "{{ is_state('switch.ipx800_7', 'on') }}"

sensor:
  - platform: rest
    resource: http://usr:mdp@192.168.50.250/api/xdevices.json?cmd=30
    name: Temperature local technique
    unit_of_measurement: '°C'
    value_template: '{{ (((((value_json["AN1"]|float)*0.00323)-0.25)/0.00028 ) | round)/100 }}'

Après, j’ai essayé de mettre les user/mdp dans secret.yaml, les lire dans 2 input text que je réutilise dans les URL du switch via un template. Syntaxe jinja testées et bonnes, mais ne fonctionne pas. Je ne sais pas si ni si c’est la bonne solution, ni ou voir les commandes / événements générées par HA pour débuger… je vais encore creuser.

Concernant l’interface graphique, je suis en phase avec toi sur les « tableaux de bord de centrales ». Perso, j’aime les UI dépouillés basées sur du material design. J’ai été rodé pour mon travail à adopter une démarche UX donc centrée utilisateur, respectant les règles d’ergonomie et basées sur les use case de chaque utilisateur type. L’objet d’un futur post peut-être…

Enfin, j’étais parti pour n’utiliser que lovelace et pas YAML pour l’interface, en me disant que l’interface va évoluer rapidement et couvrir les possibilités YAML. Vive le low code quand possible… Intéressant de connaitre l’opinion de la communauté à ce sujet.

Hello,
J’ai commencé il y a peu de temps aussi sur HA, et j’essaie de visualiser/piloter mon ipx800.

Mon retour d’expérience avec HA et IPX800 v3

Ce qui me semblait le plus intéressant, c’était d’utiliser le push de l’ipx évitant de scanner l’ipx selon un intervale régulier… mais l’utilisation de l’API HA n’est pas trop jouable avec une clé API sur l’ipx800 v3, en plus, avec l’utilisation de let’s encrypt, il faut un accès internet pour accéder à une machine local… je trouve cela un peu « bizarre »…
Nodered
J’ai donc commencé par utiliser Nodered, dont l’avantage est de pouvoir créer facilement un endpoint http et d’utiliser le push de l’IPX lorsque l’une des E/S est modifiée… donnant une très faible empreinte réseau. Je n’ai pas optimisé le flow… ça marche mais il faut jongler entre nodered et les entites créées sur HA.

API JSON
Du coup, je me suis lancé dans la config des fichiers yaml…
Je suis parti au départ sur l’utilisation de plusieurs sensor rest pour récupérer l’état des différentes E/S en passant par l’API retournant du json…
Car le problème de l’API json de l’IPX c’est d’utiliser une requête différente pour les entrées, les sorties, les compteurs… et les appels depuis HA sont fait à la suite vers l’IPX, et celui-ci n’a pas le temps de répondre à toutes les requêtes…; en jouant sur le paramètre scan_interval, cela évite dans la majorité des cas que les commandes ne soient pas lancé en même temps…et l’idéal, ce serait de pouvoir faire un délai entre les requêtes… mais bon, ça marche…
Voici un exemple de configuration:

#/config/sensors.yaml

# Récup état Entrées numeriques
- platform: rest
  resource: 'http://ipx800.local/api/xdevices.json?cmd=10'
  name: 'IPX800 entrees num'
  value_template: '{{ value_json["product"] }}'
  scan_interval: 30
  json_attributes:
    - IN1
    - IN2
    - IN3
    - IN4
    - IN5
    - IN6
    - IN7
    - IN8
    
    
# Récup état Sorties numeriques
- platform: rest
  resource: 'http://ipx800.local/api/xdevices.json?cmd=20'
  #resource: 'http://{{ IP_ipx800 }}/api/xdevices.json?cmd=20'
  name: 'IPX800 sorties num'
  value_template: '{{ value_json["product"] }}'
  scan_interval: 29
  json_attributes:
    - OUT1
    - OUT2
    - OUT3
    - OUT4
    - OUT5
    - OUT6
    - OUT7

API XML
Au final, pour éviter cela, il est possible de passer par l’API IPX800 XML, qui renvoie tous les états en 1 seul fois.
(bon, par contre attention a ne pas se faire avoir: la sortie 1, c’est out1 en json et led0 en xml… pas mieux pour les états en XML, 0,1 pour les sorties, up et dn pour les entrées…

#/config/sensors/sensor_ipx800.yaml

platform: rest
name: IPX800 global status
resource: 'http://ipx800.local/globalstatus.xml'
json_attributes_path: $.response
scan_interval: 15
value_template: OK
json_attributes:
    - led0
    - led1
    - led2
    - led3
    - led4
    - led5
    - led6
    - led7
    - count0
    - count1
    - btn0
    - btn1
    - btn2
    - btn3
    - btn4
    - btn5
    - btn6
    - btn7
    - analog0
    - analog1

L’état des différentes entrées (ou sorties, cpt…) se fait donc un seul sensor principal rest

Il suffit ensuite de créer des binary-sensors pour l’état des E/S,

#/config/binary_sensors/binary_sensor_ipx800.yaml

platform: template
sensors:
  ipx800_e1:
    friendly_name: IPX800 E1
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn0","dn") }}'
  ipx800_e2:
    friendly_name: IPX800 E2
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn1","dn") }}'  
  ipx800_e3:
    friendly_name: IPX800 E3
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn2","dn") }}'
  ipx800_e4:
    friendly_name: IPX800 E4
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn3","dn") }}'
  ipx800_e5:
    friendly_name: IPX800 E5
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn4","dn") }}'
  ipx800_e6:
    friendly_name: IPX800 E6
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn5","dn") }}'
  ipx800_e7:
    friendly_name: IPX800 E7
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn6","dn") }}'
  ipx800_e8:
    friendly_name: IPX800 E8
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn7","dn") }}'
  ipx800_s1:
    friendly_name: IPX800 S1
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led0") }}'
  ipx800_s2:
    friendly_name: IPX800 S2
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led1") }}'
  ipx800_s3:
    friendly_name: IPX800 S3
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led2") }}'
  ipx800_s4:
    friendly_name: IPX800 S4
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led3") }}'
  ipx800_s5:
    friendly_name: IPX800 S5
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led4") }}'
  ipx800_s6:
    friendly_name: IPX800 S6
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led5") }}'
  ipx800_s7:
    friendly_name: IPX800 S7
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led6") }}'
  ipx800_s8:
    friendly_name: IPX800 S8
    value_template: '{{ state_attr("sensor.ipx800_global_status", "led7") }}'

et des sensors pour l’état des compteurs et des analogiques qui se rapportent au sensor « principal »

#/config/sensors/sensor_ipx800.yaml

platform: template
sensors:
  #Compteurs
  ipx800_cpt1:
    friendly_name: IPX compteur 1
    value_template: '{{ state_attr("sensor.ipx800_global_status", "count0") }}'
    unit_of_measurement: °F
  ipx800_cpt2:
    friendly_name: IPX compteur 2
    value_template: '{{ state_attr("sensor.ipx800_global_status", "count1") }}'
    unit_of_measurement: minutes
  
  #Analogiques
  ipx800_an1:
    friendly_name: IPX800 ANA_1
    device_class: power
    value_template: '{{ state_attr("sensor.ipx800_global_status", "analog0") }}'
  ipx800_an2:
    friendly_name: IPX800 ANA_2
    device_class: energy
    value_template: '{{ state_attr("sensor.ipx800_global_status", "analog1") }}'

Tout cela permet déjà de remonter tous les états…

La commande
Pour la partie commande des E/S, utilisation de switch template

#/config/switches/switch_ipx800.yaml

platform: template
switches:
  ipx800e1:
    friendly_name: IPX800 E1
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "btn0","dn") }}'
    turn_on:
      - service: rest_command.switch_ipx800_e
        data:
          led: 100
      - service: homeassistant.update_entity
        data:
          entity_id:
            - sensor.ipx800_global_status
            - binary_sensor.ipx800_e1
    turn_off:
      - service: rest_command.switch_ipx800_e
        data:
          led: 100
      - service: homeassistant.update_entity
        data:
          entity_id:
            - sensor.ipx800_global_status
            - binary_sensor.ipx800_e1

  ipx800s7:
    friendly_name: IPX800 S7
    value_template: '{{ is_state_attr("sensor.ipx800_global_status", "led6","1") }}'
    #value_template: '{{ state_attr("sensor.ipx800_global_status", "led6") | int >=1 }}'
    turn_on:
      - service: rest_command.set_ipx800_s
        data:
          num: set7
          state: 1
      - service: homeassistant.update_entity
        data:
          entity_id:
            - sensor.ipx800_global_status
            - binary_sensor.ipx800_s7
    turn_off:
      - service: rest_command.set_ipx800_s
        data:
          num: set7
          state: 0
      - service: homeassistant.update_entity
        data:
          entity_id:
            - sensor.ipx800_global_status
            - binary_sensor.ipx800_s7

(l’appel au service: homeassistant.update_entity permet de relancer une requête API et d’avoir un retour d’état immédiat)
avec une commande rest qui va avec:

  • Fixe un état pour les sorties (on ne peut pas pour les entrées)
  • Commutation pour les entrées (on peut utiliser aussi pour les sorties si on préfère avoir une seule commande. Avec le retour d’état, ça peut être jouable.
rest_command:
  switch_ipx800_e:
    url: http://ipx800.local/leds.cgi?led={{ led }}

  set_ipx800_s:
    url: http://ipx800.local/preset.htm?{{ num }}={{ state }}

Voici une carte rapide représentant l’état des différentes E/S et des actionneurs…

Changement d’état externe → une toute petite couche de nodered
Enfin dans le cas d’un changement d’un état de l’IPX800, pour éviter d’attendre le scan, si l’on veut un retour d’état rapide, utilisation d’un simple endpoint Nodered qui lorsqu’il recevra une requête, lancera un update du sensor « principal »… (il faudra faire éventuellement un update des différents sensors si besoin)

image

[{"id":"6d000be6.d538a4","type":"http in","z":"753e90f9.ed355","name":"","url":"/ipx800/refresh","method":"get","upload":false,"swaggerDoc":"","x":240,"y":480,"wires":[["16424523.6898bb","2bedb3eb.4b5dec"]]},{"id":"2bedb3eb.4b5dec","type":"http response","z":"753e90f9.ed355","name":"","statusCode":"200","headers":{},"x":660,"y":520,"wires":[]},{"id":"16424523.6898bb","type":"api-call-service","z":"753e90f9.ed355","name":"","server":"8b0f3c25.1116b","version":1,"debugenabled":false,"service_domain":"homeassistant","service":"update_entity","entityId":"sensor.ipx800_global_status","data":"","dataType":"json","mergecontext":"","output_location":"","output_location_type":"none","mustacheAltTags":false,"x":570,"y":460,"wires":[[]]},{"id":"8b0f3c25.1116b","type":"server","name":"Home Assistant","addon":true}]

Le push pourra se faire sur l’ipx soit au niveau général, soit au niveau de l’entrée/sortie concernée

Voilà, il y a surement encore des améliorations à faire, je n’ai que quelques semaines de HA, donc je ne capte pas toute les subtilités encore… mais bon, ça marche pour l’instant à peu près…
La prochaine étape, je verrai peut-être intégration si je trouve un peu de temps…
Avant je vais voir pour commander ma zibase qui est toujours opérationnelle !

:heart: Merci pour le retour :+1:

As tu regardé si le service homeassistant.update_entity fonctionnait pour la mise à jour afin de tout faire en native HA ?

En fait, en native HA, ça fonctionne, le update_entity est fait au niveau des switchs lorsqu’on l’actionne à partir d’HA. (mais je n’ai peut-être pas compris ce que tu voulais dire)
La partie nodered est optionnel, c’est juste si l’on souhaite avoir un retour d’état rapide sur un changement d’état d’une E/S de l’IPX (ex, 1 interrupteur sur une entrée). Cela évite d’attendre le scan de HA, ou de mettre un scan très court pour limiter la latence. Je n’ai pas trouvé de moyen pour avoir ce même comportement en natif…
L’utilisation de l’API HA pourrait être bien, mais, de ce que j’ai pu avoir, c’est seulement avec une clé API, je ne sais pas si c’est possible de configurer sur l’IPX. En plus, il y a le pb de certificat avec let’sencrypt qui empêche de passer en local. alors qu’il n’y a pas de pb avec le endpoint nodered.
Mais je suis intéressé de savoir s’il y a un moyen !

Excellent !!
Cela évite de passer par les switch command_line. J’avais commencé par la et utilisé les services RESTFull et switch template, mais m’étais heurté au retour d’état. Il fallait alors coupler avec un switch binary sensor. bien vu.
Après, l’implémentation avec les switch commande_line a le mérite d’être plus compact. Le débat peut donc être ouvert et les 2 solutions se discuteront.

Concernant le push depuis l’IPX800, j’ai également le sujet dans ma TODO. J’ai une sonde inondation en entrée de l’IPX et actuellement l’IPX fait un push sur ma eedomus pour déclencher une alerte. Sur eedomus, il y a aussi une API key à passer, que l’on met dans l’URL du push sur l’entrée concernée. Mais le token est obtenu 1 fois sur le cloud puis utilisé dans l’URL localement et à vie.

Je pensais que sur HA, il suffisait aussi de demander un token longue durée via l’interface de HA (dans l’interface, fin de page du profil). Puis le token est utilisé dans l’URL (et donc pas d’accès cloud et tout en local). Mais cela ne semble donc pas possible ? Il faut 2 appels pour l’authentification que l’IPX ne sait pas gérer dans une seule URL de push ?