[Résolu] Aide pour utilisation API Rest ou API ? pour dialogue entre 2 box

bonjour,
j’ai besoin de dialoguer entre des box pour établir une synchronisation entre plusieurs box (la synchro entre les box hors HA est déjà faite) afin de récupérer dans HA (HAOS sur proxmox dans VM) les états de plusieurs lumières, capteurs et actionneurs (ouverture).
Pour ces objets que j’envisage de migrer par la suite (ils sont en zwave, réseau maillé stable depuis 3 ans), mais beaucoup (beaucoup) plus tard, je voudrais dans un 1er temps établir un pont entre les box qui les hébergent et HA.

les 2 box (lifedomus et eedomus) qui supportent les objets ne sont pas équipées de MQTT, il n’y a pas non plus de plugin disponibles pour dialoguer avec HA (ni d’un côté, ni de l’autre) ou je n’en ai pas trouvé.

comme je n’ai pas non plus énormément d’objets (5 ou 6 max) à synchroniser je pensais faire une synchro objet par objet.

donc j’envisageais d’utiliser les API Restxx pour échanger entre les box.
1- récupération d’état
2 - ordre d’allumage / extinction / ouverture / fermeture.

les 2 box ont des API simples pour envoyer et recevoir des ordres get / put / post sur les équipements déclarés.

Mon point d’interrogations est plutôt du côté HA ou je me sens perdu sur les différentes modulation d’API à utiliser et surtout comment je les relies avec des dispositifs affichable dans HA/lovelace.

j’ai créé un token longue durée qui doit me permettre d’envoyer des ordres avec bearer : token dans les entêtes, mais j’avoue ne pas comprendre comment cela se couple avec un « sensor » ou une « light » dans HA

merci de votre aide

1 « J'aime »

Salut
Dans HA, tu peux créer des sensors à partir des Api des box : RESTful Sensor - Home Assistant

je viens de regarder le lien , j’ai rien compris , probablement moi qui ne suis pas au niveau
je pensais, mais ça semble plus complexe que simple , que envoyer un ordre vers un device et recevoir un ordre depuis un device devait être simple

je fais cela très naturellement entre eedomus et lifedomus, mais là je suis perdu et la doc, surement bien faite , m’a encore plus perdu

si j’y vais étape par étape :

alias: Webhook OFF
description: ''
trigger:
  - platform: webhook
    webhook_id: basement_entrance_off
condition: []
action:
  - service: switch.turn_off
    target:
      entity_id: switch.zswitchbasementent_left
mode: single

que j’active du côté eedomus ou lifedomus via l’ordre http://homeassistant:8123/api/webhook/basement_entrance_off

est-ce que je peux utiliser la lampe virtuelle créée plus tôt pour faire la même chose ?
si c’est OK pour ces 2 points j’ai résolu la moitié du point puisque je vais synchronier mes lampes avec les lampes des autres systèmes (maitre) en amont

me restera à voir comment j’envoi les actions depuis HA vers les API des autres systèmes pour commander les lampes.

merci de me dire si je suis dans la bonne apprche ou si il y a plus simple ?
(je peux pas utiliser MQTT parce que il n’existe pas sur les plateforme eedomus et lifedomus)

voilà j’ai avancé , probablement avec des solutions qui ne sont pas les plus optimums, mais ça marche
edit pour fixer le process:

    • dans HA
  • créer les lumières virtuelles (et les actions possibles)
  • créer les scripts d’actions (turn_on, turn_off, set_level)
  • ajouter le/les webhook pour les actions entrantes
  • facultatif - ajouter un indicateur de temporisation - entrées de type interrupteur
  • redémarrer HA pour prendre en compte tout ce qui précède
  • créer (avec l’interface UI) les automatismes envois et reçois
  • redémarrer HA
  • créer une entrée dans lovelace pour la lampe (et facultatif pour voir l’interrupteur de temporisation)
  1. dans la box autre (lifedomus)
  • ajouter une commande pour envoyer les ordres sur le « nom du webhook » créé avec l’intensité en paramètre
  • créer les 3 variables (str: luminosité, str: valeur de reception, num; luminosité)
  • créer les 2 automates envoi et reçois

détail:
j’ai créé une lampe virtuelle directement dans configuration.yaml

light:
  - platform: template
    lights:
      virtual_light:
        friendly_name: "lampe salon"
        turn_on:
          service: script.turn_on
          entity_id: script.turn_on_virtual_light
        turn_off:
          service: script.turn_off
          entity_id: script.turn_off_virtual_light
        set_level:
          service: script.set_level_virtual_light
          data_template:
            level: "{{ brightness | float / 255 * 100 }}"
  • puis 3 script via l’éditeur de script
set_level_virtual_light:
  sequence:
  - service: light.turn_on
    target:
      entity_id: light.virtual_light
    data_template:
        entity_id: light.virtual_light
        brightness: "{{ level | float / 100 * 255 }}"
  alias: module lampe salon
  mode: single
turn_on_virtual_light:
  sequence:
  - service: light.turn_on
    target:
      entity_id: light.virtual_light
    data: {}
  alias: allume lampe salon
  mode: single
turn_off_virtual_light:
  sequence:
  - service: light.turn_off
    target:
      entity_id: light.virtual_light
    data: {}
  alias: eteint lampe salon
  mode: single

et ajouté dans configuration.yaml les ordres d’envoi via Restfull

rest_command:
  allume_lampe_salon_depuis_ha:
    url: "http://192.168.1.38:8080/UniversalListen?HA_trame=ha_lampe_salon&HA_valeur=on"
  eteint_lampe_salon_depuis_ha:
    url: "http://192.168.1.38:8080/UniversalListen?HA_trame=ha_lampe_salon&HA_valeur=off"
  module_lampe_salon_depuis_ha:
    url: "http://192.168.1.38:8080/UniversalListen?HA_trame=ha_lampe_salon&HA_valeur={{state_attr('light.virtual_light', 'brightness')}}"

et enfin 2 automates via l’éditeur d’automatisme
pour envoyer les ordres d’allumage, d’extinction et de modulation de la lampe virtuelle dans HA vers la box lifedomus
pour recevoir via webhook les ordres d’allumage et d’extinction à positionner sur la lampe virtuelle

# automate pour envoyer les ordres à lifedomus 
- id: '1703891181367'
  alias: 'ha envoi modifie luminosité lampe salon '
  description: ''
  trigger:
  - platform: state
    entity_id:
    - light.virtual_light
  condition: []
  action:
  - service: rest_command.module_lampe_salon_depuis_ha
    data: {}
  mode: single
  
# automate pour recevoir les ordres depuis lifedomus 
- id: '1703935803353'
  alias: reçois modifie luminosité lampe salon
  description: ''
  trigger:
  - platform: webhook
    allowed_methods:
    - POST
    - PUT
    - GET
    local_only: true
    webhook_id: module_lampe_salon
  condition: []
  action:
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.inter_lampe_salon
    data: {}
  - service: automation.turn_off
    target:
      entity_id: automation.ha_module_lampe_salon
    data:
      stop_actions: true
  - service: light.turn_on
    data_template:
      entity_id: light.virtual_light
      brightness: '{{ (trigger.query.luminosite | int) * 2.55  }}'
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: input_boolean.turn_off
    target:
      entity_id: input_boolean.inter_lampe_salon
    data: {}
  - service: automation.turn_on
    target:
      entity_id: automation.ha_module_lampe_salon
    data: {}

comme je le disais ce n’est probablement pas le plus optimisé, mais ça fonctionne

edit: trouvé: comment recevoir via le webhook un ordre de modulation à positionner sur la lampe virtuelle

mon ordre du côté lifedomus est un post ou un get c’est pareil :
http://ip_ha:8123/api/webhook/declenche_allume_lampe_salon&luminosite={position_luminosite}

edit: trouvé: je sais comment récupérer cet info et la positionner sur la lampe
dans l’automate de reception des ordres il y a la séquence :

data_template:
      entity_id: light.virtual_light
      brightness: '{{ (trigger.query.luminosite | int) * 2.55  }}'

et pour éviter l’effet boucle (modif sur l’un entraine modif sur l’autre qui entraine modif sur le 1er ect…

j’ai ajouté dans l’automate de réception des ordres une séquence qui désactive l’automate d’envoi des ordres pendant 2 secondes

#arrêt de l'automate qui va renvoyer le même ordre 
- service: automation.turn_off
    target:
      entity_id: automation.ha_module_lampe_salon
    data:
      stop_actions: true
#execution du l'action 
- service: light.turn_on
    data_template:
      entity_id: light.virtual_light
      brightness: '{{ (trigger.query.luminosite | int) * 2.55  }}'
#attente de 2 secondes 
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
# reactivation de l'automate qui transmet les ordres vers lifedomus
 - service: automation.turn_on
    target:
      entity_id: automation.ha_module_lampe_salon
    data: {}

tout fonctionne, allumer/éteindre/varier sur les 2 box ,avec alexa qui est actuelement couplée à lifedomus et les interrupteurs physiques en va et vient et variation.

comme j’avance tout seul , jeme répond

l’ordre du côté lifedomus est un post avec http://ip_ha:8123/api/webhook/declenche_allume_lampe_salon?luminosite=25
et du côté HA la réception se fait via l’automatisation avec webhook

- id: '1703935803353'
  alias: reçois modifie luminosité lampe salon
  description: ''
  trigger:
  - platform: webhook
    allowed_methods:
    - POST
    - PUT
    - GET
    local_only: true
    webhook_id: module_lampe_salon
  condition: []
  action:
  - service: light.turn_on
    data_template:
      entity_id: light.virtual_light
      brightness: '{{ (trigger.query.luminosite | int) * 2.55  }}'

bien maintenant j’ai les objets pour envoyer et recevoir les ordres allume/éteint/module
des 2 côtés
unitairement ça fonctionne, mais quand je met tout le monde ensemble, ça boucle :

  • les ordres envoyés d’un côté sont reçus, exécutés, mrepartent parce que ça modifie le récepteur , qui renvoi à l’émetteur la même chose et ça boucle

c’est bon, j’ai mis à jour la solution
Merci à moi :innocent:

Salut,
as tu des erreurs sur tes command rest depuis quelques jours ? J’ai des erreurs sur les miennes…

Salut,
c’est pas du a un changement ce mois ci ?

L’appel aux services de commande RESTful n’échouera plus silencieusement et déclenchera une exception, par exemple en cas d’expiration du délai ou d’erreurs de décodage.

Vous pouvez envisager d’utiliser continue_on_error des scripts et des automatisations qui utilisent des commandes RESTful qui peuvent échouer occasionnellement.

Continuing on error

By default, a sequence of actions will be halted when one of the actions in that sequence encounters an error. The automation or script will be halted, an error is logged, and the automation or script run is marked as errored.

Sometimes these errors are expected, for example, because you know the service you call can be problematic at times, and it doesn’t matter if it fails. You can set continue_on_error for those cases on such an action.

The continue_on_error is available on all actions and is set to false. You can set it to true if you’d like to continue the action sequence, regardless of whether that action encounters an error.

The example below shows the continue_on_error set on the first action. If it encounters an error; it will continue to the next action.

@WarC0zes : Si je comprends je dois mettre cette option à true alors ? Mais je la mets où ?

Dans un script ou automatisation.

ils ne sont pas gérer dans un script ou automation. J’ai dans switch.yaml :

- platform: template
  switches:
    volet_cuisine
      turn_on:
         service: rest_command.volet_cuisine_on
      turn_off:
         service: rest_command.volet_cuisine_off

et dans configuration.yaml :

rest_command:
# Volet Cuisine ON
volet_cuisine_on:
url: '[http://192.168.1.30/cgi-bin/domo.cgi?cmd=ON%20A1%20P10'](http://192.168.1.30/cgi-bin/domo.cgi?cmd=ON%20A1%20P10%27)
# Volet Cuisine OFF
volet_cuisine_off:
url: '[http://192.168.1.30/cgi-bin/domo.cgi?cmd=OFF%20A1%20P10'](http://192.168.1.30/cgi-bin/domo.cgi?cmd=OFF%20A1%20P10%27)

ça veut dire que je dois tout refire ?

C’est peu être pas lier a ce changement, c’était une supposition.
Le mieux est d’ouvrir un nouveau sujet avec les informations de l’erreur.

j’ai ouvert un sujet ici :
Erreur rest
…merci pour l’aide