Home Assistant & Tuya zéro cloud

On le sait tous, la domotique nous fait acheter beaucoup de bricoles qui souvent deviennent obsolètes, bref il y a toujours mieux. Par exemple les prises et autres objets Tuya ou Sonoff qui nécessitent le cloud, alors qu'un prise Shelly dispose de base de MQTT, peut être flashée avec ce que l'on souhaite et dans tous les cas fonctionne en local. Bien sur on ne va pas parler des prises en RF433 genre DIO mise au rebus faute de retour d'état, pas plus que des solutions Zigbee qui se traitent autrement. Tuya c'est du matériel OEM disponibles en marque blanche que des entreprises peuvent distribuer sous leur étiquette. Je trouve d'ailleurs scandaleux qu'une marques comme Konyks soit labelisée French Tech alors qu'il se contente de distribuer de produits chinois sous leurs marque sans aucune R&D... Bref !

Nous avons donc en Wi-Fi...

  • L'écosystème Sonoff : en dehors de quelques modèles DIY, il faudra en général ouvrir et souder pour flasher. Heureusement il existe une intégration qui permet leur utilisation en local / cloud. En gros l'intégration mets à jour à intervalles réguliers ce qu'il trouve sur le cloud Sonoff et les actions sont ensuite locales.
  • L'écosystème Tuya : de base 100% cloud et géré nativement par HA, mais on va voir plus loin comment contourner ça.
  • L'écosystème Shelly : Cloud ou 100% nativement local et MQTT, flashable si vous aimez ça. C'est clairement ce que je vous conseille pour de nouveaux achats.

Tuya sans cloud

Heureusement il y a des petits malins qui adorent faire du reverse engineering, ce qui va nous permettre d'utiliser nos produits Tuya localement avec bien souvent plus de fonctionnalités, comme par exemple la remontée des information de consommation qui ne se fait pas de base sous HA.

Dans tous les cas, comme pour les produits Xiaomi/Aqara, il faudra trouver la clé... Au fil du temps les méthodes changent, mais aujourd'hui ça n'a jamais été aussi facile. Je vous conseille donc de récupérer vos clés, même si vous ne comptez pas les utiliser tout de suite.

On part du principe que vous avez un compte Tuya/ SmartLife (ou une application OEM comme celle de Konyks, c'est la même chose) et que vos équipements y sont enregistrés. En substance on va passer par la plateforme IoT de Tuya sur lequel vous allez vous créer un compte développeur et suivre les instructions de cet article dont je me suis inspiré. (Je ne suis pas sur que tout soit utile, vous me direz...).

  1. Créez un nouveau compte sur iot.tuya.com et assurez-vous que vous êtes connecté. Allez dans Cloud -> Projet dans le tiroir de navigation de gauche et cliquez sur "Create". Après avoir créé un nouveau projet, cliquez dessus. L'ID d'accès et la clé d'accès sont équivalents à la clé d'API et aux valeurs secrètes d'API requises.
  2. Allez dans App -> App SDK -> Development dans le tiroir de navigation. Cliquez sur "Create" et entrez ce que vous voulez pour les noms de package et Channel ID (pour le nom du package Android, vous devez entrer une chaîne commençant par com.). Prenez note de l' ID de chaîne que vous avez entré. Cela équivaut à la valeur schema requise plus loin. Ignorez les clés d'application et les valeurs secrètes d'application que vous voyez dans cette section car elles ne sont pas utilisées.
  3. Allez dans Cloud -> Projet et cliquez sur le projet que vous avez créé précédemment. Cliquez ensuite sur "Link Device". Cliquez sur l'onglet «Link devices by Apps», puis sur «Add Apps». Vérifiez l'application que vous venez de créer et cliquez sur "Ok".
  4. Toujours dans Cloud -> Projet et cliquez sur le projet que vous avez créé précédemment. Cliquez ensuite sur "Link Device". Cliquez sur l'onglet «Link devices by App Account», puis Add App Account et ajouter votre compte Tuya/SmartLife et vous devriez retrouver vos petits....
  5. Sur la même page, cliquez sur "Groupe d'API" sur le côté gauche. Modifiez le statut en Ouvert pour les trois groupes d'API suivants en cliquant sur "Appliquer" pour chaque ligne, en saisissant une raison quelconque et en cliquant sur "OK": "Authorization Management", "Device Management", "Device Control", "User Management", "Network Management", "Data Service", "Home Management", "Device User Mangement" and "Device Statistics".. Cela peut prendre 10 à 15 minutes pour que ces modifications prennent effet.
  6. Ensuite sur Device List / App Account / Europe vous listez vos devices et vous récupérez les devices ID
  7. Enfin on va dans API Explorer / Get Device details, on choisit Europe et on rentre le device ID et par magie la local_key apparaitra.
{
  "result": {
    "active_time": 1609598200,
    "biz_type": 0,
    "category": "cz",
    "create_time": 1609598200,
    "icon": "smart/icon/154028815822y4yx2k5jz_0.jpg",
    "id": "871720fsdfsdfsfd8e997fec",
    "ip": "70.22.16.3",
    "local_key": "8dfsdfsdfsgggsg10ecb6",
    "name": "Konyks Priska Plus 6",
    "online": true,
    "owner_id": "19956557",
    "product_id": "j6cVsdgfsdfgsdfsdfeYpli",
    "product_name": "Konyks Priska Plus",
    "status": [
      {
        "code": "switch_1",
        "value": false
      },
      {
        "code": "countdown_1",
        "value": 0
      },
      {
        "code": "cur_current",
        "value": 0
      },
      {
        "code": "cur_power",
        "value": 0
      },
      {
        "code": "cur_voltage",
        "value": 2339
      }
    ],
    "sub": false,
    "time_zone": "+01:00",
    "uid": "eu15345fgsdfsdfdsf9crK3G",
    "update_time": 1609565564,
    "uuid": "8717244465sd6f46sdf7fec"
  },
  "success": true,
  "t": 1609606041296
}

Ceux qui sont familiers de Node JS pourront lancer le script comme décrit ici et obtenir toute les clés en une seule manipulation.

Ensuite on a deux solutions :

  • La première, Trade Face Tuya Gateway est indépendante de la solution domotique choisie car full MQTT, elle peut s'installer dans un Docker et nos amis encore sous Jeedom pourront ainsi en profiter.
  • La seconde, Local Tuya, est une simple intégration pour Home Assistant qui permettra de reconnaitre nos équipements en quelques clics et s'installe depuis HACS. Le discovery fera le reste et il faudra juste tâtonner un peu quand on configure un équipement Tuya pour faire correspondre les bonnes valeurs, mais c'est expliqué ici.

Vous aurez compris, ce qui compte encore une fois c'est d'avoir les clés. Ensuite il existe surement d'autre solutions pour exploiter. Attention : Pour toutes ces manips pensez à fermer l'application mobile (Tuya/SmartLife) car un équipement Tuya ne supporte qu'une seule connexion simultanée.

Merci Yvon pour cette exploration nocturne et conjointe d'un jour de l'an sous couvre-feu !

EDIT 04/01/2021 : Il y a un soucis dans le v3.2 ou on perd certains équipement au reboot. Revenir à la 3.1 résout le problème en attendant mieux.

EDIT 21/02/2021 : Contrairement aux Shelly les appareils Tuya ne fournissent que la consommation instantanée. Donc pas exploitable directement avec un utility_meter: par exemple. Il va donc falloir ruser un peu :

  1. Sortir la consommation instantanée (j'ai laissé le reste en exemple) disponible en attribut pour en faire un sensor :
    sensor:
      - platform: template
        sensors:
          # tuya-sw01_voltage:
          #   value_template: >-
          #     {{ states.switch.sw01.attributes.voltage }}
          #   unit_of_measurement: 'V'
          # tuya-sw01_current:
          #   value_template: >-
          #     {{ states.switch.sw01.attributes.current }}
          #   unit_of_measurement: 'mA'
          tuya_plug_1_current_consumption:
            value_template: >-
              {{ states.switch.tuya_plug_1.attributes.current_consumption }}
            unit_of_measurement: 'W'
  2. Utiliser l'intégration Riemann pour convertir la la consommation instantanée (en Watts) en consommation cumulée (en kW/h)
    sensor:
      - platform: integration
        source: sensor.tuya_plug_1_current_consumption
        name: 'Tuya Plug 1 : Cumul'
        unit_prefix: k
        round: 2
        method: left
  3. Si l'on souhaite conserver l'historique (ici année et année précédente) on va utiliser un utility_meter:
    utility_meter:
      tuya_plug_1_energy_yearly:
        source: sensor.tuya_plug_1_cumul
        cycle: yearly


Enjoy ;-)

 

 

 
 

 

 

Home Assistant & Notifications d'état

Avant, je planifiait mon chauffage avec des automations qui s'appuyaient sur des input_date, input_time pour actionner et input_number pour sélectionner la température de consigne souhaitée et je notifiait dans un journal sur Slack, ce qui me permet un debug facile. J'en avait largement parlé ici, mais maintenant il existe un vrai scheduler et je vais changer ma façon de faire. Sauf que ce scheduler, dont je vous parlerais bientôt, ne dispose pas d'une option de notification. Ca viendra peut être, et ce travail sera peut être à jeter, bien que le principe puisse être adapté à d'autre notifications.

Le scheduler pilotant dans mon cas les thermostats, je vais donc me baser sur les changement d'était du thermostat pour notifier l'état à Slack (voire faire autre chose...). Pour cela je vais stocker les états qui ont changés dans des input_number et des input_text et m'en servir pour notifier avec les bonnes variables.

La liste des courses

J'ai essayé de simplifier en minimisant les besoins, mais il nous faut des input_number: et des input_text:

input_number
  trigger_source_notify_temp_current:
    name: Température Ambiante
    mode: box
    min: 0
    max: 30
    unit_of_measurement: "°C"

  trigger_source_notify_temp_target:
    name: Température de consigne
    mode: box
    min: 0
    max: 30
    unit_of_measurement: "°C"

input_text:
  trigger_source_notify_name:
    name: Trigger Source Name

  trigger_source_notify_hvac_mode:
    name: Trigger Source HVAC Mode

  trigger_source_notify_hvac_action:
    name: Trigger Source HVAC Action
  
  trigger_source_notify_preset_mode:
    name: Trigger Source Preset Mode

  trigger_source_notify_state:
    name: Trigger Source State

Ces "inputs" vont servir à stocker temporairement les valeurs que je vais afficher dans mes notifications.

Une seule automation

Ensuite on va avoir besoin d'une automation qui va :

  1. Se déclencher (trigger) sur les changements d'état pour lesquels on souhaite envoyer une notification. Ici les attributs de deux thermostats.
  2. Ecrire (action) les valeurs liées à la source de déclenchement dans les input_number: et input_text:
  3. Notifier (action) en se servant des valeurs écrite précédemment.
- alias: Notifications des Thermostats
  trigger:
  - platform: template
    value_template: "{{ state_attr('climate.daikin','temperature')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.daikin','preset_mode')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.daikin','hvac_modes')  }}"

  - platform: template
    value_template: "{{ state_attr('climate.thermostat_antoine','temperature')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.thermostat_antoine','preset_mode')  }}"
  - platform: template
    value_template: "{{ state_attr('climate.thermostat_antoine','hvac_modes')  }}"

  action:
  - data_template:
      entity_id: input_number.trigger_source_notify_temp_target
      value: '{{ trigger.to_state.attributes.temperature }}'
    service: input_number.set_value
  - data_template:
      entity_id: input_number.trigger_source_notify_temp_current
      value: '{{ trigger.to_state.attributes.current_temperature }}'
    service: input_number.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_name
      value: '{{ trigger.to_state.attributes.friendly_name }}'
    service: input_text.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_hvac_action
      value: '{{ trigger.to_state.attributes.hvac_action }}'
    service: input_text.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_preset_mode
      value: '{{ trigger.to_state.attributes.preset_mode }}'
    service: input_text.set_value
  - data_template:
      entity_id: input_text.trigger_source_notify_state
      value: '{{ trigger.to_state.state }}'
    service: input_text.set_value

  - service: notify.slack_hass_canaletto
    data:
      message: "{{ states.sensor.date_time.state}} > {{ states.input_text.trigger_source_notify_name.state }} : Consigne à {{ states.input_number.trigger_source_notify_temp_target.state }}° |  
                Température ambiante : {{ states('input_number.trigger_source_notify_temp_current') }}° | 
                Etat : {{ states.input_text.trigger_source_notify_hvac_action.state }} / {{ states.input_text.trigger_source_notify_preset_mode.state }} / {{ states.input_text.trigger_source_notify_state.state }}

Et on obtient une notification dans le journal Slack

2020-12-06, 20:24 > Thermostat : Antoine : Consigne à 13.0° | Température ambiante : 17.1° | Etat : idle / away / heat

Bonus

On peut s'amuser à traduire les messages d'état et ainsi les insérer en clair et en français dans la notification... En bricolant quelque chose du genre :

  {% if is_state('input_text.trigger_source_notify_hvac_action', 'heating') %}
    Etat : Chauffe
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'cooling') %}
    Climatise
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'dry') %}
    Désumidifie
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'fan_only') %}
    Ventile
  {%-elif is_state('input_text.trigger_source_notify_hvac_action', 'heat_cold') %}
    Auto
  {% else %}
    Etat : Inactif
  {% endif %}

  {% if is_state('input_text.trigger_source_notify_preset_mode', 'away') %}
    Préréglage : Absent
  {%-elif is_state('input_text.trigger_source_notify_preset_mode', 'eco') %}
    Préréglage : Eco
  {%-elif is_state('input_text.trigger_source_notify_preset_mode', 'boost') %}
    Préréglage : Boost
  {% else %}
    Préréglage : Normal
  {% endif %}

  {% if is_state('input_text.trigger_source_notify_state', 'heat') %}
    Mode : Chauffage
  {%-elif is_state('input_text.trigger_source_notify_state', 'cold') %}
    Mode : Climatisation
  {%-elif is_state('input_text.trigger_source_notify_state', 'dry') %}
    Mode : Désumidifiation
  {%-elif is_state('input_text.trigger_source_notify_state', 'fan_only') %}
    Mode : Ventilation
  {%-elif is_state('input_text.trigger_source_notify_state', 'heat_cold') %}
    Mode : Auto
  {% else %}
    Mode : Arrêt
  {% endif %}

Voilà, bien entendu tout ça est adaptable à d'autres besoins....

 

Home Assistant, EJP & Tempo

En France EDF nous propose différents contrats associés à différents types de facturation. La gestion du plus classique avec les heures pleines et les heures creuses est facile, il suffit de faire tourner la nuit les appareils les plus énergivores et on connait d'avance les bonnes heures Par contre pour EJP et Tempo, la couleur est annoncée la veille et il peut être intéressant d'adapter le fonctionnement de certains appareils quand le cout de l'électricité est surtaxé, par exemple en baissant le chauffage électrique de 1 ou deux degrés ou en verrouillant l'usage de certains appareils...

Mais encore faut t'il sous Home Assistant disposer de cet état que l'on reçoit généralement par SMS la veille. Ces informations sont disponibles sur le site Web du fournisseur au format JSON et voici comment faire pour en disposer sous Home Assistant

Tempo

On crée quelques sensor:

  - platform: rest
    name: 'Tempo Demain'
    resource_template: https://particulier.edf.fr/bin/edf_rc/servlets/ejptemponew?Date_a_remonter={{now().strftime("%Y-%m-%d")}}&TypeAlerte=TEMPO
    value_template: '{{ value_json.JourJ1.Tempo }}'
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)
  - platform: rest
    name: "Tempo Aujourd'hui"
    resource_template: https://particulier.edf.fr/bin/edf_rc/servlets/ejptemponew?Date_a_remonter={{now().strftime("%Y-%m-%d")}}&TypeAlerte=TEMPO
    value_template: "{{ value_json['JourJ'].Tempo }}"
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)
  - platform: rest
    name: 'Jours Rouge restants'
    resource: https://particulier.edf.fr/bin/edf_rc/servlets/ejptempodaysnew?TypeAlerte=TEMPO
    value_template: '{{ value_json.PARAM_NB_J_ROUGE }}'
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)
  - platform: rest
    name: 'Jours Blanc restants'
    resource: https://particulier.edf.fr/bin/edf_rc/servlets/ejptempodaysnew?TypeAlerte=TEMPO
    value_template: '{{ value_json.PARAM_NB_J_BLANC }}'
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)
  - platform: rest
    name: 'Jours Bleu restants'
    resource: https://particulier.edf.fr/bin/edf_rc/servlets/ejptempodaysnew?TypeAlerte=TEMPO
    value_template: '{{ value_json.PARAM_NB_J_BLEU }}'
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)

Et après un redémarrage on doit obtenir ça :

EJP

Ici aussi on crée quelques sensor:

  - platform: rest
    name: "EJP Aujourd'hui"
    resource_template: https://particulier.edf.fr/bin/edf_rc/servlets/ejptemponew?Date_a_remonter={{now().strftime("%Y-%m-%d")}}&TypeAlerte=EJP
    value_template: '{{ value_json.JourJ.EjpSud }}'
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)
      
  - platform: rest
    name: 'EJP Demain'
    resource_template: https://particulier.edf.fr/bin/edf_rc/servlets/ejptemponew?Date_a_remonter={{now().strftime("%Y-%m-%d")}}&TypeAlerte=EJP
    value_template: "{{ value_json['JourJ1'].EjpSud }}"
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)
      
  - platform: rest
    name: 'Jours restants'
    resource: https://particulier.edf.fr/services/rest/referentiel/historicEJPStore?searchType=ejp
    value_template: '{{ 22 - value_json.SUD.TotalCurrentPeriod }}'
    headers:
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)

Et on obtient :

Exploitation

Pour exploiter ces information dans Home Assistant il sera souvent plus facile d'utiliser un binary_sensor:, voici donc l'exemple pour le tarif EJP :

- platform: template
  sensors:
    ejp_on:
      friendly_name: "Edf : EJP"
      value_template: "{{ is_state('sensor.ejp_aujourd_hui', 'EST_EJP') }}"
      device_class: power   

- platform: template
  sensors:
    ejp_on_demain:
      friendly_name: "EdF : EJP Demain"
      value_template: "{{ is_state('sensor.ejp_demain', 'EST_EJP') }}"
      device_class: power

Ce qui donne :

Chacun pourra fignoler à sa guise, en modifiant la couleur des icônes en fonction de l'état ou en envoyant les notifications idoines... Merci à Patrice pour son aide !

Sources

 

 

Home Assistant, ESP & Téléinfo

On a vu précédemment qu'il était possible de récupérer la consommation électrique via le site Enedis, mais que c'était compliqué et lié au compteur Linky. On va explorer ici une méthode pour récupérer ces informations, plus complètes, directement sur le compteur, avec pour avantage que ça fonctionne également sur les anciens compteurs.

Je n'ai pas écrit cet article et encore moins réalisé ce montage (pour l'instant). Mais la nuit, on discute au sein d'une groupe Telegram des plus confidentiels (sur invitation et parrainage s'il vous plait) et c'est Mathieu (@Bibinsa) qui a réalisé ce montage et le code qui va avec. Face à la demande je lui ai donc demandé de me faire un récap et il m'a envoyé un fichier texte dans la plus pure tradition des codeurs. Je vais donc faire le secrétaire.

L'objectif ici est de récupérer les informations du compteur électrique.

  • compteurs à informations numériques (testé sur les compteurs pré-Linky mais devrait fonctionner aussi avec Linky)
    information Téléinfo TIC diffusées sur les afficheurs
  • Dans les installations "modernes", le compteur se situe dans le bâtiment (maison, ...) et un report Teleinfo est positionné sur le domaine public (rue, ...).

Cela permet aux agents (ENEDIS/Régie locale/Sous-traitant/...) de récupérer l'information sans demander l'accès au compteur dans la maison. Linky et son infrastructure de téléreport déployée en mode "cloud" devrait à terme changer ce mode de fonctionnement. Pour autant, les compteurs Linky sont toujours munis de la sortie TIC.

Pour les spécifications techniques, Google est votre ami :

Ces compteurs sont donc munis d'un bornier avec les indications I1 et I2. Ce bornier n'est pas protégé par un scellé et est donc accessible sans sortir du cadre contractuel. Plusieurs solutions de récupération de l'information Teleinfo sont disponibles, Google est à nouveau votre ami. Nous allons ici voir une solution :

  • économe
  • pas si compliquée à mettre en œuvre pour qui connait un peu les différents éléments mis en place
  • ouverte (open source)
  • utilisant des protocoles de communication orientés domotiques

Le matériel

L'idée ici est de ne pas utiliser un système complexe (ordinateur Linux/Windows/...) pour récupérer simplement une information texte. Dans le monde de l'IoT, des chipsets très pratiques inondent nos équipements WiFi : les ESP8266 et dérivés. N'importe quel module basé sur un ESP82xx convient, pour peu que celui-ci dispose d'un GPIO RX accessible facilement. Donc des Sonoff, des Wemos, ...

Pour ce besoin spécifique, un Wemos D1 mini est le candidat idéal :

  • petit (pourra s'intégrer dans le compartiment du bas sur les compteur classiques)
  • bien pratique car muni d'une port micro-USB pour alimentation et pour le "flash"

Ce module servira d'intelligence, c'est lui qui fera tourner le petit système d'exploitation qui récupèrera les infos et les transmettra. A ce module, il faut ajouter un module TiC de type Serial qui se connecte aux bornes I1/I2 et permet la conversion du signal au format série. De la même manière, de nombreux montages sont disponibles sur Internet. Qu'on peut se faire soi-même ou commander.

Un français (forcément... on est un peu les seuls à avoir ce système... Minitel, TousAntiCovid toussa toussa) "Charles Halard" propose des modules tout prêts appelés PitInfo. Plusieurs shield disponibles dont le PitInfo light qui convient très bien. Ce module est compatible physiquement avec les Raspberry Pi (Zero, Zero W) mais ces ordinateurs sont bien trop puissant pour notre besoin. je vous conseille de commander ce module avec les connecteurs pré-soudés, ce n'est pas l'écart de prix qui va changer grand chose...

Nous allons donc nous servir de la capacité de l'ESP8266 à se connecter à n'importe quel shield. Et côté câblage ça donne :

  1. PitInfo TiC vers les bornes I2/I2
  2. Wemos D1 3,3V vers PitInfo Vcc
  3. Wemos GND vers PitInfo GND
  4. PitInfo Tx vers Wemos D1 Rx pour la communication et c'est tout

On n'oublie pas d'alimenter le Wemos en USB bien sûr. Le tout fonctionne donc en 3,3V et est alimenté par un simple câble micro-USB (5V). Il est également possible de s'alimenter sur la sortie idoine low voltage directement sur le compteur, mais dans ce cas cela nécessitera un convertisseur. A noter que si le compteur est situé en dehors du domicile, il sera souvent possible d'utiliser l'ancien câble servant au HP/HC pour y faire transiter les information série (les commandes HP/HC pouvant avantageusement être gérées par Home Assistant).

Mais avant de câbler tout ça, on va trouver un Firmware à mettre sur le Wemos D1 mini. On débranche PitInfo du Wemos... on va avoir besoin de libérer le port série.

Le firmware

Je suis un grand fan de Tasmota (ntlr : tout mon monde le sait), l'OS open source initialement inventé par Theo Arends pour piloter les modules chinois SonOff. Ce firmware alternatif est rapidement devenu compatible avec tous les ESP82xx (et bientôt les ESP32). On ne va pas parler ici de Tasmota, mais de comment récupérer la Teleinfo avec Tasmota.

Depuis la version 8.4, Tasmota embarque de quoi interpréter les infos Teleinfo. Et c'est grace en partie, au développeur de PitInfo. Seul bémol, les binaires Tasmota précompilés n'embarquent pas le code Teleinfo. Il faut donc le compiler soi-même... enfin presque. Une plate-forme de développement online, qui fonctionne avec un compte github, permet de compiler très simplement et sans compétence particulière un firmware Tasmota avec des options particulière. Cette plate-forme c'est GitPod. On se loggue sur github, on donne les droits à Gitpod. La doc Tasmota expique tout en détail et deux options sont possibles :

  1. - firmware stable
  2. - firmware dévellopement

Une dernière option, encore plus simple est disponible avec gitpod : tasmocompiler. C'est une interface web qui permet en quelques clic de compiler son firmware. Nous allons utiliser celle-ci. On charge l'URL dans un navigateur et on va prendre un café (c'est un peu long... ça compile au premier démarrage). Ensuite on check les autorisations de popup aussi, TasmoCompiler va lancer un popup avec l'interface web. Une fois le café ingurgité on est en face de l'interface web de Tasmocompiler en 5 étapes :

  1. on clic sur Download Source Code + Next
  2. La configuration WiFi : on peut passer cette étape si on maitrise l'onboarding Tasmota WiFi sinon c'est ici qu'on peut préconfigurer le SSID+Password (+ conf IP statique si besoin... pas conseillé !!!)
  3. Select Features : on ne va pas se mentir... Teleinfo n'est pas dans les features les plus réclamées par la communauté. Nous n'avons donc pas notre petite case à cocher ici.
    • Laisser les features pré remplies
    • Sélectionner des features supplémentaires si besoin (sensors T° ?)
  4. Custom parameters : c'est la partie qui nous intéresse, on ajoute :
     #ifndef USE_TELEINFO
     #define USE_TELEINFO
     #endif
  5. Select version and compile
    • sécurité : version prod (9.1.0 à la date de cet article)
    • core : 2.7.4
    • language : english - french ?
    • board : on peut spécifier Wemos D1 mini
    • speed : 80 MHz c'est largement suffisant

Compile ! (et second café... ). On récupère le binaire (firmware.bin) et c'est presque gagné. Il nous reste à uploader Tasmota sur le Wemos. Le Wemos D1 mini a de grands avantages :

  • un port micro-USB qui permet de communiquer avec lui
  • le mode flash par défaut, aucune manipulation

On va utiliser ici l'outil qui a grandement simplifié le flash des modules ESP82xx : Tasmotizer, Sous Windows, Mac ou Linux, une fois l'outil installé proprement :

  • Brancher le Wemos à votre ordinateur
  • Lancer tasmotizer
  • Sélectionner le bon port COM
  • Select Image : votre firmware.bin précédemment compilé
  • Erase flash before flashing (c'est toujours plus propre)
  • Tasmotize !!!

Quelques secondes plus tard, votre module est prêt. On peut procéder au câblage comme indiqué au début de l'article. Une fois le module démarré, et selon votre configuation WiFi dans tasmocompiler :

  • il diffuse un hotspot pour l'onboarding (se connecter au SSID diffusé, portail captif qui permet de configurer les paramètres wifi du module)
  • il est accroché au SSID préconfiguré dans tasmocompiler

On peut se connecter à l'interface web de celui-ci pour effectuer sa configuration Tasmota :

La première étape de configuration est la déclaration du template. Un template c'est une sorte de préconfiguration du module. C'est ici qu'on spécifie le type de module utilisé (Teleinfo) et la réception des infos sur le connecteur Rx du Wemos. Le plus simple ici est d'aller sur la Console web et entrer les commandes :

  • Template {"NAME":"Wemos PitInfo","GPIO":[255,255,255,210,255,255,255,255,255,255,255,255,255],"FLAG":15,"BASE":18}
  • module 0

Le module redémarre. Si tout est bien connecté, vous devriez voir les informations Teleinfo sur la page web principale de Tasmota. Par défaut, le module utilise 1200 bps pour le port série. C'est la vitesse du port Teleinfo des compteurs classiques. Les compteurs Linky fonctionnent en 9600 bps, il faut donc modifier la vitesse en mode console SetOption102 1 et là ça devrait fonctionner pour les compteurs Linky, C'est pas mal mais ce n'est pas l'objectif.

Tasmota est surtout connu pour son support MQTT. On peut le configurer et récupérer toutes les informations via ce protocole. On va supposer ici que vous connaissez MQTT et que vous avez un broker de configuré. Dans Tasmota nous allons devoir entrer les informations suivantes (dans l'interface web de configuration ou sur la page console qui permet d'entrer des commandes) :

  • broker : addresse IP
  • topic : le topic de base du module (exemple ici : mon_wemos_teleinfo)
  • fulltopic : l'arboresence complète avec les variables
       exemple ici : maison/tasmota/%topic%/%prefix%/

Le module redémarre et est désormais accroché en MQTT à votre broker. Il peut se configurer, se piloter via ce protocole grâce auquel il envoie sa télémétrie. Nous allons maintenant régler cette dernière information. Deux possibilités :

  • Message MQTT à chaque modification sur le compteur 
  • Message MQTT à intervalle régulier (mode par defaut)

Pour ma part j'ai essayé la première option : c'est trop verbeux. Chaque seconde un message MQTT c'est trop souvent pour ce qu'on souhaite récupérer. Cependant, pour un monitoring très précis de la puissance (encore que... le Power n'est pas si précis que ça avec les moteurs, ...) le premier mode peut s'avérer utile. Pour l'activer on passe en mode console SetOption108 1. Si vous êtes resté sur le mode Télémétrie Energy (par défaut), vous allez avoir les informations dans le topic :

maison/tasmota/mon_wemos_teleinfo/tele/SENSOR

avec comme valeur quelque chose comme ça :

{"Time":"2020-11-18T12:16:28","ENERGY":{"TotalStartTime":"2020-10-18T00:00:00","Total":1861.951,"Yesterday":61.250,"Today":36.852,"Period":0,"Power":630,
"Current":3.000,"Load":6,"ADCO":"xxxxxxx","OPTARIF":"HC..","ISOUSC":45,"HCHC":62617552,
"HCHP":67058436,"PTEC":"HP..","IINST":3,"IMAX":52,"PAPP":630,"HHPHC":"A","MOTDETAT":0},"BME280":{"Temperature":9.8,"Humidity":53.6,"DewPoint":0.8,"Pressure":1009.0},"PressureUnit":"hPa",
"TempUnit":"C"}(spoiler : il y a un capteur de T°/Hum/Pression en + ici)

Pour ajuster la fréquence de report de la télémétrie, en console teleperiod <valeur en secondes>, pour garder le contenu en mémoire du broker (retain), toujours sous la console sensorretain 1.

Tasmota intègre nativement un suivi de consommation d'énergie. Le mode Teleinfo prend comme source le champ PAPP de Teleinfo et s'en sert de Wattmètre. Tasmota génère ensuite 3 compteurs :

  1. Daily (reset à 00h00)
  2. Yesterday (valeur de la veille)
  3. Total (valeur depuis la première initialisation)

On va s'en servir ensuite dans Home Assistant. il est possible de modifier ces valeurs, en particulier Total, pour s'en servir de compteur mensuel, annuel, ...

Configuration Home Assistant

C'est ici qu'on va voir toute la souplesse et la puissance de HA lorsqu'il récupère des informations de Tasmota. Nos objectif sont :

  • L'affichage des infos via des sensors dans Lovelace (Power, HC/HP, ...) et l'utilisation de certaines afin de conditionner des automations (HP/HC; EJP, ...)
  • Le suivi conso énergie via utility_meter: (autre article à venir...)

Toute la configuration se fait en mode sensor. On créée un sensor MQTT qui va se sourcer des informations JSON ENERGY généré par Tasmota toutes les x secondes (teleperiod), on créée également des sensor template qui vont parser les attributs du sensor MQTT pour extraire les infos souhaitées. Exemple :

Par exemple 

sensor:

# Teleinfo

#### Wemos D1 Mini + PitInfo : Teleinfo
#    - sensor = Energy Today (consommation journalière)
#    - attributs = tout le reste du JSON

- platform: mqtt
  name: 'Wemos PitInfo'
  state_topic: "maison/tasmota/mon_wemos_teleinfo/tele/SENSOR"
  value_template: "{{ (value_json['ENERGY'].Today) |float }}"
  unit_of_measurement: "kWh"
  device_class: energy
  availability_topic: "maison/tasmota/mon_wemos_teleinfo/tele/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  json_attributes_topic: "maison/tasmota/mon_wemos_teleinfo/tele/SENSOR"
  qos: 1
#
#### Teleinfo attributes from Wemos_PitInfo
#
- platform: template
  sensors:
    #
    # Power
    teleinfo_puissance:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").Power }}'
      unit_of_measurement: "W"
    #
    # EnergyHC
    teleinfo_energyhc:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHC }}'
      unit_of_measurement: "Wh"
    #
    # EnergyHP
    teleinfo_energyhp:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHP }}'
      unit_of_measurement: "Wh"
    #
    # Energy Total + attr HP/HC
    teleinfo_energy:
      value_template: '{{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHC + state_attr("sensor.wemos_pitinfo","ENERGY").HCHP }}'
      unit_of_measurement: "Wh"
      attribute_templates:
        Index HP: >-
          {{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHP }}
        Index HC: >-
          {{ state_attr("sensor.wemos_pitinfo","ENERGY").HCHC }}
    #
    # Energy yesterday
    teleinfo_energy_yesterday:
      value_template: '{{ ( state_attr("sensor.wemos_pitinfo","ENERGY").Yesterday *1000 ) |int }}'
      unit_of_measurement: "Wh"
    #
    # Energy total (year)
    teleinfo_energy_total:
      value_template: '{{ ( state_attr("sensor.wemos_pitinfo","ENERGY").Total *1000 ) |int }}'
      unit_of_measurement: "Wh"
    #
    # Periode Tarifaire
    teleinfo_periode_tarifaire:
      value_template: '{{ (state_attr("sensor.wemos_pitinfo","ENERGY").PTEC) |replace("..","") }}'

A partir de là vous voilà avec des sensors qui peuvent servir de sources de données pour faire du suivi de consommation (energy_meter) comme vu dans d'autres articles.

  • sensor.teleinfo_puissance : Puissance instantanée
  • sensor.teleinfo_energyhc : Index Heures Creuses (pour calcul coût)
  • sensor.teleinfo_energyhp : Index Heures Pleines (pour calcul coût)
  • sensor.teleinfo_energy : Sommes des 2 index HC et HP (pour calcul consommation Wh)
  • sensor.teleinfo_energy_yesterday : consommation de la veille
  • sensor.teleinfo_energy_total : consommation totale depuis initialisation du module (reset manuel, peut-être programmé en début d'année pour calculer une consommation annuelle avec Tasmota)
  • sensor.teleinfo_periode_tarifaire : période tarifaire (pour calcul coût)

Avec tout cela vous pouvez avoir le suivi d'énergie journalier global de votre installation avec ces sensors. A coupler avec un utility_meter pour avoir le suivi. Il est possible d'y associer le coût, en ajoutant à HA les informations de votre abonnement (la séparation HC/HP est faites pour ça !)

Amusez-vous bien !

Sources

 

Home Assistant, RC & Lights

Me voici bien installé sous Home Assistant, j'ai choisi au départ Zigbee pour les capteurs de température et d'ouverture, puis au hasard des pubs sur Ali Express et de mes passages chez Ikea j'ai acheté diverses télécommandes en me disant que j'en ferait bien quelque chose... L'usage principal étant de piloter des éclairages ou des scènes, du son, ou encore une action du genre "chauffe la salle de bain" et dis à Alexa de me prévenir quand la température sera idéale". Bien sur on peut remplacer les télécommandes par Alexa ou GH, mais ça me fait toujours bizarre de parler à ces objets, surtout quand je ne suis pas seul...

Bref, pour piloter un éclairage depuis une télécommande Zigbee il existe plusieurs approches plus ou moins facile à mettre en œuvre. On part du principe que Zigbee s'appuie sur ZHA, Zigbee2Mqtt, Deconz ou directement en MQTT.

Phoscon

Il s'agit ici de l'interface de Deconz qui est la solution la plus répandue et à mon gout la plus performante. Cette passerelle va plus loin que les autres en ce sens qu'elle intègre une interface qui permet facilement d'associer les touches d'une télécommande à des ampoules ou des prises. En fait au départ Phoscon est juste fait pour remplacer les passerelles propriétaires (Hue, Ikea, etc.) sans pour autant disposer de Home Assistant et il est même possible de créer des scènes et de disposer des fonctionnalités des passerelles émulées.

C'est donc la solution idéale quand on ne dispose que d'ampoules ou prises Zigbee, d'autant plus que ces éléments seront toujours disponibles sous HA pour d'autres actions et que cette passerelle est compatible Alexa. Personnellement je recommande l'installer sur un vieux RPI à part et ainsi la placer au centre du logement.

Automations

Mais, ça va se compliquer quand on va vouloir associer une télécommande Zigbee à un équipement non Zigbee. J'ai par exemple quelques variateurs Shelly et je voulais y associer une télécommande Opple afin de plus bouger mon cul du canapé, bien que dans la vraie vie je passe tout de même plus de temps dans mon fauteuil de bureau.

La solution consiste donc à écrire des automations en se basant sur les devices et les codes retournées par ces télécommandes. C'est long, fastidieux et encombrant quand on sait qu'il faut 4 automations pour gérer les fonctions de base d'une ampoule variable , et je ne parle pas de la gestion des couleurs. C'est lourd, mais ça fonctionne à coup de copié / collé, et le faire sous NodeRed sera tout aussi fastidieux.

ControllerX

Alors j'ai longtemps laissé ces télécommandes en déshérence, puis un soir je me suis mis à explorer la communauté HA (celle en anglais) à la recherche d'une alternative, et je suis tombé sur ControllerX. Au départ je n'ai pas aimé car ça s'appuie sur AppDaemon qu'il me fallait installer, ce qui alourdit mon serveur HA. Et puis en lisant je me suis dit que ça valait le coup de creuser la chose.

Je vous laisse installer AppDaemon 4, c'est un AddOn qui s'installe comme les autres depuis le superviseur sur Hassio. On peu aussi l'installer en Docker pour ceux qui aiment se compliquer la vie. Il faut juste créer un fichier de config basic qui sera suffisant pour ce que l'on va en faire dans :

secrets: /config/secrets.yaml
appdaemon:
  latitude: 52.379189
  longitude: 4.899431
  elevation: 2
  time_zone: Europe/Paris
  plugins:
    HASS:
      type: hass
http:
  url: http://127.0.0.1:5050
hadashboard:
admin:
api:

/config/appdaemon/appdaemon.yaml

Ensuite on va installer ControllerX depuis HACS et une fois fait créer le fichier de config, non pas de ControllerX mais des apps AppDaemon :

sejour_halogène: 
  module: controllerx
  class: WXCJKG13LMLightController
  controller: aqara_opple
  integration: deconz
  automatic_steps: 30
  mapping:
    3001: hold_brightness_toggle
    3002: toggle
    3003: release
    3004: toggle_full_brightness
    3005: toggle_min_brightness
  light: light.shelly_shdm_1_f3758  

/config/appdaemon/apps/apps.yaml

Et la lumière fut ! Ces quelques lignes assurent les 5 fonctions d'une touche de ma télécommande qui en comporte 6. Et encore ici j'ai choisit un mapping personnalisé car je souhaite que chaque touche ne commande qu'un seul point lumineux en me servant du multiclic, mais ça serait encore plus simple si je voulais juste reproduire les fonction d'une télécommande Ikea ou Hue avec l'ampoule ivrée avec.

Explications lignes par lignes :

  1. un nom d'app que vous choisissez.
  2. le nom du module AppDaemon, ici ControllerX.
  3. le code de la télécommande utilisée : ici le controleur Opple avec 6 boutons (ici la liste des contrôleurs supportés).
  4. l'ID du device fournit par la passerelle (controller_id ou adresse IEEE (voir ici comment récupérer cette information).
  5. L'intégration utilisée (deconz, mqtt, zha, state) (plus d'informations ici).
  6. Des options (multiple_click_delay: 500, delay: 50, automatic_steps: 30, manual_steps: 10 (je vous laisse cherche run peu car il y en d'autres).
  7. Les mapping, ce qui qui va consister à associer les codes envoyés par la télécommande aux fonctions possibles.
  8. Enfin, on pointe sur l'éclairage déclaré dans Home Assistant, ici un Dimmer Shelly.

Je n'ai parlé ici que de ce que j'ai utilisé. Mais ControllerX va beaucoup plus loin. Il est bien sur possible de piloter des scènes, des automation ou encore des lecteurs multimédia, et par exemple d'associer le bouton rotatif Ikea à votre lecteurs Sonos. Je vous conseille la lecteur du sujet dédié et bien sur de la doc sur GitHub, même si ce développeur est bien dans le codage de ses url qu'il faudra souvent reconstituer...

Bonus

Il existe deux intégration intéressantes à associer à ces problématiques, d'abord Light Switch qui va permettre de créer une entité de type lampe à partir d'un switch, et ensuite Light Group qui va permettre de grouper plusieurs lampes pour en faire une seule...

Edit

Alors depuis que j'ai écrit cet article il y une nouveauté dans Home Assistant : Blue Print. Cela va permettre de télécharger des automations (partagées ici par exemple, et bientôt sur HACF) qui vont permettre de gérer des télécommandes en quelques clics et sans rentre dans le code. Le catalogue s'étoffe de jours en jours, donc n'hésitez pas à y retourner.

Il n'en reste pas moins qu'il y a une chose que je n'ai pas trouvé en Blue Print. Je voulais avec une télécommande Ikea 5 boutons, pouvoir passer d'une ampoule à une autre avec les touches directionnelles.  Et ça je n'ai réussit à le faire qu'avec ControllerX, en créant un input_select: et en me servant des options de contrainte, voilà un exemple pour deux lampes :

select_light_app:
  module: controllerx
  class: CallServiceController
  controller: ikea_tradfri_rc
  integration: deconz
  mapping:
    4002:
      service: input_select.select_previous
      data:
        entity_id: input_select.rc_ikea_1
    5002:
      service: input_select.select_next
      data:
        entity_id: input_select.rc_ikea_1

light_app_1:
  module: controllerx
  class: E1810Controller
  controller: ikea_tradfri_rc
  integration: deconz
  light: light.shelly_shdm_1_f3d426
  constrain_input_select: input_select.rc_ikea_1,light_1
  excluded_actions: [4002, 5002]

light_app_2:
  module: controllerx
  class: E1810Controller
  controller: ikea_tradfri_rc
  integration: deconz
  light: light.shelly_shdm_1_f3a100
  constrain_input_select: input_select.rc_ikea_1,light_2
  excluded_actions: [4002, 5002]

Home Assistant & Enedis

Dans le grand foutoir de la pseudo concurrence des fournisseurs d'électricité on trouve Enedis qui gère les infrastructures et vous colle d'autorité un compteur Linky. On ne va pas parler ici des polémiques que cela à suscité, sa dangerosité sanitaire est très certainement moindre que toutes les technologies que nous utilisons, tout au moins pourrais t'on s'interroger sur son cout global qui sera nécessairement répercuté sur les clients.

Ce qui m'intéresse ici c'est ce que l'on peut en faire. Enedis remonte en temps (presque) réel (toutes les heures) les informations de consommation et on peut donc imaginer qu'il est possible de récupérer facilement ces informations qui après tout nous appartiennent. En fait ce n'est pas si simple et il semblerait que ce soit tout le contraire, Enedis faisant tout pour en limiter l'usage à la consultation de son piètre site web, tout en ayant certainement une arrière pensé de monétisation possible... Ainsi, au fil du temps, les diverses extensions permettant la récupération de ces informations ont été mises en échec.

A ce jour, et d'après mes informations, la règle est que seule une société a la possibilité de demander un accès (gratuit pour l'instant) à l'API. Ca limite fortement nos habitudes de DIY !

Alors un développeur de la communauté (M4dm4rtig4n) a eu la riche idée, un projet personnel qui se sert de la façade légale de son employeur, de monter une passerelle d'accès : https://enedisgateway.tech. On lui fait confiance, il fera tout pour assurer la confidentialité des données, mais l'utilisation de cette passerelle sous entend de confier l'accès à vos données à cette société. Le risque est faible, les données peu sensibles, le jeton est révocable, et surtout rien ne vous force à utiliser cette passerelle qui pour l'instant est la seule solution fonctionnelle.

Dans la pratique

On commence, si ce n'est pas fait, par créer un compte sur le site Enedis et y associer votre compteur Linky. Attention, j'espère qu'Enedis maitrise mieux le réseau électrique que le CSS car il y a pas mal de bugs et il vaudra mieux faire tout ça avec Firefox, car aléatoirement ça ne passe pas sous Edge ou Chrome (qui est juste le navigateur le plus utilisé au Monde). Ensuite on se rend sur la passerelle (https://enedisgateway.tech) et on crée un token qui aura cette forme :

Votre token : 1ETPfWPjxmkHe2GfsggdfhdgfshgfhgfNRKnhdgfhMpOrGzKe3i

Vos points de livraison : 258465654641

Il ne faut pas oublier d'activer l'enregistrement de la consommation horaire et de sa collecte si on veut disposer des infos HP/HC. Une commande de test est fournie, elle permettra de vérifier que ça fonctionne avant de passer à la suite

curl -X POST https://enedisgateway.tech/api -H 'Authorization: 1ETPfWPjxmkHe2G2hj87w8shfgsdfghsdfghhsfghgfhjsfOrGzKe3i' -H 'Content-Type: application/json' -d '{"type": "consumption_load_curve","usage_point_id": "25464656546695","start": "2020-11-10","end": "2020-11-11"}'

A partir de là on peu repasser sous Home Assistant et installer dans HACS deux Custom repositories créés par un autre développeur de talent (saniho) de la communauté HACF, qui correspondent d'une part à un composant qui va créer un sensor personnalisé, et d'autre part une carte pour Lovelace.

Une fois ces deux installations terminées on redémarre Home Assistant, et on crée le sensor, ce qui nécessitera un nouveau redémarrage.

sensor:
    - platform: myEnedis
      token: fTEHWCldfsgsdfghsjdhjdFGHJFHSDHDSFGhfdfhNfWqwCE3
      code: 464554438199434
      heures_creuses: "[['00:00','05:00'], ['21:30', '24:00']]"
      hc_cout: 0.1337
      hp_cout: 0.1781
      scan_interval: 3600
      delay: 7200  # OPTION

Après un redémarrage et le temps que tout se mette en place, le sensor.myenedis devrait nous retourner ces informations :

attribution: ''
version: 1.0.2.5
lastSynchro: '2020-11-20T23:51:21.456065'
lastUpdate: '2020-11-20T23:51:21.456048'
timeLastCall: '2020-11-20T23:51:21.456021'
yesterday: 53347
last_week: 240629
day_1: 53347
day_2: 42741
day_3: 42420
day_4: 30767
day_5: 36311
day_6: 35932
day_7: 32130
daily:
  - 53.347
  - 42.741
  - 42.42
  - 30.767
  - 36.311
  - 35.932
  - 32.13
halfhourly: []
offpeak_hours: 19.947
peak_hours: 33.4
peak_offpeak_percent: 62.60895645490843
yesterday_HC_cost: 2.6669139000000004
yesterday_HP_cost: 5.94854
daily_cost: 8.6154539
current_week: 169275
last_month: 909684
current_month: 702447
last_year: null
current_year: 2670999
errorLastCall: >-
  {'error': 'result_404', 'enedis_return': {'error': 'no_data_found',
  'error_description': 'no measure found for this usage point', 'error_uri':
  'https://bluecoder.enedis.fr/api-doc/consulter-souscrire'}}
monthly_evolution: 0
unit_of_measurement: kWh
friendly_name: myEnedis

Vous pourrez utiliser ces données à souhait, ce sont des attributs, mais le plus simple reste de créer une carte custom et on y coller ça :

type: 'custom:content-card-linky'
entity: sensor.myenedis
showInTableUnit: false

Et le résultat est tout de suite bien plus lisible. Voilà. Et pour suivre le projet ça se passe ici sur HACF.

Alternatives

Ici je vous ai parlé d'une solution native dans Home Assistant. Mais les afficionados de NodeRed vous diront que non, que c'est nul et qu'il faut le faire en NR. Vu que je ne parle jamais de NodeRed, vous avez déjà compris que je ne suis pas fan, même si j'ai pas mal testé et que je trouve le concept génial, pour l'heure je préfère me cantonner au YAML, après tout j'en ai bien chié pour comprendre, et comme disais ma tante qui n'avais jamais eu de descendance, je ne vais pas jeter tout de suite le bébé avec l'eau du bain ! Mais bon, pour ceux qui veulent faire tout ça avec NodeRed, ça se passe ici, toujours sur HACF.

Une autre possibilité est de se servir de la prise Teleinfo que l'on trouve sur les compteurs, mêmes plus anciens. Il existe plusieurs montages DIY, certains à base ESP et même sous Tasmota. Mais ça on en reparlera bientôt.

EDIT 18/03/2021 : Cette intégration comporte deux dépendances de taille. Enedis dont la plateforme est instable et n'a aucune volonté de rendre ces donnes disponibles, tout au moins gratuitement et facilement. Du coup seul les professionnels peuvent y accéder, mais certains fournisseurs alternatifs commencent à proposer une API. L'autre dépendance c'est l'intermédiaire bénévole sur lequel s'appui cette intégration. Il faut de son mieux tout comme le développeur. Mais voir cette intégration cassé lors de chaque redémarrage, devoir régulièrement refaire un consentement, bref, pas envie de revivre l'époque Jeedom avec des plugins instables. Donc j'ai désactivé, je reste en observation, mais je m'appuie sur mon Shelly EM, peut être un peu moins précis mais bien plus fiable pour l'instant.

 

Home Assistant, Shelly & Energy

Il y a quelques avantages à choisir des modules Shelly plutôt que des chinoiseries. D'abord ces modules sont aux normes européennes, et ce n'est pas juste un adhésif CE posé par un mineur au fond d'une usine chinoise (pensez surtout aux assurances qui peuvent se montrer tatillonnes en cas de sinistre), le tarif est accessible et si vous avez une question (technique ou autre) le CEO de la boite vous répondra dans le fil Facebook de la marque ou par mail.

Une chose intéressante est également que beaucoup de ces modules remontent la consommation instantanée et cumulée. Je pensais naïvement que tous conservaient la consommation cumulée en cas de coupure secteur, mais, même si dixit le CEO c'était vaguement en projet en 2019, ce n'est toujours pas le cas et cette information sera perdue localement (sauf EM), bien qu'elle reste accessible sur le cloud Shelly via l'application idoine, mais impossible à récupérer via l'API.

Pour conserver cette information je me suis un peu torturé l'esprit depuis quelques jours en cherchant différentes solutions pour stocker et conserver ce chiffre, alors qu'en fait la solution était sous mes yeux et que je l'avait déjà utilisée quand j'avais déployé mon module de calcul des couts électrique globaux. La solution passe par l'intégration utility_meter: proposée de base par Home Assistant.

Utility Meter est une intégration qui va permettre de stocker le cumul d'une valeur sur une période donnée (hourlydailyweeklymonthlybimonthlyquarterly and yearly), ainsi que la même valeur sur la période n-1. Par exemple, si vous configurez en journalier,  à 13:45 vous pourrez afficher (ou utiliser) la valeur de consommation d'un compteur depuis minuit ainsi que celle à la même heure pour le jour précédent. Imaginez juste le code et les template qu'il aurait fallut imaginer sans cette intégration...

En ce qui me concerne, en prenant par exemple un Shelly 1PM qui pilote un convecteur, ce qui va m'intéresser est de connaitre la consommation cumulée en cours et celle pour le même jour l'an dernier.

Bien sur il est possible, avec un peu d'imagination et quelques lignes de code YAML, de stocker les années précédentes dans un input_number: ou même l'évolution dans une base de données et pour les plus maniaques d'utiliser Grafana pour afficher de beaux histogrammes. Même si ça ne changera probablement rien à la facture EdF, en partant du principe que si la domotique apporte un indéniable confort, de part le surcoût induit elle permet au final rarement réaliser de vraies économies.

En pratique

Dans cet exemple j'utilise l'intégration Shelly for Hass, mais il est toute à fait possible de faire la même chose avec d'autres types de modules, voire en intégrant les modules Shelly (ou autres) avec MQTT...

On crée nos entrées utility_meter: dans notre fichier de configuration : 

utility_meter:
  energy_total_yearly_ch_bureau:
    source: sensor.shelly_shplg_s_f8ccf83_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_cheminee:
    source: sensor.shelly_shsw_pm_68c63afaf521_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_salon:
    source: sensor.shelly_shsw_pm_68c63afaf658_total_consumption
    cycle: yearly
    
  energy_total_yearly_ch_cuisine:
    source: sensor.shelly_shsw_pm_68c63afaf1ca_total_consumption
    cycle: yearly

Ensuite on va pouvoir les utiliser directement pour les afficher, ici dans une carte ou j'ai utilisé le composant multiple-entity-row pour les besoins de l'affichage. Vous remarquerez l'utilisation de l'attribut last_period pour afficher l'année précédente.

entities:
  - entities:
      - attribute: last_period
        name: Année passée
        unit: kWh
    entity: sensor.energy_total_yearly_ch_cheminee
    name: Convecteur Cheminée
    secondary_info: last-changed
    show_state: true
    state_header: Année en cours
    type: 'custom:multiple-entity-row'
title: Consomation cumulée
type: entities

Bonus

Etant donné que j'avais dans un séjour ouvert trois convecteurs qui fonctionnent en même temps, j'ai créé deux sensor: pour regrouper ces informations afin de pouvoir afficher une seule ligne pour le séjour, un pour l'année en cours et un pour l'année précédente, qui de fait sera à zéro pour un moment. Attention, utility_meter: commence à compter au moment ou les entrées sont crées.

- platform: template
  sensors:
    energy_total_yearly_ch_sejour:
        friendly_name: "Total Séjour"
        unit_of_measurement: 'kWh'
        value_template: "{{ 
            (states('sensor.energy_total_yearly_ch_cheminee') | float) +
            (states('sensor.energy_total_yearly_ch_cuisinee') | float) +
            (states('sensor.energy_total_yearly_ch_salon') | float) }}"

- platform: template
  sensors:
    energy_total_yearly_ch_sejour_last_period:
        friendly_name: "Total Séjour (N-1)"
        unit_of_measurement: 'kWh'
        value_template: "{{ 
            (states('sensor.energy_total_yearly_ch_cheminee.attributes.last_period') | float) +
            (states('sensor.energy_total_yearly_ch_cuisinee.attributes.last_period') | float) +
            (states('sensor.energy_total_yearly_ch_salon.attributes.last_period') | float) }}"

 

 

EDIT 21/01/2021 : On peut parfois avoir besoin de changer la valeur d'un utility_meter: . Dans les Outils de développement / Services vous trouverez un service utility_meter.calibrate et utility_meter.reset. Sauf qu'il y a un petit bugg et seuls les utility_meter: qui ont une option tariffs: s'affichent. Qu'à cela ne tienne, il suffit de coller le nom de l'entité + TAB et ensuite changer la valeur :

entity_id: sensor.energy_total_yearly
value: 25550

 

 

 

Home Assistant & Visonic

Jadis, quand j'ai commencé à m'intéresser à la domotique, avec une Zibase, j'avais intégré les capteurs de mon système d'alarme Visonic Powermaster Pro. Ensuite sous Jeedom je les ai perdus, j'ai bien tenté avec un RFPLayer, qui dans l'absolu intégrait la techno ZiBase, de les retrouver, mais sans succès tant le plugin dédié et payant étant en dessous de tout. Un échec de plus pour Jeedom, peu importe que ce soit de leur faite ou celle de ZiBlue qui ne fournissait que peu d'informations, le résultat était négatif.

Sous Home Assistant j'ai bien essayé de me servir de la ZiBase pour récupérer ces informations, mais je n'ai pas trop insisté et j'ai fini par tout doubler avec des capteurs Xiaomi/Aqara.

Jusqu'à ce que je découvre la semaine dernière qu'il existait une intégration Visonic ! Mais pour ça il faut que ça communique. La centrale a des options que je n'ai pas et j'étais moyennement chaud pour commander une option RS232 à 80 € sur un site exotique. En lisant un peu j'ai fini par découvrir que cette option ne faisait qu'exposer physiquement le signal qui existe en TTL sur des broches accessibles. Alors j'ai fait des tests avec un câble RS232, USB/RS232 et j'ai même acheté un adaptateur Ethernet / RS232 (USR-TCP232-302) mais ça succès alors que certains disent y être parvenus, et même une pince pour sertir des connecteurs Dupont (l'enfer !), bref je me suis cassé le crane tout un week-end sans succès.

Reste une solution que je n'ai jamais explorée, utiliser un ESP_01 avec le firmware ESP-Link qui convertir les signaux TTL série afin de pouvoir les utiliser en Ethernet depuis l'intégration sous Home Assistant.

Communication

Alors d'abord il faut se procurer le module ESP NodeMCU. Ca doit pouvoir fonctionner avec d'autres ESP et d'autres firmwares mais je me suis contenté de suivre ce que j'ai trouvé. Ca vaut 1 €, c'est minuscule et ca peut tenir dans la centrale qui ainsi devient "WI-FI" !

Pour flasher le firmware ESP-Link il faut un adaptateur USB que je n'avais pas commandé pensant pouvoir le faire avec mon adaptateur USB éclaté. Certains ESP ont un bouton pour les passer en mode flashage, sur celui ci rien de tel, pas plus que sur l'adaptateur... C'est un peu le mystère laissé par les barbus, ne pas tout documenter sans quoi ce serait trop facile, ce genre de montage ça se mérite ! Bref, il faut shunter IO0 et GND avant d'insérer l'objet dans le port USB, ça permet de passer en mode programmation (je l'ai fait juste avec un câble Dupont...).

Maintenant il va falloir trouver un outil de flashage. Mais les barbus bossent sous Linux, et même s'il est possible de faire du Bash ou du Python sous Windows, ma machine ne s'est pas avérée très coopérative...

curl -L https://github.com/jeelabs/esp-link/releases/download/v2.2.3/esp-link-v2.2.3.tgz | \
    tar xzf -
cd esp-link-v2.2.3
esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 4m -ff 40m \
    0x00000 boot_v1.5.bin \
    0x1000 user1.bin \
    0x7C000 esp_init_data_default.bin \
    0x7E000 blank.bin

Si la plupart des outils de flashage sous Windows fonctionnent, et même Tasmotizer, (Mathieu si tu me lis...), on va avoir besoin ici de flasher plusieurs fichiers .bin à des adresses particulières et le seul utilitaire qui a fonctionné est NodeMCU Firmware Programmer, qui selon les ESP utilisés permet de les fichiers flasher au bon endroit...

Une fois cette opération réussie (YES ! Ca m'a pris l'après midi...), on peu détacher l'ESP_01 de son support USB et aller le brancher dans la centrale. Il sera alimenté en 3.5 v par elle et servira d'interface TCP/Serie. Visonic a prévu des connecteurs dans la centrale afin d'y connecter des cartes optionnelles et couteuses, sauf que les signaux sont disponibles sur les connecteurs et que les cartes ne servent qu'à supporter des connecteurs... Des petits malins on fait un joli travail de recherche (voir les sources). Le connecteur qui nous intéresse est celui de gauche et en branchant un petit câble Dupont à 4 fils sur les 4 du haut à droite on sortira aisément GND TX RX et les 3.75 v nécessaires à l'alimentation de notre ESP.

Il ne reste plus qu'à connecter ça à notre ESP aux bons endroits, en inversant RX/TX et en faisant attention au connecteur d'alimentation car il n'y a pas de fusible...

Ensuite on se connecte en WI-FI sur son SSID (ESPxxx) et on renseigne le réseau WI-FI que l'on consacre aux IoT dans l'onglet WI-FI Station, il redémarre et on peu le pinguer... On pense à le mettre en réservation DHCP... Le seul réglage qui nous intéresse est la vitesse (9600 ou 38400 selon les modèles de centrales), et même si ce firmware permet de faire du MQTT et autres joyeusetées on désactive tout, il ne servira qu'à ça !

Intégration à Home Assistant

Cette intégration j'ai du la lancer 50 fois, mais quand on a la bonne communication ça fonctionne du premier coup. Elle permet beaucoup de choses, mais le mode standard qui me permet de voir et utiliser mes capteurs est suffisant. Je m'en contenterais car dans mes bricolages j'ai perdu le code installateur de la centrale ce qui va me limiter à l'avenir ! (code impossible à reseter). EDIT : Je viens d'apprendre qu'on peut justement le récupérer, grâce à une fonction non documentée de cette intégration...

On installe donc l'intégration Visonic, encore un excellent travail d'un passionné, et on renseigne l'IP et le port (23) de notre ESP. Et c'est tout, comme par magie les capteurs remontent ainsi que le panneau de commande. Il sera ainsi possible d'armer et désarmer la centrale depuis Home Assistant (Géoloc, présence pour l'armement et tag NFC pour le désarmement dans mon cas) et de savoir quel capteur à déclenché l'alarme dans une notification (Slack, TG ou SMS), mais aussi de conserver un log (CSV et/ou XML).

Ce qui m'embête c'est que je me retrouve avec d'un coté mes capteurs Xiaomi / Aqara qui me servaient à l'alarme HA, à couper le chauffage quand on ouvre les fenêtre ou allumer une lampe en cas de passage, et mes capteurs Visonic qui peuvent faire la même chose... Bref, j'aurais su avant je ne me serait pas lâché sur Ali Express...

Sources

J'ai écrit ça rapidement, mais voici mes sources qui contiennent pas mal d'informations pour qui voudra se lancer dans l'expérience

 

Unifi Dream Machine Pro

Chez les afficionados de la marque on a généralement tous commencé par un AP WI-FI. Et puis comme ça fonctionnait bien et que c'était beau on s'est laissé aller pour un USG, et là c'était beau, mais pas exempt de bugs et surtout limité en CPU pour exploiter une fibre ou DPI/IPS. Il y a bien eu l'USG Pro, pas vraiment beaucoup plus puissant. Sur tous ces modèles le VPN n'a jamais été le point fort et quant à faire de la publication il n'y a rien d'autre qu'une possible translation de ports entrants comme sur un vulgaire routeur grand public, si cela pouvais se comprendre sur les modèles précédents, on aurait aimé un reverse proxy sur la machine censée nous faire rêver !


(source Unifi)

Mais il n'en est rien, il faut considérer l'UDM Pro, et c'est son positionnement marketing, comme un routeur d'accès avec des services (Contrôleur Unifi, Unifi Protect, contrôle d'accès, téléphonie IP, etc..). Si l'on souhaite publier des services on regardera plutôt du coté de pfsense ou autres Appliance qui font ça très bien. Et si on veut faire du VPN,  ce qui est par contre dans la cible du produit, ce sera IPSEC ou OpenVPN. Zerotier ayant été porté sur la gamme Edge, il y a des chances que quelqu'un fasse le portage sur l'UDM Pro, voire qu'Unifi le fasse, à moins qu'ils ne se laissent tenter par WireGuard...

A 319 € (HT) l'UDM est un produit intéressant qui combine donc plusieurs fonctions : 

  • un USG performant avec fonctionnalités de firewall avancées (IPS/IDS, DPI)
  • un switch 8-port Gigabit et un port 10G SFP+, un port WAN Gigabit et un second port WAN en 10G SFP+ (de quoi y raccorder les nouveaux produits en 2.5 GB et 10 GB actuellement en Early accès et profiter des offre fibre en 2.5 GB ou 10 GB proposées par certains FAI).
  • un contrôleur UniFi (= CloudKey ou CloudKey Gen2+).
  • un NVR UniFi Video avec emplacement disque dur 3.5″ ou 2.5".
  • d'autres contrôleurs à venir (contrôle d'accès, téléphonie IP, et certainement quelques autres projets dans les cartons...).
  • et enfin comme tous les Gen2 de la marque on est en présence d'un petit écran de contrôle en face avant. Petit gadget pour doigts de fée !

Si le contrôleur Unifi intégré pourrait très bien trouver sa place ailleurs (VM, Cloud, ...), l'enregistreur vidéo (Unifi Protect), qui est identique, mais plus puissant que celui que l'on trouve sur le CloudKey 2+, constitue un vrai plus si on veut gérer un grand nombre de caméras et stocker jusque à 14 TB de vidéos de surveillance. A noter qu'il existe chez Unifi un autre NVR plus puissant avec le support de 4 disques.

Le NVR

Ca c'était le bla bla marketing annoncé. Dans la pratique Unifi Protect sur l'UDM Pro me semble bien bogué pour un produit sorti il y plus de six mois. Ca commence avec le disque dur, quelque soit le modèle installé parfois il le voit, parfois pas, et quand il le voit il ne l'exploite pas (impossibilité d'enregistrer). Certains conseillent de le retirer et de le formater en ext4, pas mieux, de juste supprimer les partitions, là il est visible mais non exploitable. Pas très normal qu'on ne puisse pas lancer l'initialisation/formatage depuis l'interface. Et je passe sur les paramètres des caméras qui sont pris en compte depuis l'application mobile mais impossible depuis le portail web qui lui répond que la caméra n'est pas reconnue, alors qu'elle l'est bien sur... A cette heure je regrette ma CloudKey 2+ !

Le routeur

Le routeur d'accès qui lui remplacera l'USG reste à apprécier à l'usage, Ca remplace mais ça reste un USG dont je ne vais pas reprendre le détail ici, un une partie qui mériterais de la part d'Unifi quelques évolutions, avec notamment l'intégration à l'interface de tout ce qui n'apparait pas mais reste faisable en CLI.

2 ports WAN, mais un seul en 10 G !

A noter que le WAN1 qui est en 1 GB est toujours le port principal WAN et que si on souhaite faire du failover on le fera avec le WAN 2 qui lui est en 10 GB (SFP+) ou en 1 GB en utilisant un adaptateur UF-RJ45-1G. C'est d'autant plus bête qu'en utilisation normale on peut imagine une grosse fibre sur le WAN principal et un xDSL en secours. Ca reste du soft, et on peut imaginer une évolution du firmware, et pourquoi ne pas banaliser tous les ports en WAN/LAN comme le fait Cisco depuis plus de 10 ans sur des produits SMB de la gamme RV.

Dans tous les cas, sur le papier, on reste sur de l'agrégation ou du failover utilisable en sortie, et pour l'instant c'est failover only (La seule solution intégrale d'agrégation via un tunnel restant l'OTB d'OVH ou sa version open source openMPTCP).

Quand au WI-FI contrairement à l'UDM, l'UDM Pro qui se place dans un rack n'intègre logiquement pas d'AP. Alors on est tout de même en droit de se demander pourquoi sur un produit qui est censé gérer des AP et des caméras en POE, on ne trouve aucun ports POE ? Je pense simplement qu'à la conception la question a bien du se poser, le marketing l'a emporté en argumentant que cela ferait vendre des commutateurs POE, produits sur lesquels la marge est certainement bien plus importante. C'est dommage car avec quelques ports POE l'UDM Pro aurait été presque parfait ! Business is business !

Un firmware intégré...

Contrairement aux habitudes prises avec Unifi, ici le firmware intègre tout, le firmware de la machine de base proprement dite (USG), le contrôleur Unfi Network, le contrôleur Unifi Protect et les autres applications... Si la bonne idée est de simplifier, on va voir que dans la pratique ce n'est pas si simple tant les versions sont évolutives chez eux...

Coïncidence, mon UDM Pro est arrivé le lendemain du jour ou j'ai mis à jour (par erreur) ma CloudKey 2+ avec le contrôleur avec 6.0.20. Mal m'en a pris car cette version, tout comme la suivante en 6.0.22 est tellement buggées qu'on peut aisément penser qu'elle a été lâchée en release par erreur (un stagiaire ?). Problème, la 6.0.x n'existe pas sur l'UDM Pro qui est en firmware 1.8 qui intègre le contrôleur en 5.x. Dès lors impossible de migrer une installation en 6.x vers du 5.x ! (il ne s'agit pas vraiment d'un process de migration mais une simple opération de backup/restaure, il faut donc que la source ait un niveau de release inférieur ou égal au contrôleur de destination).

Alors j'ai cherché, j'ai fini par installer la 1.8.1 RC3 qui n'apporte hélas pas de contrôleur en 6.x ... et pour finalement découvrir qu'il était possible de mettre à jour le contrôleur d'UDM Pro en SSH. Et pourquoi pas avec un bouton upload ? On a parfois l'impression qu'il y a chez Unifi pas mal d'ingés de l'ancien monde, ceux pour qui le CLI est et reste la seule option possible... Ce qui n'est pas très logique pour un constructeur qui se démarque avant tout par ses magnifiques interfaces !

ssh udm ...
unifi-os shell
cd /tmp
curl -o "unifi_sysvinit_all.deb" https://dl.ui.com/unifi/x.xx.xx_version/unifi_sysvinit_all.deb
dpkg -i unifi_sysvinit_all.deb 
rm unifi_sysvinit_all.deb 

Et comme je n'ai pas reçu ce produit du service de presse pour le tester, mais que je l'ai acheté pour l'utiliser, me voilà donc en principe dans la possibilité de migrer. Je fait un export du contrôleur et un export du NVR depuis la CK 2+ (je ne me pose pas la question d'exporter les vidéos de la CK 2+, mais il parait que c'est possible...). Ensuite je débranche l'USG et la CK 2+, c'est important. A partir de la il me suffira en principe d'importer le backup du contrôleur sur l'UDM Pro et ensuite le backup du NVR.

Dans la pratique c'est un peu plus compliqué. Si l'importation se passe bien le redémarrage annoncé ne s'opère pas. Je le fais manuellement au bout d'une heure. Mais au retour je ne peux me connecter localement, ni sur l'ancienne l'IP (192.168.1.1), ni sur l'IP de configuration importée (192.168.210.1). Par contre je peux le faire à distance (à noter que c'est un nouveau portail d'administration). Et là en fouillant je constate deux choses :

  • Le port 11 (SFP) qui assure la liaison avec mon USW-48 a perdu sa configuration en 1 GB FDX (et non il n'est pas auto sense...)
  • Que si l'IP LAN a bien été importée dans la configuration, c'est toujours l'ancienne IP qui répond, et de fait le système ne voit pas les autres équipements importés (SW, AP).

Réactiver le port SFP en FDX est facile, pour que l'IP LAN soit bien prise en compte j'ai finalement rentré l'ancienne à la place de la nouvelle, appliqué la configuration, et ensuite remis la nouvelle, et oh merveille ça fonctionne. Oh merveille mon cul, car c'est vraiment n'importe quoi.

A ce stade tout semble fonctionner, bien que dans cette version non finalisée (6.0.22) certaines choses sont à faire dans la nouvelle admin (VPN) tandis que pour d'autres actions il faudra revenir à l'ancienne interface. beta bug beta bug ! Enfin, tout sauf que si le WAN2 sait bien fonctionner en failover, contrairement à l'USG il est ici impossible de la basculer en agrégation (pas de réponse à ce sujet pour l'instant).

Il y a également depuis le 6.0.x des équipements WI-FI qui décrochent. C'est par exemple systématique sur les ampoules Xiaomi/Yeelight, j'ai tout retourner sans trouver de contournement. Et pour mémoire, quand on migre d'une 5.x vers une 6.0.20 il y a un Vlan only network - 0 qui se crée, je pense que c'est lié à la nouvelle façon de gérer le WI-FI Guest, en attendant il empêche toute connexion WIFI normale et il faut donc l'effacer ou le le changer d'ID (en 100 par exemple). Sur le 6.0 le WI-FI est géré différemment et on peu créer plus de 4 SSID, ce qui est par exemple plus souple pour les différencier en 2 ou 5 Ghz. et en isoler certains (IoT par exemple).

Domotique

Pour information les intégrations Unifi et Unifi Protect que l'on utilise dans Home Assistant fonctionnent et reconnaissent bien l'UDM. Petit hic il faut les réinstaller car je n'ai pas trouvé (pas trop cherché non plus) la façon de changer l'IP du contrôleur et du NVR (dans HA). Le résultat est que certaine entités peuvent changer de nom et qu'il faudra s'adapter.

Accéder au contrôleur depuis l'extérieur

Le plus simple pour administrer le contrôleur intégré à l'UDM est bien sur de passer par le cloud Unifi et l'application. Mais on peu vouloir y accéder directement depuis le port WAN. Pour cela on va commencer par suivre ces recommandations et ainsi créer une règle WAN Local :

Action : Accept
IPv4 Protocol : TCP
Rule Applied : Before pre-defined rules
Destination : Create a new port group with port 443 in the group

A partir de là on peut accéder au contrôleur sur son port par défaut (443) depuis l'extérieur. Sauf que le port par défaut n'est pas une bonne idée et on peut vouloir en faire autre chose. On va donc créer une règle dans Port Forwarding qui redirigera par exemple le port 8443 sur l'IP LAN du contrôleur, et ainsi on y accède via ce port. Au même endroit on peut créer une autre règle pour rediriger le port 443 vers une autre IP du LAN, et si on en a pas besoin on la redirige sur 127.0.0.1 afin de bloquer l'accès externe via le 443... Je sais c'est un peu tordu par les cheveux mais je n'ai pas trouvé mieux ! En ce qui me concerne j'en ai eu besoin pour cette solution de backup. Attention toutefois à verrouiller cet accès sur des IP sources pour plus de sécurité.

Conclusion

Par la force des choses je me retrouve :

  • en prod avec du matériel qui tourne intégralement sur des versions beta. Une pratique à éviter.
  • avec un enregistreur qui n'enregistre plus rien...
  • des équipements WI-FI qui décrochent.
  • avec une foule de bugs dont une agrégation de ports inopérante.

Vous l'aurez compris, la machine à rêver ne m'a pas fait rêver mais perdre beaucoup de temps et me retrouver dans une situation très instable !

  • EDIT 22/09/2020 14:00 : la v6.0.23 du contrôleur est sortie et ça règle bien plus de choses qu'annoncé. Dont mes déconnections avec les ampoules Xiaomi/Yeelight. En fait non, mais ça tient quelques heures au lieu de 5 minutes...
  • EDIT 22/09/2020 17:30 : S'agissant de l'enregistrement sur détection de présence (Protect) et de l'enregistrement il semblerait qu'un paramètre n'ait pas été pris en compte lors de la migration ou qu'il soit nouveau (sur chaque caméra, Recording/Motion Events/Motion Algorithm), il faut faire un choix et aucun des deux n'était sélectionné. Dès lors qu'un disque dur est bien reconnu on a donc bien les enregistrements.
  • EDIT 23/09/2020 04:37 : Il est possible d'intervertir WAN1/WAN2 afin que WAN1 (le principal) profite de l'interface 10 GB sur WAN1 (et sans passer par SSH). Par contre pour l'instant seul le support du mode Failover, pour le Load Balancing (supporté sur l'USG) il faudra repasser plus tard.
  • EDIT 23/09/2020 18:22 : En parlant de plus tard, le SNMP, un peu la base sur un routeur, est caché (New Seetings + search snmp), mais pour autant il ne fonctionne pas. Il parait que apt-get ... etc... On se marre !
  • EDIT 23/09/2020 19:30 : Passage de la 6.0.23 en release et sortie de la 6.0.24 en beta. Ca turbine chez Uniquiti, il faut dire que ça grogne partout ! Nouveaux firmwares UAP/USW. Nouvelles déconnexions sur les ampoules Xiaomi.
  • EDIT 29/09/2020 17:17 : S'agissant des ampoules Xiaomi, j'ai essayé tous les paramètres possibles et imaginable ainsi que les version beta de firmware sans obtenir de résultat. J'en conclu que quelque chose a vraiment changé dans cette version qui a plus une allure de beta que de release. J'ai donc honteusement ressorti un vieil AP Netgear...
  • EDIT 29/09/2020 17:17 : A la version 1.8.4 du firmware les choses sont rentrées dans l'ordre.

J'espère pouvoir échanger avec Unifi et qu'ils sauront m'apporter des réponse satisfaisantes à tous ces problèmes. Je mettrais bien sur à jour cet article énervé en fonction de.

Sources

 

Home Assistant & BLE : Présence

Il y a quelques temps je vous avait déjà parlé de BLE (Bluetooth Low Energy) pour remonter des sondes de température Xiaomi. Le composant utilisé fonctionne bien et ça évolue, il n'y a rien à redire, sinon que ça ne gère pas la présence. Hors la notion de présence est importante en domotique.

Il y a plusieurs façons de gérer la présence dans Home Assistant

  • En géolocalisation en utilisant les API Google. Ça fonctionne bien au point de faire peur, mais ce n'est pas suffisamment réaction pour certaines actions. Par exemple si je veux ouvrir le portail, allumer des lampes et désactiver l'alarme lors de mon arrivée, il y a des chances que j'attende 5 minutes face au portail... Et que si j'ouvre le portail avec une télécommande l'alarme soit encore active lorsque je rentre dans la maison. C’est donc inutilisable pour cet usage.
  • Une application genre OwnTrack n'est pas beaucoup plus performante et consomme plus de batterie.
  • Un TAG RFID, ça fait le job mais il y a une interaction physique. Donc OK pour l'alarme, mais pas pour le portail...
  • Le WI-FI, en s’appuyant sur l'intégration Unifi (il y en a d'autres), c’est pas mal mais il me faudrait un AP à l'extérieur pour un meilleur résultat.
  • Un gardien ou un majordome serait idéal, mais je n'en ai pas les moyens !
  • J'ai pensé au ZigBee, mais la portée est trop courte et il me faudrait déporter un répéteur.
  • Il reste donc la voie du BLE que j'avais laissé de coté car l'intégration de base n'est pas à la hauteur de ce que j'avais avec un des meilleurs plugin sous Jeedom.

Pour palier à l'intégration BLE d'origine sous HA on dispose à ce jour de deux projets bien aboutis qui peuvent fonctionner soit de façon autonome sur un RPI, soit sous forme d'addon à installer directement dans Home Assistant. Dans les deux cas ils communiqueront avec HA en MQTT, et c'est un plus indéniable ! En ce qui me concerne j'ai testé les addon, mais un RPI0 indépendant sera idéal si on veut créer un réseau avec le second projet.

Monitor

Bluetooth Presence Monitor s'installe en ajoutant son dépôt dans le gestionnaire d'addon ou en partant du dépôt original si on veut l'installer à part. La configuration est simple :

mqtt:
  broker: 192.168.210.44
  port: 1883
  username: user
  password: password
  topic_root: presence
  publisher: ''
known:
  beacons:
    - 'F8:DE:32:B1:07:3D Tile'
  static:
    - '94:65:1D:D1:AD:96 5T'
    - '50:77:05:F6:0F:2F Note 9'
blacklist:
  - '58:2D:34:10:1D:4F'
  - '58:2D:34:10:12:77'
extra_arguments: '-a -x -b -tdr -r'

Par contre il faudra prendre soin d'aller régler le port BT dans le fichier /share/presence-monitor/behavior_preferences afin que cela ne rentre pas en confit avec un autre port (à ce niveau l'O/S ne gère pas le partage des ports comme celà pourrait être le cas sous Windows ou MacOS par exemple). Cela veut dire que si on a déjà une intégration qui utilise un port BT il faudra un dongle USB BT. Dans mon cas j'utilise une clé SENA TD100 que l'on trouve encore ici. C'est dans ce même fichier de configuration que l'on pourra ajuster tous les paramètres, fichier que l'on aurait aimé accessible depuis l'addon bien sur...

PREF_HCI_DEVICE=hci1

A partir de là on lance l'addon et on observe le log pour ajuster la configuration afin de choisir ce qui sera notifié au broker MQTT. Ensuite il faut créer un sensor: qui aura pour valeur le pourcentage d'éloignement ainsi qu'une très utile notion de départ / arrivée.

  - platform: mqtt
    state_topic: 'presence/homeassistant/tile'
    value_template: '{{ value_json.confidence }}'
    unit_of_measurement: '%'
    name: 'Tile BLE'
    icon: mdi:bluetooth

On va également créer un device_tracker: qui lui nous fournira un device tracker que l'on retrouvera comme d'habitude dans le fichier known_devices.yaml

  - platform: mqtt
    devices:
      TileBLE: 'presence/homeassistant/tile/device_tracker'
      name: "Tile BLE"
      icon: mdi:bluetooth

A ce stade ça fonctionne avec une prise en compte des équipements perfectibles, mais je n'ai pas creusé les paramètres avancés car entre temps je suis tombé sur Room Assistant. Par ailleurs mon TAG Tile ne semble pas être le meilleur pour cet usage et j'ai commandé un Nut 3.

Room Assistant

Room Assistant est à ce jour ce que j'ai trouvé de plus complet et de plus prometteur. L'installation de l'addon se fait depuis ce dépôt (ou ici si on installe à part) et on se concentrera sur le fichier de configuration, un lancement à vide nous permettant de repérer les adresses MAC des différents équipements.

Le gros avantage de Room Assistant est qu'il offre la possibilité de fonctionner en réseau, ce que l'on connaissait avec le plugin BLEA de Jeedom. Il sera ainsi possible de localiser les habitant d'un logement à la pièce près en se basant sur le signal BT/BLE. Je n'ai pour l'instant pas exploité cette possibilité, mon besoin étant le départ / arrivé de mes utilisateurs.

global:
  instanceName: canaletto_ble
  integrations:
    - homeAssistant
    - bluetoothLowEnergy
    - bluetoothClassic
    - xiaomiMi
homeAssistant:
  mqttUrl: 'mqtt://192.168.210.44:1883'
  mqttOptions:
    username: user
    password: password
bluetoothClassic:
  minRssi: '-20'
  hciDeviceId: 1
  addresses:
    - '94:65:2D:D4:XX:77'  # Mon mobile
bluetoothLowEnergy:
  hciDeviceId: 0
  onlyIbeacon: true
  timeout: 30  # Utile pour éviter les faux départs sur certains tags
  whitelist:
    - f8dedfgh73d  # Mon Tag Tile
  tagOverrides:
    f8dedfgh73d:
      name: Tile
xiaomiMi:
  hciDeviceId: 0
  sensors:
    - name: Clear Cuisine  # Xiaomi CGG1
      address: 582d3dfgsd6d
    - name: Clear SdB  # Xiaomi CGG1
      address: 582d3dgf3286
    - name: Clear Exterieur  # Xiaomi LYWSDCGQ
      address: 4c6dfgd1db75
    - name: Clear Square  # Xiaomi LYWSD02
      address: 3fdfg88270ca
    - name: Clear Clock  # Xiaomi CGD1
      address: 58sdfgsd3292
      bindKey: cc0d9dfgdsfgsdf4e7f495d27eacf5250e2e8
entities:
  behaviors:
    ble-f8desdb1073d-tracker:
      debounce:
        wait: 10.75
        maxWait: 20

On passe rapidement sur la classique config MQTT pour noter que si l'intégration bluetoothLowEnergy et xiaomiMi peuvent partager le même port BT (BLE dans les deux cas), ce port devra être différent pour du bluetoothClassic. Le développeur travaille au partage de port mais ce n'est pas pour l'instant possible.

L'intégration, la création, dans Home Assistant des sensors: est automatique via MQTT (présence, température, etc..), par contre il faudra manuellement créer les device_tracker: si on souhaite les exploiter.

  - platform: mqtt # Room-Assistant
    devices:
      ra_tile: 'room-assistant/device_tracker/ble-f8de32b1073d-tracker/state'
      name: "Tile BLE"
      icon: mdi:bluetooth
    payload_home: 'true'
    payload_not_home: 'false'
    source_type: bluetooth   

Ensuite il va falloir exploiter et pour le debug je me sert de Slack pour faire un log dynamique. On commence par deux automations pour simuler un départ et une arrivée (je me contente d'enlever la pile du Tile ou de le coller dans le micro onde... Je me sert ici du device_tracker:

- alias: Alarm Test Tile leave
  trigger:
    platform: state
    entity_id: device_tracker.ra_tile
    from: 'home'
    to: 'not_home'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Leave" 

- alias: Alarm Test Tile enter
  trigger:
    platform: state
    entity_id: device_tracker.ra_tile
    from: 'not_home'
    to: 'home'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Return" 

Mais, car il y a un mais, j'ai remarqué que visuellement mes deux icônes ne changeait pas d'état à la même vitesse, le sensor: étant plus rapide. Je fais donc une seconde paire d'automation avec lui...

- alias: Alarm Test Tile leave device
  trigger:
    platform: state
    entity_id: sensor.tile_room_presence
    from: 'canaletto_ble'
    to: 'not_home'

  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Leave Sensor" 

- alias: Alarm Test Tile enter device
  trigger:
    platform: state
    entity_id: sensor.tile_room_presence
    from: 'not_home'
    to: 'canaletto_ble'
  action:
  - service: notify.slack_hass_canaletto
    data:
      message: "{{now().strftime('%d/%m/%Y, %H:%M:%S')}} > TEST TILE Return Sensor" 

Et là on a une vraie surprise dans les résultats car on gagne 10 secondes ! Et 10 secondes sur une arrivée c'est hyper important car c'est à peu près le temps que je dois mettre pour aller du portail à la porte d'entrée...

14/09/2020, 23:12:41 > TEST TILE Leave using sensor:
14/09/2020, 23:12:52 > TEST TILE Leave using device_tracker:
14/09/2020, 23:13:01 > TEST TILE Return using sensor:
14/09/2020, 23:13:12 > TEST TILE Return using device_tracker:

Voilà, il va maintenant falloir faire des tests en live, l'idéal serait que le tag puisse être détecté quand je me gare devant le portail, mais pour ça il me faudra que j’équipe la clé SENA avec une antenne plus performante. Je trouve que les délais d'Accroche / Décroche des mobiles sont excellents et j'attend mon Nut pour d'autres tests.

Le support des capteurs Xiaomi est récent et pour l'instant l'information concernant le niveau de batterie n'est pas disponible pour tous contrairement à MiTemp. Mais ça devrait venir. Ce qui est amusant, sinon intéressant, c'est que dans cette intégration un capteur de température Xiaomi peut devenir un TAG et être vu par HA en tant que tel... Mon Tile ne fonctionnant pas très bien, j'ai donc pensé à laisser un CGG1 dans ma voiture...

Voilà pour ces petits tests, je suis bien sur disponible pour échanger sur TG ou ici dans les commentaires. N'hésitez pas à partager vos expériences afin que je puisse au besoin mettre à jour cet article.

EDIT : Je n'ai pas encore eu le temps de tester mais les informations trouvées ici me semblent pertinentes.

EDIT 2 : Pour  la géo loc l'application Life 360 semble ce qui se fait de mieux, il existe une intégration à HA. A combiner avec le reste.

Et en WI-FI

Si gérer la présence en Bluetooth peut sembler évidente, à l'usage on s'aperçoit que le BT des mobiles décroche trop souvent, que celui des tags BLE n'est pas assez rapide et surtout que même avec une clé Sena et une antenne la portée est trop réduite. Finalement le WI-FI reste une très bonne solution, à condition d'avoir un AP gérable (Unifi avec intégration Unifi ou Unifi AP qui est légèrement plus rapide) et d'autres marques reconnues, Netgear par exemple. Ce qui est intéressant ici c'est que dès que l'AP voit le mobile (sa MAC, sans pour autant que le signal soit suffisant pour un appairage et qu'il ait une IP) HA est informé de la présence du device et peut ainsi gérer des automatismes. Le décrochage est long ce qui garantie l'absence de faux positifs mais l'accrochage est lui très rapide.

Sources