C.A.F.E : Editeur pour automatisation

Bonjour,

Je suis tombé sur cette article sur un nouvel éditeur graphique pour les automatisations sur HA.

Bonne journée.

Salut

Il y a aussi ce sujet qui en parle.

3 « J'aime »

J’ai vu cet article, j’ai testé, et je n’ai pas trouvé comment faire des boucles…

Si pas de boucle cela va être un frein pour certaines choses en effets…

Vu qu’on peut éditer une automatisation existante tu as essayé de voir comment il affichait une boucle crée depuis l’éditeur HA ?

Je verrai ce weekend si j’ai le temps pour ma part. Histoire de voir si ça apporte un plus ou non.

J’ai essayé cet après midi, ceci n’est que mon avis perso.

Ca ressemble a du nodered, mais uniquement pour la représentation « graphique » mais en nettement moins pratique et moins abouti.

L’interface graphique n’est pas pratique, et je trouve plus facile a visualiser les automatismes sur interface utilisateur de HA.

Perso, je pense pas utiliser dans l’état.

J’ai préféré de loin nodered a l’époque où je l’utilisais, même si depuis je fais les automatismes a 100% avec HA.

2 « J'aime »

Je l’ai installé mais pas vraiment essayé (juste ouvert une automatisation existante pour voir ce que ça donnait) Il y a du potentiel mais en l’état l’interface demande encore un peu de travail.
Ne pas oublier que c’est encore en beta…

2 « J'aime »

Bonjour,

en l’état il ne gère pas très bien les boucles en effet…
Visuellement c’est pas top :

représentation de :

Dans le bloc action on retrouve au final du yaml représentant la boucle :

{
  "until": [
    {
      "condition": "numeric_state",
      "entity_id": "input_number.test",
      "above": 5
    }
  ],
  "sequence": [
    {
      "action": "input_number.increment",
      "target": {
        "entity_id": "input_number.test"
      },
      "data": {},
      "metadata": {}
    }
  ]
}

Champs qu’on ne peut à priori créer autrement qu’en passant par l’onglet YAML de C.A.F.E.
Pas du tout fini donc pour passer entièrement dessus si on utilise des boucles.

Bonsoir.

J’ai cherché (probablement mal) un exemple d’utilisation de la déclaration de l’outil “Définir une variable”. J’ai renseigner un nom et une valeur, mais dans une action, j’ai besoin d’utiliser cette variable et j’ai eu beau essayer des tas de solutions, rien n’y fait. Je suis vraiment novice dans HA. J’arrive à bricoler quelques trucs, mais c’est pas très évident sans connaitre le langage.

Est-ce que quelqu’un pourrait m’indiquer la syntaxe ?
J’ai nommé la variable msg_sms et je voudrait l’utiliser dans une action dans lequel j’ai un champ “Message”.

Vous l’aurez deviner, le but est de créer une automatisation pour plusieurs éléments de sécurité qui utiliserons la même action mais en personnalisant le texte d’un SMS qui me sera envoyé.

Merci d’avance

deux solutions:

  • tu définis une entrée input-text que tu viens modifier dans ton automatisation.
  • tu définis une variable dans ta séquence d’action

La variable ne sera utilisable que dans la séquence d’action, ni dans les déclencheurs, ni dans les conditions et ne sera plus utilisable une fois la séquence terminée.

L’entrée input-text est une entité à part entière, donc elle pourra même être consultée après l’automatisation ou affichée dans un dashboard (comme un log…)

Je ne sais pas comment ça marche avec CAFE
:hot_beverage:

Mais dans les automatisation HA c’est comme ça.

cf la série d’article en cours (bon la différence variables / entrées est abordée dans le #3 qui n’est pas encore sorti…), mais les variables sont définies dans le #2 là: blocs dans les actions

Pour la doc officielle: c’est là: Script Syntax - Home Assistant

Apres l’implementation de ça dans C.A.F.E. je n’en sais rien…

[edit] pour des exemples, tu en as là, gentiment suggérés dans la discussion du #1 pour que je rajoute ça aux articles…

Salut

Dans cafe c’est exactement la même chose puisque ça ne fait que reprendre le code yaml et le présenter différemment de l’interface HA

Merci pour vos réponses.
Maintenant, ca ne répond pas tout a fait à la question ou du moins je n’ai pas réussit à comprendre et mettre en application. Le but serait de pouvoir faire la création et l’utilisation d’une variable graphiquement avec C.A.F.E.
Je suppose que s’il existe l’outil “Définir les varibales”, c’est qu’on peux créer une ou plusieurs variables qui pourront être utilisées dans les autres fonctions. Je pense qu’il me manque simplement la syntaxe.
J’ai essayé sans succès d’utiliser les syntaxe ci-dessous dans l’envois d’un message :
(msg-sms), (msg-sms.value), “ (msg-sms)“
{{msg-sms}}, {{ msg-sms }} et “{{ msg-sms }}”
{{msg-sms.value}}, {{ msg-sms.value }} et “{{ msg-sms.value }}”

Mais sans dout devrais-je demander directement au créateur de l’addon.

Autre solution:

Tu prends un des exemples d’automatisation avec variables qui marchent postés deux post au dessus.
Tu crées une automatisation a partir de ça (copie colle le yaml)

Tu l’ouvres dans CAFE et tu regardes la syntaxe.

J’ai été curieux, j’ai téléchargé et installé CAFE…

Bon j’aimais pas nodered, je n’aime pas non plus.

Même sur mes automatisations les plus complexes, je ne vois pas la plus value par rapport à l’editeur graphique ou le yaml…

Au moins CAFE n’est pas intrusif et permet de rester compatible de HA, contrairement à NodeRed.

Mais pour créer des automatisations, j’y ai passé un temps infini, et je trouve qu’on perd de vue le concept de base trigger / condition / actions ce qui peut être problématique pour les débutants…

Toutes les explications sur la syntaxe et la portée ds variables est indiqué dans le lien de la doc mis par @BBE un peu plus haut.

un exemple de variable et son appel :

    alias: Arrosage - Zone 1
    description: >-
      Lance un cycle d'arrosage de la zone 1.
      Si vous avez moins de 1 zones d'arrosage vous pouvez supprimer cette automatisation.
    triggers:
      - entity_id:
          - input_boolean.arrosage_auto_zone_1
        from: "off"
        to: "on"
        trigger: state
        id: auto_zone_1
    conditions: []
    actions:
      #- action: script.arrosage_nombre_electrovannes_par_zone
      - variables:
            all_data: "{{ state_attr('sensor.arrosage_data_zones', 'data_zones') | from_json }}"
            infos: "{{ all_data.zone_1 }}"
            duree_cycle: "{{ infos.duree_cycle }}"
            toutes_voies_disconnected: "{{ infos.toutes_voies_disconnected }}"
            liste_voies_disconnected: "{{ infos.voies_hors_ligne }}"
      - choose:
          - conditions:
              - condition: template
                value_template: "{{ toutes_voies_disconnected }}"
            sequence:
              - delay:
                  hours: 0
                  minutes: 0
                  seconds: 0
                  milliseconds: 100
              - action: input_boolean.turn_off
                metadata: {}
                data: {}
                target:
                  entity_id:
                    - input_boolean.arrosage_auto_zone_1

Exactement le même ressenti.

Merci pour vos renseignements.

J’avais espéré que cela serait plus simple à comprendre et utiliser.
Mes notions en “programmation” sont le Batch et le langage AutoIt, le YAML est assez abstrait, bien que certains éléments me parraissent compréhensible (plus ou moins).

Je vais continuer d’investiguer et tester.
Merci encore.

on ne parle même pas de comprendre le yaml.

on parle de copier coller un code dans une automatisation. et revenir en mode edition graphique.

puis observer le contenu du bloc « variables » de l’automatisation comme montré là:

Ensuite tu ouvres la même automatisation avec CAFE et tu regardes le noeud « variables » dans ton torrefacteur préféré…

et tu en déduis la façon dont il faut déclarer ses variables dans le capuccino…

C’est même pas du YAML, c’est juste de la lecture…

Honnêtement commence plutôt par ça pour avoir les bases puis passe au 2eme article pour comprendre l’integratlité de ce qu’on peut faire avant de te lancer dans la torrefaction…

Et attention il n’y a pas que le YAML, il y a aussi (et surtout) les templates en JINJA2… gare à la confusion…

3 « J'aime »

Le repo sur github a été créé il y a 1 mois et c’est écrit partout que c’est une beta.
Faut pas s’attendre à ce que ça remplace tout. Ca doit encore murir.

Je n’ai pas essayé mais ça semble tout de même intéressant, le fait que ça vienne en surcouche de core et que du coup il ait accès au fichier des automatisations de façon non destructive c’est vraiment pas mal quand même.

Il n’est pas impossible que ça fasse partie de HA un jour pour une version plus visuelle des automatisations comme d’autre systèmes domotique le proposent.

2 « J'aime »

Je partage le point de vue j’ai pas trouvé de vraie plus value dans mon cas
Par contre attention, comparer l’efficacité/temps passé sur un truc qu’on maîtrise et manipule au quotidien, c’est pas jouable versus un truc qu’on découvre. C’est exactement la même chose que les nombreux transfuges jeedom avec les scénario

3 « J'aime »

Par ailleurs il y a truc qui au final me chagrine un peu pas que sur CAFE car c’est valable pour Nodered ou Button-card :
HA est déjà très riches sur les périmètres à maîtriser : concept des éléments, réseau, algo, yaml, jinja2.. Donc vouloir en exploiter d’autres avec des surcouches et/ou extensions ça me semble de plus en plus contre productif avec le recul

1 « J'aime »