Home Assistant, Zigbee, encore...

Alors, comment dire, dans la série jamais content, le Zigbee... Aujourd'hui ce protocole dispose d'une multitude d'approches plus ou moins simples à mette en œuvre, on résume :

  • Deconz / Phoscon : l'ancêtre toujours vaillant avec les clés Combee I et II ou le module RPI. Ca fonctionne, mais le développement est lent les nouveaux appareils tardent à êtres intégrés. De plus ça nécessite un addon et une intégration, le tout étant moyennement bien intégré. C'est ce qui assure la grande majorité de mes objets Zigbee depuis le début, d'abbord Sous Jeedom et ensuite sous Home Assistant.
  • ZHA (Zigbee Home Automation) : Totalement intégré à Home Assistant c'est la voie la plus simple qui supporte la majorité des clés du marché. Rien à redire, presque trop simple...
  • Zigbee2MQTT : La voie royale de geeks en tout genre, MQTT est à la mode, ce protocole est certes génial, mais franchement si vous débutez en domotique il est tout à fait possible de s'en passer en passant par ZHA.
  • Les passerelles des marques (Xiaomi, Ikea, Hue, etc...) : ça peut faire le job, mais ça restera lié aux équipement de la marque.
  • Les passerelles sous Tasmota, comme la Sonoof : pas testé, donc par essence ça me parait complexe et vaut mieux avoir un pote barbu habile du fer à souder. Idem pour la fameuse SLS dont certains ont du entendre parler.

Si la première des solutions (Deconz) fonctionne exclusivement avec la clé de la marque, ZHA et Zigbee2MQTT savent fonctionner avec toutes les clés disponibles. A commencer par la peu couteuse mais pas très performante cc2531. C'est pas cher et c'est une bonne option pour se faire la main, mais on se rendra rapidement compte que ça manque parfois de réactivité, une faiblesse qui ne sera pas gênante sur des sondes de température, mais qui le deviendra sur des interrupteurs, ou pire des variateurs. On va donc chercher à gagner du temps en explorant d'autres options.

Je vais explorer deux options en utilisant Zigbee2MQTT, mais j'aurais pu faire la même chose avec ZHA si j'avais voulut faire simple.

Clé USB à base de cc2652P

Si on commence à en trouver sur le net, il se trouve que j'ai un pote habile de ses mains qui sait souder et cherche à gagner sa vie en intégrant cette clé. Je lui ai donc acheté une des premières productions il il y a quelques semaines et je l'ai faite fonctionner sous Zigbee2MQTT en replacement de la cc2532.

J'ai un peu galéré sur la config à changer (pan_id) et surtout on passe en Zigbee 3.0 et le ré appairage des équipements est obligatoire, au final surtout fastidieux.

  serial:
  port: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
advanced:
  rtscts: false
  log_level: info
  pan_id: 231  ## Attention à ce point...

La réactivité est bien meilleure et dans l'absolu le nombre d'équipements supportés simultanément bien plus important

La passerelle Xiaomi V3

Là vous vous demandez ce que vient faire cette passerelle que je dénigras plus haut. En fait elle est là car je vais l'utiliser non pas en mode natif avec une liste de devices limitée, mais en remplacement de la clé USB avec Zigbee2MQTT (ou ZHA). La liaison se fait en WIFI, et je peux donc placer la passerelle ou je veut dans la maison. Et cerise sur le gâteau les devices BLE reconnus remontent nativement dans Home Assistant...

La mise en place est un peu plus compliquée car il y a plusieurs façon d'utiliser ça, mais je vais essayer de vous mâcher un peu le travail. D'abord il vous faut une Gateway Xiaomi v3 (ZNDMWG03LM (CN) ou ZNDMWG02LM (EU) et rien d'autre), on en trouve chez AliExpress (27 €) ou Amazon (35/40€), de plus ces temps ci il y en a pas mal en reconditionnées état neuf chez Amazon à 25 €, donc plus simple que d'attendre 3/4 semaines avec le risque que le tanker se mette en travers du canal de Suez...

Une fois que vous avez en main votre nouveau jouet, vous l'ajoutez à Mi Home sans faire les mise à jour proposées (serveur Chine, j'ai pas essayé en serveur Europe mais ça devrait fonctionner également, retour welcome). A partir de là il faut récupérer le token (Mi Home, ou ici par exemple.) et lui assigner une réservation DHCP pour ne pas la perdre.

Ensuite sous Home Assistant :

  • On installe cette intégration via HACS (si vous n'avez pas HACS ou ne savez pas ce dont il s'agit, repassez dans quelques semaines...).
  • On ajoute l'intégration Xiaomi Gateway 3 dans Home Assistant (choisir Host & Token) en renseignant le HOST et le TOKEN et sans toucher aux options Telnet. Si ça ne fonctionne pas c'est surement lié à la version du firmware, firmware qu'il est possible de downgrader via Telnet (et pour une fois sans rien à souder).

Je vous ai perdu ? Pas de panique, tout est expliqué dans le GitHub de l'intégration et Google Translate est notre ami !

Modes de fonctionnement

  1. Natif Mi Home : On remonte dans Home Assistant les devices associables à Mi Home en ZigBee ou BLE (modules Xiaomi, Aqara et quelques ampoules Ikea).
  2. ZHA : La passerelle devient le coordinateur de ZHA et on profite de tous les devices supportés par ZHA. Cette option n'est pour l'instant pas la plus stable.
  3. Zigbee2MQTT : La passerelle devient le coordinateur de Zigbee2MQTT et on profite de tous les devices supportés par cette option. C'est la voie que j'ai explorée.

En choisissant l'option 3 et en considérant que Zigbee2MQTT est bien installé avec son broker, il suffit de modifier la configuration de l'addon en remplaçant la clé USB par un port TCP :

serial:
  port: 'tcp://192.168.210.119:8888'
  adapter: ezsp

Et bien sur de refaire les associations... Et constater une excellente réactivité. Meilleure qu'avec la clé à base de cc2652P, il me semble mais ça reste vraiment très subjectif. En tous cas sans commune mesure comparé à une clé cc2531.

On fait ainsi d'une pierre deux coups avec du Zigbee déporté qui intéressera ceux qui font tourner Home Assistant dans une VM installée au fond du garage, mais aussi la remontée des capteurs BLE, ce qui permettra de faire le ménage dans les intégrations dédiées BLE, et dans mon cas me séparer de mon Home Assistant remote qui supportait les clés USB

Et si on fait l'impasse sur le BLE, je pense qu'une fois la passerelle configurée pour Zigbee2MQTT on peut même désinstaller l'intégration...

Cette solution basée sur du reverse engineering sera pérenne pour peu que vous ne fassiez pas les mises à jour depuis Mi Home, et pour ça il existe dans l'intégration une possibilité de blocage.

 

Home Assistant & Unifi Doorbell

Ca faisait un moment que je voulais moderniser la sonnette basic du portail par quelque chose de plus moderne. Il existe bien des solution élégantes de type Ring ou Nest, voire des chinoiseries plus ou moins attrayantes, mais l'inconvénient de toutes ces solutions c'est qu'elles passent par le cloud et que je trouve ridicule une telle dépendance, sans compter qu'il faut passer à la caisse...

En étant déjà équipé Unifi Protect j'ai donc attendu la disponibilité du système Dorbell G4 EU. Ce système fonctionne en WI-FI et la version EU est fournie avec un transformateur au format DIN pour l'alimenter en 24 volts. Donc entre le portail et la maison nous n'aurons besoin que d'une paire en BT et bien sur d'un signal WI-FI convenable.

Le problème est que ce système d'origine US est prévu pour fonctionner en 24 V. AC, le standard US pour ce genre d'équipement. Hors les sonnettes européennes fonctionnent soit en 220 V AC soit en 8 V. AC. Je me suis donc mis dans un premier temps à la recherche d'un carillon fonctionnant avec la bonne tension comme expliqué ici, objet rare sous nos latitudes et avec des commentaires déplorables.

Et puis j'ai réfléchit un peu, le Doorbell G4 remonte dans Home Assistant et j'ai des enceintes connectées dans toutes les pièces, on devrait donc pouvoir se passer d'une antique sonnette...

Après quelques tentatives j'ai utilisé un BluePrint existant (et perfectible) qui va me permettre de notifier avec un message vocal (TTS) une enceinte Google et d'envoyer une notification sur mon mobile avec la photo de la personne qui sonne, ce qui dans la pratique est bien plus efficace que l'application Unifi qui se contente de notifier mais qui ensuite est longue à afficher l'image. De plus si j'avais un portail électrique je pourrais me servir d'une action sur la notification pour l'ouvrir à distance depuis Home Assistant.

Mais tout ça ne sera pas suffisant pour me sortir du lit quant un livreur sonne tôt. Il me faut donc aller plus loin et faire sonner plusieurs enceintes Sonos. Le problème étant que si vous envoyez simplement un son à une enceinte Sonos, ça va certes le jouer au volume en cours, mais également casser l'état et le groupage des enceintes ainsi que le programme courant. J'ai donc créé une automation en parallèle qui va :

  • Sauvegarder l'état courant du système Sonos
  • Ajuster le volume des enceintes choisies
  • Grouper les enceintes choisie pour cette notification
  • Jouer le mp3 de la sonnerie (large choix ici).
  • Restaurer l'état précédent...
- alias: "RC : Dorbell sound"
  trigger:
    - platform: state
      entity_id: binary_sensor.doorbell_g4_doorbell
      from: 'off'
      to: 'on'
  condition: []
  action:
  - data: {}
    entity_id: all
    service: sonos.snapshot
  - data:
      volume_level: 0.5
    entity_id: media_player.sonos_hall, media_player.sonos_cuisine
    service: media_player.volume_set
  - data:
      master: media_player.sonos_hall
    entity_id: media_player.sonos_hall, media_player.sonos_cuisine
    service: sonos.join
  - data:
      media_content_id: https://home-assistant.canaletto.local:8123/local/chime.mp3 # ou IP de HA
      media_content_type: music
    entity_id: media_player.sonos_hall
    service: media_player.play_media
  - delay: 00:00:05
  - data: {}
    entity_id: all
    service: sonos.restore

Voilà, tout ceci reste perfectible, mais comme on dit, ça fait le job et il me reste à fixer l'objet !

A noter que cet appareil comporte également un détecteur de présence qui pourra ainsi permettre de signaler une présence (facteur ?), et que ce détecteur peut également allumer un led sous l'appareil. Le problème étant qu'il sera fixé dans la rue à la portée du premier vandale venu...

 

Cloud Drives et sécurité

Au fil du temps nous avons pris l'habitude d'utiliser des Cloud Drives. S'ils ont tous été comparés et décortiqués il reste des aspects souvent laissés de coté. La vraie menace aujourd'hui n'est pas tant de perdre ses fichiers mais plutôt de se les faire chiffrer à ses dépends, et dans ces cas comment les récupérer, et surtout les récupérer rapidement.

La majorité des ces offres permettent la synchronisation sélective (ne synchroniser que ce qui est utile) et surtout le travail en ligne avec des web apps. L'avantage de travailler ainsi est qu'aucun crypto virus ne pourra venir vous chatouiller.

Je ne vais pas faire le tour de toutes les offres mais me concentrer sur celles que je connais bien et me pencher sur les environnements Windows et MacOS.

Microsoft OneDrive

Depuis SkyDrive cette offre a beaucoup évoluée. Il existe en fait deux offres, l'une grand public (qui fait partie de l'offre Outlook grand public) et l'autre à destination des professionnels et des entreprises (qui fait partie de l'offre tentaculaire Microsoft 365, et n'est pas achetable à part). Techniquement l'usine qui est derrière est différente, mais dans sa manie habituelle Microsoft les appelle du même nom, et cette pratique confuse n'est pas nouvelle. 

Dans la pratique les deux offres proposent un historique des versions de tous les documents, on peu donc considérer que si un document est vérolé par un crypto virus, il sera toujours possible de restaurer la version précédente. Cette opération peut bien sur être fastidieuse, et là ou Microsoft va plus loin c'est qu'il offre la possibilité de restaurer l'ensemble des fichiers à une date donnée. Ainsi il sera possible de restaurer rapidement tout le contenu. C'est un vrai plus.

Pour la version Entreprise le client permet également de synchroniser localement des librairies de groupe, par ailleurs accessibles via Teams. Et dans ce cas il est également possible de faire une restauration complète à une date donnée.

Google Drive

Chez Google il existe également deux offres. La première pour tout le monde (Google One) et la seconde à destination des professionnels et des entreprises (Google WorkSpace). Le client Sauvegarde et Synchronisation est utilisable sur les deux offres, il permet entre autre de synchroniser localement son drive, mais également de sauvegarder en continu des répertoires de l'ordinateur. C'est ainsi que ma fille, traumatisée par la perte d'une partie de ses cours sur OneDrive Business (sous Mac) les sauvegarde sur Google Drive... Une autre application réservée aux entreprise permet d'utiliser son drive comme un disque supplémentaire. Dans l'offre professionnelle il est également possible de créer des drives partagés qui pourront être accessible aux utilisateurs de la solution gratuite.

A ma connaissance il n'existe pas d'option permettant de restaurer l'ensemble des documents à une date donnée sur l'offre grand public. Par contre l'historisation des fichiers fonctionne sur les deux offres.

Attention : les des offres Google Drive sont en pleine mutation des de nouvelles fonctionnalités sont prévue pour fin avril début mai.

Infomaniak KDrive

Cette offre suisse est à considérer pleinement car full RGPD, US Cloud Act free et avec la garantie que vos données ne seront jamais exploitées. Plus jeune et encore perfectible elle propose comme les autres une offre gratuite et une offre payante plus complète. Une historisation plus ou moins évoluée est au rendez vous mais sans possibilité d'une restauration globale.

A noter que sur les offres de groupe il n'est pas possible à l'administrateur d'accéder aux drives des autres utilisateurs et ainsi les sauvegarder. Donc ok dans un groupe d'indépendants ou la confidentialité de chacun est assurée, mais pas en entreprise.

Un des gros plus de KDrive est toutefois d'être full compatible WebDav, donc accessible sans client et par un Synologie pour par exemple une sauvegarde... (One drive également, mais il faut passer par Internet Explorer, c'est fastidieux, antique et plutôt décourageant...).

Le produit est plus jeune mais vraiment prometteur.

Dropbox

Ca existe encore ? Oui bien sur, mais il y a longtemps que je n'ai pas testé.

Box

Idem

Ice Drive

Un petit nouveau prometteur que je suis en train de tester.

Synology Drive et autres...

Un simple NAS, si possible hébergé, peut constituer une possibilité de cloud drive full privé. Ca fonctionne très bien. Il existe d'autres offres dans ce genre, NextCloud par exemple, mais ce n'est pas l'objet de la réflexion d'aujourd'hui.

Apple Cloud

Un autre monde.

Sauvegarder son / ses cloud drives

Comme on l'a vu tous ces cloud drives offrent des garanties de moyens pour assurer la sécurité de vos données. Mais aucune de ces solutions n'est infaillible et en cas de désastre (un crypto par exemple) la restauration risque d'être fastidieuse. Donc s'agissant de données critiques ou d'utilisateurs exigeants il va falloir s'assurer coté IT d'outils de restauration rapides et faciles à mettre en œuvre. Il en existe une multitude, Par exemple Veeam propose une solution qui nécessite un serveur Windows pour l'exploiter, une autre alternative consiste à utiliser un NAS Synologie et Active Backup pour Office 365 ou GSuite. Ce NAS peut être dans l'entreprise, ou par exemple loué chez Infomaniak qui le propose et ou les débits seront en adéquation avec cet usage. Une sorte d'assurance anti stress pour le responsable IT.

Clients alternatifs

Toutes ces offres proposent leur client propriétaire. Avec le temps ces clients fonctionnent plutôt bien, même s'il reste des lacunes. Que dire de OneDrive toujours en 32 bits là ou Microsoft prône du 64 bits ? Que dire du client Mac OneDrive qui fonctionne enfin (je touche du bois) après des années pour le moins catastrophiques ?

Bref, si on a un usage particulier, ou si on utilise plusieurs services en parallèle, il est tout à fait possible de passer par des clients alternatifs comme MountainDuck (Mac et Windows) ou RaiDrive (Windows). Ce n'est pas un conseil, mais une alternative possible. Il en existe d'autres bien sur, et les plus barbus s'orienteront naturellement vers RClone.

 

Home Assistant & Planification, Schedy, la suite !

Encore, allez vous me dire ! Oui car d'une part mon dernier article sur Schedy était un peu fouillis, et surtout en relisant les réponses de son auteur à ceux qui tentent de créer une interface, je me suis aperçu que l'approche que j'avais, qui consistait à faire passer à Schedy des plages horaires, n'était pas la plus simple ni la plus adaptée. D'une part il faut transformer des input_time en sensor ou en input_number (les deux seules possibilité pour transmettre à Schedy un horaire de début et de fin de plage sous la forme du nombre de minutes écoulées depuis minuit). C'est lié à son fonctionnement interne, ce n'est pas très pratique. Son auteur n'a pas le temps de faire évoluer, et surtout c'est un barbu qui déteste les interfaces graphiques...

J'ai donc opté pour une autre approche plus simple et plus concise qui va consister à se servir des input_datetime: de début et de fin de plage pour actionner un binary_sensor: qui passera à ON si on se trouve dans la plage.

A partir de là dans Schedy, on change la température de consigne (input_number:) de la la plage, si la plage est activée (input_boolean:) et la période active (binary_sensor:).

Et bien sur on le fait en fonction des contraintes que l'on s'impose en fonction de la situation de chacun (jour de travail, demie journée de travail, week-end ou télétravail), et tout ça pour chacune des pièces que l'on gère auxquelles correspond un thermostat (climate:) ou un groupe de thermostats.

De cette façon on continue à faire une gestion horaire qui correspondra à la majorité des usages, mais avec ce "mode" binaire on peut très bien imaginer une gestion à base de géolocalisation. Par exemple, en été, si un des membres du logement travaille à une distance de 20 Km, on peut imaginer mettre en route la climatisation s'il se rapproche à moins de 10 Km... Le chauffage (convecteurs + climatiseur) ne se gérant pas comme la climatisation (climatiseur seul) j'y reviendrait prochainement.

Le script

Pour plus de facilité on va utiliser un script afin de créer l'ensemble des entités nécessaires. Dans ce script on crée les entités nécessaires à chaque pièce et le nombre de plages que l'on veut gérer chaque jour que l'on multiplie avec le nombre de jours particuliers à gérer ( jours de semaine, le samedi qui est travaillé le matin et les dimanches et fériés par exemple). 

Pour chaque plage on crée (à chaque plage correspond un fichier qui est stocké dans les pakages) :

  • Deux input_datetime: pour le début et la fin de chaque plage,
  • Un binary_sensor: pour savoir si on est dans la plage,
  • Un input_number: pour définir la température de consigne de la plage,
  • Un input_boolean: pour activer ou désactiver la plage.

On va également créer un fichier heating_global.yaml qui va contenir :

  • Un binary_sensor: s'appuyant sur workday: pour savoir si on est un samedi travaillé,
  • Deux input_number: pour définir la température de consigne pour les plages inactives (deux ou trois car ce n'est pas pareil pour une chambre vide ou un climatiseur),
  • Deux input_boolean: un premier pour activer un mode télétravail, et un autre pour activer / désactiver le bazard.

On pense à éditer les lignes 39 pour définir les pièces et 41 pour le nombre de plages par pièces. On est pas obligé de faite tout d'un coup bien sur (et je vous conseille de commencer light).

/bin/bash
test -d /config/packages || mkdir /config/packages
cd /config/packages
cat >heating_global.yaml<<EOF
input_boolean:
  heating_enabled:
    name: Heating Global
    icon: mdi:toggle-switch
  homeoffice:
    name: Home Office
    icon: mdi:toggle-switch
input_number:
  off_temperature:
    name: Off Température
    min: 14
    max: 26
    step: 1.0
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
  off_temperature_ac:
    name: Off Température
    min: 14
    max: 26
    step: 1.0
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
binary_sensor:
  - platform: template
    sensors:
      workday_saturday_working:
        friendly_name: "Samedi travaillé"
        value_template: >
          {% if now().isoweekday() in (5,) and states.binary_sensor.workday_sensor.state == 'on' %}
            true
          {%else%}
            false
          {% endif %}
EOF
for room in hall_ac
do
for period in {1..12}
do
cat >${room}_heating_period_${period}.yaml<<EOF
input_datetime:
  ${room}_heating_period_${period}_start:
    name: "Heating Period ${period} Start Time"
    has_date: false
    has_time: true
  ${room}_heating_period_${period}_end:
    name: "Heating Period ${period} End Time"
    has_date: false
    has_time: true
binary_sensor:
  - platform: template
    sensors:
      ${room}_slot_${period}:
        entity_id: sensor.time
        friendly_name: ${room}_Slot ${period}
        value_template: >
          {% set t = states('sensor.time') %}
          {% set start = states('input_datetime.${room}_heating_period_${period}_start') [0:5] %}
          {% set stop = states('input_datetime.${room}_heating_period_${period}_end') [0:5] %}
          {{ start <= t < stop if start < stop else (start <= t or t < stop) }}
input_number:
  ${room}_heating_period_${period}_temperature:
    name: Heating Period ${period} Temperature
    min: 18
    max: 25
    step: 1
    unit_of_measurement: °C
    icon: 'mdi:thermometer-lines'
input_boolean:
  ${room}_heating_period_${period}:
    name: Heating Period ${period} Enabled
    icon: mdi:toggle-switch
EOF
done
done
exit

On teste la configuration (check configuration) et on recharge ce qui est nécessaire (reload input booleans, reload input date times, reload input numbers, reload templates entities).

Les cartes Lovelace

Ici on a deux approches possibles. Un mode normal ou un mode compact. J'ai déjà évoqué le mode normal, mais quand on 12 plages par pièces on va essayer de compacter la chose. C'est un peu plus fastidieux pour saisir les valeurs, mais en général on ne change pas ces valeurs tous les jours.

type: entities
entities:
  - entity: input_boolean.heating_enabled
    name: Activation AC mode chauffage
  - entity: binary_sensor.heating_enabled
    name: Etat global du chauffage
  - entity: binary_sensor.workday_sensor
    name: Jour de semaine
  - entity: binary_sensor.workday_saturday_working
  - entity: input_boolean.homeoffice
  - entity: input_number.off_temperature
  - entity: schedy_room.schedy_heating_hall_ac
    name: Retour Schedy AC
  - label: SEMAINE
    type: section
  - entities:
      - entity: binary_sensor.hall_ac_slot_1
        name: false
      - entity: input_number.hall_ac_heating_period_1_temperature
        name: false
        unit: °
        format: precision1
      - entity: input_datetime.hall_ac_heating_period_1_start
        name: false
        format: relative
      - entity: input_datetime.hall_ac_heating_period_1_end
        name: false
    entity: input_boolean.hall_ac_heating_period_1
    name: Plage 1
    show_state: false
    toggle: false
    icon: 'mdi:calendar-range'
    type: 'custom:multiple-entity-row'
    state_color: true
# >>> Ici les autres avec un séparateur...
show_header_toggle: false
state_color: true
theme: teal
title: Schedy AC
footer:
  type: graph
  entity: sensor.daikin_inside_temperature
  hours_to_show: 24

Et voici le résultat...

Schedy

S'agissant de la configuration de Schedy il a bien sur fallut l'adapter. Vous dire que j'ai tout compris serait un mensonge et il y a certainement moyen de simplifier, et je suis preneur d'idées. Voici donc ce que ça donne (j'ai volontairement laissé quelques commentaires).

schedy_heating:
  module: hass_apps_loader
  class: SchedyApp

  actor_type: thermostat
  actor_templates:
    default:
      send_retry_interval: 15
      send_retries: 20
      supports_hvac_modes: true
      off_temp: 17
  
  watched_entities:
  - input_boolean.homeoffice
  - binary_sensor.workday_sensor
  - binary_sensor.workday_saturday_working
  - input_boolean.heating_enabled

  schedule_prepend:
  - x: "14 if is_off('input_boolean.heating_enabled') else Next()" # Le HorsGel... Possible aussi de créer un input_number...
  
  rooms:
    hall_ac:
      allow_manual_changes: true  # On autorise le changement manuel de consigne ou le passage en off
      rescheduling_delay: 90      # Délais après lequel Schedy repassera sur les valeurs prédéfinies
      actors:
        climate.thermostat_x:
          template: default
      watched_entities:
      # COMMON
      - input_boolean.homeoffice
      - binary_sensor.workday_sensor
      - binary_sensor.workday_saturday_working
      - input_number.off_temperature
      # ROOM SPECIFIC
      - input_number.hall_ac_heating_period_1_temperature
      - input_boolean.hall_ac_heating_period_1
      - binary_sensor.hall_ac_slot_1
      - input_number.hall_ac_heating_period_2_temperature
      - input_boolean.hall_ac_heating_period_2
      - binary_sensor.hall_ac_slot_2
      - input_number.hall_ac_heating_period_3_temperature
      - input_boolean.hall_ac_heating_period_3
      - binary_sensor.hall_ac_slot_3
      - input_number.hall_ac_heating_period_4_temperature
      - input_boolean.hall_ac_heating_period_4
      - binary_sensor.hall_ac_slot_4
      schedule:
      - rules:
        # WORKDAY
        - rules:
          - x: "Next() if is_on('binary_sensor.workday_sensor') else Break()"
          - x: >
              state("input_number.hall_ac_heating_period_1_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_1") and (is_on("binary_sensor.hall_ac_slot_1")))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_2_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_2") and (is_on("binary_sensor.hall_ac_slot_2")))
              else Next()
          - x: >
              state("input_number.hall_ac_heating_period_3_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_3") and (is_on("binary_sensor.hall_ac_slot_3")))
              else Next()
          - x: "Break(2)"
        # WEEK-END
        - rules:
          - x: "Next() if is_off('binary_sensor.workday_sensor') else Break()"        
          - x: >
              state("input_number.hall_ac_heating_period_4_temperature")
              if (is_on("input_boolean.hall_ac_heating_period_4") and (is_on("binary_sensor.hall_ac_slot_4")))
              else Next()
          - x: "Break(2)"

      # - v: 13 # On remplace par un input_number >>> Attention : v = valeur, x = expression
      - x: state("input_number.off_temperature") # Consigne entre les plages

A suivre...

Il existe dans Schedy un système d'events qui vont permettre de créer des dérogations ponctuelles. Par exemple un bouton ou une commande vocale quand je vais aller prendre une douche qui va lancer une dérogation pour augmenter sensiblement la température de la salle de bain pendant un temps défini ou jusqu'à ce qu'on lui envoie un contre ordre. On peu aussi imaginer chauffer une chambre d'amis lorsqu'on reçoit ou le boudoir lors d'une galante visite (encore que ces temps-ci la fonction ne servirait pas à grand chose...).

Et bien sur la gestion des ouvertures est gérée pour couper le chauffage... Plus tard...

Pour en finir...

Dans cet usage Schedy n'est plus vraiment le planificateur mais un moteur qui va surveiller (re planification) les thermostats et leur donner les bons ordres en fonction des évènements, états  et ordres venus de Home Assistant. Si Schedy peut également gérer des lampes (light:) et des actionneurs (switch:) c'est sans internet, sauf peut être pour superviser la machinerie d'une piscine...

 

Sauvegardes & Stockage Cloud

Il aura suffit d'un incendie ravageant un des data centers d'OVH pour que tous les IT de France dorment mal et que s'engagent de longues discutions de comptoir sur ce sujet. Il y a aussi les vautours opportunistes qui en profitent pour proposer leurs alternatives. Je ne vais pas ici vous expliquer si OVH est en faute, à mal fait ou bien fait son travail d'hébergeur, je n'en ai ni les moyens ni toutes les compétences. Je suis juste content de ne rien avoir chez eux et je compatis avec mes collègues qui sont dans la panade. Je vais donc juste vous parler de ce que je connais, sachant qu'il existera toujours un delta entre les meilleures pratiques et ce que l'ont peut s'offrir, techniquement et financièrement.

Il n'en reste pas moins qu'en matière de sauvegarde il y a des règles. La première veut qu'on dispose d'au moins 3 copies, les logiciels modernes le font très bien, ensuite que ces copies soient sur plusieurs support (NAS, Bandes), et surtout que l'on dispose d'au moins une copie externalisée. La fameuse sauvegarde de la sauvegarde.

Que veux t'on sauvegarder ?

PC isolé :

Premier conseil, on mets tous les documents dans un cloud drive (Google, Dropbox, Onedrive, KDrive) et on le configure pour qu'il sauvegarde le bureau et les documents. On peut aussi faire ça avec son cloud privé à base de Synology Drive ou autres logiciels de cloud privé comme NextCloud, enfin, quand on maitrise...

Mais on peut également vouloir sauvegarder ailleurs : Il existe une multitude logiciels qui vont savoir faire des sauvegardes incrémentales chez un fournisseur. On peut également vouloir faire une sauvegarde de type image, c-a-d un clone de sa machine. Dans ce cas le plus simple est d'utiliser Veeam Agent (gratuit) et de sauvegarder sur un disque externe, un second disque interne sur un desktop ou un NAS sur le réseau. Possible également de le faire vers OneDrive. Avantage, historisation et restauration intégrale en cas de besoin (ne pas oublier de créer la clé USB de boot....).

Site web

Un site web hébergé est généralement composé de fichiers et parfois d'une base de donnée (Wordpress par exemple). Les offres sont très disparates et on sauvegarde généralement les pages en FTP ou via des options proposées. Le FTP est universel et le minimum à faire lors de chaque mise à jour. S'il y a DB (WP par exemple) le process de sa sauvegarde est intégré dans une copie en FTP. Tout cela est un peu archaïque et il faut trouver un moyen pour l'automatiser ou s'imposer une véritable discipline...

VPS

Un VPS (Virtual Private Server) est rarement sauvegardé par l'hébergeur. Donc selon l'O/S c'est à vous de le prévoir et cela dépendra de ce que vous voulez sauvegarder (RClone, FTP).

Serveur dédié

Que votre dédié soir chez un hébergeur ou dans votre bureau, c'est pareil. C'est à vous de gérer les sauvegardes en fonction de sa criticité. Et si hyperviseur, voir plus loin.

Instance cloud managée

Managée veut dire que la notion de sauvegarde est intégrée. En général plusieurs options sont proposées et le tarif varie en conséquence. De base le fournisseur doit garantir la disponibilité. Il faut lire les contrats. On ne parle pas vraiment de sauvegardes mais de disponibilité, pour résumer si le data center brule, l'instance doit toujours être disponible car elle est censée être répliquée sur un autre site géographique. Enfin, c'est ce qui se passe chez Azure, AWS, etc... et l'expérience à démontrée que chez d'autres ça peut être plus hasardeux. Donc dans tous les cas, mettre en place une sauvegarde de secours pour les datas (base SQL par exemple) chez un fournisseur tiers n'est pas forcément un luxe !

NAS

Un NAS sert souvent des destination de sauvegardes, mais également pour partager des fichiers. Donc si la maison brule il n'y a plus rien. Il faut donc externaliser une sauvegarde à l'aide des logiciels fournis (HyperBackup sur Synology par exemple) qui fonctionne avec tous les fournisseurs de stockage. Et ne pas confondre synchronisation (CloudSync) ou on réplique des données même si elles sont vérolées, et sauvegarde (HyperBackup) ou on historise des sauvegardes. Synology propose C2 qui est également une bonne alternative intégrée.

VM et Hyperviseurs

Ici on creuse dans le dur et en général il y a un IT qui sait faire son boulot. S'il est possible de pratiquer des sauvegardes au niveau VM comme sur un serveur physique, la sauvegarde s'effectue en général au niveau de l'hyperviseur avec des outils tels que Veeam Backup&Recovery (il y a de la concurrence et même des produits gratuits). Idéalement on sauvegarde sur un stockage local (un gros NAS par exemple) et en parallèle on externalise vers un fournisseur de stockage externe. Bien sur la taille de l'infrastructure est un facteur décisionnel. Et pour des données critiques rien n'empêche de mettre en place une sauvegarde spécifique à l'intérieur des VM.

A ce stade on pense également PRA. En effet rien ne sert de sauvegarder si on ne dispose pas de quoi restaurer après une catastrophe... Mais c'est un autre sujet.

Fournisseurs de stockage

Un bon principe consiste comme souvent à ne pas mettre tous ses œufs dans le même panier.

Le choix de l'hébergeur est fait en fonction de la criticité de ce que l'on héberge et des moyens dont on dispose. Pour un résultat apparemment identique les tarifs peuvent s'étaler de 1 à 10, voire plus. Donc si vous êtes une entreprise riche et peu regardante sur sur le CloudAct et autres RGPD, visez Azure ou AWS, ce sont les meilleurs. Dans le cas contraire faites attention ou vous mettez vos datas et lisez bien les contrats. Une fois bien que vous aurez choisit votre fournisseur il faudra penser à une solution de stockage indépendante pour la fameuse seconde sauvegarde. Et attention à ne pas utiliser pour cette seconde sauvegarde une solution qui serait hébergée chez ce même fournisseur mais dans une offre concurrente. En gros savoir ou sera physiquement hébergée la sauvegarde de secours.

Pour le stockage et l'hébergement il faut également prendre n compte le niveau de certification du data center (Tiers 3/4, etc...).

Une sauvegarde externe c'est aussi la disponibilité d'un protocole qui sera utilisé par les logiciels de sauvegarde. Il vaut mieux éviter les protocoles exotiques ne fonctionnant qu'avec tel ou tel logiciel.

  • FTP : un peu old school mais adapté et utilisé sur les petits sites. Peu performant et peu adapté aux gros volumes.
  • SMB et NFS : pourquoi pas, mais je déconseille sur internet. Et SMB 1 on oublie, même en local, c'est une passoire que les marchands de copieurs forcent à réactiver.
  • S3 : Créé par Amazon AWS c'est un standard supporté par de nombreux logiciels, Veeam par exemple.
  • Swift : Alternative plus ouverte que l'on peut comparer à S3.

Je ne vais pas ici faire le tour de tous les fournisseurs de stockage, mais uniquement de ceux que j'ai testés.

  • Azure Backup : couteux et compliqué. Pas adapté aux TPE, à considérer dans un environnement d'entreprise structurée. A noter que s'il est possible de sauvegarder facilement un NAS Synology vers de l'Azure Backup, vous ne connaitrez pas à l'avance le montant de la facture...
  • AWS S3 : idem
  • OneDrive : utilisable avec Veeam Agent (tuto ici) pour sauvegarder des images de PC. On peut également s'en servir avec RClone si on a un barbu dans ses potes.
  • Google Drive : Synology et tout ce qui est à base de RClone : Ca peut être intéressant coté tarification dans un cadre GSuite. Débits très rapides.
  • Wasabi : véritable alternative à AWS S3, ce fournisseur ne fait que du stockage et il le fait bien, et à des tarifs très concurrentiels (5 € / mois / TB sans frais de transfert). Localisation des DC aux Etats Unis, Japon et Europe à Amsterdam. Protocole S3 exclusivement, avec un accès admin de secours en FTP. Je m'en sert depuis quelques années.
  • Scaleway : je vais éviter car j'héberge mes serveurs chez eux. Leur offre Object Storage est moins couteuse que les GAFAM mais plus que Wasabi par exemple. Par contre leur offre C14 (Cold) est certainement la plus intéressante du marché pour de l'archivage. Mais c'est un autre sujet : sauvegarde = usage à la demande, archivage = conservation légale et usage différé.
  • OVH : Swift et depuis peu S3. Tarifs abordables. Mais bon, OVH ces temps ci ça fait un peu peur...
  • Swiss Backup : Infomaniak est un des plus gros hébergeurs suisses, non content de proposer une véritable alternative GAFAM, ils offrent une solution de sauvegarde très complète (5 € / TB avec une tarification dégressive). Support S3, Swift et FTP, mais également ne offre Acronis pour les PC et Macs ainsi que le support des mobiles avec la possibilité de partager un même compte entre divers usages en affectant des quotas... Et puis la Suisse c'est rassurant !

Sauvegarder est une chose, mais il est important de pouvoir accéder à ses sauvegardes en tous temps et et parfois autrement qu'avec le logiciel qui a servi à les faire. Ces logiciels utilisent en général un format propriétaire, de plus quand on sauvegarde chez un tiers on prend soin de chiffrer les sauvegardes un minimum.

En cas d'un crash, et le temps que l'infrastructure soit remontée / rétablie, on peu avoir besoin de façon urgente de certains fichiers. Dans tous les cas attention à bien disposer des mots de passe et autres certificats ayant servi au chiffrage.

  • Pour les sauvegardes en clair (FTP, RClone, etc...) c'est simple et il suffit d'aller chercher le fichier.
  • Veeam Backup&Recovery et ses clones : il faudra disposer du logiciel dans une version identique. Environnement d'entreprise, donc le même logiciel installé dans un PRA en attente. Au pire monter le logiciel rapidement sur une machine de secours.
  • Synology HyperBackup : Facile en C2 en web. Si on ne dispose pas d'un NAS de rechange, HyperBackup Explorer sur un PC il faudra pouvoir accéder à la sauvegarde. Deux solutions, un montage CloudDrive sur du S3 ou Swift, fonctionnel avec Wasabi et Scaleway, mais pas avec Swiss Backup pour l'instant (ticket ouvert). Alternative : télécharger la sauvegarde avec CyberDuck (Swift) ou S3 Explorer de CloudBerry (S3) afin de pouvoir l'explorer en local.

Voilà pour ce petit tour d'horizon. N'hésitez pas à partager vos expériences, je mettrais à jour cet article.

 

Home Assistant & Coupures secteur

Ceux qui habitent à la campagne le savent, le réseau ERDF/Enedis est dans un état suffisamment lamentable pour que la moindre intempérie provoque des coupures électriques. Par ailleurs il peut arriver que pour une raison ou une autre un différentiel saute. Et ces coupures on un impact sur toute installation domotique, si sur certains appareils on peut gérer le comportement lors de la reprise électrique (Shelly par exemple) ce n'est pas le cas de beaucoup d'ampoules ou de prises commandées (Tuya pour le mauvais élève), il faudra donc gérer ce que l'on fait lors de la reprise en domotique et / ou être avertit en cas d'absence afin de mandater quelqu'un pour réarmer le différentiel du congélateur...

Et pour ça il faut que Home Assistant soit très rapidement informé sur les points de coupure possibles afin par exemple de sauvegarder et restaurer un état comme j'en avait parlé ici. Chez moi je dénombre 4 point de coupures. Le disjoncteur général + 4 disjoncteurs différentiels (1 par étage de mon tableau électrique).

Il me fallait donc un système qui me permette de tester la non présence électrique sur ces 5 points de coupure. Pour y parvenir j'ai commandé une carte qui comporte 8 optocoupleurs (lien non sponsorisé) (ça existe en 1, 3 et 8 canaux) que je vais pouvoir exploiter en GPIO. Le principe est simple, si présence électrique en entrée le port passe à 1.

Au départ je comptais exploiter ça sur le Raspberry qui me sert en remote pour le Zigbee et BLE avec l'intégration GPIO idoine, mais ce n'était pas assez réactif, j'ai donc opté pour un ESP que j'avais sous la main, et c'est ainsi que j'ai mis le doigt dans Tasmota, chose dont je connaissait l'existence grâce à @mathieu qui en fait une promotion quasi sectaire, mais que je n'avais jamais exploré...

ESP8266

Ce module présente l'avantage de s'alimenter en Micro USB, avantage car on a tous dans nos tiroirs des chargeurs et des câbles dans ce format. C'est également avec ce câble que l'on va le brancher sur un PC afin de le Tasmotiser (pas sur que l'Académie ajoute ce verbe cette année). Pour le reste, je ne suis pas spécialiste pour vous parler de ses avantages et inconvénients, ah si, il était présent au fond de mon tiroir.

On lance tasmotizer.exe (ça existe pour d'autres confessions que Windows) et le reste se fait tout seul, ça va même télécharger le firmware idoine. Presque trop facile. Une fois que c'est fait alimente l'ESP et on se connecte dessus en WI-FI afin de renseigner notre SSID dédié IoT. Après un redémarrage on peut ouvrir avec un navigateur et débuter la configuration du module. Je vous laisse trouver comment repérer l'IP et lui faire une réservation DHCP.

Tasmota

Dans la configuration on commence par choisir le type de module (Generic 18) et on configure 5 GPIO en mode SWITCH. Attention tous les ports ne sont pas utilisables, il faut tâtonner un peu quand on ne connait pas la signification des options possibles.

Ensuite on va passer à la configuration MQTT (Host, port, user et password). Et c'est tout. Enfin, il faut tout de même connecter notre carte optocoupleur avec l'ESP avec des câbles Dupont (+3.3, GND et GPIO 1 2 3 4 5).

Intégration

Sous Home Assistant il a plusieurs façons d'exploiter Tasmota (voir ici), en mode pur MQTT pour intégriste barbu (au sens Geek du terme hein !) en déclarant les devices en YAML, en mode MQTT discovery et depuis peu avec l'intégration Tasmota officielle qui va s'appuyer sur MQTT pour créer les devices et les entities. Comme je ne suis pas barbu et que je pense qu'il faut s'ouvrir au plus grand nombre, vous imaginez bien que j'ai choisit cette option.

On ajoute l'intégration avec le bouton + dans les intégrations et on laisse les options de base.

Ensuite on va dans la console du module Tasmota afin de saisir quelques options (que l'on pourrait du reste envoyer en MQTT ou en HTTP...).

SetOption19 0 # Pour lui dire de ne pas faire du discovery en MQTT mais via l'intégration Tasmota

SetOption114 # Pour activer le mode switch

SwitchMode1 2 # Mode folow inversé (0 = on, 1 = off) sur switch 1
SwitchMode2 2 # Mode folow inversé (0 = on, 1 = off) sur switch 2
SwitchMode3 2 # Mode folow inversé (0 = on, 1 = off) sur switch 3
SwitchMode4 2 # Mode folow inversé (0 = on, 1 = off) sur switch 4

Normalement à ce stade il ne nous reste plus qu'à tester notre montage en alimentant chacun des ports en 220 V. Attention, on ne le répètera jamais assez, le 220 V c'est très dangereux, donc on prend ses précautions (et si on ne le sent pas on retourne jouer à la marelle avec ses copines !). Moi je décline bien sur toute responsabilité.

Vous devriez rapidement obtenir quelque chose qui ressemble à ça :

Usage

Il ne restera ensuite plus qu'à exploiter ces binary_sensor: pour des actions ou des notifications, et pour ça je vous conseille l'intégration alert...

alert:
  tableau_1:
    name: Diff 1
    entity_id: binary_sensor.switch2
    state: 'off'   # Optional, 'on' is the default value
    repeat:
      - 10
      - 30
      - 60
      - 300
    can_acknowledge: true  # Optional, default is true
    skip_first: true  # Optional, false is the default
    message: "{{ states.sensor.date_time.state}} > ALERTE | Différentiel 1 : OFF" 
    done_message: "{{ states.sensor.date_time.state}} > ALERTE | Différentiel 1 : OK"
    notifiers:
      - slack_hass_canaletto
      - Free_Mobile

Voilà, presque trop simple. Et merci à ceux qui m'ont aidé à cogiter tout ça !

 

NextDNS, une bonne alternative

Traditionnellement, et encore aujourd'hui, la grande majorité des utilisateurs se servent du DNS de leur fournisseur d'accès sans vraiment savoir de quoi il s'agit. Certains plus aguerris l'ont changé, enfin ceux qui peuvent car certains fournisseurs comme par Orange (lamentable sur ce point) rendent ce changement impossible sur les LiveBox. Mais il y a toujours moyen de contourner sur les appareils connectés ou mieux les navigateurs. Depuis peu les navigateurs modernes permettent de configurer un DNS sécurisé (DNS over HTTPS, DoH), et d'ailleurs dans les dernières version celui ci est déjà plus ou moins configuré.

Les choix :

  • Google : ça reste le premier choix alternatif que l'on retrouve. Donc au cas ou Google aurait loupé un de vos pas, il se rattrape en fournissant un DNS gratuit.
  • Cloudflare : on ne présente plus, certainement le plus rapide.
  • Quad9 : une autre initiative suisse, plus transparent et qui assure un filtrage de domaines malveillants...
  • La liste est longue et vous la retrouverez ici.

Pour aller un un peu plus loin on peut également utiliser un DNS filtrant à installer (et maintenir) sur son propre réseau. Il en existe principalement deux, Pi Hole et AdGuard Home. Je ne suis pas fan du premier, mais j'aime bien Adguard. L'inconvénient est qu'il faut une infrastructure minimale (VM, Docker, etc..) et que cela ne fonctionnera que sur un site. J'ai longtemps utilisé AdGuard, et comme tous les DNS filtrants on se retrouve parfois avec des faux positifs qui au final peuvent ralentir les flux.

L'intérêt d'utiliser un DNS filtrant réside principalement dans les points suivant :

  • Protection de la vie privée : confidentialité des requêtes, protection contre les trackers, suppression des publicités intrusives,
  • Sécurité : protection contre les menaces qui utilisent le DNS,
  • Contrôle parental,
  • Supervision.

NextDNS

Enfin, si je vous parle de tout ça c'est pour vous présenter NextDNS.

NextDNS est une offre hébergée qui combine les avantages d'un AdGuard Home et d'un DNS rapide accessible partout. L'avantage étant que je vais pouvoir l'utiliser sur plusieurs sites ou je me déplace, mais également en situation de mobilité.

Pour en profiter il est possible de changer (quand on peut) le DNS affecté au DHCP sur le routeur ou la box par ceux proposés par NextDNS. Mais pas que. Il est également possible de configurer DoH sur les navigateurs et les O/S Mobiles de façon très simple afin d'en profiter en situation de mobilité, sans pour autant avoir à modifier la configuration à chaque usage. Et pour ceux qui sont réfractaires à la technique, les service propose des applications pour tous les systèmes avec des guides très clairs proposés sur le panneau de contrôle de NextDNS.

Et oui car panneau de contrôle il y a, et c'est un gros plus offert par NextDNS. Outre les diverses configurations possibles on vas y retrouver des statistiques ainsi que la liste des requêtes que l'on a fait. Bien sur ces options sont facultatives, ces données ne sont présentes que pour vous et si on le souhaite NextDNS n'enregistrera simplement rien. Mais laissez les au moins un temps, histoire de vous faire peur en voyant le nombre de requêtes faites par vos appareils, ainsi que votre dépendance aux GAFAM's, c'est juste effarant ! (le graphique qui suit c'est juste 24 heures chez moi...).

Navigateurs

Si DNS over HTTPS fonctionne très bien sur Opera, Edge (Chromium MS) ou Firefox, la fonctionnalité est par contre bloquée sur ma machine avec Chrome et brave au motif que ces navigateurs seraient managés par une organisation. Ce n'est pas le cas, hormis le fait que ce PC fait partie d'un domaine Active Directory, sans toutefois de policies spécifiques à navigateurs. Pas de problème par contre sur MacOS ou sur d'autres PC hors domaine. Un point à creuser.

Aller plus loin en entreprise

Dans le cas d'un réseau d'entreprise ou d'utilisateur avancé on va donc aller changer le DNS sur le routeur ou le serveur DNS. Et si on est sur un domaine Active Directory, ce qui est mon cas, le DNS Windows est un passage obligatoire. Et là c'est le bug, car si Microsoft commence timidement à introduire DoH sur Windows 10, le DNS de Windows Server sur lequel repose Active Directory n'est toujours pas adapté à DNS over HTTPS ou DNS over TLS au niveau des redirecteurs (forwarders).

La seule solution est donc de passer en clair entre le DNS du serveur Windows et les IP de NextDNS. Et justement passer en clair est une des choses qu'on ne veut pas faire. Pour contourner ça NextDNS propose une sorte de proxy DNS sur lequel on pourrait faire pointer nos forwarders, une version graphique qui installe un driver TAP (en 2021 sérieux ?) et un client CLI qui ferait bien l'affaire mais ne fonctionne pas correctement. Clairement chez NextDNS Windows c'est pas leur truc et les explications et réponses aux questions que l'on trouve sur leur forum ou le GitHub en témoignent.

Pour l'expérience j'ai donc monté un AdGuard transparent dans un Docker qui pointe sur https://dns.nextdns.io/xxxxxx en DoH. Ca fonctionne en faisant pointer dessus le sforwarders de mon serveur DNS sous Windows Server. Je suppose que j'aurais pu faire la même chose avec un petit Linux et le client CLI, mais mon but était démontrer que ça tourne dans un environnement Windows d'entreprise. Après avoir perdu pas mal de temps à chercher des informations je me suis dit que ce CLI n'avait peut être jamais été testé sur Windows Serveur 2016/2019 et qu'il fonctionnerait peut être sur une vieille version de Windows, et banco ça fonctionne sur un Windows 2008R2 vintage... Sérieux ? Donc :

nextdns install -config 71fc72 -report-client-info -listen 0.0.0.0:53

Et ensuite on fait pointer du DNS Windows sur l'IP de ce serveur et c'est transparent pour les utilisateurs.

Une alternative pourrait consister à changer de DNS sur les clients (via le DHCP) et à les faire pointer sur le proxy DNS en précisent que les requêtes du domaine Active directory local pointeront bien sur le DNS AD. C'est possible, mais ce n'est pas ce que je conseillerais.

nextdns install -config 71fc72 -report-client-info -listen 0.0.0.0:53 -forwarder canaletto.fr=192.168.10.10

Dans l'absolu ce petit CLI est très bien fait, il est juste un peu bâclé en ce qui concerne l'environnement Windows. Par contre il s'installe en mode service et sera donc persistant.

Bonus

NextDNS permet de faire de la réécriture de DNS, une fonction qui sera intéressante quand on utilise un VPN/SDN comme Zerotier car cela de permettre de résoudre des nom de hosts internet sur des adresses IP privée, ce qui est théoriquement contraire aux RFC sur un DNS public (bien que certains come CloudFlare l'acceptent, ce n'est jamais une bonne idée de documenter ainsi une architecture interne).

Conclusion

Je ne vais pas détailler tout ce que les autres sites ont pu écrire, pas même insérer un lien d'affiliation qui pourtant existe.

Ce service est un peu jeune, mais il avance rapidement. il est le fruit de deux Français expatriés aux Etats Unis. Personnellement je suis séduit et je vous invite à le prendre en main.

NextDNS est un service qui peut être gratuit pour un usage Soho limité à 300.000 requêtes, ça peut être suffisant dans pas mal de cas, en ce qui me concerne j'en suis à 150.000 en 24 heures, mais il faut dire que j'ai un peu poussé la chose dans ses retranchements. La tarification est très accessible (2 € par mois ou 20 € par an pour l'utilisation que j'en ai) et il existe des offres destinées aux entreprises et à l'enseignement.

Enjoy ;-) (je mettrais à jour cet article au fil du temps... N'hésitez pas à revenir).

Sources

 

Home Assistant & Alarme

De base Home Assistant contient ce qu'il faut pour construire son propre système d'alarme DIY. Ca fonctionne très bien avec un peu d'huile de coude, et même que certains n'hésitent pas à publier sur ce sujet des articles du genre pute à clics, qui en fait n'expliquent rien et proposent plus de liens sponsorisés que de mots utiles. Soyons sérieux, il suffit de chercher sur Google avec deux ou trois mots clés pour trouver de bien meilleures explications.

De mon coté je ne vais pas vous parler de ça (Alarm Control Panel) mais d'une intégration faite par Niels (le développeur du Scheduler). Cette intégration très poussée va cous permettre de créer un système d'alarme personnalisé en quelques clics de souris.

Attention :  on parle ici d'un système de sécurité DIY, donc non agrée par les assurances et autres... Ca ne veut pas dire que ça ne fonctionne pas, juste que ça ne répond pas aux normes NF en vigueur dans ce domaine.

Alarmo

C'est le nom de cette intégration que vous allez pouvoir installer depuis HACS. Ensuite il suffit de l'ajouter dans le menu des intégrations. Je ne vous fait pas un dessin, comme toujours Niels documente très bien ses créations.

Une fois en place vous allez voir apparaitre Alarmo sur la barre latérale. On clique et obtient la page de configuration qui comporte plusieurs onglets.

Les réglages généraux

je ne vais pas les décrire en détail car ils sont parfaitement explicites, juste vous dire que l'option MQTT servira à communiquer avec des applications tierces, une tablette murale par exemple, mais on y reviendra. Pour le reste on règle des délais, des zones et les différents modes de l'alarme selon que l'on soit absent ou que l'on veuille conserver une sécurité périphérique la nuit. Ou encore un mode personnalisé à customiser.

Les capteurs

Cet onglet nous permettra de les sélectionner et de les adapter à chaque type de surveillance. Par exemple en mode nuit seul les capteurs périphériques (portes et fenêtres seront surveillées alors que les détecteurs d'incendie sont surveillés dans tous les modes. 

Les codes

Ici on va configurer les utilisateurs et leurs codes d'activation. Dans la pratique je trouve qu'ouvrir son smartphone pour rentrer un code est encore moins pratique que de le saisir sur un boitier mural. Il existe une autre option qui n'est pas prévue ici et nécessitera une petite automation, c'est l'utilisation de tags RFID. Par exemple, dans l'automation qui suit, quand je passe mon mobile sur le tag RFID collé sur la porte on va désactiver l'alarme et loguer cette action dans Slack. On pourrait bien sur également en profiter pour exécuter d'autres actions... 

- alias: "Alarm : Action on return"
  trigger:
  - platform: tag
    tag_id: b38qdq2-c0qdsddc-43cds2-8881-c6a7824fa4ff # TAG Porte
  action:
  - service: alarm_control_panel.alarm_disarm
    data:
      code: !secret alarm_code
    entity_id: alarm_control_panel.home_alarm
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > ENTER HOME | DISARM ALARM | State : {{ states.alarm_control_panel.home_alarm.state }}" 

On peut également utiliser le RFID avec un lecteur de tags et des cartes ou portes clé RFID. Autre possibilité, utiliser une télécommande, un bouton Aqara par exemple qui permettra d'exécuter des actions différentes selon le nombre de clics

Une variante pourrait consister à désactiver par géolocalisation, mais non, mauvaise idée, car si on vous dérobe votre mobile il pourrait servir à désactiver alors que le RFID ne fonctionnera que si ce même mobile est déverrouillé. Par contre on peut imaginer utiliser la géolocalisation pour activer l'alarme en considérant que tous les occupants sont hors zone...

Les actions

Le dernier paramétrage porte sur les actions. On a deux types d'actions possibles, des notifications et des actions plus concrètes. Les notifications (notify.xx) nous permettront de tenir un journal des évènements, sur Slack par exemple, et de notifier une ou plusieurs alarme(s) par SMS en précisant la source de déclanchement. Il est également possible à chaque étape de faire de doubler ça avec des notifications vocales, pour ça je vous conseille de créer des notifiers adaptés au TTS que vous utilisez (ici le cloud Home Assistant NabuCasa). Cela sera par exemple très pratique pour avoir un retour vocal si l'alarme de veut pas s'activer car une fenêtre est ouverte, et vous préciser quelle ouverture il faut fermer, une fonctionnalité gérée par Alarmo.

notify:
  - name: tts_sonos_hall
    platform: tts
    tts_service: tts.cloud_say
    media_player: media_player.Sonos_hall

Les actions permettent quant à elles de déclencher des appareils ou des scripts. On peu par exemple en cas d'intrusion détectée allumer des projecteurs, une sirène ou lancer un script pour combiner des actions plus complexes.

Aller plus loin

Et puis il y a ceux qui aiment les afficheurs de contrôle muraux. Pour ça un autre développeur a créé de son coté MQTT Alarm Panel, un autre système d'alarme conçurent basé sur une application Android qui travaille en MQTT avec Home Assistant. C'est plus primaire, par contre l'interface sur une tablette est parfaite, elle affiche par défaut l'état de l'alarme et en option Lovelace. Et la bonne nouvelle c'est que les deux développeurs sont en train de discuter pour s'entendre entre eux de façon à ce que le projet Android puisse s'adapter facilement à Alarmo. Elle est pas belle la vie open source  !

Notez que...

Pour une efficacité maximale Il est évident que tout ce qui va se rapporter à ce système d'alarme devra être autonome. Home Assistant sur onduleur, mais également les moyens de transmission (routeur, voire routeur GSM), ainsi que les sirènes, etc... Il existe également des sirènes secourues en Zigbee comme la Heiman HS2WD dans sa version Zigbee par exemple, ou encore des sirènes vraiment pas couteuses et très puissantes, bref, pas de liens mais Amazon Et AliExpress sont vos amis...

 

Home Assistant & Shelly

Il y a un an quand j'ai commencé à utiliser des Shelly sous Home Assistant l'évidence était d'utiliser l'intégration tierce Shelly4HASS. Depuis la compatibilité MQTT s'est bien améliorée et j'y ait trouvé un intérêt, alors même  que les équipes de Home Assistant ingéraient le support natif de Shelly au core. Donc aujourd'hui il n'y a plus vraiment d'intérêt à utiliser cette intégration tierce, toujours dans la logique de faire au plus simple. Bien que Shelley4HASS fonctionne toujours très bien et présente l'avantage de fournir beaucoup d'informations dans les attributs.

Deux options

  1. Vous débutez en domotique ou vous voulez juste allumer deux ampoules et actionner un relaie. Laissez vous guider, HA découvrira vos modules et vous les piloterez en deux clics afin d'n exploiter toutes les possibilités, l'intégration de base supporte toutes les possibilités et s'améliore de releases en releases.
  2. Vous passez vos nuits sur votre serveur domotique, vous fréquentez des barbus qui vous poussent à souder des cartes électroniques, votre facteur vous regarde bizarrement depuis que vous recevez plusieurs fois par semaine des paquets en provenance de Chine. Attention, bientôt vous n'aurez plus de famille, d'ailleurs votre femme pense à demander le divorce. Mais faites vous plaisir prenez la route MQTT, en attendant de retrouver la votre, c'est aussi une forme de liberté.

Je ne vais pas vous expliquer MQTT, d'autres l'ont fait, mais MQTT est un vrai protocole domotique en devenir. Attention toutefois, chez Shelly, c'est Cloud (App mobile, Alexa, GH) ou MQTT. Il faut choisir. Attention également aux modules Shelly fonctionnant sur piles, personnellement j'ai abandonné ces modules car même avec du WI-FI Low Energy les piles sont trop rapidement à changer, et il y a des chances qu'en MQTT ce soit encore pire. Donc pour les sondes et autres capteurs, Zigbee est à mon sens plus adapté.

MQTT sur Home Assistant

Je ne vais pas détailler ici l'a mise en œuvre de MQTT, ce n'est pas le propos, mais en gros on installe un broker (dans les adons) et ensuite on ajoute l'intégration MQTT depuis la page des intégrations. Et si on ne veut pas se taper la configuration individuelle des modules, on installe Shelly Discovery qui est un script Python qui va le faire pour vous. Pourquoi ça alors que d'autre modules vont en MQTT créer tout ce qui est nécessaire sous HA ? Simplement parce que Shelly se veut générique et ainsi ils n'ont pas à gérer cette partie. Ca se défend.

Migration vers MQTT

On commence par imprimer une liste des Shelly existants sous Shelly4HASS avec leur adresse et leur usage afin de pouvoir les repérer en MQTT.

Dans l'intégration MQTT qui a remonté nos modules c'est le moment de penser au renommage. C'est un point important et il sera bien moins aisé d'y revenir. Il y a plusieurs écoles.

  • Renommage soft ou on renomme juste le display name.
  • Renommage hard ou l'on renomme le display name et l'entité. Dans ce cas il faut le faire avant d'aller faire le travail suivant car ça aura des conséquences sur le travail d'intégration.
  • Renommage unique du display name de l'entité qui actionne (light ou switch). Ca sera utile pour le présenter dans Alexa ou GH.
  • Dans tous les cas il ne faut pas oublier d'affecter une pièce (qui sera également reprise dans Alexa et GH)
  • Et sur la config des Shelly de type relais (1, 1PM, 2.5 ou prises) utilisés pour les éclairages, aller dans Appliance type et changer general pour light.

A ce stade on veut virer Shelly4HASS dans les intégrations et aussi le composant dans HACS. Avantage on va voir tout de suite ce qui ne fonctionne plus. Mais on peu aussi le faire après avoir migré en MQTT si on ne pense pas pouvoir faire ce travail d'une traite. Quand Shelly4HASS n'est plus présent on va voir remonter automatiquement les modules via l'intégration de base Shelly. On peut éviter ça si on en a beaucoup ou simplement clique sur ignorer dans les intégrations.

discovery:
  ignore:
    - shelly

Ensuite il va falloir de la patience et comme toujours de la rigueur.

Point à vérifier pour chaque module :

  • S'ils sont affichés dans Lovelace (relais et conso).
  • S'ils sont télécommandés (par quoi, automation, BP ou ComanderX).
  • S'ils sont déclarés en utility_meter:
  • S'ils sont utilisé dans les automations ou des thermostats
  • S'ils sont utilisés dans d'autres cas particuliers.

On les faits les uns après les autres et on valide chaque étape en en vérifiant le bon fonctionnement.

Bienvenue dans MQTT !

En bonus, MQTT Explorer qui sera bien utile pour mettre au point des choses complexes et vérifier ce qui se trame sur votre broker. Broker que l'on a ici monté sur HA, mais qui dans l'absolu pourrait être sur une autre machine, un NAS, voire même sur un autre site. Il existe d'ailleurs des brokers publics pour faire communiquer différents objets entre eux. Vous allez me dire que c'est une façon de recentraliser l'information, oui, mais ça peut être nécessaire en IoT avec des objets volatiles car si l'objet A ne parvient pas à joindre l'objet B, le broker conservera alors le message le temps que l'objet B soit disponible... D'où l'intérêt d'une certaine centralisation qui peut d'ailleurs être répartie...

EDIT : un article très bien fait : https://henriksozzi.it/2021/02/shelly-e-home-assistant/ (clic droit traduire si vous ne maitrisez pas l'italien...)

 

Home Assistant & UPS

Vous allez me demander pourquoi gérer les onduleurs sur Home Assistant ? Simplement pour être avertit en cas de coupure électrique via une notification (si on est en déplacement il peut être intéressant d'envoyer une personne de confiance réarmer en cas d'une défaillance locale, histoire de ne pas perdre le contenu du congélateur (vécu)), ensuite exécuter des actions sur ce qui est secouru et en dernier ressort éteindre le serveur. Les informations ainsi remontées donneront également des indication sur l'état des batteries afin de les changer préventivement.

J'ai souvent des coupures à la campagne, j'ai deux gros onduleurs réseau de marque APC et je me suis dès mes débuts intéressé à eux avec ce que j'ai alors trouvé de plus simple.

APC UPS Daemon

ApcUpsd s'installe sous la forme d'un addon et la suite est intégrée à Home Assistant.

On ajoute aux addons ce repository : https://github.com/korylprince/hassio-apcupsd et on installe la version IP ou USB qui nous convient. Et on configure.

name: APC UPS
cable: ether
type: snmp
device: 192.168.210.6

Ensuite on ajoute ça dans configuration.yaml :

apcupsd:

Ainsi que quelques sensors :

- platform: apcupsd
  resources:
    - apc
    - date
    - hostname
    - version
    - upsname
    - cable
    - driver
    - upsmode
    - starttime
    - model
    - status
    - linev
    - loadpct
    - bcharge
    - timeleft
    - mbattchg
    - mintimel
    - maxtime
    - maxlinev
    - minlinev
    - outputv

Et on termine avec un binary :

- platform: apcupsd
  name: UPS

Les paquets sont marqués obsolètes, mais pour l'instant j'utilisait ça depuis un an et ça fonctionne très bien.

SNMP

Si on dispose d'un onduleur réseau, ici APC, voici un "package" (mode pakage de HA) pour le faire en SNMP. Le gros avantage c'est qu'il n'y a absolument rien à installer, SNMP étant supporté de base dans Home Assistant. Attention c'est un peu long...

sensor:
  - platform: snmp
    name: ups_smart_750_capacity
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.1.0
    accept_errors: true
    unit_of_measurement: '%'
  - platform: snmp
    name: ups_smart_750_runtime_remaining
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.3.0
    accept_errors: true
    value_template: >-
      {% set time = (value | int) / 100 | int %}
      {% set minutes = ((time % 3600) / 60) | int %}
      {% set hours = ((time % 86400) / 3600) | int %}
      {% set days = (time / 86400) | int %}
    
      {%- if time < 60 -%}
        Less than a minute
        {%- else -%}
        {%- if days > 0 -%}
          {{ days }}d
        {%- endif -%}
        {%- if hours > 0 -%}
          {%- if days > 0 -%}
            {{ ' ' }}
          {%- endif -%}
          {{ hours }}h
        {%- endif -%}
        {%- if minutes > 0 -%}
          {%- if days > 0 or hours > 0 -%}
            {{ ' ' }}
          {%- endif -%}
          {{ minutes }}m
        {%- endif -%}
      {%- endif -%}
  - platform: snmp
    name: ups_smart_750_load_percentage
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.2.3.0
    accept_errors: true
    unit_of_measurement: '%'
  - platform: snmp
    name: ups_smart_750_battery_temperature
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.2.0
    accept_errors: true
    unit_of_measurement: '°C'
  - platform: snmp
    name: ups_smart_750_battery_status
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.2.2.4.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        Good
      {% elif value == '2' %}
        Failed
      {% endif %}
  - platform: snmp
    name: ups_smart_750_type
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.1.1.1.0
    accept_errors: true
  - platform: snmp
    name: ups_smart_750_input_voltage
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.3.2.1.0
    accept_errors: true
    unit_of_measurement: 'V'
  - platform: snmp
    name: ups_smart_750_last_transfer_reason
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.3.2.5.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        No events
      {% elif value == '2' %}
        High line voltage
      {% elif value == '3' %}
        Brownout
      {% elif value == '4' %}
        Loss of mains power
      {% elif value == '5' %}
        Small temporary power drop
      {% elif value == '6' %}
        Large temporary power drop
      {% elif value == '7' %}
        Small spike
      {% elif value == '8' %}
        Large spike
      {% elif value == '9' %}
        UPS self test
      {% elif value == '10' %}
        Excessive input voltage fluctuation
      {% endif %}
  - platform: snmp
    name: ups_smart_750_output_load
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.2.3.0
    accept_errors: true
    unit_of_measurement: '%'
  - platform: snmp
    name: ups_smart_750_output_current
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.2.4.0
    accept_errors: true
    unit_of_measurement: 'A'
  - platform: snmp
    name: ups_smart_750_last_self_test_result
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.7.2.3.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        OK
      {% elif value == '2' %}
        Failed
      {% elif value == '3' %}
        Invalid Test
      {% elif value == '4' %}
        Test In Progress
      {% endif %}
  - platform: snmp
    name: ups_smart_750_last_self_test_date
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.7.2.4.0
    accept_errors: true
  - platform: snmp
    name: ups_smart_750_communication_status
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.8.1.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        on
      {% elif value == '2' %}
        off
      {% endif %}
  - platform: snmp
    name: ups_smart_750_status
    host: 192.168.210.7
    baseoid: 1.3.6.1.4.1.318.1.1.1.4.1.1.0
    accept_errors: true
    value_template: >-
      {%if value == '1' %}
        Unknown
      {% elif value == '2' %}
        On Line
      {% elif value == '3' %}
        On Battery
      {% elif value == '4' %}
        On Smart Boost
      {% elif value == '5' %}
        Timed Sleeping
      {% elif value == '6' %}
        Software Bypass
      {% elif value == '7' %}
        Off
      {% elif value == '8' %}
        Rebooting
      {% elif value == '9' %}
        Switched Bypass
      {% elif value == '10' %}
        Hardware Failure Bypass
      {% elif value == '11' %}
        Sleeping Until Power Returns
      {% elif value == '12' %}
        On Smart Trim
      {% endif %}

homeassistant:
  customize:
    sensor.ups_smart_750_status:
      device_class: connectivity
      friendly_name: Smart-UPS status
    sensor.ups_smart_750_capacity:
      device_class: battery

NUT

Enfin on peut aussi utiliser NUT (Network UPS Tools) que beaucoup ici connaissent et qui est une légende dans le monde des UPS.

Pour ça il faut installer le serveur NUT que l'on trouvera dans les addons et qui communiquera avec vos onduleurs. Voici deux configurations à adapter selon que l'onduleur soit connecté en USB ou en IP. La documentation de NUT est une véritable bible des UPS et vous y trouverez ce qui vous manque.

USB

users:
  - username: nut
    password: MyPassword
    instcmds:
      - all
    actions: []
devices:
  - name: apc
    driver: usbhid-ups
    port: auto
    config:
      - desc = "APC Back-UPS 600VA"
      - vendorid = 051d
mode: netserver
shutdown_host: 'false'

IP

users:
  - username: nut
    password: MyPassword
    instcmds:
      - all
    actions: []
devices:
  - name: apc_1400
    driver: snmp-ups
    port: 192.168.210.6
    community: public
    snmp_version: v1
    pollfreq: 15
    config:
      - desc = "APC Smart-UPS 1400VA"
  - name: apc_750
    driver: snmp-ups
    port: 192.168.210.7
    community: public
    snmp_version: v1
    pollfreq: 15
    config:
      - desc = "APC Smart-UPS 750VA"
mode: netserver
shutdown_host: 'false'

A partir de là il faut aller dans les intégrations, ajouter l'intégration NUT, la configurer avec ces informations :

  • Host : a0d7b954-nut
  • Port : 3493
  • Username : nut
  • Password : MyPassword

Et ensuite choisir les seniors que l'on souhaite créer, utiliser et superviser.

Automations

Une fois que l'on dispose des sensors il sera possible d'effectuer des actions selon le comportement de ceux ci. Libre à vous d'imaginer, ou par exemple utiliser l'intégration Alert pour recevoir des notifications répétées.

ups_1:
  name: UPS APC 1
  entity_id: binary_sensor.ups
  state: 'off'   # Optional, 'on' is the default value
  repeat:
    - 10
    - 30
    - 60
    - 300
  can_acknowledge: true  # Optional, default is true
  skip_first: true  # Optional, false is the default
  message: "{{ states.sensor.date_time.state}} > A L A R M  U P S | Coupure EDF" 
  done_message: "{{ states.sensor.date_time.state}} > A L A R M  U P S | Rétablissement EDF"
  notifiers:
    - slack_hass_canaletto
    - Free_Mobile

Voilà, un peu soporifique, je suis d'accord, mais le sujet n'est pas rigolo !