Utilisation de switch REST pour piloter un IPX800

Argonaute · Janvier 20, 2021, 7:17

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

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 ?

mycanaletto · Janvier 20, 2021, 7:44

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'

Clemalex · Janvier 20, 2021, 8:07

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.

mycanaletto · Janvier 20, 2021, 9:45

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…

Argonaute · Janvier 21, 2021, 3:05

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.

gremlinsy · Janvier 21, 2021, 9:11

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)

[{"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 !

Clemalex · Janvier 21, 2021, 9:26

Merci pour le retour

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

gremlinsy · Janvier 21, 2021, 11:45

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 !

Argonaute · Janvier 21, 2021, 11:57

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 ?

gremlinsy · Janvier 22, 2021, 9:23

[Argonaute]
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.Citation

Je suis d’accord avec toi, la config semble un peu « lourde » avec l’utilisation du switch template; ce qui est dommage, c’est de pas pouvoir faire des actions communes, peu importe que l’on passe l’état à 0 ou 1. car pour le coup, ceux sont exactement les mêmes actions. Je n’ai pas trouvé mais peut-être que cela existe…
avec la comand_line, peut-on lancer un update, car c’est surtout ce qui nous intéresse pour remonter l’état.
A voir pour l’utilisation du token… c’est du bonus maintenant !

Merci à Clemalex pour la configuration package… c’est ce que j’avais cherché en fait.
J’avais déjà fait la config par répertoire/type, mais du coup, on se retrouve avec de la conf un peu éparpillé pour le même device… je regarde ça ce WE…

Argonaute · Janvier 22, 2021, 2:09

Hello,

Si je comprends bien ta question, oui avec switch command_line il y a bien une mise à jour de l’état via la partie command_state.

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'

Du coût l’implémentation est très compacte. Par contre, pour faire changer un icone comme tu le fais, j’ai du utiliser un template binary switch qui change en fonction de l’état du switch command line.
J’avais essayé initialement de récupérer la réponse de la requête preset-html, mais ce n’était pas la bonne voie. Il aurait fallu l’envoyer dans un fichier et le parser.

Suite à ton précédent message, je vais creuser le push et l’appel de l’API HA.

Autrement, question de petit nouveau, je n’ai pas encore vu ou on trouve le moyen de voir dans un log les requêtes et commandes faites par HA (par exemple nos commandes /preset.htm, status.xml…). Sais tu cela ?

gremlinsy · Janvier 22, 2021, 2:37

ah ok, vu pour le command_state… ça met à jour le switch lui même.
Mais si tu veux mettre à jour une autre entité ? Dans mon cas, je suis parti sur un sensor principal qui contient tous les états… donc c’est lui que je vais mettre à jour (et c’est le seul qui fait une requête à l’IPX pour les retours d’état)
Je pense que ce soit bien que l’on ne soit pas parti pareil, c’est comme ça que l’on va pouvoir améliorer et comparer les soluces…
Je suis aussi nouveau…je ne sais pas trop pour les logs… j’ai vu par contre que l’on pouvait en faire avec rflink, il faudrait regarder le code pour voir comment c’est fait…
Mais il y a quelques connaisseurs surement sur le forum qui connaissent déjà la réponse !

Argonaute · Janvier 22, 2021, 3:09

Pour mettre à jour une autre entité, je dirai qu’il faut utiliser un template. En tout cas, j’ai pas mal appris en lisant ton code et merci pour le partage.

Pour les logs, effectivement on en a pour chaque add-on. Mais pas trouvé pour les entités type RESTFull. Et ce n’est pas dans les logs généraux HA. Je dois mieux comprendre le debug et la gestion des erreurs pour avoir confiance. Encore du chemin et pas mal de tests pour moi, avant de décider de migrer ma eedomus hyper fiable…
J’ai aussi du mal à me dire qu’il faut relancer HA à chaque modif du fichier config. Outre le fait que c’est fastidieux, je ne me vois pas faire cela en permanence en prod, avec le chauffage, la piscine, la sécurité, etc. etc. Je me demande si les gens utilisent des machines de test.
Mais bon, cela mériterait de lancer une autre discussion sur le debug et la gestion des erreurs. Je m’éloigne du sujet REST - IPX800.

gremlinsy · Janvier 23, 2021, 6:34

Hello,
Peut-être que tu avais déjà trouvé ça, mais je suis tombé sur ces paramètres de log:

    homeassistant.components.rest_command: debug
    homeassistant.components.rest.sensor: debug

Clemalex · Janvier 23, 2021, 7:37

Et la documentation qui va avec pour comprendre d’où ca vient et comment l’utiliser

Argonaute · Janvier 23, 2021, 10:17

Excellent !! Juste quand j’en avais besoin. Je cherchais le paramétrage dans l’interface.
Un grand merci @Clemalex et @gremlinsy.

nono1024 · Novembre 17, 2023, 7:15

Bonjour tout le monde,
Je suis en train de lire vos messages et voir vos implémentations des IPX800V3 sur Home assistant.
C’est très intéressant.
Ce sujet étant assez ancien, avez-vous changé votre façon de votre les choses concernant l’IPX800v3 ou continuez-vous à utiliser ces implémentations ?
Merci

Argonaute · Novembre 18, 2023, 1:48

Une intégration existe pour l’ipx800 v4, mais pas la v3 a ma connaissance. Pas de changement pour moi.

nono1024 · Novembre 18, 2023, 7:16

Oui en effet, du coup j’ai commencé à appliquer vos configurations, mais je me suis dit qu’avec 3 ans de recul ça avait surement évolué.
Merci pour la réponse.

letoine · Décembre 12, 2023, 3:42

bonjour,
j’ai parcours tout le sujet concernant l’intégration de l’IPX800v3 sur HA. J’ai suivi la méthode de @gremlinsy et plus particulièrement la version API XML. Du coup, j’ai bien les remontés d’état des entrées mais au bout de 15s impossible d’avoir un retour d’état immédiat avec la méthode nodered. J’ai fait un couac quelques parts mais impossible de trouver ou? est ce qu’il faut mettre tout les fichiers même sensors.yaml de API JSON
Du coup, j’appelle à l’aide.
je vous remercie par avance