Home Assistant & Arrosage

Je n'ai pas vraiment la main verte et et mon jardin ressemble souvent à un no man's land, mais au printemps dernier une amie m'a convaincu de créer un carré d'herbes aromatiques, l'idée à fait son chemin et au centre on a même planté des plants de tomates qui produisent bien cet été ! Bon, vous imaginez bien que je ne vais pas ici vous conter ma vie privée mais plutôt la part domotique de cette réalisation !

En Provence, si on veut un peu de verdure et espérer manger ses propres tomates, il n'y a pas de secret, il faut arroser ! J'ai donc commencé par disposer un tuyau poreux sur mon carré. Ensuite j'ai acheté un robinet Zigbee et préparé un petit scheduler qui me permet facilement d'activer ou pas la plage journalière d'arrosage. J'ai fait quelque chose de simple en m'inspirant de ce que j'avais fait pour mon chauffe eau. Je publie ici le code suite à quelques demandes, même si ça n'a pas une grande valeur ajoutée.

Pour l'instant ça ne prends pas en compte les valeurs remontés sur les capteurs de plantes car je n'en suis pas satisfait.

L'offre en matière de capteurs de plantes n'est pas énorme :

  • Le capteur Xiaomi (ou ses copies) qui fonctionnent en Bluetooth et que l'on trouve sur Amazon ou Ali Express : C'est ce qui fonctionne le "mieux", mais cela nécessite un proxy BLE à l'extérieur que l'on peut facilement se bricoler avec un ESP sous ESPHome.
  • Le capteur Rehent en Zigbee que j'ai acheté chez Domadoo : Et là c'est la déconvenue. Il est un peu encombrant mais ne pose pas de soucis particulier pour l'appairer en ZHA ou Z2M (ou sur une passerelle Tuya), sauf que si ce capteur remonte parfaitement la température du sol, l'humidité du sol reste invariablement entre 75% et 85% (voir les sources au bas de cet article). Et bien sur chez Domadoo on est pas chez Amazon, le client a tort et l'éventuel retour est à votre charge. Bref capteur et fournisseur à éviter ! Il semblerait qu'autres séries de ce capteur que l'on trouve chez AliExpress fonctionnent, mais là il faudra aussi oublier le retour...

J'utilise une vanne Zigbee Woox qui alimente le tuyaux poreux (que je devrais remplacer par un un goute à goute). Pour avoir un réseau Zigbee fiable à l'extérieur, j'ai installé sous la toiture de la terrasse des prises Zigbee dont le relais est HS mais qui continuent à remplir parfaitement leur rôle de routeur Zigbee.

Tout cela reste très expérimental... Coté intégration j'utilise Home Assistant Plant et la carte qui va avec.

Automation

Une automation de schedule simple et visuelle :

input_datetime:
  watering_start:
    has_date: false
    has_time: true
  watering_stop:
    has_date: false
    has_time: true

input_boolean:
  watering_day_monday:
    name: "WATERING : Lundi"
    icon: mdi:toggle-switch
  watering_day_tuesday:
    name: "WATERING : Mardi"
    icon: mdi:toggle-switch
  watering_day_wednesday:
    name: "WATERING : Mercredi"
    icon: mdi:toggle-switch
  watering_day_thursday:
    name: "WATERING : Jeudi"
    icon: mdi:toggle-switch
  watering_day_friday:
    name: "WATERING : Vendredi"
    icon: mdi:toggle-switch
  watering_day_saturday:
    name: "WATERING : Samedi"
    icon: mdi:toggle-switch
  watering_day_sunday:
    name: "WATERING : Dimanche"
    icon: mdi:toggle-switch

automation:

- id: 'xx8d0e1-fcb6-4412-abvxx-99c4d37be5xx'
  alias: 'WATERING ON'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.watering_start.state[0:5] }}'
  condition:
    condition: or
    conditions:
      - '{{ (now().strftime("%a") == "Mon") and is_state("input_boolean.watering_day_monday", "on") }}'
      - '{{ (now().strftime("%a") == "Tue") and is_state("input_boolean.watering_day_tuesday", "on") }}'
      - '{{ (now().strftime("%a") == "Wed") and is_state("input_boolean.watering_day_wednesday", "on") }}'
      - '{{ (now().strftime("%a") == "Thu") and is_state("input_boolean.watering_day_thursday", "on") }}'
      - '{{ (now().strftime("%a") == "Fri") and is_state("input_boolean.watering_day_friday", "on") }}'
      - '{{ (now().strftime("%a") == "Sat") and is_state("input_boolean.watering_day_saturday", "on") }}'
      - '{{ (now().strftime("%a") == "Sun") and is_state("input_boolean.watering_day_sunday", "on")}}'
  action:
  - service: switch.turn_on
    entity_id: switch.vanne_woox_switch
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > WATERING | START | Soil : {{ states.sensor.soil_01_soil_moisture.state }}%" 


- id: 'zz9csdfsef-76dd-4fdd-9dzz-40bfsdq158zz'
  alias: 'WATERING OFF'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.watering_stop.state[0:5] }}'
  action:
  - service: switch.turn_off
    entity_id: switch.vanne_woox_switch
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > WATERING | STOP | Soil : {{ states.sensor.soil_01_soil_moisture.state }}%"   

La carte Lovelace :

type: vertical-stack
cards:
  - type: entities
    entities:
      - entities:
          - entity: automation.watering_on
            name: false
          - entity: sensor.energy_total_yearly_1pm_watering
            name: false
            unit: kWh
            format: precision2
          - entity: sensor.soil_01_soil_moisture
            name: false
        entity: switch.vanne_woox_switch
        name: Arrosage
        icon: mdi:watering-can-outline
        show_state: false
        state_color: true
        type: custom:multiple-entity-row
  - type: horizontal-stack
    cards:
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_monday
        name: Lundi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_tuesday
        name: Mardi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_wednesday
        name: Mercredi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_thursday
        name: Jeudi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_friday
        name: Vendredi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_saturday
        name: Samedi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.watering_day_sunday
        name: Dimanche
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
  - type: conditional
    conditions:
      - entity: automation.watering_on
        state: 'on'
    card:
      type: custom:vertical-stack-in-card
      cards:
        - type: horizontal-stack
          cards:
            - type: markdown
              content: '#### <center> Heure de début'
            - type: markdown
              content: '#### <center> Arrosage'
            - type: markdown
              content: '#### <center> Heure de Fin'
        - type: horizontal-stack
          cards:
            - entity: input_datetime.watering_start
              type: custom:time-picker-card
              name: Début
              layout:
                align_controls: center
                embedded: true
              hide:
                name: true
                icon: true
            - type: glance
              show_state: true
              show_name: false
              entities:
                - switch.vanne_woox_switch
            - entity: input_datetime.watering_stop
              type: custom:time-picker-card
              layout:
                align_controls: center
                embedded: true
              hide:
                name: true
                icon: true
  - color_thresholds:
      - color: '#039BE5'
        value: 0
      - color: '#0da035'
        value: 19
      - color: '#e0b400'
        value: 25
      - color: '#e45e65'
        value: 2400
    color_thresholds_transition: hard
    entities:
      - entity: sensor.plant_01_moisture
        name: Humidité du sol
      - entity: sensor.plant_01_temperature
        name: Températire du sol
      - color: rgba(0,0,255,1)
        entity: binary_sensor.night_reworked
        name: Nuit
        show_line: false
        y_axis: secondary
    group: false
    hour24: true
    hours_to_show: 24
    line_width: 2
    name: Humidité et température du sol
    points_per_hour: 4
    show:
      extrema: true
      fill: fade
      icon: true
      labels: false
      name: true
      state: true
    state_map:
      - label: Day
        value: 'off'
      - label: Night
        value: 'on'
    type: custom:mini-graph-card
  - type: custom:flower-card
    entity: plant.jardin
    show_bars:
      - illuminance
      - humidity
      - moisture
      - conductivity
      - temperature
      - dli
    battery_sensor: sensor.demo_battery

Souces

Capteur Rehent

 

Home Assistant & Plug Security

On utilise souvent des prises commandées uniquement pour mesurer la consommation de certains appareils. Ces prises sont toujours en position ON. Ces prises, si elles ne sont pas de trop mauvaise qualité un mécanisme de sécurité intégré qui les passent OFF en cas de surtension ou de surcharge. Et dans la pratique ça arrive parfois et on constate plus tard que le lave linge ou le lave vaisselle s'est arrêté, ou pire dans le cas d'un congélateur.

Pour palier à cet inconvénient on va créer une automation qui va réarmer la prise après quelques minutes en OFF. Jusque là c'est simple, mais il se peut également que le problème soit plus grave et qu'il ne faille pas forcer indéfiniment ce réarmement automatique. Etant donné qu'on ne dispose généralement pas d'information sur la cause de ce passage en sécurité on va considérer qu'au bout de "n" tentatives sur un temps donné on ne réarme plus. Pour ça on va utiliser des compteurs (à créer avec un minimum à 0 et un maximum à 10) et on fera un reset de ceux-ci toutes les nuits...

J'ai fixé ici arbitrairement à 5 le nombre de réarmements possibles.

Attention : Je vous explique ici comment j'ai fait, mais un risque existe toujours et la mise en œuvre de cette solution est à vos risques (et périls). Je me dégage ainsi de toute responsabilité.

On va faire ça avec une seule automation que j'ai voulue la plus concise et qui servira également à notifier :

automation:
- id: '2bd0ertyyf-2687-45f98f-aed0-to-off'
  alias: "Notify Plug Off"
  description: "Notification mise en sécurité des prises"
  mode: single
  trigger:
    - platform: state
      entity_id: switch.bw_1
      to: "off"
      id: "Lave Vaisselle"
    - platform: state
      entity_id: switch.bw_2
      to: "off"
      id: "Lave Linge"
    - platform: state
      entity_id: switch.bw_3
      to: "off"
      id: "Seche Linge"
    - platform: state
      entity_id: switch.bw_4
      to: "off"
      id: "Congelateur"
    - platform: time
      at: "00:05:00"
      id: "Reset"
  condition: []
  action:
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0  
  - choose:
      - conditions: "{{ trigger.id in ['Lave Vaisselle'] and states('counter.plug_bw_1') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_1
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_1
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_1')}} du {{ trigger.id }}"               

      - conditions: "{{ trigger.id in ['Lave Linge'] and states('counter.plug_bw_2') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_2
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_2
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_2')}} du {{ trigger.id }}" 

      - conditions: "{{ trigger.id in ['Seche Linge'] and states('counter.plug_bw_3') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_3
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_3
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_3')}} du {{ trigger.id }}" 

      - conditions: "{{ trigger.id in ['Congelateur'] and states('counter.plug_bw_4') | int < 5 }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.bw_4
          - service: counter.increment
            target:
              entity_id: counter.plug_bw_3
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Réarmement n°{{ states('counter.plug_bw_4')}} du {{ trigger.id }}" 

      - conditions: 
          - condition: or
            conditions:
              - "{{ trigger.id in ['Lave Vaisselle'] and states('counter.plug_bw_1') | int >= 5 }}"
              - "{{ trigger.id in ['Lave Linge'] and states('counter.plug_bw_2') | int >= 5 }}"
              - "{{ trigger.id in ['Seche Linge'] and states('counter.plug_bw_3') | int >= 5 }}"
              - "{{ trigger.id in ['Congelateur'] and states('counter.plug_bw_4') | int >= 5 }}"
        sequence:
          - service: notify.slack_hass_mondon
            data:
              message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > Problème avec le {{ trigger.id }}. On ne réarme plus, une vérification s'impose." 

      - conditions: "{{ trigger.id in ['Reset'] }}"
        sequence:
          - service: counter.reset
            target:
              entity_id:
                - counter.plug_bw_1
                - counter.plug_bw_2
                - counter.plug_bw_3
                - counter.plug_bw_4

Home Assistant & Sirènes

J'ai déjà parlé ici du système d'alarme Alarmo pour Home Assistant et notamment des commandes possibles pour armer et désarmer le système. Aujourd'hui il s'agira des sirènes.

J'ai trois modèles

  • La plus basique est juste branchée sur une prise commandée Zigbee ondulée. Donc un switch: vu en tant que siren:.
  • Une sirène Heiman qui sous ZHA décroche régulièrement et que j'ai du appairer à ma seconde passerelle sous Z2M.
    • Sous ZHA elle était vue en tant que siren:.
    • Sous Z2M elle est vue en tant que rien du tout...
  • Une sirène SMaBit sous Z2M également vue en rien du tout...

Pour commander une sirène via ZHA HA propose :

    - service: siren.turn_on
      target:
        entity_id:
          - siren.heiman_sirene

Pour commander une sirène sous Z2M il faut lui envoyer le payload correspondant :

    - service: mqtt.publish
      data:
        topic: zigbee2mqtt/Sirène SMaBiT/set
        payload: >-
          {"warning": {"mode": "fire", "level": "very_high", "strobe_level": "low", "strobe": "false", "strobe_duty_cycle": "10", "duration": "360"}}

Un peu plus compliqué et moins facile à mémoriser, mais ça fonctionne.

Mon objectif a donc été de faire en sorte qu'une sirène Z2M soit vue par Home Assistant comme une sirène ZHA et ainsi pouvoir la commander par un siren.turn_on comme les autres... Et voici ce que ça donne :

mqtt:
  siren:
    - unique_id: heiman_sirene_1s
      name: Heiman Sirène 1s
      state_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      optimistic: false
      qos: 0
      retain: true
      state_value_template: "{{ value_json.warning['mode'] }}"
      command_template: '{"warning": {"duration": 2, "mode": "burglar", "level": "very_high", "strobe": true}}'
      command_off_template: '{"warning": {"duration": 2, "mode": "stop", "level": "very_high", "strobe": true}}'
      state_on: "burglar"
      state_off: "stop"

Problème, car il y en a un, la sirène Heiman ne retourne aucun état sous Z2M. Il y a beaucoup d'articles à ce sujet, et l'intégration ne semble pas vraiment terminée. Hors dans l'activation il y a une durée, le principe étant d'activer la sirène pour x secondes. Et donc comme elle ne retourne pas son état, son commutateur restera sur ON alors que le délais d'activation est terminé et la prochaine action n'aura aucun effet... De plus certaines sirènes proposent plusieurs fonctions et tonalités (les bips de délais d'armement et désarmement par exemple).

Donc contrairement à ZHA ou l'intégration siren: peut gérer tous les modes, chercher à gérer une sirène Z2M en tant que siren: n'a pas de sens... (hormis peut être de bricoler un template: qui en fonction de la durée d'activation repasserait le commutateur à off, on peut aussi le faire via une automation: mais là ça va alourdir la chose...).

Alternative

S'agissant d'envoyer un payload à une sirène Z2M, ce que j'ai trouvé de plus logique est un mqtt:/button: et il faut donc en faire deux :

mqtt:
  button:
    - unique_id: siren_heiman_1_warning
      name: "Sirène Heiman 1 : Waraning"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      payload_press: '{"warning": {"duration": 2000, "mode": "burglar", "level": "very_high", "strobe": true}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_heiman_1_stopped
      name: "Sirène Heiman 1 : Stopped"
      command_topic: "zigbee2mqtt/Heiman Sirène 1/set"
      payload_press: '{"warning": {"duration": 2, "mode": "stop", "level": "very_high", "strobe": true}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"   

Ou plusieurs pour gérer les différents mode de la SMaBit :

mqtt:
  button:
    - unique_id: siren_smabit_armed
      name: "Sirène SMaBit : Armed"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"squawk": {"state": "system_is_armed", "level": "veryhigh", "strobe": "true"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_disarmed
      name: "Sirène SMaBit : Disarmed"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"squawk": {"state": "system_is_disarmed", "level": "veryhigh", "strobe": "true"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_warning
      name: "Sirène SMaBit : Warning"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"warning": {"mode": "fire", "level": "very_high", "strobe_level": "low", "strobe": "false", "strobe_duty_cycle": "10", "duration": "360"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

    - unique_id: siren_smabit_stopped
      name: "Sirène SMaBit : Stopped"
      command_topic: "zigbee2mqtt/Sirène SMaBiT/set"
      payload_press: '{"warning": {"mode": "stop"}}'
      qos: 0
      retain: false
      entity_category: "config"
      device_class: "restart"

Vous l'aurez compris, il s'agit plus d'un exercice de style qu'autre chose. Mais ça m'aura permis de comprendre comment créer des devices MQTT non reconnus par le discovery:. Merci @Mathieu pour ta participation !

Sources

 

Sony mon amour !

Amour déçu comme on le verra plus loin ! Depuis très jeune j'ai toujours été un afficionado de la marque Sony. Et si d'aucune pourraient trouver cela déplacé, il est des domaines ou je suis fidèle ! Coté TV après avoir eu quelques Trinitrons cathodiques célèbres tel le Profeel, je me suis offert jadis le premier moniteur plasma pro de la marque, qui avait du me couter un an de salaire et que je me suis résolu récemment à le porter à la déchetterie, le pauvre il trainait dans le garage depuis bientôt 20 ans !

Je ne vais pas vous faire la liste des écrans Sony que j'ai eu successivement, ni leur cout car ça me déprimerait, mais juste vous parler des déboires de mon dernier TV. Il y a un an j'ai craqué pour le A80J, un Oled ! Un TV intelligent sous Google TV, même si d'intelligence il n'a que la pub et les traqueurs que cela induit !

Je considère Google TV / Android TV comme étant le meilleur choix car il me permet d'installer les application qui me sont utiles, en opposition aux écosystèmes fragmentés de la concurrence qui ne proposent que l'essentiel bien commercial ! C'est du business, on le sait et on l'accepte car ça nous apporte du confort.

Autres points que les pseudo journalistes testeurs oublient souvent, c'est la télécommande et l'implémentation du CEC. Celles de Sony m'ont toujours satisfait alors que je déteste certaines d'autres marques. Mais Sony est radin, et sur le A80J la télécommande n'est pas même rétroéclairée ! Qu'à cela ne tienne il suffit de commander sur Amazon celle du A90J qui elle est premium et rétro éclairée... Quant au CEC il a toujours été très bien chez Sony.

Je ne vais pas vous raconter ce que vaut cette TV, plusieurs sites l'ont déjà fait plus ou moins bien. Enfin, je parle de TV, mais je ne regarde même pas la télé et aucune antenne n'y est raccordée. Je rêve d'une version moniteur !

Domotique

Oh le gros mot ! Encore un client qui veut faire des choses louches ! Louches car je ne me plie pas à la domotique commerciale et forcément limitative (Amazon, Google, Apple, Tuya, etc...) mais que ma domotique est libre, Home Assistant.

Et pourquoi faire ? Pas grand chose, juste inclure ce TV dans me scénarios (scènes). Et on va faire simple !

  • Play / Pause : on éteint et on rallume progressivement les éclairages comme au cinéma.
  • On / Off : on mets sur pause la musique qui était diffusée.

Ce n'est pas sorcier et très simple à faire. Mais pour ca il faut pouvoir extraire les informations du TV. Ca tombe bien ce TV est reconnu sous Home Assistant par l'intégration Bravia ou HomeKit. Dès lors on dispose des information idoines et ça fonctionne très bien, il suffit d'agir en fonction de l'état remonté.

Mais alors il se plaint de quoi le râleur ? Et oui il y a un "mais" !

Consommation

Pour accéder à ces fonctions il faut que le contrôle à distance ou / et HomeKit soit activé. C'est d'ailleurs le cas par défaut. Et les ingés de chez Sony, dont je ne doute pas des prouesses en audio / vidéo s'avèrent des brèles en réseau ! Pour que ces fonctions soient accessibles ils laissent simplement la partie réseau allumée quand le téléviseur est en veille. Et comme leur carte réseau doit dater du siècle dernier (elle a du mal à accrocher le réseau et est limitée à du 10/100 en 2022 ou on est censés passer de la full 4K !), elle consomme en veille pas moins de 26/28 W alors que si ces fonctions sont désactivées la veille est à seulement 0.9 W.

Cela pose deux constats :

  • Il est inacceptable qu'un TV en veille consomme 27 W en 2022 (c-a-d + ou - 50 € / an).
  • Il est inacceptable que ces fonctionnalités soient activées par défaut et induisent cette surconsommation ! Et certainement contraire aux directives européennes en la matière. Il est en effet peu probable qu'un consommateur lambda ne pense à mesurer et désactiver ces fonctions.

En l'état il est donc inenvisageable d'utiliser ces fonctionnalités qui ajoutent un plus au téléviseur. Et il faut noter que tout pilotage par les applis standard, Chromecast, Alexa, etc pose le même problème...

Le pire étant que si on désactive ces fonctions, quand on allume le téléviseur il mets bien trop longtemps pour accrocher le réseau, que ce soit en Ethernet ou en WI-FI. Je sais c'est fait pour regarder la télé avec un râteau sur la toiture !

Alternative

Avant j'utilisait un LCD Sony bien plus bête et une NVidia Shield que je pilotait très bien sans que cela ne grève mon budget. Le Shield allumait le TV en CEC et tout était parfait. Je vais peut être en racheter un, encore que mon Shield de 2015 fonctionne encore très bien dans ma chambre. Un bel exemple de non obsolescence qui mérite d'être signalé !

Et les autres ?

Je ne sais pas comment ça se passe chez les autres constructeurs de TV car je ne suis pas client. On me remonte 1 à 2 W avec les options de pilotage activées chez Samsung ou Panasonic, mais je n'ai pas vérifié. Par contre j'ai un bel élevage de Sonos, et là non plus ce n'est pas très joli à voir : aucun progrès depuis le début, conso identique en veille sur les anciens Play 1 et 3 et les nouveaux One (gen 1 et 2), entre 3 et 4 W voire plus de 8 à 11 W sur un AMP ou 6 W pour une Beam !

Moralité

La domotique n'est pas vraiment écologique, elle crée un énorme talon de consommation de part son infrastructure (caméras, nvr, switches, micro modules et autres prise connectées). Elle apporte plus de confort qu’elle ne fait réaliser des économies (les économies c’est le bobard que racontent certains à leur compagne quand c’est elle qui tiens les cordons de la bourse, car, hélas, la domotique reste un truc de mec, comme le BBQ, n’en déplaise à Sandrine).

Un panneau solaire va devoir s'imposer à moi !

Sources

 

 

Home Assistant & Volets roulants, automatismes !

Dans un précédent article je vous avait parlé de la partie matérielle de mes volets roulants et de leur commande via des interrupteurs et des télécommandes. Mais avec une installation domotique ouverte, on peut faire bien mieux !

L'objectif ici sera pour chaque volet (ou groupe de volets) d'automatiser leur ouverture, position intermédiaire et fermeture en fonction de :

  • Le jour et la nuit
  • La température extérieure et intérieure et les contraintes météo (canicule, etc.)
  • La position du soleil
  • Les contraintes de vie (lever tardif, soirée, etc...)
  • Les contraintes de présence / absence plus ou moins longue (alarme et simulation de présence)
  • Le débrayage de l'automatisme afin de laisser en paix un invité ou les enfants en vacances avec leur propres horaires et mode de vie.

Vous allez me dire tout de suite que la tache est complexe et vous aurez raison, mais pas tant que ça car je vais m'appuyer sur le travail de Fabien qui a créé un superbe moteur pour gérer tout ça, moteur que chacun pourra adapter à ses propres besoin en lui fournissant des prérequis (inputs, binary, etc..) qui permettront de gérer les différents conditions de positionnement. Vous trouverez les détails sur son blog, mais l'installation est relativement aisée, on commence par créer les entités nécessaires, ensuite on ajoute les BluePrint's de configuration et on termine avec un peu de yaml pour la configuration des conditions.

Facile, mais ça prends un peu de temps. Et surtout commencez par mettre sur le papier le résultat que vous voulez obtenir. Dans cet article je vais vous parler de ce que j'ai mis autour de son travail, plus que de son travail. 

Avant de chercher à intégrer mes exemples, prenez le temps d'avoir une installation vraiment fonctionnelle avec les Blueprint's de Fabien.

De base et sans rien ajouter le moteur de Fabien va permettre d'ouvrir le volet au lever de soleil et de le fermer au coucher du soleil grâce à l'intégration sun.sun. Bon, pour faire ça on a pas besoin d'une usine, c'est pour ça que je vais vous montrer que son moteur permet bien d'autres choses.

Température extérieure et position du soleil

Voici un exemple des plus basic de ce que j'avais fait au départ, mais je vous conseille d'adapter la version de Fabien que j'ai moi même adoptée et qui permet d'aller plus loin, avec différentes sources et notamment un capteur de luminosité.

Exemple

J'utilise les Packages et je vais commencer par créer deux sensor: en fonction de ma localisation en m'appuyant sur sun.sun

sensor: 
  - platform: template
    sensors:
      sunelevation:
        friendly_name: "Elevation du soleil"
        value_template: "{{ state_attr('sun.sun', 'elevation') }}"
      sunazimuth:
        friendly_name: "Azimut du soleil"
        value_template: "{{ state_attr('sun.sun', 'azimuth') }}"

Ensuite je vais me servir de ce site pour trouver les bonnes valeurs et je vais créer 3 binary_sensor: avec les les valeurs basses et hautes d'azimut, ces binary passeront à ON quand le soleil tapera sur la façade concernée. Bien sur il faudra un peu tâtonner pour trouver les bonnes valeurs et les ajuster.

binary_sensor:
  - platform: threshold
    name: "Soleil : Ouest"
    upper: 170
    lower: 80
    entity_id: sensor.sunazimuth
  - platform: threshold
    name: "Soleil : Sud"
    upper: 270
    lower: 100
    entity_id: sensor.sunazimuth
  - platform: threshold
    name: "Soleil : Est"
    upper: 299
    lower: 260
    entity_id: sensor.sunazimuth

Et pour terminer je vais créer un dernier binary_sensor: pour déterminer les conditions météo. Il s'appuie sur les infos de l'intégration Météo France (ou avec un capteur de luminosité en s'appuyant sur l'exemple de Fabien) et dépend de seuils définis dans des input_number: qui pourront s'afficher dans Lovelace. (je n'ai pas pris en compte la température intérieure pour l'instant).

binary_sensor:
  - platform: template
    sensors:
      vr_sun_hot:
        device_class: heat
        delay_on: 
          seconds: 300
        delay_off:
          seconds: 300
        value_template: "{{states('sensor.avignon_temperature')|float(0) >= states('input_number.vr_sun_hot') |float(0)
                        and states('sensor.avignon_cloud_cover')|float(0) <= states('input_number.vr_cloud_cover')|float(0) }}" 
        friendly_name: "Alerte haute température"

input_number:
  vr_sun_hot:
    name: Seuil haute température
    min: "10"
    max: "40"
    step: "1"
    unit_of_measurement: "°"
    icon: mdi:sun-thermometer-outline
  vr_cloud_cover:
    name: Seuil couverture nuageuse
    min: "0"
    max: "100"
    step: "5"
    unit_of_measurement: "%"
    icon: mdi:cloud-lock-outline 

Et voici le travail :

Exploitation

Vous aurez remarqué que j'ai deux seuils. Il y aura donc deux conditions possibles dans le choose: de l'automation de positionnement qui exploite les Blueprint's de Fabien. On retrouve dans l'ordre :

  1. La ou les conditions (and), ici la température est hot et le soleil au sud.
  2. La séquence de services à lancer :
    1. Je positionne le volet dans un input_number: à partir d'un input_number: de préréglage.
    2. A des fin de debug je note la dernière condition utilisée et la position du volet dans un input_text: que je peux afficher dans Lovelace
        - conditions:
            - condition: state
              entity_id: binary_sensor.vr_sun_hot
              state: "on"
            - condition: state
              entity_id: binary_sensor.soleil_sud
              state: "on"
          sequence:
            - service: input_number.set_value
              target:
                entity_id: input_number.vr_cuisine_planned_position
              data:
                value: "{{ states('input_number.vr_global_position_sun_alert') }}"
            - service: input_text.set_value
              target:
                entity_id: input_text.vr_cuisine_condition
              data:
                value: "Condition : Ensoleillement excessif - {{ states('input_number.vr_global_position_sun_alert') }} %"

Attention : Dans un choose: l'ordre de priorité des différentes conditions est important. Il y a aussi une option par défaut si aucune des conditions n'est valide mais que l'automation est tout de même déclenchée. On placera donc en premier celles qui doivent prendre le dessus, par exemple la condition issue de l'activation de l'alarme sera en premier car il est évident que l'on se moque de position du soleil si on est en voyage et que la maison est fermée.

Cela n'empêchera éventuellement pas une solution de simulation de présence qui agirait sur les volets de fonctionner. Je suis en train de tester cette intégration, attention à bien valider avant de partir en vacances...

Contraintes de vie

Réveil

Ici c'est au petit bonheur de chacun. En ce qui me concerne je n'ai pas d'horaires réguliers et je suis un lève tard. J'ai donc créé un script qui se déroule quand je dis bonjour (ou bonne nuit) à Alexa ou que j'appuis simplement sur un bouton de télécommande. Ce script va entre autres choses faire un push, si je suis présent dans la maison, sur un input_button: que je vais utiliser ici pour entrouvrir le volet de ma chambre et de la baie du séjour (une baie vitrée coulissante s'ouvre très facilement si elle n'est pas protégée, je vais donc éviter d'ouvrir son volet quand je dors). On a donc deux input_button: :

input_button:
  lionel_up:
    name: Je me lève
    icon: mdi:human-greeting-variant
  lionel_down:
    name: Je me couche
    icon: mdi:bed

La condition correspondant au réveil (la position du volet est stockée dans un input_number: afin d'être facilement ajustée depuis l'interface)

        - conditions:
            - "{{ as_timestamp(states('input_button.lionel_up'))|timestamp_custom('%H:%M', true) == states('sensor.time')  }}"
          sequence:
            - service: input_number.set_value
              target:
                entity_id: input_number.vr_lionel_planned_position
              data:
                value: "{{ states('input_number.vr_global_position_reveil') }}"

Il faut bien sur ne pas oublier de déclarer input_button: dans le BluePrint correspondant au volet (en condition immédiate) et l'actionner dans le script ou l'interface :

  - service: input_button.press
    target:
      entity_id: input_button.lionel_up

Et pour ce volet je vais modifier l'action par défaut d'ouverture dans l'automation afin qu'il ne se passe rien avant 13 heures... mais également rien si le volet est déjà un peu ouvert par une condition fugitive (button.press).

            - conditions:
                - condition: numeric_state # On ouvre le volet si le soleil est au dessus de l'horizon
                  entity_id: sun.sun
                  attribute: elevation
                  above: 0
                - condition: time
                  after: "13:00:00"
                - condition: state
                  entity_id: cover.vr_baie
                  state: "closed"

Soirée

En soirée, surtout en été, je n'ai pas envie que les volets soient complètement fermés car c'est l'heure ou on ouvre les fenêtres pour faire entrer un air plus frais. Je vais donc définir un binary-sensor: correspondant à ma soirée (merci Fabien) :

binary_sensor:
  - platform: template
    sensors:
      vr_evening:
        value_template:  "{{ (state_attr('sun.sun', 'azimuth') | float(0.0)) > 180 and (state_attr('sun.sun', 'elevation') | float(0.0)) < 0 and ('12:00:00' < states('sensor.time')) }}"
        friendly_name: "Soirée"

J'aurais pu y ajouter un and supplémentaire afin de valider la saison en me basant sur l'intégration Season. Sauf que les saisons tout le monde sait que ça ne veut plus dire grand chose et qu'ici depuis le début du mois de mail il fait plus ou moins 30° en journée, je testerais donc un input_boolean: de plus pour valider cette condition (que j'aurais également pu valider dans le binary-sensor:) :

        - conditions:
            - condition: state
              entity_id: binary_sensor.vr_evening
              state: "on"
            - condition: state
              entity_id: input_boolean.vr_evening
              state: "on"
          sequence:
            - service: input_number.set_value
              target:
                entity_id: input_number.vr_cuisine_planned_position
              data:
                value: "{{ states('input_number.vr_global_position_soir') }}"
            - service: input_text.set_value
              target:
                entity_id: input_text.vr_cuisine_condition
              data:
                value: "Condition : Soirée - {{ states('input_number.vr_global_position_soir') }} %"

On peut aussi faire la même chose avec d'autres conditions et sans binary_sensor: et tout mettre dans les conditions...

        - conditions:
            - condition: numeric_state
              entity_id: sun.sun
              attribute: azimuth
              above: 180
            - condition: numeric_state
              entity_id: sun.sun
              attribute: elevation
              below: 0
            - condition: time
              after: "18:00:00"            
            - condition: state
              entity_id: input_boolean.vr_evening
              state: "on"     

Présence / Absence et Alarme 

Pour ce chapitre c'est un peu plus compliqué. J'utilise en parallèle deux système. Ma centrale Visonic indépendante mais que je pilote dans Home Assistant et l'intégration Alarmo. Lors de mes test je me suis aperçu que tester uniquement l'état "armed" pouvait conduire à des surprises. Lors de l'armement et surtout le déclenchement d'une alarme (possiblement fausse) l'état de alarm_control_panel: passe par des phases successives peu simple à gérer, et ça peu conduire à une ouverture des volets non souhaitée.

Chez moi j'ai différentes possibilités pour armer ces deux systèmes (télécommande, code, tag), je vais donc me servir d'Alarmo qui permet de lancer un script selon un état pour basculer un input_boolean: qui me servira dans la condition immédiates du volet :

  • On passe tous les volets en mode automatique (certains auraient pu êtres débrayés comme on le verra plus loin)
  • On active l'input_boolean: qui va nous servir dans la condition de l'automatisation
  • Sur le mode Vacances (absence de longue durée) je rebascule tous les volets en mode manuel. Une sécurité de plus afin d'empêcher qu'ils soient ouverts par erreur.
script:
  alarmo_after_arm:
    alias: Alarmo - after Arm
    sequence:
      - if:
        then:
        - service: input_select.select_option
          target:
            entity_id:
              - input_select.vr_cuisine_immediate
              - input_select.vr_marie_immediate
              - input_select.vr_baie_immediate
              - input_select.vr_sejour_immediate
              - input_select.vr_antoine_immediate
              - input_select.vr_lionel_immediate
          data:
            option: Automatique
      - if: "{{ is_state('alarm_control_panel.alarmo', 'armed_away') }}"
        then:
          - service: input_boolean.turn_on
            target:
              entity_id: input_boolean.alarmo_armed_away
      - if: "{{ is_state('alarm_control_panel.alarmo', 'armed_vacation') }}"
        then:
          - service: input_boolean.turn_on
            target:
              entity_id: input_boolean.alarmo_armed_vacation
          - delay: "00:02:30"
          - service: input_select.select_option
            target:
              entity_id:
                - input_select.vr_cuisine_immediate
                - input_select.vr_marie_immediate
                - input_select.vr_baie_immediate
                - input_select.vr_sejour_immediate
                - input_select.vr_antoine_immediate
                - input_select.vr_lionel_immediate
            data:
              option: Manuel              
      - if: "{{ is_state('alarm_control_panel.alarmo', 'armed_home') }}"
        then:
          - service: input_boolean.turn_on
            target:
              entity_id: input_boolean.alarmo_armed_home
                entity_id: input_boolean.alarmo_armed_away

Et au retour sur le disarm :

  • Je repasse les input_boolean: à off
  • Je repasse tous les volets en automatique afin que les conditions courantes prennent effet.
  • Et si ma fille ou mon fils sont présents présente je vais basculer leurs volets en manuel afin qu'ils soient gérés comme bon leur semble. Mais j'attend un peu afin que l'automatisation du volet  le place dans la position de la contrainte en cours.
script:
  alarmo_after_to_disarm:
    alias: Alarmo - after Disarm
    sequence:
      - if:
        then:
        - service: input_boolean.turn_off
          target:
            entity_id: 
              - input_boolean.alarmo_armed_away
              - input_boolean.alarmo_armed_vacation
              - input_boolean.alarmo_armed_home
        - service: input_select.select_option
          target:
            entity_id:
              - input_select.vr_cuisine_immediate
              - input_select.vr_marie_immediate
              - input_select.vr_baie_immediate
              - input_select.vr_sejour_immediate
              - input_select.vr_antoine_immediate
              - input_select.vr_lionel_immediate
          data:
            option: Automatique
      - if: "{{ is_state('input_boolean.presence_marie', 'on') }}"
        then:
          - delay: "00:01:30"
          - service: input_select.select_option
            target:
              entity_id:
                - input_select.vr_marie_immediate
            data:
              option: Manuel
      - if: "{{ is_state('input_boolean.presence_antoine', 'on') }}"
        then:
          - delay: "00:01:30"
          - service: input_select.select_option
            target:
              entity_id:
                - input_select.vr_antoine_immediate
            data:
              option: Manuel

Ensuite il me reste qu'à configurer la contrainte dans l'automatisation, et surtout de la placer en priorité (la première).

        - conditions:
            - condition: state
              entity_id: input_boolean.alarmo_armed_away
              state: "on"
          sequence:
            - service: input_number.set_value
              target:
                entity_id: input_number.vr_cuisine_planned_position
              data:
                value: "{{ states('input_number.vr_global_position_alarm') }}"
            - service: input_text.set_value
              target:
                entity_id: input_text.vr_cuisine_condition
              data:
                value: "Condition : Alarmo Away - {{ states('input_number.vr_global_position_alarm') }} %"

J'ai deux positions d'alarme, ARMED_AWAY et ARMED_VACATION. J'utilise la première quand que pars quelques heures, ça laisse certains volets entrouverts afin de simuler une présence avec d'autres artifices, et la seconde pour une fermeture totale.

Le débrayage

Les automatismes c'est bien, mais si mes enfants sont ici en vacances ou des amis occupent leurs chambres, je ne voudrais pas qu'un automatisme les sortent du lit à l'aube. Pour mes enfants qui disposent de l'application Home Assistant je pourrait imaginer un automatisme, mais on va oublier et leur laisser de la liberté, d'autant plus que s'agissant d'amis je ne vais pas leur imposer ma domotique.

Par contre je dispose facilement de leur date de départ et d'arrivée et une automation bascule déjà un input_boolean: qui sert au chauffage. Je vais donc m'en servir pour passer le volet de leur chambre en mode manuel :

automation:
- id: a800970c-9bf4-48ce-aedg-a67c29093eb3
  description: Change vr_marie_immediate
  alias: VR Global - Change mode VR Marie
  mode: restart
  trigger:
    - platform: state
      entity_id: input_boolean.presence_marie
  action:
    - choose:
        - conditions:
            - condition: state
              entity_id: input_boolean.presence_marie
              state: "on"
          sequence:
            - service: input_select.select_option
              target:
                entity_id:
                  - input_select.vr_marie_immediate
              data:
                option: Manuel
        - conditions:
            - condition: state
              entity_id: input_boolean.presence_marie
              state: "off"
          sequence:
            - service: input_select.select_option
              target:
                entity_id:
                  - input_select.vr_marie_immediate
              data:
                option: Automatique

Enfants et amis commanderont donc leur volets avec la petite télécommande de leur chambre.

Suspension

Si vous êtes arrivés là et que vous avez lors de la configuration des BluePrint's la durée de suspension vous vous demandez peut être de quoi il s'agit. En fait configure là le durée pendant laquelle l'automatisme sera suspendu. Imaginons que celle ci est réglée du 60 minutes, il est 13 heures, le soleil frappe fort et vous décidez de déjeuner dans le cuisine. Vous remontez le volet avec la télécommande (ou l'application), il restera levé le temps de manger (suspension de 60 minutes) et l'automatisme reprendra le dessus ensuite avec la contrainte idoine... Magique !

Conclusion

Tout cela m'a pris un peu de temps et j'ai servi de cobaye dans la phase de test d'appréhension de la solution que Fabien viens de mettre à disposition. Quand vous aurez parfaitement validé le fonctionnement souhaité sur un volet pour pourrez le dupliquer sur l'ensemble des volets.

Pour cela il faut :

  1. Dupliquer le fichier qui contient les informations propres à chaque volet (mes fichiers sont ici) et changer l'ID: de l'automation.
  2. Repérer les informations des 3 BluePrint's du premier volet dans le fichier /config/automations.yaml, les dupliquer à la suite en changeant les informations propres à chaque volet et les ID: . Si vous ne le sentez pas configurez les BluePrint's individuellement à la main.
  3. Vérifier une fois de plus que tous les ID: ont bien été changés. J'insiste sur ce point car ça peut être la cause de bien des dysfonctionnements. Vous trouverez ici un générateur d'UUID.
  4. Redémarrer Home Assistant
  5. S'armer de patience car ce que l'on imagine parfait pour le premier volet ne le sera pas nécessairement pour les autres.
  6. Et surtout tester toutes les conditions car il sera désagréable de voir s'ouvrir le volet de la chambre quand on dort (vécu) voir certains volets ne pas se fermer sur l'alarme enclenchée quand on part que l'on est déjà en retard (vécu avec obligation de tous les passer en mode manuel et de les baisser à la main).

Avec plaisir pour en parler, ici ou mieux sur ce fil HACF.

Sources

Home Assistant & Wake on Lan

L'heure est aux économies d'énergies et il parait qu'il faut éteindre "la" Wi-Fi ! Ce n'est peut être pas ce qui consomme le plus et notre domotique fait certainement mieux.... Par contre nombre d'entre nous ont des PC énergivores qui mériteraient de passer en veille. Sauf que dans la pratique on laisse souvent ce PC allumé en se disant que l'on pourra en avoir besoin depuis l'extérieur... Ce que j'ai longtemps fait !

Un PC moderne avec un SSD sait sortir de veille en quelques secondes. Alors pourquoi ne pas ressortit une vieille fonctionnalité très peu utilisée, le Wake on Lan.

Sous Linux, Windows, voire même les mobiles il existe des application GUI ou CLI. Il faut tout de même savoir que Wake on Lan n'a pas été conçu à l'époque pour fonctionner à distance, et même s'il existe des possibilités ça reste compliqué. Alors pourquoi ne pas simplement utiliser Home Assistant qui lui sera toujours disponible, voire même simplement ajouter ça à un ESP existant, sous ESP Home par exemple..

La première chose pour vos tests sera de vérifier en local que le Wake on Lan fonctionne (il y a pas mal d'utilitaires et d'explications sur ce site).

Avec Home Assistant

On commence par ajouter l'intégration au fichier de configuration et on redémarre :

wake_on_lan:

Ensuite on peur créer un switch: , mais aujourd'hui on préfèrera un button: dans Lovelace qui actionnera le service correspondant :

  - action_name: 'Sleep/UnSleep'
    double_tap_action:
      action: call-service
      service: button.press
      target:
        entity_id: button.lia_monitors_off
      action: call-service
      confirmation:
        text: Etes vous sur ?
    tap_action:
      action: call-service
      service: wake_on_lan.send_magic_packet
      data:
        mac: 00-0C-29-FB-77-97
    icon: mdi:microsoft-windows
    name: 'Windows 10 PC'
    type: button

Vous remarquerez que j'ai configuré ça sur le tap_action:, le double_tap_action: étant lui configuré pour la commande de mise en veille via Home Assistant Agent.

Avec ESP Home

J'ai un client full cloud qui dispose d'une douzaine de PC, mais pas de serveur et encore moins de Home Assistant. La première solution était de laisser un PC allumé et y installer de quoi faire du Wake on Lan en remote. Il y a également des possibilités via TeamViewer et hélas pas de base dans l'UDM Pro d'Ubiquiti. On verra ce l'on utilisera mais j'ai également pensé faire ça via un simple ESP qui lui pourrait resté allumé...

Dans ESP Home on va éditer la config et simplement ajouter (attention, ici les séparateurs ne sont pas des "-" mais ":") :

web_server:    

button:
- platform: wake_on_lan
  name: "VM Annia"
  target_mac_address: 00:0C:29:FB:77:97

A partir de là il est possible de presser notre button: qui remonte dans Home Assistant, sur la page web de l'Esp, mais également via la commande curl (la doc est ici) :

curl -X POST http://192.168.210.153/button/vm_annia/press

Et comme on ne va pas demander à l'utilisateur final de faire un "curl" on va lui emballer tout ça dans une page web accessible que l'on sécurisera afin que lui seul puisse y accéder, en partant de cette base :

<HTML>
<center>

	<form name="myform" action="http://192.168.210.153/button/vm_annia/press" method="post">
  	<button>PC Annia ON</button>
	</form>

</center>
</HTML>

Variante avec un WebHook

L'ESP remonte sur Home Assistant via ESPHome. De fait on peu presser un bouton pour réveiller le PC distant, voire même intégrer ce bouton sur un autre Home Assistant en remote. Mais il est également possible de créer un WebHook et de déclencher avec un raccourcis depuis le PC de l'utilisateur distant :

- alias: Réveil PC Carole (WebHook)
  description: ""
  trigger:
    - platform: webhook
      webhook_id: "secret-id"
  condition: []
  action:
    - service: button.press
      data: {}
      target:
        entity_id: button.reveil_pc_carole
  mode: single

Et le raccourcis à créer sur le PC de l'utilisateur qui doit réveiller son PC de bureau...

curl -X POST https://ha-online.suptel.org/api/webhook/<secret-id>

Infos

  • Attention, Microsoft a introduit un concept de veille moderne qui souvent demandera à être désactivé. Des infos ici et .
  • Il n'est pas possible de réveiller un PC connecté en Wi-Fi ou en Ethernet via USB.
  • A noter que la Freebox dispose d'une option permettant de laisser passer du Wake on Lan. Ce n'est pas le cas pour tous les routeurs et il faut parfois ruser avec le port 9.

Sources

 

Home Assistant & BLE Proxy

J'entend souvent parler d'esp32, je ne suis pas un crack du fer à souder, ma vue baisse et je ne me lance généralement pas dans des montages au delà de mes compétences. De plus j'aime que ce que je déploie soit maintenable le plus facilement possible par des tiers. Je reste donc dans les standards, par exemple tous mes Shelly ont leur firmware d'origine, là ou ils seraient plus simples à gérer en ESP Home...

Ceci étant, j'aime aussi bricoler et j'avais un problème à résoudre. Si les petits capteurs de température Aqara en Zigbee sont parfaits, pas mal d'utilisateurs ont une préférence pour des sondes avec afficheur. Et le marché ne nous propose quasiment que des sondes afficheur en Bluetooth (BLE), Xiaomi, Aqara, Swithboot, Goovee ou encore InkBird... En général on peut facilement les gérer avec BLE Monitor et un bon dongle Bluetooth. Mais.

Depuis la version 2022.09 Bluetooth est géré nativement dans Home Assistant, il travaillent avec le développeur de BLE Monitor, une intégration qui devrait disparaitre à terme. Dans la pratique tout n'est pour l'instant pas reconnu mais les premiers résultats avec la version intégrée sont très honorables et j'ai obtenu des meilleurs résultats en BLE Proxy qu'avec des dongles USB ou du Bluthoot de base (NUC).

Pour autant se pose toujours le problème de la porté des sondes, dans notre cas d'usage BLE est uni directionnel et l'intégration se contente d'écouter, de décoder les trames et d'intégrer ce qui est exploitable. Sauf que s'il ne reçoit rien il n'intègre rien, et tout le monde sait que la portée du Bluetooth n'est pas phénoménale.

Lors de mes débuts avec HA j'avais essayé avec des potes des passerelles BLE, l'idée était de dédier des RPI Zero judicieusement placés à cet usage. Ca c'était soldé par un échec, certainement trop débutant que nous étions.

Mais avec la release 2022.09 une nouvelle option intégrée à HA a vu le jour : BLE Proxy

L'idée géniale est de se servir d'un module ESP configuré sous ESP Home et disposant du Bluetooth afin de capter les trames et les présenter à HA qui les décode. Et bien sur ce module sera judicieusement placé là ou on a besoin (cave, dépendance, aile gauche du château, etc...), pour peu que l'endroit dispose de Wi-Fi ou à minima d'Ethernet.

Le plus basic

La méthode la plus simple consiste à acheter un ESP-WROOM-32 (ici ou encore moins cher sur Ali), de le connecter au PC en USB après avoir installé les drivers et de le configurer à partir de cette page qui en fin de configuration vous proposera de l'intégrer à Home Assistant. 

Pour ceux qui jouent déjà avec l'add-on ESP Home il est aussi possible d'intégrer directement ce module et d'ajouter le code que vous trouverez ici et qui ressemble à ça :

esphome:
  name: "esp32-ble-proxy"
esp32:
  board: esp32dev
  framework:
    type: arduino
logger:
api:
  encryption:
    key: "AnUMyESfgsfgsdfhgjfjhhjkhg1WJLcGZHTiD7NoOEog="
ota:
  password: "3fb1ee84wgfsdhgsgh46sgh869d9a4856"
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "Ss Fallback Hotspot"
    password: "ws7qfgsfgh6Bl"
captive_portal:
web_server:
dashboard_import:
  package_import_url: github://esphome/bluetooth-proxies/esp32-generic.yaml@main
esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true
bluetooth_proxy:
button:
- platform: safe_mode
  name: Safe Mode Boot
  entity_category: diagnostic

Une fois que le module est intégré à Home Assistant celui ci décodera les trames et vous proposera les sondes qu'il reçoit. Il est également possible de les ajouter avec leur adresse MAC.

Le plus compact

L'Atom Lite me plait bien (détails ici). D'une part il n'est pas plus gros qu'une pièce de monnaie, et d'autre part il est livré dans un petit boitier plastique ce qui sera toujours plus élégant que le précédent. De plus on peut avec un coupleur USB-A / USB-C le brancher directement sur un chargeur, à défaut un câble court fera l'affaire. On trouve l'Atom Lite sur Ali ou sur le site de son fabricant.

La mise en œuvre est identique, et en bonus on peut piloter la led multicolore qui pourra éventuellement servir à notifier visuellement des états de ce que vous voulez via HA :

light:
  - platform: fastled_clockless
    chipset: WS2812B
    pin: 27
    num_leds: 1
    rgb_order: GRB
    id: status_led
    name: Stack Light
    effects:
      - random:
      - flicker:
      - addressable_rainbow:  

Et comme il expose des ports GPIO rien n'empêche, comme pour les autres de s'en servir pour faire autre chose. Je vous conseille d'ailleurs d'aller explorer l'univers M5STACK ou vous pourrez piocher des idées, comme ce lecteur RFID par exemple....

Le plus complet

L'Olimex (qui s'achète ici) est le plus complet car il dispose en plus du Wi-Fi d'un port Ethernet ce qui permettra de le placer là ou le Wi-Fi est absent. De plus il est disponible dans une version avec antenne externe pour une meilleure réception, ainsi qu'une version industrielle garantie de -40 + 85C. Le sports GPIO sont présents mais il faudra sortit le fer à souder...

Coté configuration c'est identiques au autres. On peut commence par configurer en USB en Wi-Fi et ensuite on active le port Ethernet en mettant à jour en Wi-Fi. Il semble déconseillé d'utiliser le port USB et le port Ethernet en même temps et on ne va pas jouer... Par contre je vous conseille de figer l'adresse affectée par la résa DHCP dans les deux cas car dans le cas contraire ESP Home a un peu de mal à le retrouver via son adresse en .local qui par définition changera.

# wifi:
#   ssid: !secret wifi_ssid
#   password: !secret wifi_password
#   ap:
#     ssid: "Esp-Test Fallback Hotspot"
#     password: "MHPdiJUnJ8i8"
#   use_address: 192.168.210.69
  
ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO17_OUT
  phy_addr: 0
  power_pin: GPIO12
  use_address: 192.168.210.108

Alternatives

Il existe d'autre options que je n'ai pas testé, comme le GL-Inet GL-S10, que je n'ai pas pu me procurer. Dans un petit boitier on a du Wi-FI, de l'Ethernet et une antenne externe pour $ 25.

Shelly

Les modules Plus de Shelly permetent également d'activer le mode proxy et ainsi jouer ce role. Donc si on a des Shelly+ ou des Prises commandées Plusg S+ on pourra se passer d'un ESP dédié. J'ai validé ça avec succès sur un apartement en duplex de 175 m² avec 2 Shelly+ 1PM.

Usages

En fait tout cela nous ouvre pas mal de portes. Imaginons que je veuille faire des relevés de température / humidité sur un site distant ou il n'y a pas de domotique. J'ai alors le choix d'un ESP du genre Atom Lite sur une prise USB qui va remonter les informations des sondes locale sou Bluetooth vers un site Home Assistant distant qui le verra dès lors que j'ai ouvert le port 6053. Mon ESP communiquera alors via l'API avec Home Assistant comme s'il était local et je pourrais le maintenir, changer sa config et le mettre à jour avec ESPHome. L'alternative consiste à monter MQTT et à le faire communiquer avec un brooker. Ca évite d'avoir un port à ouvrir, mais je ne pourrais plus le maintenir.

On peut échanger ici ou sur HACF.

Alternative

Si le mode proxy est intéressant pour couvrir une surface plus grande, il est également possible de déclarer les sondes BLE dans ESPHome et ainsi les voir remoter dans Home Asistant :

sensor:
  - platform: xiaomi_cgg1
    mac_address: "58:2D:34:10:F8:22"
    temperature:
      name: "Cuisine Temperature"
    humidity:
      name: "Cuisine Humidity"
    battery_level:
      name: "Cuisine Battery Level"    

  - platform: xiaomi_lywsd03mmc
    mac_address: "A4:C1:38:AB:59:F7"
    bindkey: "93f19252bcdfhfdqshdhb4f9957424"
    temperature:
      name: "Square Temperature"
    humidity:
      name: "Square Humidity"
    battery_level:
      name: "Square Battery Level"  

  - platform: xiaomi_lywsdcgq
    mac_address: "4C:65:A8:D1:DB:22"
    temperature:
      name: "Terrasse Temperature"
    humidity:
      name: "Terrasse Humidity"
    battery_level:
      name: "Terrasse Battery Level"

  - platform: xiaomi_lywsd02
    mac_address: "3F:59:C8:82:70:2A"
    temperature:
      name: "Hall Temperature"
    humidity:
      name: "Hall Humidity"
    battery_level:
      name: "Hall Battery Level"

EDIT 15/08/2023

Deux choses :

  • Un composant pour les sondes qui ne sont pas reconnues de base.
  • Un constat, beaucoup d'ESP en WIFI donnent des résultats parfois aléatoires. Dans tous mes tests les résultat le plus fiable et constant est celui obtenu avec un ESP Olimex en Ethernet (POE), et avec son antenne externe il couvre toute la maison, terrasse et jardin compris.
  • Eviter plus de 3 proxy (attention avec les Shelly qui jouent ce rôle).

Home Assistant & Entity Controler

Vous voilà content, vous pouvez allumer, gérer et éteindre votre ampoule via Home Assistant. Je suis sur que vous savez également faire ça via un bouton sans fil, par exemple via ControlerX etc... Mais on peut mieux faire et automatiser en détectant la présence dans une pièce avec quelques lignes et un capteur d'occupation genre Aqara ou Xiaomi... Et pour ça il y a plusieurs méthodes.

EDIT 25/10/2022 : Finalement le problème majeur de Entity Controler est que toute modification impose un redémarrage complet de Home Assistant. J'ai donc basculé sur AD-Automoli qui lui est sous AppDaemon, donc dynamique car les modifications sont prises en compte immédiatement. A considérer également Light Automation pour des éclairages  heures fixes.

L'option classique en YAML

- id: 'fab33b5b-b526-4f6c-a23f-ee98c300012c'
  alias: "PRESENCE : Eclairage Bureau"
  description: ''
  trigger:
    - platform: device
      type: occupied
      id: enter
      device_id: a65b2d5c507be85f0964131f26f8d31e
      entity_id: binary_sensor.motion_bureau_occupancy
      domain: binary_sensor
    - platform: device
      type: not_occupied
      id: leave
      device_id: a65b2d5c507be85f0964131f26f8d31e
      entity_id: binary_sensor.motion_bureau_occupancy
      domain: binary_sensor
  condition:
  action:
    - if:
      - condition: trigger
        id: enter
      then:
        - service: light.turn_on
          data:
            entity_id: light.shellydimmer_db2f18
    - if:
        - condition: trigger
          id: leave
      then:
        - service: light.turn_off
          data:
            entity_id: light.shellydimmer_db2f18

Alternatives

Pour les plus flémards on peu aussi faire ça avec des BluePrint's, ou même en NodeRed si on veut se compliquer la vie (je déteste mais ça vous le savez). Mais j'ai encore plus simple à vous proposer.

Entity Controler

EC pour les intimes. EC est un moteur qui va contrôler des entités (light, switch, scènes, etc...) en fonction d'informations binaires. Donc les sensor: d'entrée seront de détecteurs de présence ou de mouvement, des capteurs d'ouverture ou dans l'absolu n'importe quel binary_sensor: , et pourquoi pas ceux que vous aurez créé dans un usage détourné... A ce contrôle on va bien sur pouvoir appliquer diverses contraintes (horaires, nuit/jour) ou simplement dire que dès lors qu'une lampe s'est allumée automatiquement elle ne s'étendra que manuellement. C'est assez souple et adaptable à quasiment tous les besoins. En tous cas les miens.

Le Git est ici et la doc très complète .

Voici un exemple pour allumer une lampe pendant 180 secondes (durée par défaut) : 3 lignes

motion_light:
  sensor: binary_sensor.motion_sejour
  entity: light.shellydimmer_d3e57c

On peut bien sur régler la durée :

  delay: 320

Faire en sorte que ça ne s'allume que la nuit, avec ici un offset :

  start_time: sunset - 00:30:00
  end_time: sunrise + 00:30:00

Et appliquer des valeurs à la lampe :

  service_data:
    brightness: 255
    color_name: blue
  service_data_on: 
    transition: 5
  service_data_off: 
    transition: 10

Faire en sorte que ça ne s'éteigne pas !

  stay_mode: on

Ou applique une contrainte externe. Ici j'ai mis un input_boolean: mais ça aurait pu être l'état d'une autre lampe, voire un media_player:. A noter que l'on peu également se servir des overrides pour simplement désactiver le contrôle. J'ai par exemple un éclairage extérieur avec des projecteurs que je ne veux pas voir s'allumer quand on dine et que l'éclairage via la guirlande est amplement suffisant et plus agréable.

  overrides:
    - input_boolean.auto_motion_salon

Pareil quand on regarde un film il ne faut pas que l'éclairage se mette en route si on bouge sur le canapé. Pour ça j'ai déjà une automation qui fonctionne sur le play/pause et qui augmente lentement l'éclairage quand je fait pause et inversement (comme au cinéma). Pour l'instant ça ne fonctionne que sur Emby, il faut que je l'intègre à Android TV et EC., je métrais à jour ici quand je le ferait).

Conclusion

Un peu comme ControlerX, voilà de quoi simplifier la chose et gagner des lignes de code. A noter que sous AppDaemon il y Wasp in a Box qui est un peu moins complet ou AD-Automoli qui lui est trop complet...

On peut en discuter ici ou sur HACF.

Home Assistant & Cloudflare Zero Trust

Une fois de plus on va parler de VPN. J'avais ici évoqué Zerotier (gratuit pour 25 nodes) que j'utilise toujours notamment pour interconnecter plusieurs sites entre eux en remplacement d'IPSEC. Ca fonctionne très bien et ça se fait oublier. Entre temps on a découvert Wireguard qui est très performant et peut être utilisé en natif (faut faire le taff) ou via des intégrations comme Tailsacle (entre autres) dont la version gratuite sera suffisante pour bien des usages.

Aujourd'hui on va parler de Cloudflare Zero Trust. Au départ je voulais juste tester sous Home Assistant car cela permet de publier son Home Assistant sans ouvrir de ports sur le routeur, de la même façon que l'on peut le faire si l'on dispose d'un abonnement Nabu Casa. J'ai cet abonnement, mais je ne veux pas l'imposer aux utilisateurs que j'aide.

Si Zero Trust est basé sur Wireguard il n'a rien d'open source. Certains n'aimeront pas quelque chose qui passe par Cloudflare qui comme beaucoup d'acteurs du marché pratique la collecte de donnée. C'est le business de l'époque, d'autres font pire mais ce n'est pas le débat ici, alors épargnez moi vos digressions sur ce sujet, ce n'est pas l'objet. Si vous choisissez cette solution c'est en connaissance de cause. Il existe des alternatives, moins simples à mettre en œuvre.

Zero Trust est un VPN orienté client qui permet notamment deux approches :

  • Publier et sécuriser, sans ouvrir de ports, un (ou plusieurs) site hébergés en premise (premise = chez vous, dans votre entreprise) et le rendre accessible publiquement avec des restrictions qui assureront sa sécurité (MFA) et surtout des restrictions géographiques qui sont quasi impossibles avec les autres solutions, notamment à cause de Let'Encrypt.
  • Rendre accessible des réseaux privés (VPN) en passant par le client Warp de Cloudflare) et ainsi accéder à toutes les machines du réseau (RDP, SMB, SSH, etc...).

Ce qui fait la force de cette solution ce sont les policies qui permettent une très grande granularité. Cloudflare Zero Trust est gratuit jusqu'à 50 utilisateurs. Et dans l'absolu pour sécuriser Home Assistant on a même pas besoin du moindre utilisateur.

Home Assistant

Un Add-on est disponible ici et sa mise œuvre est 'une simplicité enfantine mais il y a une petite subtilité. En effet il y a deux façons pour gérer un tunnel :

  • En local et en CLI
  • Depuis le dashboard de Zero Trust

On part du principe que vous avez un compte Cloudflare et qu'un de vos domaines y est géré. Vous avez également activé Zero Trust. A faire avant toute chose.

Dans les deux cas on ajoute ou modifie le fichier de configuration de Home Assistant ainci :

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24

Option 1, gestion en local

On installe l'add-on sur Home Assistant, on choisit un host pour Home Assistant, ha.domaine.com par exemple et on lance l'add-on. Il suffit simplement ensuite d'aller copier dans le log l'url de validation et de la copier dans votre navigateur.

Et ça fonctionne, installation du certificat intermédiaire comprise. On pourra ensuite sécuriser et jouer avec les options, la doc de l'add-on est ici et cette  de Zero Trust . Si vous ne pensez pas utiliser Zero Trust pour autre chose c'est la solution la plus simple.

Option 2, gestion en remote

Vu que je compte utiliser Zero Trust à d'autres fin, c'est l'option que j'ai choisit.

  • Dans la console (Access/Tunnels) je crée un nouveau tunnel que ne configure pas.
  • Je copie le token que je viens reporter dans l'add-on et je lance l'add-on
  • Je vais dans le log et je copie l'url de validation que je colle dans le navigateur afin de finaliser l'installation et valider le certificat. 
  • Dans la gestion du tunnel je vais créer un Public Hots Name qui va correspondre à mon serveur et sera exposé avec le nom de domaine choisit :

Votre Home Assistant est maintenant accessible, ici https://test-ha.canaletto.fr (sans le port).

Aller plus loin...

En premier lieu je vous conseille de définir une policie dans Access/Applications afin que votre serveur ne soit accessible que depuis votre pays et surtout pas depuis des états plein de black hat's ...

Ensuite il faut savoir que vous avez installé sur votre serveur une passerelle VPN qui va vous permettre d'accéder à tout votre réseau local en passant par le client Warp. Pour cela il faut dans la configuration du tunnel déclarer un Private Network.

Ensuite dans les SettingsGeneral on va définir le nom de (Team) :

Dans Settings/Network on va changer le mode des tunnels. De base, dès lors que le client Warp est activé, Zero Trust va faire passer tout ce qui ne ressemble pas à une adresse privée dans ses tuyaux, c-a-d tout votre trafic, probablement à des fins de collecte de donnée... On va donc remplacer le mode Exclude par le mode Include et y déclarer uniquement notre réseau privé. Ainsi seul le trafic tunnelisé transitera par Cloudflare, et comme il est dans un tunnel ce sera théoriquement incognito. Je dis théoriquement car dans cette solution ce n'est pas vous mais Cloudflare qui a les clés... Mais nous sommes dans le cadre d'un service de classe entreprise et les CGU garantissent la confidentialité des données...

Dernier point, déclarer une méthode d'authentification. De base une authentification par code PIN est proposée, vous déclarez un domaine ou une adresse mail et vous revenez un code PIN à 6 chiffres qu'il suffit de rentrer... En option il est possible de configurer un SSO en utilisant une authentification que l'on exploite déjà (Azure AD, Centrify, Facebook, GitHub, Google Workspace, Google, LinkedIn, Okta, OneLogin, Saml, OpenID Connect, etc...). Plus complet, mais ça peut répondre à certains besoins en entreprise.

A partir de la on installe le client et on se connecte avec le nom que l'on a défini plus haut. On teste un RDP, SMB ou SSH sur une IP du réseau privé, et ça marche. Ca veut dire qu'à ce stade tout est ouvert dès lors que l'on a connecté le client, pourquoi pas dans le cadre d'une utilisation personnelle, mais je ne saurait trop vous conseiller de tout interdire et de n'autoriser que ce qui est utile (Gateway/Policies/Network).

Cet outil étant avant tout destiné à une utilisation en entreprise les possibilités sont immenses. Pour autant l'administration n'est pas très compliquée, avec quelques connaissance de base dans la gestion des réseaux.

Echanger

J'ai créé un sujet sur HACF, plus pratique qu'ici pour échanger.

 

Home Assistant & ECS

Mon chauffe eau électrique était géré par une automation datant de mes débuts sur Home Assistant. Ca fait le job mais je me disais que je pourrais améliorer la  chose afin de pouvoir ajuster plus facilement la plage horaire et les jours de chauffe. En effet faute d'avoir la température de l'eau (il faudrait y insérer une sonde, et comme je viens de le changer dans l'urgence je veux pas bricoler), bref, quand je suis seul dans la maison chauffer l'eau un jour sur deux est bien suffisant.

Bien sur je pourrait améliorer ça en me basant sur la présence ou non des enfants ou des invités. Mais parfois il faut savoir faire simple...

Interface

Je suis donc parti de l'interface car c'était le but premier. Pouvoir facilement et rapidement changer les heures et jours de chauffe. J'aurais pu me servir du Scheduller (moins pratique d'accès) ou de la nouvelle entité Agenda (pas encore aboutie). J'ai donc fait à ma sauce.

J'utilise quelques composants que vous allez retrouver dans le code de la carte :

type: vertical-stack
cards:
  - type: entities
    entities:
      - entities:
          - entity: automation.ecs_on
            name: false
          - entity: sensor.energy_total_yearly_1pm_ecs
            name: false
            unit: kWh
            format: precision2
          - entity: sensor.pm_ecs_power
            name: false
        entity: switch.pm_ecs
        name: ECS
        icon: mdi:waves
        show_state: false
        state_color: true
        type: custom:multiple-entity-row
  - type: horizontal-stack
    cards:
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_monday
        name: Lundi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_tuesday
        name: Mardi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_wednesday
        name: Mercredi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_thursday
        name: Jeudi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_friday
        name: Vendredi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_saturday
        name: Samedi
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
      - type: custom:button-card
        color_type: card
        entity: input_boolean.ecs_day_sunday
        name: Dimanche
        show_last_changed: false
        show_state: false
        tap_action:
          action: toggle
        state:
          - value: 'on'
            color: green
            icon: mdi:water-boiler
          - value: 'off'
            color: grey
            icon: mdi:water-boiler-off
        styles:
          card:
            - height: 60px
            - border-radius: 5px
            - font-size: 12px
  - type: conditional
    conditions:
      - entity: automation.ecs_on
        state: 'on'
    card:
      type: custom:vertical-stack-in-card
      cards:
        - type: horizontal-stack
          cards:
            - type: markdown
              content: '#### <center> Heure de début'
            - type: markdown
              content: '#### <center> Chauffe Eau'
            - type: markdown
              content: '#### <center> Heure de Fin'
        - type: horizontal-stack
          cards:
            - entity: input_datetime.ecs_start
              type: custom:time-picker-card
              name: Début
              layout:
                align_controls: center
                embedded: true
              hide:
                name: true
            - type: glance
              show_state: true
              show_name: false
              entities:
                - switch.pm_ecs
            - entity: input_datetime.ecs_stop
              type: custom:time-picker-card
              layout:
                align_controls: center
                embedded: true
              hide:
                name: true

Automation

Bien plus simple que la carte Lovelace. On se base sur des input_datetime:

input_datetime:
  ecs_start:
    has_date: false
    has_time: true
  ecs_stop:
    has_date: false
    has_time: true

Et des input_boolean:

input_boolean:
  ecs_day_monday:
    name: "ECS : Lundi"
    icon: mdi:toggle-switch
  ecs_day_tuesday:
    name: "ECS : Mardi"
    icon: mdi:toggle-switch
  ecs_day_wednesday:
    name: "ECS : Mercredi"
    icon: mdi:toggle-switch
  ecs_day_thursday:
    name: "ECS : Jeudi"
    icon: mdi:toggle-switch
  ecs_day_friday:
    name: "ECS : Vendredi"
    icon: mdi:toggle-switch
  ecs_day_saturday:
    name: "ECS : Samedi"
    icon: mdi:toggle-switch
  ecs_day_sunday:
    name: "ECS : Dimanche"
    icon: mdi:toggle-switch

Et ensuite deux automations, la première pour activer :

- id: '678d0e1-fcb6-4412-abvfr-99c4d37be5aa'
  alias: 'ECS ON'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.ecs_start.state[0:5] }}'
  condition:
    condition: or
    conditions:
      - '{{ (now().strftime("%a") == "Mon") and is_state("input_boolean.ecs_day_monday", "on") }}'
      - '{{ (now().strftime("%a") == "Tue") and is_state("input_boolean.ecs_day_tuesday", "on") }}'
      - '{{ (now().strftime("%a") == "Wed") and is_state("input_boolean.ecs_day_wednesday", "on") }}'
      - '{{ (now().strftime("%a") == "Thu") and is_state("input_boolean.ecs_day_thursday", "on") }}'
      - '{{ (now().strftime("%a") == "Fri") and is_state("input_boolean.ecs_day_friday", "on") }}'
      - '{{ (now().strftime("%a") == "Sat") and is_state("input_boolean.ecs_day_saturday", "on") }}'
      - '{{ (now().strftime("%a") == "Sun") and is_state("input_boolean.ecs_day_sunday", "on")}}'
  action:
  - service: switch.turn_on
    entity_id: switch.pm_ecs

Et une seconde pour désactiver :

- id: 'c69csdfsef-76dd-4fdd-9d20-40bfsdq158ae'
  alias: 'ECS OFF'
  trigger:
  - platform: template
    value_template: '{{ states.sensor.time.state == states.input_datetime.ecs_stop.state[0:5] }}'
  action:
  - service: switch.turn_off
    entity_id: switch.pm_ecs

Bonus

Pour suivre la période de chauffe on peut se servir du switch associé dans un history graph. Mais il y a plus malin à faire, en se basant sur la consommation, on va créer un binary afin de connaitre la période pour le chauffe eau chauffe réellement, et pas seulement la période ou il est on :

template:
  - binary_sensor:
      - name: "ECS Power On"
        delay_on:
          minutes: 1
        delay_off:
          minutes: 1
        state: >
          {{ states('sensor.legrand_contactor_power')|float > 0 }}

Et on aura une seconde ligne afin de savoir quand le chauffe eau était en chauffe.