ARTICLE INCOMPLET EN COURS DE RÉDACTION

Ce ne sont que mes notes compilées au fil de l'eau...
N'hésitez pas à revenir ou d'utiliser la touche F5, et de me signaler les erreurs :-)

Suite à cet article les choses ont bien avancées. Mon premier soucis étant le chauffage, l'objectif étant de faire au moins aussi bien avec HA qu'avec Jeedom. La philosophie des deux produit est bien différente, sur Jeedom on confie les taches à des plugins plus ou moins stables, sous HA on prend un éditeur et on code, et comme je ne sais pas trop faire, comme beaucoup je suis devenu le roi du copié collé, en essayent de comprendre ce que je fais. Mais quand une fonction est ok, elle est très stable et pas sujette à une mise à jour de plugin foireuse.

Installation 

On part du principe que vous avez installé Home Assistant, pour ma part HASS.IO dans une VM ESXi, mais cela est tout à fait envisageable sur un RPI 4 ou au pire un RPI 3. Je n'arrivais pas à convertir le VMDK proposé. Impossible à installer sans conversion, erreurs lors de la création de la VM. Il y a un très bon tuto ici et une aide là. Après avoir perdu 3 heures j'ai refait la même conversion avec une autre console ssh et là j'ai un retour positif !

# /vmfs/volumes/datastore1/Home Assistant # vmkfstools -i "ha38.vmdk" "ha.vmdk"
  Destination disk format: VMFS zeroedthick
  Cloning disk 'ha38.vmdk'...
  Clone: 100% done.

Et du coup ça s'installe bien ! Sous Windows la première console SSH était Terminus qui en principe fonctionne bien, la seconde Bitwise SSH. Je pense à un problème de mapping de caractères.

Premier démarrage

Quand HA se lance il va reconnaître tout seul ce qu'il connait et qui est disponible sur le réseau local. Sonos, des ampoules Xiaomi, mon contrôleur Unifi et surtout ma passerelle Zigbee Phoscon et ses équipements ! Et d'autres bricoles, si tant est que les bonnes clés soient branchées sur la machine... Un vrai +

Les choses à installer ensuite

• SSL : Le plus simple est d'utiliser DuckDNS. Ca prends 5 Minutes, mais le plugin Let'sEncript fait aussi le travail sur un domaines personnalisé avec les API OVH ou CloudFlare, entre autres, mais pas avec Gandi. Comme ce n'est pas non plus l'adresse d'un site public, je conseille DuckDNS qui me semble bien plus stable. Bien sur avant ça on ouvre le port idoine sur le routeur, mais ça vous maîtrisez déjà. (voir plus bas le chapitre SSL).
• L'addon Configurator qui vous sera très rapidement indispensable.
• L'addon SAMBA vous permettra d’accéder aux fichiers de config depuis votre ordinateur Windows ou Mac.
• L'addon SSH pourra être utile également.
• L'addon Check Home Assistant Configuration sera lui utile pour faire une vérification de cohérence avant une mise à jour.

Comme je n'ai pas besoin d'une solution domotique pour allumer deux ampoules on va passer sur ce sujet, mais tout comme Jeedom, HA sait automatiser plein de choses. On  va donc passer au cœur de ma problématique, et il en découlera plein d'autres rencontrées au fil de ces jours et nuits ou je me suis plongé dans Home Assistant.

Chauffage et climatisation

Pour gérer le chauffage électrique sous Jeedom je me sert essentiellement de 3 plugins.

Thermostat

Sous HA il faudra les implémenter les thermostats à la main. Le mieux est de créer un /config/climate.yaml et de l'inclure dans /config/configuration.yaml. 

climate: !include climate.yaml

Dans climate.yaml on va installer et paramétrer les thermostats :

- platform: generic_thermostat
  name: Thermostat Cuisine
  heater: switch.study_heater # On indique ici le relais on/off du convecteur
  target_sensor: sensor.mi_cuisine # On indique ici le capteur de température
  min_temp: 15
  max_temp: 21
  ac_mode: false
  target_temp: 17
  cold_tolerance: 0.3
  hot_tolerance: 0
  min_cycle_duration:
    seconds: 5
  keep_alive:
    minutes: 3
  initial_hvac_mode: "off"
  away_temp: 16
  precision: 0.1

Il est important de faire très attention à l'indentation, on est dans des fichiers .yaml et les règles propres à Yaml s'appliquent ici scrupuleusement. Dans bien des cas Configurator ne vous laissera d’ailleurs pas sauvegarder si le fichier est mal formaté.

Autre chose. Etant donné que toutes la documentation, les sites, ainsi que la majorité des tutos sont en anglais, je vous recommande de passer l'interface de HA en anglais, ça sera plus simple pour suivre...

Une fois que notre thermostat est installé il faut relancer HA. C’est une des plaies de HA, pour l'instant et on passe pas mal de temps à relancer. D’où l’intérêt qu'il soit installé sur une machine un peu puissante. On peut ensuite aller sur la page d’accueil de HA pour y ajouter le thermostat, en passant en mode configuration, en haut à droite, et obtenir ce joli visuel, tant sur votre desktop que via l'application mobile, qui du reste est un pur bonheur quand on pense à l'application mobile (payante) de Jeedom. Il existe des variantes possible de présentation et de customisation.

A ce stade on a obtenu très rapidement un thermostat fonctionnel, mais manuel. Sous Jeedom j'utilisais pour le piloter les plugins MODE et AGENDA, et j'avoue que le résultat était quasi parfait. Sous HA on va pouvoir facilement (enfin j'ai tout de même un peu cherché) utiliser input.select pour remplacer le plugin MODE, par contre coté agenda c’est un peu le désert pour l'instant et il va falloir faire ses propres automatisations, mais il y a des choses qui se préparent (1 | 2 | 3). On pourrait également utiliser Schedy qui m'a parut complet mais complexe, et surtout dépourvu d'interface. Donc dans un premier temps je vais faire la programmation de mes thermostats avec ce qui est disponible de base dans le core de HA.

Les modes et les consignes

Je me sert sous Jeedom de plusieurs commutateurs de modes, par exemple pour définir différents modes de chauffage selon que je suis seul, que je reçoit du monde à dîner, que j'ai des visiteurs qui passent le week-end à la maison, ou encore que ma fille ou mon fils sont présents, elle ou lui, ou les deux. Chaque mode sous entend des plages horaires de chauffage différentes et des températures de consigne adaptées à la situation. Actuellement le passage entre les différents modes est manuel, mais il pourrait être automatisé en relation avec mon agenda Outlook ou Google.

Avec input.select je vais pouvoir définir une sorte de combo que je placerait sur ma page d'accueil. Soit dans configuration.yaml, soit dans un fichier dédié que j'aurais inclus comme expliqué plus haut.

input_select:
  office_radiator:
    name: Radiateur Bureau
    icon: mdi:radiator
    options:
     - Arrêt
     - Hors-Gel
     - Eco
     - Confort -
     - Confort
     - Confort +

  chauffage_enfants:
     name: Modes du Chauffage Enfants
     icon: mdi:account-switch
     options:
     - Présence
     - Présence Antoine
     - Présence Marie
     - Abscents

  chauffage:
     name: Mode du Chauffage
     icon: mdi:home-minus
     options:
     - Normal
     - Diner
     - Week-End
     - Abscent

Le premier servira à piloter un thermostat à la française, c’est optionnel et il faudra le dupliquer sur n thermostats. Les autres pays ne se servent pas de ces modes hérités du fil pilote.ils agissent directement sur la valeur de consigne. A vous de voir si vous souhaitez les conserver. On verra plus loin comment les associer aux thermostats.

Le second mode est dédié à la présence des enfants, tandis que le troisième sera celui utilisé au quotidien. Et voici ce que ça donne sur l'interface de HA.

Maintenant il va falloir un peu de code pour faire communiquer tout ça. On peut le générer avec Configuration/Automation, plus facile pour débuter, mais qui produit un code moins propre, ou directement en éditant automations.yaml dans Configurator. La première solution évite le redémarrage, et c’est ce que je conseille en phase de test.

Les consignes avec input.select

On va donc créer une "automation" qui aura pour Trigger (déclencheur) input_select.office_radiator (notre premier input.select) et en action le code suivant (en mode édition YAML) qui permetra d'affecter au thermostat les différents preset de température :

data_template:
  temperature: |
    {% if is_state("input_select.office_radiator", "Confort") %}
      20
    {% elif is_state("input_select.office_radiator", "Confort -") %}
      19
    {% elif is_state("input_select.office_radiator", "Confort +") %}
      21
    {% elif is_state("input_select.office_radiator", "Eco") %}
      17
    {% elif is_state("input_select.office_radiator", "Hors-Gel") %}
      5
    {% elif is_state("input_select.office_radiator", "Arret") %}
      0
    {% else %}
      0
    {% endif %}
entity_id: climate.thermostat_bureau
service: climate.set_temperature

Etant donné que je suis plus système et réseaux que développeur, je n'ai pas tout compris, mais ça fonctionne, et si j'actionne ma combo sans l'interface les températures de consignes changent sur mon thermostat. Pour programmer un thermostat sur une plage horaire on pourra ainsi le faire en indiquant directement une température de consigne, mais également une mode prédéfini.

Les modes avec input.select

Ici on va gérer les modes de vie et de présence. On les actionnera manuellement avec la combo, mais on pourrait également les programmer ou les basculer avec une application de géolocalisation ou un tag de présence. On va donc créer une "automation" qui aura pour Trigger (déclencheur) input.select.chauffage (notre troisième imput.select par exemple) et en action le code suivant (en mode édition YAML) qui permettra d'affecter au thermostat les différents preset. On voit ici que l'on peut ajouter une seconde action pour déclencher de la même façon de scripts, par exemple pour activer ou désactiver des automatisations.

La première action pour changer l'état d'un thermostat :

data_template:
  option: |
    {% if is_state("input_select.chauffage", "Normal") %}
      Confort
    {%-elif is_state("input_select.chauffage", "Diner") %}
      Confort +
    {%-elif is_state("input_select.chauffage", "Week-End") %}
      Confort -
    {%-elif is_state("input_select.chauffage", "Abscent") %}
      Hors-gel
    {% endif %}
entity_id: input_select.office_radiator
service: input_select.select_option

La seconde action pour exécuter des scripts ou des automation en fonction de l'état :

data_template:
  entity_id: |
    {% if is_state("input_select.chauffage", "Normal") %}
      script.1580948753991
    {%-elif is_state("input_select.chauffage", "Diner") %}
      script.1580948753992
    {%-elif is_state("input_select.chauffage", "Week-End") %}
      script.1580948753993
    {%-elif is_state("input_select.chauffage", "Abscent") %}
      script.1580948753994
    {% endif %}
service: script.turn_on

Voilà pour vous expliquer ce que l'on peut faire d'input.select. Mais input.select comme d'autres états peut également servir à autre chose. Et notamment on va s'en servir en tant que "condition" puisque il s'agit d'un état commuté.

Les plages horaires basées sur input.select

Chacun emménage son mode de vie dans son logement comme, et ce mode de vie est également lié aux pièces et à leur dispositions. Faute d'agenda intégré on va donc définir des des Automations de planification. Pour chaque zone qui pourra contenir plusieurs thermostats il faudra une Automatiion de mise en route dans un mode de Confort et une automation de mise en route en mode Eco (en utilisant les modes prédéfinis ou des températures (Dans Action, on n'utilisera pas la fonction Wait car faute d'un agenda qui re schedulerait la valeur de cette fonction serait perdue en cas de redémarrage de HA). Enfin ces deux Automations seront conditionnées par l'état de notre Mode, ainsi se déclencheront uniquement les événements du mode choisit.

- id: '1580935599789'
  alias: 'Thermostat : Normal / Eco (Cuisine, Hall)'
  description: 'Passage en mode...'
  trigger:
  - at: 00:30:00
    platform: time
  condition:
  - condition: state
    entity_id: input_select.chauffage
    state: Normal

  action:
  - data:
      entity_id: input_select.office_radiator_hall
      option: Eco # Ici on applique un preset
    service: input_select.select_option

  action:
  - data:
      entity_id: input_select.office_radiator_kitchen
      temperature: 19 # Ici on applique une température
    service: input_select.select_option

Alors en attendant une véritable fonctionnalité de planification, voici ce que j'ai trouvé en quelques jours.  C'est donc un peu fastidieux, mais au final pas plus qu'avec des plugin Jeedom car ici le copié collé est roi ! Pour modifier les valeurs de consigne dans l'interface il est possible d'utiliser la fonction input.number de de créer un Slider :

input_number:
  slider1:
    name: Confort
    initial: 20
    min: 18
    max: 24
    step: 0.1
    unit_of_measurement: °C

Le mode Absent sera quant à lui géré par un script qui passera tous les thermostats sur Hors-Gel et toutes les Automations en mode désactivé. Il me faut également intégrer la planification ECS et VMC ainsi que le déclenchement de la VMC sur un seuil d'humidité, ce qui devrait se faire facilement.

Enfin, la reprise après une redémarrage de de HA. Je pense que la position des thermostats et des états restent tel qu'ils étaient avant avant l'incident. Point à vérifier.

Voilà une façon basic de remplacer le trio de plugins Jeedom Thermostat/Mode/Agenda. J'ai fait avec ce que j'ai découvert en quelques jours et je reste persuadé qu'il existe d'autres façons de faire ou d'optimiser. Je n'ai pas testé en situation, mais ça fonctionne avec une ampoule de test. 

Sondes et actionneurs

Si mes équipement Zigbee sont nativement reconnus via ma passerelle Phoscon (mais ils le sont également nativement si la clé est sur HA), pareil pour les équipement Shelley et Tuya (en cloud pour ce dernier), j'ai un problème avec mes équipements gérés par un truc bien de chez nous, le RFPlayer. Ca concerne de X2D, du Di-O en RF433, du Visonic en RF868 ainsi que mes détecteurs de coupure électrique et ma mesure de consommation électrique. J'ai un autre problème, mon hyperviseur ESXi est dans le garage, donc pas vraiment au centre de la maison pour y coller une clé Bluetooth Sena. Bref, dilemme !

J'ai donc commencé par installer un second HA en remote sur un RPI3 déporté pour gérer le Bluetooth. Çà fonctionne très bien et HA peut gérer plusieurs HA distants. Et puis il m'est venu une idée à la hauteur de mon désaveux pour Jeedom, l'utiliser en esclave !

Esclavage de Jeedom

Si le terme est un peu exagéré, il s'agit dans mon idée de continuer à utiliser les équipements qui ne sont disponibles que sur Jeedom. J'ai d'abord testé avec les URL de Jeedom disponibles sur tous les équipements, ça fonctionne mais c'est un peu vintage à l'heure ou MMQT est sur toutes les lèvres et que je suis le seul à ne pas l'utiliser. Allez on s'y colle !

MQTT

Il s'agit d'une messagerie d'objets à objets. Il faut un Broker (serveur d'échange) qui peut se trouver n'importe ou sur le réseau, c’est mieux, mais dans l'absolu il est possible d'utiliser un Broker public sur internet.

Ensuite il faut un client sur chaque objet ou solution domotique qui intègre des objets. Coté Jeedom il y en a deux de disponibles, j'ai installé le plugin JMQTT car à la lecture des forums son développeur me parait moins lunatique que l'autre... Et coté HA il suffit d'utiliser MQTT qui est intégré nativement.

Coté Jeedom le plugin s'installe facilement si ce ne sont les dépendances qui prennent un temps de fou. Ce plugin présente l'avantage d’installer en même temps le broker Mosquitto. Pratique si on n'en a pas déjà un sur le réseau. On configure le broker et on ajoute un équipement (sonde Bluetooth ici) avec les actions que l'on souhaitera échanger avec HA via MMQT.

Pour les tests on pourra se servir du bouton tester, mais ensuite il faudra créer un ou créer une action afin qu'à chaque changement de valeur de la sonde le message idoine soit transmis via MQTT. Dans un premier temps j'avais créé un scénario pour faire bouger MQTT, mais au final je j'ai fait dans la configuration de la sonde comme expliqué ici.

Coté Home Assistant on active MQTT via les intégrations et on configure le broker qui dans ce cas se trouve sur l'IP de Jeedom et on ajoute ce code dans /config/configuration.yaml :

sensor:
    - platform: mqtt
      state_topic: 'jeedom/temp'
      name: 'BT Température'
      unit_of_measurement: '°C'
      value_template: '{{ value_json.temp }}'
    - platform: mqtt
      state_topic: 'jeedom/humidity'
      name: 'BT Humidité'
      unit_of_measurement: '%'
      value_template: '{{ value_json.humidity }}'
    - platform: mqtt
      state_topic: 'jeedom/battery'
      name: 'BT Batterie'
      unit_of_measurement: '%'
      value_template: '{{ value_json.battery }}'

Et nous voici avec notre capteur Bluetooth rattaché à Jeedom disponible en temps réél sur HA. Simple !

Bluetooth 

Le Bluetooth et notamment BLE est bien sur géré des base. Pour les capteur Xiaomi il existe un composant pour améliorer l'ordinaire qui reste perfectible. Mais pour peu que HA soit installé dans une VM sur un serveur au fond du garage, va se oser un problème de portée. Si dans un premier temps je vais utiliser l'esclavage Jeedom.

Il existe une passerelle Bluetooth / MQTT (bt2mqtt) que l'on pourra monter sur un RPI 3 ou Zero, même si pour l'instant elle ne supporte pas tous les types de capteurs, et voici comment l'installer sur une carte Rasbian : (Notes de Sébastien à tester et à corriger le cas échéant).

Installation

sudo apt update && sudo apt upgrade -y
sudo apt install git virtualenv python3 python3-virtualenv python3-pip python3-wheel bluetooth bluez libglib2.0-dev -y
pip3 install --upgrade virtualenv
git clone https://github.com/zewelor/bt-mqtt-gateway.git
cd bt-mqtt-gateway
virtualenv -p python3 .venv
source .venv/bin/activate
sudo pip3 install -r requirements.txt

Configuration

sudo hcitool lescan (va trouver tous les devices Bluetooth disponibles)
cp config.yaml.example config.yaml
nano config.yaml (Editer avec les devices trouvés précédement dont on veut remonter les infos)
pip3 install `./gateway.py -r configured` 
source .venv/bin/activate
sudo ./gateway.py -d (Test de la configuration en mode debug)

Déploiement

sudo cp bt-mqtt-gateway.service /etc/systemd/system/
sudo nano /etc/systemd/system/bt-mqtt-gateway.service
sudo systemctl daemon-reload
sudo systemctl start bt-mqtt-gateway
sudo systemctl status bt-mqtt-gateway
sudo systemctl enable bt-mqtt-gateway

Attention: Il faut définir le chemin absolu du fichier service.sh dans bt-mqtt-gateway.service

Oui, Mais... Un peu compliquée ces passerelle DIY à mon gout... Il existe une autre voie qui va me permettre de désosser encore un peu Jeedom. Un HA en remote sur un RPI que je vais placer au centre de la maison. Sur ce RPI je vais y coller ma clé Bluetooth SENA, et la clé Combee II (ZWave si on en a), ensuite de quoi il suffit d’installer sur le master le composant Remote... Les performances sont au top et on peu même imaginer d'avoir plusieurs HA en remote via Internet (famille, etc...). Attention à bien filter ce que vous souhaitez importer avant le lancement, faute de quoi toutes les entitées es disponibles sur le distant seront remontées...

remote_homeassistant:
  instances:
  - host: '192.168.210.43'
    port: '8123'
    secure: false
    verify_ssl: false
#    access_token: !secret rpi_access_token
    access_token: myRemoteToken
    entity_prefix: "rpi_"
    include:
      domains:
      - sensor
#      - switch
#      - light
#      - group
#      - zwave
    subscribe_events:
    - state_changed
    - service_registered
#    - zwave.network_ready
#    - zwave.node_event
    filter:
    - entity_id: sensor.rpi_mi_*

IPX800 et autres équipements Jeedom

Je pourrais ainsi gérer ma vieille carte IPX800 v2 qui bien qu'ancienne fonctionne parfaitement, d'autant que chaque relais est équipé d'un contacteur de puissance, et qu'elle peut être configurée pour retrouver son état après une coupure électrique. Pour tester je l'ai fait en direct en mode URL, c'est simple, d'autant plus que cette carte ne propose pas de retour d'état direct, il va falloir interroger le fichier status.xml ...

IPX800 v2 (sur les versions suivantes il doit être possible de le faire en rest), on part toujours du principe que vous utilisez un fichier switch.yaml inclut depuis le ficher de configuration principal.

-  platform: command_line
   switches:
     ipx800:
       command_on: 'wget -O- "http://192.168.210.31/preset.htm?led7=1" >/dev/null'
       command_off: 'wget -O- "http://192.168.210.31/preset.htm?led7=0" >/dev/null'
       friendly_name: VMC

Pour gérer le retour d'état sur une IPX800 v2 il faut interroger le fichier status.xml. Là j'avoue qu'avec mes lacunes en matière de parse ça m'a pris du temps... (mes premières version en commentaire pour parvenir à une seule ligne car seule la valeur true nous intéresse (à noter que sur une seule ligne il faut remplacer les " de la partie recherchée par des ', un mystère pour moi...). Attention également à un autre piège, dans le fichier de status les relais, appelés led sont numérotés de 0 à 7 alors que pour les actionner il faudra le faire de 1 à 8, pas très cohérent tout ça...

    command_state: 'curl "http://192.168.210.31/status.xml"'
    value_template: '{% set status = value | regex_findall_index("<led6>(.*)</led6>") %} {% if status == "1" %} true {%- endif -%}'
#
#    value_template: >  # Variante 2
#      {% set status = value | regex_findall_index('<led6>(.*)</led6>') %} {% if status == "1" %} true {%- endif -%}
#
#    value_template: >  # Variante 1 (départ)
#      {% set status = value | regex_findall_index('<led6>(.*)</led6>') %}
#      {% if status == "1" %}
#        true
#      {%- elif status == "0" -%}
#        false
#      {%- endif -%}

Pour utiliser des équipements qui seront gérés par notre esclave Jeedom, c’est encore plus simple en utilisant les url API. Le retour d'état (souvent virtuel sur de vieux équipements) est signalé par un 0 ou un 1, simple. On part toujours du principe que vous utilisez un fichier switch.yaml inclut depuis le ficher de configuration principal.

- platform: command_line
  switches:
    dio_presence_exterieur:
      command_on: curl "https://canaletto.x:6969/core/api/jeeApi.php?apikey=xxxxxx&type=cmd&id=4106"
      command_off: curl "https://canaletto.x:6969/core/api/jeeApi.php?apikey=xxxxxx&type=cmd&id=4108"
      command_state: 'wget -O- "https://canaletto.xxx:6969/core/api/jeeApi.php?apikey=xxxxxx&type=cmd&id=4105"'
      value_template: '{{ value == "1" }}'
      friendly_name: Présence Extérieur

Home Assistant pour la sécurité

Si HA ne replacera jamais une véritable centrale de sécurité, cette fonctionnalité est intégrée et permettra en se servant de capteur de présence ou d'ouverture de déclencher une alerte ou une notification silencieuse. On ajoute ce code dans /config/configuration.yaml :

  alarm_control_panel:
  - platform: manual
    name: Home Alarm
    code: 1234
    pending_time: 30
    armed_home:
    pending_time: 0
    triggered:
    pending_time: 20
    trigger_time: 4

On place un input-text  dans ce même fichier configuration.yaml. Celà va nous aider pour les notifications détaillées.

input_text:
  trigger_source:
     name: Trigger Source # alarm notification

Ensuite on crée une Automation et le tour est joué, dans mon cas je ne fais que recevoir une notification sur Slack, mais il est tout à fait possible d'actionner une sirène, de faire clignoter des lampes...  Il restera à trouver une sirène autonome en Zigbee (ou autre, la plateforme HA est autonome et secourue, les capteurs également, il faut donc que la sirène et les notifications le soient).

Normalement le composant Alarme permet de notifier uniquement le fait qu'il y a eu un déclenchement, sauf bien sûr à créer plusieurs Automations. Pour intégrer le tout dans une seule automation et avoir en prime un message indiquant la source du déclenchement (capteur) ainsi que l'horodatage, je me suis inspiré de ce post.

- id: '1580693836436' # cet ID veut dire que j'ai fait ça avec l'interface HA : Automations
  alias: Alarm
  description: 'Détection et Notification'
  trigger:
  - entity_id: binary_sensor.motion_sensor
    platform: state
    to: 'on'
  - entity_id: binary_sensor.window_door_01
    platform: state
    to: 'on'
  condition:
  - condition: state
    entity_id: alarm_control_panel.home_alarm
    state: armed_home
  action:
  - entity_id: alarm_control_panel.home_alarm
    service: alarm_control_panel.alarm_trigger
  - data_template:
    entity_id: input_text.trigger_source
    value: '{{ trigger.to_state.attributes.friendly_name }}'
    service: input_text.set_value
  - data_template:
       message: "Alarme déclenchée par le capteur : {{ states('input_text.trigger_source')\\ }} à {{now().strftime('%H:%M le %d/%m/%Y')}} \n"
    service: notify.slack_hass_canaletto

Les résultat est : Alarme déclenchée par l'ouverture de la porte d'entrée à 03:10 le 08/02/2020

On peut également fignoler une carte de récapitulatif des capteurs en modifiant le code afin d'obtenir l’affichage du dernier déclenchement, et il est possible de cliquer sur les icônes pour obtenir l'historique.

entities:
   - entity: binary_sensor.pir_hall 
     secondary_info: last-changed

^{On obtient ainsi un affichage plus explicite}

Mais delà ne nous donne que la dernière communication entre le capteur et HA. On peut également créer un sensor: supplémentaire pour obtenir l'heure de la dernière ouverture de la porte, que l'on insérera à la place de l'heure de la dernière communication...

- platform: template    
  sensors:
    last_open_porte_entree:
      friendly_name: 'Last open :'
      value_template: "{{ as_timestamp(states.binary_sensor.openclose_40.last_changed)|timestamp_custom('%H:%M - %d/%m') }}"

Pour simplifier on va créer des groupes de détecteurs (dans groups.yaml)

all_sensors: # GROUP ALL pour ALARME
  name: All Sensors
  entities:
    - binary_sensor.lumi_sensor_smoke    
    - binary_sensor.porte_entree
    - binary_sensor.porte_garage
    - binary_sensor.fenetre_cuisine
    - binary_sensor.fenetre_antoine
    - binary_sensor.motion_hall
    - binary_sensor.motion_garage
    - binary_sensor.motion_sejour
    - binary_sensor.motion_cuisine

Ce qui nous permettra de d'utiliser un seul trigger comme source de déclenchement :

- alias: Alarm
  description: ''
  trigger:
    - entity_id: group.all_sensors
      platform: state
      to: 'on'
  condition:
  - condition: state
    entity_id: alarm_control_panel.home_alarm
    state: armed_home
  action:
  - entity_id: alarm_control_panel.home_alarm
    service: alarm_control_panel.alarm_trigger
  - data_template:
      entity_id: input_text.trigger_source
      value: '{{ trigger.to_state.attributes.friendly_name }}'
    service: input_text.set_value
  - data_template:
      message: "{{now().strftime('%d/%m/%Y, %H:%M')}} > A L A R M  W A R N I N G  | Sensor : {% for state in states|selectattr('entity_id','in',state_attr('group.all_sensors','entity_id'))|selectattr('state','eq','on')|list -%}{{state.name+' '}}{%- endfor %}"
    service: notify.Free_Mobile

On notera le template de notification qui permet d'indiquer la source de déclenchement :

11/03/2020, 00:17 > A L A R M  W A R N I N G | Sensor : Fenêtre Cuisine

On peut également créer un binary_sensor: en s'appuyant sur un groupe de portes ou de fenêtres (faire des groupes à part) et ainsi afficher leur état, mais également s'en servir comme condition pour ne pas activer l'alarme si une fenêtre est ouverte, ou prévenir par un tts (message vocal) si la pluie est annoncée et qu'une fenêtre est ouverte...

- platform: template
  sensors:
    state_doors:
      friendly_name: "Etat des portes"
      device_class: door
      value_template: "{{ is_state('group.doors_status', 'on') }}"

Notifications

S'il est bien sur possible de'utiliser toutes sortes de notifications possible (sms, mail, telegram, etc..), j'ai personnellement choisit d’utiliser un canal de Slack dont je me sert par ailleurs . Il y a plusieurs façons de faire :

Slack

notify:
- name: Slack
  platform: slack
  api_key: xoxp-xxx-xxx-xxx......
  default_channel: '#hass_canaletto'

- name: slack_hass_canaletto # Alternative API
  platform: rest
  method: POST_JSON
  resource: https://hooks.slack.com/services/0/2/es...........
  verify_ssl: true
  message_param_name: 'text'

Free Mobile

Ici aussi, pas besoin du moindre plugin, c'est intégré :

- name: Free_Mobile
  platform: free_mobile
  username: 12345678
  access_token: jlkjJLjlJLjlMkLhkh

Infos EDF Tempo et EJP

On pourra s'en servir pour faire quelques économies en baissant les consignes de températures les jours rouges. Pour obtenir les valeurs mise à jour, il suffit simplement (en vrai on a un peu galéré...) les sensor: correspondants :

# TEMPO
    - platform: command_line
      name: 'EdF : Tempo demain'
      command: curl -A "'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0' '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 }}"

    - platform: command_line
      name: 'EdF : Tempo'
      command: curl -A "'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0' '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 }}"

    - platform: command_line
      name: 'EdF : EJP'
      command: curl -A "'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0' '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 }}"

# EJP
    - platform: command_line
      name: 'EdF : EJP'
      command: curl -A "'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0' '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 }}"

    - platform: command_line
      name: 'EdF : EJP Demain'
      command: curl -A "'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0' '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 }}"    

    - platform: rest
      name: 'EdF : EJP : 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 si on veut fignoler l'affichage (promis bientôt en rouge cligotant)

binary_sensor:
  - platform: template
    sensors:
      ejp_on:
        friendly_name: "Edf : EJP"
        value_template: "{{ is_state('sensor.edf_ejp', 'SUD_EJP') }}"
        device_class: power   
        icon_template: >
          {% if is_state('binary_sensor.ejp_on','on') %} 
            mdi:alert
            red
          {% else %} 
            mdi:sleep
          {% endif %}
#        icon_color: >
#           if (state === 'on') return 'red';
#           return 'green';

  - platform: template
    sensors:
      ejp_on_demain:
        friendly_name: "EdF : EJP Demain"
        value_template: "{{ is_state('sensor.edf_ejp_demain', 'SUD_EJP') }}"
        device_class: power   
        icon_template: >
          {% if is_state('binary_sensor.ejp_on_demain','on') %} 
            mdi:alert
            red
          {% else %} 
            mdi:sleep
          {% endif %}

Ampoules Yeelight

https://www.home-assistant.io/integrations/yeelight/
https://www.w3.org/TR/css-color-3/#svg-color

Gestion des coupures électriques

Avant je gérait les coupures électriques avec des module ITS23. Mais comem j'ai viré tout ce qui était en 433 Mhz, ça ne va plus être possible. J'ai donc monté un plugin qui va lires les données des onduleurs et est capable de me dire si l'arrivée est down.

https://community.home-assistant.io/t/apcupsd-for-multiple-ups/98962/2

https://community.home-assistant.io/t/how-to-connect-your-apc-ups-to-rpi-and-home-assistant-using-apcupsd/10609/4

Sauvegarde

Il est de base possible de faire des snapshots complets ou partiels de la configuration. On peut améliorer en automatisant avec le plugin Auto Backup qui en outre notifiera si ça se passe mal. Ces sauvegardes étant stockées sur la machine HA ça ne me paraissait pas suffisant. J'ai finalement trouvé une solution de gestion des sauvegardes qui en conserve localement et en externalise une partie sur Google Drive, bien intégrée à HA et qui fonctionne parfaitement.

Alerte batteries faibles...

Avec tous ces capteurs qui fonctionnent sur piles il faut être prudent. Don va donc mettre en place des alertes si les piles sont trop faibles, le message pourra être reçu sur n'importe quel type de notifications, ici Slack :

On commence par créer une entité dans groups.yaml :

battery_levels:
  name: Battery Levels
  entities:
    - sensor.aqara_bouton_battery_level
    - sensor.aqara_inter_battery_level
    - sensor.motion_sensor_battery_level
    - sensor.ikea_tradfri_on_off_battery_level
    - sensor.ikea_tradfri_rc_battery_level
    - sensor.mi_antoine_battery_level
    - sensor.rpi_mi_batt_582d34104d6d
    - sensor.rpi_mi_batt_582d34103286
    - sensor.rpi_mi_batt_4c65a8d1db75
    - sensor.mi_bureau_battery_level
    - sensor.mi_congelateur_battery_level
    - sensor.mi_cuisine_battery_level
    - sensor.mi_garage_battery_level
    - sensor.mi_lionel_battery_level
    - sensor.mi_marie_battery_level
    - sensor.presence_41_battery_level
    - sensor.mi_refrigerateur_battery_level
    - sensor.mi_sejour_battery_level
    - sensor.openclose_40_battery_level
    - sensor.window_door_01_battery_level

Et ensuite une automation :

- alias: Notification- Alert That Batteries Are Low
  initial_state: 'on'
  trigger:
    - platform: time
      at: '19:50:00'
  condition:
    condition: or
    conditions:
      - condition: template
        value_template: >
          {% set min_battery_level = 10 -%}
          {% set ns = namespace(found=false) -%}
          {% for entity_id in states.group.battery_levels.attributes.entity_id -%}
            {% set parts = entity_id.split('.') -%}
            {% if (states(entity_id) | replace("%","") | int) < min_battery_level -%}
              {% set ns.found = true -%}
            {% endif -%}
          {% endfor -%}
          {{ ns.found }}
  action:
    - service: notify.slack_hass_canaletto
      data_template:
        message: >
          {%- set min_battery_level = 10 -%}
          {%- for entity_id in states.group.battery_levels.attributes.entity_id -%}
            {%- set parts = entity_id.split('.') -%}
            {%- if (states(entity_id) | replace("%","") | int) < min_battery_level -%}
              {{ states[parts[0]][parts[1]].name }} battery level is only {{ states(entity_id) }} % !{{ '\n' }}
            {%- endif -%}
          {%- endfor -%}

Utilisation des voyants de la ZiBase

La ZiBase n'est pas tout à fait morte... Certains sous Jeedom s'en servent comme d'une sorte de RFPlayer pour profiter de ses protocoles, c'est fastidieux et je n'ai jamais réussit à faire fonctionner le plugin idoine. Moi je me contente d'utiliser ses 5 leds comme un afficheur d'état en les définissant en switch: avec in curl (depuis j'ai constaté que ça passait mieux avec un wget) :

    zibase_led_1:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%202"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%203"
    zibase_led_2:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%205"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%206"
    zibase_led_3:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%208"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%209"
    zibase_led_4:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2011"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2012"
    zibase_led_5:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2014"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2015"

    zibase_led_1_flashing:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%204"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%203"
    zibase_led_2_flashing:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%207"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%206"
    zibase_led_3_flashing:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2010"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%209"
    zibase_led_4_flashing:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2013"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2012"
    zibase_led_5_flashing:
      command_on: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2016"
      command_off: curl "http://192.168.210.30/cgi-bin/domo.cgi?cmd=LM%2015"

Géolocalisation et présence

Inside et de base grâce à l'application mobile. Pour aller pus loin il sera bien sur possible de gérer des tags ou d'utiliser les API de Google afin d'obtenir la position des membres de la famille et interagir.

https://www.home-assistant.io/integrations/google_maps/

Une autre idée intéressante : 

https://www.home-assistant.io/integrations/owntracks/
https://www.juanmtech.com/owntracks-http-mode-and-home-assistant/

HassOS et mode développeur

S'il est possible de monter Home Assistant sur un Linux, il existe également une version qui intègre tout dans une image et qui sera bien plus facilement installable, que ce soit sur un RPI ou en VM. 

L'inconvénient est que l'on a pas facilement accès au shell avec l'add-on SSH de base. Mais qu'à delà ne tienne, il est possible de passer en mode développeur en ajoutant sa propre clé SSH et ainsi accéder à tout. Attention à ne pas tout casser, je ne suis pas développeur mais cela l'a été utile pour récupérer des informations, et par exemple connaitre l'adresse MAC de ma clé Bluetooth Sena (1 - 2 | 3)

# hciconfig
hci0:   Type: Primary  Bus: USB
        BD Address: 00:xx:xx:47:D6:C2  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING
        RX bytes:616 acl:0 sco:0 events:37 errors:0
        TX bytes:942 acl:0 sco:0 commands:36 errors:0
hci1:   Type: Primary  Bus: UART
        BD Address: B8:zz:zz:CE:AD:83  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING
        RX bytes:85743 acl:2 sco:0 events:2054 errors:0

# hcitool dev
Devices:
        hci1    B8:xx:xx:CE:AD:83
        hci0    00:zz:zz:47:D6:C2

SSL

Je revient ici sur le SSL et les différentes méthodes possibles. Toute la question étant de savoir si on va faire du SSL de bout en bout, ou pas, car si on installe un certificat sur HA, celui ci ne répondra plus qu'en SSL.

• DuckDns : C'est le plus simple. Ca prends 5 minutes. Inconvénient on n'utilise pas son propre domaine. Ce n'est pas très gênant car HA n'est pas un site public.
• Let'Encrypt : Ça revient au même, sauf que c'est le plugin qui se charge du renouvellement des certificats. Le plugin est compatible Acme 2 en DNS API, Cloudflare et OVH OK, par contre l'API Gandi n'est pas implémentée pour l'instant.
• Cloudflare : Il peut être tentant de profiter d'un certificat gratuit pour 15 ans. Mais il y a un hic, pour que ça fonctionne cela sous entend que les requêtes passent par leur reverse proxy. Concrètement toutes les requêtes locales transiteront chez eux, et comme on se sert beaucoup de HA en local cela peu provoquer un ralentissement (la route est plus longue avec cet aller/retour) qui peut poser problème pour ceux qui ont un faible débit. Sans parler du fait que vos données transitent par un tiers. Une solution peu consister à utiliser leur mode flexible ou l'on sera en SSL entre le client et le reverse de Cloudflare, le reste transitant en clair, mais dans ce cas on peut sécuriser en et restreindre l'IP externe de HA uniquement sur les IP Cloudflaire. A réfléchir, mais la solution Cloudflare me parait bancale pour cet usage.
• OVH SSL Gateway : Inconvénients identiques à Cloudflare
• Proxy Local : C'est une solution (Nginx, HA Proxy, Synology, etc...), dans ce cas c'est au niveau du proxy que se gère le certificat et HA reste en HTTP. Dans l'appli mobile n peut déclarer une adresse locale en fonction du SSID.

Je reviendrait plus tard sur cette problématique (1 | 2), mais pour l'instant DuckDNS me va très bien.

Sources

• https://www.awesome-ha.com/
• https://github.com/frenck/awesome-home-assistant
• https://github.com/home-assistant/operating-system/blob/dev/Documentation/network.md
• https://forum.hardware.fr/hfr/electroniquedomotiquediy/domotique_maisonconnectee/domotique-connectee-intelligente-sujet_5_659.htm
• https://github.com/hassio-addons/repository-edge/blob/master/README.md
• https://github.com/romquenin/home-assistant-config-fr
• https://forum.jeedom.com/viewtopic.php?f=96&t=32675&sid=4cb49bef4c6e91e278d6d6f0721fbcbb
• https://projetsdiy.fr/mosquitto-broker-mqtt-raspberry-pi/
• https://www.home-assistant.io/docs/mqtt/discovery/
• https://github.com/snarky-snark/home-assistant-variables
• https://github.com/daenny/climate_group
• https://community.home-assistant.io/t/controlling-climate-from-input-select/132557
• https://www.12h26.com/archives/gerer-qubino-flush-pilot-wire-home-asistant
• https://community.home-assistant.io/t/time-input-sliders-help/33176/6
• https://community.home-assistant.io/t/map-values-for-an-input-select/94354/18
• https://www.wouterbulten.nl/blog/tech/home-assistant-smart-home-hardware-setup/
• https://github.com/joch/home-assistant-config
• https://home-assistant-china.github.io/components/alarm_control_panel.manual/
• https://community.home-assistant.io/t/how-to-make-sure-automation-triggers-in-a-set-time-interval/100439
• https://community.home-assistant.io/t/template-turn-on-multiple-lights-devices-at-once/55700
• https://cdn.materialdesignicons.com/3.2.89/
• https://github.com/home-assistant/home-assistant-polymer
• https://github.com/home-assistant/home-assistant-polymer/pull/2929
• https://github.com/home-assistant/architecture/issues/148
• https://community.home-assistant.io/t/easiest-way-to-trigger-an-automation-with-one-tap-from-lovelace/108564
• https://www.bountysource.com/issues/70029780-climate-scheduler
• https://community.home-assistant.io/t/climate-automation-for-time-schedules-over-the-day/161041
• https://community.home-assistant.io/t/generic-thermostat-with-scheduler/35047
• https://ledstripsandcode.blogspot.com/2018/11/simple-thermostat-scheduler-in-home.html
• https://github.com/home-assistant/home-assistant/issues/20154

Comme bien des utilisateurs, Jeedom, que j’utilise depuis deux ans, m’exaspère bien souvent. De fait s’est installé dans les communautés d’utilisateurs un étrange mouvement de Jeedom Bashing. Jeedom exaspère car s’il s’agit bien d’un programme Open Source, dans la pratique bien des options sont payantes, et même si le prix de ces options est parfois dérisoire (2 à 8 € pour un plugin), le simple fait de payer conduit à ce que les utilisateurs se sentent autorisés à râler envers les développeurs qui font parfois (souvent) la démonstration de leur arrogance. Les gens râlent face à des plugins qui ne sont pas toujours bien maintenus, peu documentés, parfois abandonnés, et face à des choix discutables et arbitraires. Bref, Jeedom respire parfois l’amateurisme et surtout l’ambiance qui règne sur les forums fait que bien souvent les utilisateurs n’osent même plus poser une question légitime de peur de se prendre un mauvais retour !

Alors quand on est pas content, on a envie d’aller voir ailleurs si l’herbe est plus verte, c’est d’ailleurs le conseil parfois donné sur les forums par des personnes plus ou moins représentantes de Jeedom (ça on ne sait jamais vraiment). Aller ailleurs quand on a énormément investit sur une plateforme n’est pas une décision anodine car il s’agit là d’une activité chronophage et l’on n'a pas l’assurance de pouvoir faire mieux, voire simplement aussi bien, avec une solution concurrente.

S’il existe d’innombrables solutions concurrentes tant en mode commercial que DIY, et que je ne vais pas comparer ici, celle qui a vraiment la cote ces temps-ci c’est Home Assistant. HASS est une solution full open source qui dispose d’une énorme communauté internationale. Et là on sort déjà du cadre car Jeedom n’a jamais réussi à dépasser l’hexagone, le revers de la médaille est qu’il faudra d’une part un minimum de maîtrise de l’anglais, et d’autre par que certaines spécificité du marché national seront peu prise en charge.

Un soir dans un fil Telegram on a été plusieurs à se dire « chiche ? » et c’est ainsi que j’ai passé 24 heures avec Home Assistant, que je vais essayer de vous narrer (les vidéos sont prises au hasard en deux clics sur Google, mais la toile regorge d'informations).

Homme Assistant s’installe à peu près n’importe où (base Linux) et ne pose aucun problème particuliers, si en mode production un RPI4 est conseillé, je l’ai personnellement installé en quelques minutes sur une VM ESXi pour tester et grâce à un VMDK pré-buildée. La configuration est tout aussi simple, on découvre une interface hyper réactive et intuitive, mais également que HASS découvre tout seul une grande partie de vos équipements installés sur le site ! Avantage à HASS.

Une solution domotique doit communiquer avec l’extérieur, et pour cela il faut du SSL. HASS propose deux solutions, basées sur Lets’Encrypt, la première avec DuckDns prends 5 minutes et suffit amplement, la seconde adaptée à un domaine personnalisée est un peu plus longue mais pas vraiment plus. Et vu que l’adresse liée à ce domaine ne servira qu’à vous ou votre application mobile, le fait qu’il soit personnalisé n’a que peu d’importance. Avantage à HASS.

On passe ensuite à l’application mobile, on est ici face à une application très fluide qui s’appuie sur l’interface native de HASS. On y retrouve tout avec en prime la localisation qui est intégrée. Que dire, rien, si le SSL est bien configuré, on lance l’application qui reconnait toute seule HASS et ça fonctionne. On est à des années lumières du semblant d’application mobile payante de Jeedom. Avantage à HASS.

Homme Assistant dispose de plusieurs « boutiques » d’addons, tant officielles que communautaires, parler de boutiques est abusif car ici tout est gratuit et bien documenté. On est très loin de Jeedom qui se prend pour l’Apple Store. En option je recommande l’installation de HACS, la boutique communautaire optionnelle de référence basée sur Github. Avantage à HASS.

Si à l’utilisation on fait souvent beaucoup de copié / collé de code sous HASS, la majorité des automatisations et la gestion des scènes se font via l’interface utilisateur. Personnellement ce qui m’a conduit à utiliser d’abord une ZiBase, puis Jeedom, c’est la gestion de mes thermostats virtuels pour gérer mon chauffage électrique. Le chauffage électrique avec plusieurs convecteurs est une spécificité bien de chez nous. Et sur ce point, si HASS dispose bien d’un équivalent au niveau thermostat, qui s’appuie sur un capteur de température et un actionneur, son niveau est en deçà et si on veut remplacer les plugins MODE et AGENDA faciles à mettre en œuvre sous Jeedom, il faudra plonger dans le cambouis car rien n’existe vraiment, à part coder. Avantage à Jeedom. (pour l’instant j’espère).

EDIT : Après quelques semaines je me rends compte que si HA mériterait un agenda, c'est d'ailleurs en cours de développement, ce n’est pas bien compliqué de mettre les doigts dans le cambouis, et au moins on peut faire du sur mesure, et que finalement l'agenda étaient plus compliqués ! Donc finalement, avantage à Home Assistant, même s'il faut bien reconnaître qu'au début c’est moins évident à appréhender ! (voir les articles suivants : 1 | 2 )

Enfin concernant la prise en charge des Assistants vocaux Google Home ou Alexa, si cette option est bien intégrée, sous HASS la prise en charge de l’infrastructure cloud nécessaire a été confiée à un partenaire, c’est cher ($ 5 par mois contre 12 € / an pour Jeedom) mais le service est professionnel. Rien à ajouter sur cette facturation, qui est tout à fait compréhensible de part et d’autre.

Conclusion, je suis conquis. Bien sur ce n’est pas exhaustif et ces quelques lignes sont discutables, mais en 24 heures j’ai fait le tour et pas trop mal maîtrisé Homme Assistant, ce qui m’avait pris des semaines lorsque j’ai basculé de ZiBase vers Jeedom. C’est clair, aéré et fonctionnel. Ce qui n’est pas là n’est pas là, mais ce qui est proposé fonctionne, donc pas de perte de temps inutiles. J’espère donc ne jamais avoir à basculer vers Jeedom v4 et il n’est pas exclu que je laisse pour l’instant le chauffage sur Jeedom tout en migrant le reste sur Home Assistant.

Sources

• https://www.antoineguilbert.fr/choix-solution-domotique-home-assistant-ou-jeedom/
• https://www.youtube.com/channel/UCbCJtFizTFNf4waPWPFAqcA/videos
• https://www.nabucasa.com/
• https://www.home-assistant.io/integrations/#search/sh
• https://www.awesome-ha.com/
• https://www.pofilo.fr/post/20190224-home-assistant-install/#hass-io

Unifi Protect pour gérer ses caméras (Unifi) de surveillance c'est top. Sauf qu'on est face à une solution professionnelle et qu'en se sens ils ne se préoccupent pas de l'intégration avec Alexa. J'ai récemment acheté un Alexa Echo Show 5 pour remplacer mon radio réveil et je me disait que ce serait bien que je puisse lui demander de voir le flux vidéo de mes caméras, fonctionnalité non proposée de base par Unifi Protect.

En cherchant un peu j'ai trouvé un service qui pourrait m'aider, service par ailleurs pas réservé aux caméras Unifi puisque basé sur le protocole RSTP. Et cerise sur le gâteau Monocle va me permettre de demander à Alexa de voir le flux de mes caméras, sans pour autant que ce flux circule à l'extérieur de mon réseau local. Pour y parvenir il faut faire tourner localement un petit service (Linux, Windows, OSX, Docker, Synology) à caser sur une machine existante qui servira de relais, Monocle ne servant alors qu'çà aiguiller les requêtes et les flux entre les serveurs et devices Alexa et les caméras locales (via le NVR pour Unifi Protect).

On part bien sur du principe que les caméras sont installées, et fonctionnent correctement avec Unifi Protect dans notre cas. 

La première chose à faire sera de se créer un compte sur le site https://www.monoclecam.com. Ensuite on va sur la page de configuration d'Unifi Protect activer le flux RSTP (le medium me semble suffisant) et on copie le lien correspondant, que l'on pourra au passage tester en se servant de VLC.

Lien que l'on reportera sur le dasboard Monocle lors de la création de la caméra, avec simplement son adresse IP locale (rien à faire coté routeur puisque la passerelle Monocle servira de relais) et dans notre cas le TAG @tunnel, cette balise sera utilisée pour demander à Monocle de transférer les connexions d'un appareil Alexa vers la caméra de votre réseau local. Cela indique à Monocole de créer une connexion tunnel sécurisée directement entre la caméra et l'appareil Alexa sans faire transiter le flux à l'extérieur.

Il va maintenant falloir configurer la passerelle locale. Cette passerelle communique avec le Skill Alexa hébergé dans le cloud Monocle et qui utilise les détails configurés dans les étapes ci-dessus pour dire à mon Echo Show comment communiquer avec ma caméra locale. La documentation fournie par Monocle contient d'excellentes instructions sur la façon de configurer la passerelle sur différents systèmes différents, mais dans mon exemple, je vais simplement la configurer sur une VM Windows Server disponible pour ce test.

J'ai donc simplement téléchargé la version x64 de la passerelle, que j'ai décompressée dans le répertoire c:\monocle, ensuite je suis allé créé et télécharger la clé API sur mon compte Monocle et je l'ai copiée dans ce même répertoire. Il suffit ensuite de lancer monocle-gateway.exe en ligne de commande. Et voilà ! (en mode production on pourra bien sur installer cette passerelle en tant que service Windows comme décrit dans la documentation).

Coté Alexa on installe le Skill Monocle depuis l'application mobile, ce qui permettra de faire remonter les cameras dans Alexa et de les affecter à des pièces, et ensuite on demande à Alexa sur l'Echo Show de vous montrer la caméra, et miracle ça marche du premier coup !

Sources

• https://mullineaux.com.au/2019/11/10/setup-unifi-protect-cameras-on-an-echo-show-5/
• https://monoclecam.com/

Et voilà un mail de Sonos qui nous annonce la mise au rebut forcée de ses anciens produits, produits par ailleurs parfaitement fonctionnels. Un peu comme si Renault vous envoyait un mail pour vous dire que votre vieille Fuego allait être désactivée (ce qui du reste arrivera un jour j’en ai bien peur…).

Ce message ne dit rien d’autre, avec un argument technique de pacotille pour se justifier, le but est bien là : Poubelliser. Sonos pourrait se contenter de limiter les fonctionnalités des anciens produits, ce qu'il laisse entendre de façon très floue, et ce qui est d’ailleurs déjà le cas car tous les appareils ne disposent pas de toutes les fonctionnalités. Mais il ne faut pas se méprendre, sans mises à jour dans les mois qui suivent, la présence des "trop anciens" équipements pénalisera suffisamment l'utilisation de l'ensemble pour que les utilisateurs les retirent, mais comme ils en ont le contrôle ce sera selon la réaction des utilisateurs afin d'essayer de na pas faire trop de dégâts, l'objectif restant tout de même la poubelle forcée.

Le problème de sonos c’est d’avoir conçut dès le départ des produits de très bonne qualité. Vous en connaissez vous de produits avec du soft et un microprocesseur qui fonctionnent encore très bien 15 ans après ? Moi non. C’était leur leitmotiv de départ, et sur ce point bravo, sauf qu’aujourd’hui Sonos a perdu son âme !

Et aujourd'hui se retourne contre eux, car comme toute société, Sonos à des actionnaires, actionnaires qui exigent des résultats, donc des ventes. Et si les clients n’ont pas de raison de renouveler leur matériel, il n’y a pas de ventes. Et ce d’autant plus que l’offre a changée, les marché regorge d’enceintes connectées, souvent moins coûteuses et aux performances et qualité comparables.

Alors pourquoi continuer à acheter Sonos ? Jusqu’alors je recommandais Sonos pour sa qualité et surtout sa pérennité, mais voilà que Sonos devient le champion de l’obsolescence décidée.

Sonos a révolutionné le multi room qui était avant réservé à quelques luxueuses installations. Sauf que, même si Sonos est certainement le maître en la matière, la concurrence fait également du multi room, par exemple et très simplement avec le ChromeCast Audio à 30 € (qui n’est hélas plus proposé par Google), des enceintes assistant Google Home ou Amazon Alexa, ou encore des enceintes connectées d’autres marques, Bose, Sony, Samsung, etc… des chinoiseries qui s’en sortent souvent très bien ou des bricolages DIY très simples à base de RPI. Mais qui utilise vraiment du multi room ? Je n’ai pas de statistiques, seul Sonos qui ne se prive pas dans sa collecte de donnée en dispose, mais en ce qui me concerne je vois surtout des ados envoyer leur playlist vers une enceinte depuis Spotify sans même utiliser l’appli Sonos qu'ils n'aiment pas ! Et ça c’est possible sur toutes les enceintes connectées.

Alors dans un contexte ou les gouvernements commencent à se préoccuper de l’obsolescence programmée, ou une (timide) loi a d’ailleurs été votée en ce sens, ou le green est de plus en plus en vogue, je trouve la stratégie annoncée par Sonos vraiment déplacée et même suicidaire. Proposer 30% sur un nouveau produit à la condition d’accepter la désactivation de l’ancien, et sans d’ailleurs se préoccuper du son recyclage, c’est du pur mépris pour ses client (et oui, vous n’êtes pas maître du produit que vous avez acheté, Sonos peut désactiver à tout instant vos produits, vous l’avez accepté dans les conditions d’utilisation que vous n’avez pas lues).

Proposer une vraie continuité de fonctionnement en mode dégradé, ou une remise acceptable (50% ?) sur un produit équivalent et surtout la garantie que l’ancien équipement sera correctement recyclé (pas juste désactivé) me paraîtrait une bonne base de départ pour conserver la confiance des clients, faute de quoi il y a tout de même de grandes chances que les constructeurs concurrents se fassent un plaisir de les accueillir. D’ailleurs, si cette concurrence est un brin intelligente, elle proposera elle-même un peu plus de 30% pour un achat conçurent en échange d’un vieux Sonos.

Pendant ce temps Sonos pourra toujours pleurer en accusant la concurrence (Google et Amazon) d’avoir copié leurs technologies, probablement avec raison, mais il y a de fortes chance que privé de sa base de clients fidèles qui se seront sentis floués, le titre chute, que Sonos perde peu à peu son aura et finisse un jour par disparaître… Ce qui ne serait pas une première dans la tech. Fin annoncée d’une belle histoire !

NB : pour ceux qui seraient tentés de faire la parallèle, on ne peu pas comparer la fin du support (regrettable) de Windows 7 par Microsoft avec la mise au rebus imposée par Sonos. Si dans les deux cas on peut parler d’obsolescence programmée, la comparaison s’arrête là, car d'un coté on est face à un O/S installable sur n'importe quel matériel et sujet à d'innombrables problèmes de sécurité, alors que Sonos est un eco-système totalement fermé et maîtrisé par son constructeur.

Il y a un peu plus d'un an j'écrivais un article pour exprimer mes questionnements quant à l'évolution de la Zibase vers Jeedom. Jeedom n'est pas la panacée, mais c'est une boite à outils. Voici donc points par points en reprenant le fil de 2018 comment ça a évolué.

L'objectif est de rendre tout cela le plus acessible que possible, de sortir de Jeedom ce qui ne sert à rien et de piloter de plus en plus d'équipements via Alexa tout en conservant un contrôle local hors cloud.

Se pose également la question du passage à la v4 de Jeedom, mais ça attendra une version bien finalisée, en tous les cas pas avant la fin de l'hiver !

Objectifs

Le chauffage électriques sur 6 zones avec divers scénarios.

• Le plugin Thermostat est parfait
• Les plugins Agenda, Présence et Mode permettent de gérer manuellement ou automatiquement en fonction de calendriers et des événements (j’ai des amis pour diner, périodes de vacances scolaires, etc…).
• J'ai viré toutes les sondes Oregon peu esthétiques au profit de sondes Xiaomi / Aquara en Zigbee ou Bluetooth. Je n'en pouvais plus de devoir ré-appairer les sondes à chaque changement de piles.

Le chauffe-eau

• Le mode nuit du chauffe-eau était géré par la ZiBase, il est maintenant géré par un agenda une nuit sur deux pendant les heures creuses. J'ai abandonné l'idée d'y intégrer une sonde.

La VMC

• Je ne la gérais pas mais il doit être simple de la gérer via Jeedom à partir de l’hygrométrie de la salle de bain ou de la cuisine (article). C'est chose faite en fonction de l'hygrométrie ambiante dans la salle de bains.

Simulation de présence

• Pour l’instant, j’ai choisi de ne pas intégrer cette fonction à Jeedom mais de la gérer en autonome avec des prises WiFi et l’application Tuya. Jeedom dispose maintenant d'un plugin qui fait le job.

Confort et éclairage

• Idem, c’est facilement géré en autonome avec des ampoules ou des prises WiFi et l’application Tuya, la commande se faisant depuis un smartphone, une tablette ou mieux en vocal avec Google Home (Alexa possible, j’aime bien sa voix…). Bref, c’est plus naturel. Pas de design ou de tablette, on ne contrôle pas une centrale nucléaire et je pars du principe que la domotique doit se faire oublier. Uniquement Alexa en vocal ou via son interface qui constitue une alternative à la désastreuse application mobile proposée par Jeedom.
• Donc il n’est pas utile pour l’instant de reporter ça dans Jeedom, sauf si on veut que certains équipements soient actifs quand les habitants sont présents. J’ai bon espoir de voir l’arrivée du plugin idoine. Ça reste possible en IFTTT, mais c’est un peu lent (2 sec environ)
• Jeedom dispose maintenant du plugin SmartLife / Tuya pour les prises et ampoules, d'autres ampoules Xiaomi / Yellight sont également gérées, ainsi que les modules Shelly. J'aime bien ces modules car ils permettent de conserver l’appareillage original (interrupteur) et d’ajouter une entrée domotique, pilotable via Jeedom grâce à un plugin et sur Alexa. Il ne faut pas que la domotique supprime les fonctionnalités de base de la maison, n'importe doit pouvoir continuer à allumer un luminaire !

Consommation des appareils énergivores

• Les prises Konyks via Tuya gèrent la consommation, notamment en veille, et parfois ça fait peur. De plus elles permettent de gérer des scénarios de base et un minuteur (genre, j’allume le home cinéma et celui-ci s’éteindra dans deux heures, soit après que j’ai regardé mon film). Tout cela est finalement un peu gadget, la domotique apporte du confort, pas des économies !
• Comme pour l’éclairage, on n’encombre pas Jeedom pour l’instant avec ça.

Les coupures EDF

Pourquoi en utiliser plusieurs points de détection ? En province il y a souvent des coupures EdF (vent, orages, vétusté) mais aussi parfois des différentiels de section qui tombent (surement d’humidité quelque part). Et dans ce cas il est important de savoir ce qui s’est passé à distance afin de pouvoir faire intervenir et guider un proche afin de ne pas retrouver un congélateur perdu au retour de voyage.

• Sur la ZiBase j’utilisais des micro-modules InterTechno alimentés sur piles pour déclencher une action en cas de coupure EdF. Ça doit être réutilisable sous Jeedom via le RFPlayer. C'est fait, même si le RFPlayer et sont plugin sont la partie la plus désastreuse de l'installation !
• Pour la partie informatique je devrais pouvoir récupérer les infos des onduleurs APC avec le plugin SNMP.
• Notification SMS / Pushbullet et / ou action voire IFTTT. J'ai basculé toutes notifications vers Slack.

Alarmes

• Le système d’alarme Visonic est autonome. C’est un principe minimal de sécurité.
• Par contre la remonté des capteurs sur Jeedom peut être intéressante afin d’identifier ce qui a déclenché une alarme à distance, voire déclencher une action secondaire en cas d’intrusion. Contrairement à la Zibase les RFPlayer dont il est issu remonte très mal les infos Visonic, enfin, c'est plutôt le plugin qui ne fait pas le job, mais visiblement a décidé de le laisser à l'abandon, et comme Ziblue est en liquidation ça laisse peu de perspectives...
• Plus pratique, se servir des contacts d’ouverture pour désactiver un radiateur ou des capteurs de présence en temporisant pour réduire l’éclairage ou la climatisation (gadget en phase 2…). Ce seront plutôt des capteurs d'ouverture en Xiaomi en Zibgee qui feront un jour ce travail...

Présence

• Déterminer via la localisation du mobile la mise en route du chauffage ou climatisation. Il y a je crois un plugin pour ça… Rien de stable, donc rien place...
• Gérer l’éclairage extérieur à l’approche de la maison via le WiFi. J'ai fait quelques test en BLEA avec un porte clés Tile, ça fonctionne.

Les logiciels

• Jeedom
• Application mobile Jeedom (je ne suis pas fan). Définitivement oublié. Il vaut mieux je pense utiliser l'interface web en mode mobile....
• Application mobile ImpériHome (je m'en servait déja sur la ZiBase) via le plugin idoine dans Jeedom. Le plugin est abandonné mais je m'en sert encore, il faudra un jour trouver une alternative.
• Application mobile TuyaSmart, complétée par Xiaomi et Shelly pour les setups, mais surtout par Alexa.

Le matériel

Serveur, box domotique

Jeedom est installé sur un Raspberry Pi3 et les dongles USB utiles. Evolution possible dans une VM VMWare ESXi. Toujours sur un RPI afin que la domotique reste indépendant de tout le reste. C'est aussi plus simple pour gérer les clés des protocoles.

Avant que l’on me pose la question je vais expliquer pourquoi  je n’ai pas utilisé de Z-Wave, qui est pourtant le protocole roi dans cet univers, protocole ayant eu le soutien de tous les boutiquiers de la domotique (maintenant remplacés par Amazon…). Bref, je n’en ai jamais utilisé sur la ZiBase et j’ai pu m’en passer. Et surtout c’est trop cher, le moindre module Z-Wave étant affiché à 50 €.

Sondes de température :

• Oregon : j’en ai plusieurs, elles étaient reconnues par le ZiBase et elles fonctionnent correctement via la clé RFPlayer (125 €) et le plugin idoine. Inconvénient, elles sont moches et il faut refaire l’appairage à chaque changement de piles ce qui est une corvée à l’usage. Vendues et replacées par des Xiaomi / Aquara.
• Xianomi et Xiaomi Aquara en Zigbee (6/12 €) : Fonctionnement OK via la clé ZiGate (45 €) et le plugin idoine. En cas de longue distance on peut mailler avec une prise Zigbee. Ces sondes esthétiques et très discrètes ne transmettent les infos (température, humidité, pression) que s’il y a un changement d’état et / ou très aléatoirement s’il n’y a pas de changement. Le modèle carré (Aquara) semble plus volubile. A valider en période de chauffage. J'ai abandonné la clé ZiGate dont les évolutions rendaient l'installation instable au profit d'une Combee II installée sur un second RPI qui fait office de passerelle Zigbee universelle (Phoscon / Deconz). C'est stable.
• Xiaomi en Bluethoth 12/18 € : reconue par le plugin BLEA. Intervalle réglable. Elles sont très esthétiques. La portée est réduite avec le Bluetooth intégré au Pi mais ça devient correct (100 m²) avec une clé Bluetooth longue portée (UD100, 45 €). Test ici. Je m'en sert là ou j'ai besoin d'une sonde avec afficheur, elles sont hélas un peu généreuses, +1°...

Présence

• Capteurs d’alarme Visonic via le RFPlayer toujours en chantier...
• Capteurs Xianomi via la ZiGate Replacé par Combee II
• BLEA + tag Nutt Tag Tile
• WiFI via les smartphones : Pas vraiment exploitable car les smartphones mettent de plus en plus le WIFI en veille. Il faudrait le faire en Bluetooth, je crois qu'un plugin est en préparation.

Notifications

• SMS (Free API)
• Pushbullet Remplacé par Slack que j'utilise au quotidien.

Alarmes et sécurité

• (voir présence)

Eclairages et appareils

• Prise et ampoules Konyks ou Sonoff, WiFi via Tuya. Les prises Sonoff S26 permettent de gérer l'état à la mise sous tension, ce n'est pas le cas des prises Konyks ou c'est plus aléatoire. J'ai disqualifié Konyks (cher pour ce que c'est), Sonoff (pas CE/NF) au profit de Shelly.
• Possible extension en Philips Hue, Osram, Ikea and co (Zigbee) via la ZiGate et son plugin Les ampoules Xiaomi SmartBulb en WIFI sont très bien.

Actionneurs

• IPX800 : pour l’instant j’ai une IPX800 v2.
  C’est une simple carte 8 relais qui me sert pour l’instant à actionner les radiateurs et le chauffe-eau. En sortie j’ai câblé des contacteurs de puissance Finder avec le bon pouvoir de coupure et de ne pas forcer sur les relais de la carte. L’intérêt de ces contacteurs est de disposer d’un bypass manuel et ainsi de pouvoir passer les équipements en manuel en cas de défaillance de la domotique. Les versions 3 et 4 de l’IPX800 n’ont pas d’intérêt dans mon cas.

• Prises et modules Chacon : ils se pilotent via le RFPLayer, mais ça reste un protocole peu fiable.
  Etat aléatoire lors de la remise en tension après une coupure EdF, auquel cas il est gênant de retrouver la moitié des prises ON… Impossibilité également d’utiliser deux équipements proches, c’est by design. Donc mon aventure Chacon / DI-O est terminée. J'élimine Chacon / DI-O au profit de prises Tuya et des modules Shelly avec retour d'état.

• X2D : Je n’utilisais qu’un seul module DeltaDore pour commander le sèche-serviettes et je dois pouvoir le gérer avec le RFPlayer. Il est toujours présent, mais il passera à la trappe bientôt...
  Cette solution permet de gérer le fil pilote, mais il est vrai que je pourrais le faire avec un jeu de diodes. A voir.
• Prises et ampoules Zigbee : via la ZiGate et son plugin. J’ai une Osram qui me fait le maillage. Remplacé par Combee II
• Prise et ampoules WiFi : via Tuya, plugin en devenir ? Pas d’urgence. Plugin OK

Réseau et Wi-Fi

• Le réseau et le WiFi sont gérés depuis longtemps avec du matériel Unifi (AP AC Pro et USG). Le top ! Au-delà de cette solution qui reste un peu complexe pour un particulier je recommande Amplfi de chez Unifi ou la solution WiFi proposée par Google. Un bon réseau est une base impérative en domotique et généralement le WiFi proposé par les box est à oublier. On attends la Dream Machine Pro...

Vidéo surveillance

• Caméras et PVR Unifi (je sais, je suis fan de cette marque) dans une VM VMWare. C’est géré à part de façon autonome. J'ai remplacé le NVR soft par Unifi Protect sur une Cloud Key II, c'ets le jour et la nuit....

Multimédia

Vidéo

• Emby (j’y reviendrai dans un post à part) en remplacement de Kodi. Des box NVidia Shield et Xaomi Mi Box 3S sous Android TV ont remplacé les PI. Elles supportent également Netflix et Amazon Vidéo.
• TV : Tuner réseau HDHome Run qui permet de recevoir les chaînes sur les box Android TV et les autres devices (même si dans la pratique je ne regarde pas la TV). Ce n’est pas compatible Canal, ce n’est pas mon problème car je ne suis pas fan, mais le cas échéant il est toujours possible d’installer MyCanal ou Molotow sur les box.

Musique

• Sonos dans toutes les pièces, certains équipements datent de 2005 et n’ont pas pris une ride. On ne change rien. Spotify et base locale de CD numérisés. Je me suis fait plaisir avec un Sonos AMP auquel j'ai ajouté des voies arrière avec deux petites enceintes Ikea by Sonos, au départ c'était pour la musique mais le rendu en home cinéma est fabuleux !

Quand on envoie un mail on ignore bien souvent que le niveau de confidentialité équivaut à peu près à une carte postale. En effet, tout comme la carte postale pourra être lue par le facteur, un mail pourra être lu par les différents services d’acheminement. De même ce n’est parce que l’adresse de l’expéditeur est emmanuel.macron@elysée.fr que c’est forcément le Président qui vous a contacté, tant il est simple de falsifier une adresse d’expéditeur.

On souhaite donc parfois d’une part garantir à un contact la provenance d’un message et d’autre par en assurer la confidentialité.

Pour y parvenir il existe plusieurs solutions, certaines sont propriétaires comme ce qui est offert (contre monnaie) par Office 365, plutôt simples à mettre en œuvre, d’autres s’appuient sur des utilitaires pour chiffrer le contenu et on peut également penser à PGP pour les plus geeks. Enfin, S/Mime répond à un standard défini en 1999 (RFC 1847) que l’on peut utiliser sur tous les clients de messagerie, et bien sûr moins facilement sur les Webmail qui eux ont tendance à rendre l’Internet de plus en plus propriétaire.

Pour faire court S/Mime est une méthode de chiffrement asymétrique qui utilise une paire de clés, l’une est privée, la vôtre, l’autre est publique, celle qui est transmise à vos correspondants.

Obtenir un certificat

Pour utiliser S/Mime il va falloir se procurer un certificat auprès d’une autorité de certification. Il existe plusieurs classes de certificats en fonction de la méthode de vérification. Cela va du simple échange de mails avec un niveau de sécurisation basic à un passage devant un notaire, qui, grace à la fourniture de documents, attestera de votre identité. On va ici s’en tenir à des certificats basics et gratuits, mais le principe d’utilisation reste le même.

La durée de vie d’un certificat ne peut pas excéder deux ans, voire moins pour certains. Dans notre cas, les certificats gratuits pour un usage personnel proposés par Actalis ou Comodo (il existe d'autres sources) ont une durée de validité de un an. Pour en faire la demande c’est très simple, il suffit de remplir un formulaire et de valider grâce aux informations reçues par mail, ce qui constitue la preuve de validation. (A une époque le site impots.gouv.fr en fournissait pour se connecter, cela aurait pu être une opportunité formidable de fournir des certificats aux citoyens, mais l’idée a été écartée).

Une fois le certificat obtenu, il faut l’importer dans son système d’exploitation, via une MMC sous Windows, ou via le trousseau de sécurité sur MacOS (ou sur votre mobile). Il n’y a plus ensuite qu’à configurer son logiciel de messagerie pour qu’il l’utilise et le tour est joué. On choisira soit de l’utiliser systématiquement pour signer ses messages, soit ponctuellement. Pour le chiffrement il faudra au préalable que votre correspondant ait reçu de votre part un message signé et vous en ayez reçu un de sa part afin de disposer de sa clé publique. Par ailleurs il est également possible d’utiliser de tels certificats pour signe des documents PDF par exemple.

Je ne vais pas vous expliquer pas à pas comment faire tout cela, d’autres l’ont très bien fait (Google est votre ami... avec le mot clé S/Mime). Le but était simplement de rappeler que cette possibilité existe, et qu’elle est définie par un standard.

Sources

• https://www.ionos.fr/digitalguide/email/securite-email/smime/
• https://support.office.com/fr-fr/article/chiffrer-les-messages-%C3%A0-l-aide-de-s-mime-dans-outlook-web-app-2e57e4bd-4cc2-4531-9a39-426e7c873e26
• https://www.youtube.com/watch?v=nanBL5cbNT4
• https://www.sslmarket.fr/ssl/utilisation-de-certificat-smime/
• https://www.ssl.com/how-to/installing-an-s-mime-certificate-and-sending-secure-email-with-outlook-on-windows-10/

La solution Unifi Protect fonctionne bien mieux que l’ancienne version Unifi Video. Sauf qu’un client vous demandera toujours ce qui n’existe pas… Si on peut très facilement visionner ses cameras sur un navigateur (astuces inside : 1 - 2) ou un application mobile, mais rien n’est prévu sur un TV isolé, sauf à connecter un PC. Et un PC n’est pas franchement ce qui sera le plus fiable sur la durée. Je suis donc allé chercher du coté de chez Raspberry, le nano ordinateur à tout faire et on y trouve un petit projet simplement nommé DisplayCameras. 

L’installation devait être simple mais m’a tout de même un peu cassé la tête, en fait simplement parce que j’ai pris une image Raspbian trop récente pour que tout se déroule normalement, donc voici : 

1. On télécharge une image Raspbian, la Buster lite fera très bien l’affaire (Ou simplement une Stretch ici qui sera compatible avec le script). Avec Etcher (ou autre chose) on prépare la carte µSD
2. Une fois terminé, on insère la carte dans le RPI et on y connecte un clavier et le réseau
3. Une fois qu’il a démarré on lance sudo raspi-config et on configure ces options :

^{(3) Boot Options > Wait For Network at Boot
(4) Localisation Options > Change Timezone > (tant qu’à y être aussi votre langue et clavier…)
(5) Interfacing Options >  SSH >  Yes
(7) Advanced Options > Expand File System
(7) Advanced Options > Memory Split > 256}

5. On en profite pour faire une petite mise à jour
   sudo apt-get update && sudo apt-get upgrade -y && sudo reboot
6. A ce stade je recommande de passer l’IP en statique avec sudo nano /etc/dhcpcd.conf (on enlève les # et on complete). Mais avant allez repérer le nom de votre interface avec un ip a car eth0 ça devait trop simple… Et ensuite on redémarre avec un sudo reboot.

# Example static IP configuration:
interface enxb827eb1aa100
static ip_address=192.168.210.35/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=192.168.210.1
static domain_name_servers=192.168.210.12 8.8.8.8

7. A partir de là on oublie le clavier du RPI et on passe en SSH, avec Teminus par exemple. C’est plus pratique pour la copié / collé. On se connecte avec le username / password par defaut si on ne l’a pas changé plus haut (ce serait bien de le faire…) :
   Username = pi / Password = raspberry 

8. Une fois connecté on va télécharger le code qui nous intéresse, le décompresser et enfin l’installer...

wget https://github.com/Anonymousdog/displaycameras/archive/0.8.3.3.zip
unzip 0.8.3.3.zip
cd displaycameras-0.8.3.3
chmod +x install.sh
sudo ./install.sh

Sauf que comme le script d’installation n’est pas fait pour l'ultime version de Rasbian, il en oublie l'essentiel. Il va falloir ruser un peu :

sudo apt-get update
sudo apt-get install omxplayer

Maintenant on va configurer le flux de nos caméras avec sudo nano /etc/displaycameras/layout.conf. Ce fichier contient également tous les réglages possibles de positionnement, mais par défaut il est configuré pour 4 caméras sur un écran HD. La principale partie qui nous intéresse est celle-ci :

camera_feeds=( \
"rtsp://192.168.1.2:7447/i6m4f1act8nwtp4bg0veqw4u_1" \
"rtsp://192.168.1.2:7447/ifkjakg27dboh5ho6ull349u_1" \
"rtsp://192.168.1.2:7447/n7jt8fimlqvm6o0a0nwjdal6_1" \
"rtsp://192.168.1.2:7447/9lqpgwvrusvk8u0br7n3t2ki_1" \

CameraDisplay ne s’appuie pas sur Unifi Protect mais sur les flux RTSP qui sont configurables en option dans Unifi Protect au niveau des réglages de chaque caméras et ce en différentes résolutions. J’ai fait mes tests sur un RPI2, je me suis donc abstenu de passer en full HD, mais c’est jouable sur un RPI3. Dans les liens ci dessous vous trouverez d’autres réglages, tel que la rotation d’images si on dispose de plus de 4 caméras par exemple…

A ce stade on est pressé de voir le résultat, alors on lance sudo systemctl restart displaycameras.service. On peut aller brancher le RPI au dos de la TV sans clavier, il redémarrera tout seul avec la bonne config. Voilà !

EDIT

Il y a des choses qui se préparent chez Unifi...

Sources 

• https://selfhostedhome.com/raspberry-pi-video-surveillance-monitor/
• https://github.com/Anonymousdog/displaycameras
• https://tutorials.technology/tutorials/Tutorial--Raspberry-Pi-3-RTSP-Stream-Viewer.html
• https://community.ui.com/questions/Tutorial-Raspberry-Pi-3-RTSP-Stream-Viewer/cc54f892-b8d6-46c5-81f3-ee58b9284889?page=1
• https://community.ui.com/questions/NUC-ODROID-H2-TinkerBoard-RTSP-Multi-monitor-viewer/dda27a47-f502-48f5-956b-cb6dc15fbbc4
• https://www.bitpi.co/2015/03/18/raspberry-pi-surveillance-monitor/
• https://community.ui.com/stories/My-First-Unifi-Video-Setup-with-Raspberry-Pi-Monitor/c00fd0a1-1b62-4a9c-bdeb-97a83ab1ef01?page=1

Alors voilà, je bosse depuis une douzaine d’année sur le même PC, un HP i7 alors un peu haut de gamme, sous Windows 7. Au fil des années je lui ai donné un peu de mémoire (16 GO) et j’ai remplacé le disque par un SSD. Le Windows 7 est d’origine avec un nombre incalculable d’installations de logiciels et d’utilitaires à tester, et la particularité est que je ne le redémarrais jamais, en dehors de quelques coupures électrique, et il y a bien longtemps que j’avais désactivé les mises à jour visant à le pousser vers la sortie ! Bref, la robustesse même d’un bon PC avec un O/S éprouvé.

Lors de la dernière coupure électrique j’ai toutefois remarqué qu'il avait mis un peu de temps à redémarrer, et même qu’il voulait chercher des secteurs défectueux, je ne l’ai pas fait et il a fini par redémarrer, c’était au début de l’été je crois.

Je me suis tout de même dit qu’il serait temps de faire quelque chose avant de me retrouver vraiment en rade. Au début je voulais le remplacer par un NUC. Mais un NUC un peu sérieux sur lequel je pourrais raccorder au moins trois écrans va chercher dans les 1500 €, voire plus. Alors je me suis dit, pourquoi ne pas faire comme pour les serveurs et regarder le marché de l’occasion chez les brookers. Les maîtres en la matière sont les allemands. Ils rachètent des lots aux grandes entreprises, ils révisent, polissent et finissent par vous livrer une machine comme neuve ! Et c’est ainsi que je me suis offert une Workstation HP Z230SF avec un Xeon E3-1245v3 (au moins aussi puissant que les i7 des NUC), un SSD pour Windows et un disque dur parce-que le brooker ne doit pas aimer laisser des emplacements vides… Ah j’oubliais surtout 32 GO de mémoire, le tout pour 380 € TTC !

Pas besoin d’installer Windows, la version Pro est une vraie version OEM, et surtout la dernière build ce qui m’évite les fastidieuses heures de mise à jour. Windows 10 je connais car même si j’ai longtemps boudé sur mon PC principal j’en ai sur des laptops ou des VM chez moi ou sur Azure. Il n’y a pas que du bon, loin de la, mais on ne peut pas rester indéfiniment sur un O/S vintage, et puis avec le temps Windows 10 commence à se stabiliser, au moins quand les développeurs de chez Microsoft ne se prennent pas une murge la veille du lancement d’une mise à jour importante. La dernière à du être sérieuse (je parle de la murge) car je me suis retrouvé avec des mises à jour appliquées d’office et surtout avec l’antivirus désactivé au redémarrage. Bref, tout va bien du côté de Redmond…

Mais ce n’est pas pour vous narrer ma life que j’ai voulu écrire ce billet, mais pour vous explique un problème que vous pourriez bien rencontrer, si ce n’est pas déjà fait !

Sous Windows 7 j’avais trois écrans HD, un en VGA, un autre en DVI et un troisième en USB via un adaptateur. Je l’avais oublié celui-là, et entre temps j’aurais pu le raccorder sur le port HDMI de la carte graphique de que j’avais dû remplacer (les constructeurs installent des cartes graphiques avec ventilateur, inutile en bureautique, le ventilateur lâche au bout de 3 ans et on doit changer la carte graphique, un classique de l’obsolescence programmée, alors qu’une carte fanless fait parfaitement l’affaire en bureautique).

Su ma nouvelle machine j’ai trois sorties Display Port. J’ai donc acheté 2 câbles DP vers DVI pour deux de mes écrans et je me suis offert un écran UHD pas trop cher (Samsung U28E590D) pour mettre au centre, et qui dispose lui d’une entrée Display Port. Je raccorde le tout et tout fonctionne merveilleusement. Edge me permet de rapidement installer Chrome et ainsi d’installer les applications qui me seront utile. Bon, je suis mauvaise langue, Microsoft s’est enfin décidé à copier Google et la RC du nouveau Edge Chromium fonctionne très bien, à la différence que ce n’est plus Google qui vous espionnera mais Microsoft, pas sur que ça change grand-chose si ce nouvel Edge se popularise… J’évite d’installer trop de choses car j’ai pris soin de virtualiser mon ancien Windows 7 sur mon ESXi et je pourrais ainsi y retrouver les petits utilitaires que j’utilise une ou deux fois par an.

Le hic !

Alors vous devez vous dire, tout ce bla bla pour vous dire que j’ai un nouveau PC ? Hélas il y a un problème ! En effet, le petit matin qui suit le grand soir, lendemain de la première nuit avec lui (comme dirait Bénabar), j’ai eu la surprise de retrouver toutes les fenêtres que j’avais méticuleusement ordonnées, ramassées, tapies au coin de l’écran de droite. C’est très désagréable sur ce genre de config ou tout à sa place. Après quelques tests et mises à jour de pilotes, je me suis rapidement aperçu que c’était la mise en veille ou l’extinction des écrans qui provoquait ça, en effet Alexa les éteint pour économiser quand je lui souhaite une bonne nuit…

Je suis donc parti pour une longue nuit à l’exploration des forums afin de trouver une solution. A la surface du net, Microsoft conseille comme d’habitude de mettre à jour les pilotes, de réinstaller Windows ou d’autres conseils du même acabit. Bien sûr, continuez à prendre les gens pour des ânes ! En cherchant un peu on s’aperçoit qu’il y a bien un problème, mais que c’est By Design, comme ils disent. Et surtout je me suis aperçu que je suis loin d’être le seul concerné, quelque part ça me rassure !

Explications

Un écran Display Port (ou HDMI) est un peu moins bête que nos bons vieux VGA. Il communique avec le PC via la carte graphique. Windows lui demande de se mettre en veille, il se met en veille et puis il s’éteint. Et sur ce type d’écran si l’écran est éteint, Windows considère tout bonnement qu’il n’est plus présent, donc il agit comme s’il avait été débranché et il déplace les fenêtres de cet écran sur un écran qui lui est présent, même éteint car connecté en VGA ou DVI, Windows ignore son état. Je schématise un peu, tout cela est géré par les protocoles DDC/CI et l’EDID (voir les liens en bas pour les curieux).

Alors vous allez me dire qu’il doit bien exister une clé de registre pour palier à cet inconvénient ? Et bien non, en fait il y en avait une sous Windows 7 et la première version de Windows 10, mais depuis elle a été supprimée, Microsoft (et l’industrie qui va avec) considérant surement qu’il n’y avait plus sur terre d’écrans VGA ou DVI et que tout le monde disposait d’écrans DP ou HDMI, auquel cas ce problème n’existerait pas car tous les écrans sont alors absents et il n'y a pas lieu de déplacer les fenêtres.

On retrouve ce problème dans des configurations différentes, par exemple ceux qui utilisent un TV connecté au PC et l’éteignent quand ils ne regardent plus de films, le Player rejoint alors l’écran principal. Ou la situation ou on connecte un vidéo projecteur le temps d’une présentation et ou PowerPoint rejoint l’écran du laptop quand on débranche le projecteur. Mais dans ces cas ça a du sens ! Ce qui est rageant c’est que Microsoft ne laisse pas le choix, fusse t'il via une position de registre pour ceux qui osent RegEdit.

On pourrait également penser que cela puisse se passer au niveau du driver, et ce serait assez logique. En gros aujourd’hui de ce côté là on a NVidia, AMD et Intel. Sur les NVidia Quatro (des cartes pro) il y a une astuce, attention, pas une fonctionnalité mais juste une astuce qui peut disparaître lors de la mise à jour suivante. Mauvaise note également pour Samsung qui sur ce modèle ne prévoit pas la désactivation DDC/CI, certains écrans Dell le permettent.

Me voici donc condamné à travailler avec un seul écran ou à renouveler tous mes écrans. Quand je disais à mon comptable que j’aurais du prendre un 8K de 95 pouces… Ce n’est pas une solution, et je préfère travailler avec plusieurs écrans, un principal en 28" UHD, un 24" HD à droite qui me sert principalement pour des connections à des dizaines de sessions RDP sur des serveurs distants, et un autre 24" à gauche dédié aux divers moyens de communication (WA, Messenger, Slack, Hangouts, etc…). C’est ainsi, à mon âge je ne vais pas changer mes habitudes, déjà qu’il faut manger bio se sentir responsable de la planète ! Et je n’ai aucune envie de me plier à un quelconque dictat. Et pour ceux, oui je l’attendais celle-ci, qui me diront que je devrais passer sous Mac, sachez que j’ai aussi un Mac et que le problème est exactement identique.

Contournement

Puisque j'ai vu sur des centaines de posts sur de forums ou des sites qu’il n’y a pas de solution simple et efficace, je vais essayer de contourner ce dysfonctionnement. Après tout je ne demande pas la Lune, je ne cherche qu’à retrouver la disposition de mon espace de travail au réveil !

Je me suis d’abord dit qu’il devait exister des utilitaires permettant de retrouver une disposition précise, ou mieux la dernière disposition, après une mise en veille. Certains le promettent comme DisplayFusion dans sa version payante, hélas promesse non tenue, et c’est même pire, il mélange tout ! D’autres, gratuits, semblent faire mieux mais sont statiques et datent de Windows XP. Je me suis épuisé à chercher et je n’ai rien trouvé de satisfaisant, de plus quand l’écran Display Port se rallume, Windows effectue le processus de reconnaissance Plug&Play, ce qui n’est pas instantané. En listant certains forums j’ai également vu des utilisateurs excédés couper ou isoler des broches sur les connecteurs HDMI, solution pas totalement satisfaisante car du coup l’écran ne se mettra pas en veille.

Il existe bien une solution, mais elle consiste à sortir le fer à souder, c’est l’affaire d’une paire de résistances à deux centimes. Et comme toujours en pareille situations il y a ceux qui ont décidé de rentabiliser leur fer à souder. Ainsi il existe deux solutions clé en main, l’une en HDMI sur un site qui n’inspire pas vraiment confiance, mais ses adaptateurs son bien livrés et fonctionnent à ce que j’ai pu lire sur des forums, l’autre solution vient du Japon, elle est dédiée au Display Port, son auteur prend soin d’expliquer que ça ne fonctionne pas toujours… Tant pis, je suis joueur et pour 47 € je viens de passer commande… Je reviendrais vous en parler ici…

EDIT 07/11/2019 : J’ai reçu l’adaptateur DPHPDMA. En fait il y a deux modèles, le plus simple est censé fonctionner tout seul en Fake mode, mais dans mon cas ça n’a rien changé. Heureusement il y a un jumper pour forcer le Fake mode. En fait de jumper il s’agit ici de faire une microscopique soudure après avoir démonté l’adaptateur. Je ne suis pas équipé pour ce genre de soudure sur CI, j’ai tenté le coup avec mon fer à souder d’électricien, par chance ça n’a rien brûlé et ça fonctionne. Alexa peut éteindre mes écrans quand je vais me coucher sans risque de tout retrouver en vrac le lendemain.

Le second modèle, outre qu’il dispose d’un cavalier afin d’éviter toute soudure hasardeuse, dispose également d’un lien USB qui permettra de gérer les modes directement depuis Windows. Il n’en reste pas moins que ça fait beaucoup et cher pour une fonctionnalité arbitrairement retirée de Windows.

Autre chose...

En fait il y a un autre paramètre à prendre en compte car ça peut être gênant à l’usage. Sur un UHD de 28" on utilise une mise à l'échelle de 150% sans quoi c’est vraiment trop petit. Par contre sur le HD qui est à coté en 24" on conserve le ratio standard à 100%. Et quand on fait glisser une fenêtre d’un écran à un autre, Windows il la resize à la volée, d’une part c’est visuellement désagréable et d’autre part ça plante quand on le fait plusieurs fois sur la même fenêtre...

Donc pour faire cohabiter un écran UHD avec des écrans HD de 24" il faut dans l’absolu que le UHD fasse 42" afin de pouvoir utiliser une mise à l'échelle standard de 100%, dans mon cas ça s'est terminé avec un 32" et une mise à l’échelle à 125%.

Windows 10

Et sinon, ça fait quoi de passer de Windows 10 après avoir résisté tout ce temps ?

Bof, à une époque où tout se passe de plus en plus dans un navigateur, L’O/S a-t-il encore une grande importance ? Pour preuve, j’ai envoyé à ma fille un vieux ChromeBook pour remplacer son MacBook Pro le temps d’une réparation (250 € mais on n’a pas su me dire quoi), bref au-delà de son profond attachement à son MacBook (merci le Marketing Apple), elle ne m’a exprimé aucune gêne liée à l'usage du ChromeBook pour son travail à la fac. Seul hic, Netflix ne se lance pas sur ce vieux ChromeBook, mais il a cinq ans…

Tout ça pour dire qu’en ce qui me concerne Windows 10 ne m’apporte pas grand-chose, je pourrais en dire plus quand j’aurais réglé ce problème d’écran. Pour l’instant je le sens bien plus gourmand. Par exemple, outre Outlook, Slack, Opera pour WA, Telegram et Messenger, pas mal d’utilitaires chargés, deux OneDrive et Google Drive, j’ai en permanence 256 onglets dans Chrome (impossible avec d’autres navigateurs), ceci était contenu sous Windows 7 dans mes 16 GO de mémoire, là j’arrive aisément à 24 GO sous Windows 10 alors que j’ai surement moins de choses qui tournent en tache de fond… Donc quand il se dit que Windows 10 est moins gourmand c’est un leurre, d’ailleurs il ne se vend plus de laptops au-dessous de de 8 GO de mémoire à ce que je sache… Bref, Windows 10 c’est l’industrie en marche, mais les utilisateurs ont des habitudes, cela profite à Microsoft, il n’y a qu’à voir Office que tout le monde réclame pour envoyer trois courriers et faire quatre additions. Je pense sincèrement que l’avenir pour les utilisateurs lambda est un Chromebook, peut être que Microsoft le comprendra et sortira son équivalemment, je pense même qu’ils y travaillent… En plus ça ne plante pas, car il n’y a rien dedans, tout étant dans le cloud…

Windows 10 c’est aussi la plaie des mises à jour. Il faut donc rapidement installer ce petit utilitaire si on ne veut pas être emmerdé. Oui j’ai bien dit emmerdé car je veux pouvoir décider quand je vais consacrer du temps à installer des mises à jour et pas que Microsoft me l’impose (même combat sous Windows Serveur 2016/2019, mais là il y a une alternative car on passe de plus en plus de serveurs sous Linux, d’ailleurs en parlant de Linux, je vous parlerai un jour de mon expérience plutôt positive avec Ubuntu / KDE / Plasma).

Bonus : Gadgets

Sous Windows 7 nous avions les Gadgets de bureau, parfois gadget mais parfois très utiles comme par exemple pour pouvoir surveiller d’un œil des processus ou des liaisons (SNMP, VPN, services). Microsoft ayant décidé que nous n’en avons plus besoin (sous l'ovni Windows 8 je crois ou ça faisait tache avec les tuiles), des développeurs indépendants se sont hâtés de rendre ça disponible sous Windows 10. Il faut bien le dire, si ça fonctionne bien, le design vintage fait un peu tache sous Windows 10. Heureusement il y a d’autres développeurs qui on produit Rainmetter (1). Ca ne date pas d’hier mais aujourd’hui le projet est bien aboutit et le design est magnifique. Donc si les gadgets vous manquent, je recommande !

Bonus : mes petits outils du quotidien...

• Player vidéo universel : https://mpv.io/
• Extracteur universel : https://www.extractnow.com/
• Gestionnaire de fichier hosts : http://www.abelhadigital.com/hostsman 
• Pour remplacer la calamiteuse application photo : https://imageglass.org
• Et pour l'audio : http://www.digimezzo.com/software/dopamine/

Bonus : Windows Defender

Si vous trouvez que Windows Defender prend trop ses aises, restreignez le avec cette commande PowerShell (Microsoft vous donne les explications ici ). 

Set-MpPreference -ScanAvgCPULoadFactor 25

Et à moins que vous ne passiez votre temps dans les coins sombres du net, évitez les outils de sécurité tiers, pour le coup celui qui est intégré à Windows fait bien son job. Désinstallez également tous les crapwares livrés avec votre nouveau PC, deux antivirus c'est contre productif. Et si vous pensez vraiment qu'il vous faut une meilleure protection, vous n'avez pas besoin de mes conseils et ce n'est pas avec des solutions grand public que vous vous bâtirez vos défenses....

Sources

• https://www.displayfusion.com/
• http://www.desksoft.com/WindowManager.htm
• http://www.stefandidak.com/windows-layout-manager/
• http://www.systemgoods.com/
• https://www.dell.com/support/article/fr/fr/frbsdt1/sln295708/display-windows-move-resize-after-resuming-from-sleep-state?lang=en
• https://sites.google.com/site/ebobster/stuff/displayportblanking
• https://superuser.com/questions/630555/turning-displayport-monitor-off-disables-monitor-completely/631691#631691
• http://monitordetectkiller.com
• https://paleblew.blogspot.com/p/engdphpdma.html
• https://www.datapro.net/techinfo/hot_plug_detection.html
• https://www.intowindows.com/set-custom-resolution-on-windows-10/
• https://davidvielmetter.com/tricks/disable-hdmi-hot-plug-detection-in-windows-7/
• https://meanwhileblog.wordpress.com/2016/01/08/disable-hot-plug-detect/
• https://appuals.com/what-is-ddc-ci-and-how-to-use-it/
• https://clickmonitorddc.bplaced.net/
• https://www.ghacks.net/2016/05/08/test-control-monitor-softmccs/
• https://www.entechtaiwan.com/lib/softmccs.shtm
• https://www.nicomsoft.com/products/display-tuner/
• https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU
• https://community.amd.com/thread/191221
• http://www.realtimesoft.com/ultramon/download.asp
• http://www.surfacetablethelp.com/2018/08/how-to-disable-displayport-auto-monitor-detection-in-windows-10.html
• https://answers.microsoft.com/en-us/windows/forum/windows_10-power/monitor-off-detection-moving-windows-to-turned-off/58f3d247-b0bf-4990-8627-fb15a94c5167
• https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/disabling-monitor-auto-detection-in-windows-10/e4f6bbc3-b45f-4880-8b06-3e339d62ac59?page=4
• https://answers.microsoft.com/en-us/windows/forum/windows_vista-performance/i-get-a-flash-ddcci-enable-disable-on-my-monitor/5594ae1c-ceec-4eae-a6d2-49f308c72aac?messageId=3ef5d0b2-023f-4116-8d78-aa38b0040b03 

À la suite de mes mésaventures avec la clé ZiGate, j’ai commandé une clé Combee II.

Etant sous Jeedom j’avais découvert la naissance d’un plugin officiel qui lui est dédié (6 € tout de même, mais en principe les plugins officiels sont mieux maintenus dans la durée que les plugins tiers, encore que parfois Jeedom décide arbitrairement de les abandonner aussi). A première vue j’ai failli suivre bêtement la recommandation du plugin qui consiste à installer la gateway deCONZ / Phoston sur le RPI Jeedom. Puis je me suis ravisé, sans avoir à ce moment-là totalement appréhendé l’affaire, je me suis dit qu’il ne fallait pas tout lier à Jeedom. En fait installer la passerelle à part la rend indépendante puisque de toutes façons le plugin Jeedom n’est qu’un client IP de cette passerelle qu’il interroge localement (127.0.0.1) si elle est installée sur la même machine et via son IP dans le cas contraire. D’une part ça permet de la placer au centre de la maison, et également de la contrôler directement avec d’autres applications en se passant de Jeedom (Alexa par exemple), sachant que Jeedom recevra de toutes façons les retours d’état. Et pour faciliter la chose, plusieurs images SD pour RPI sont proposées sur le site Phoscon (attention de base le client DHCP de ces images ne prend pas la GW, de toutes façons vaut mieux figer l’IP, donc éditer la configuration).

Voilà déjà une chose impossible avec l’approche ZiGate. Ensuite à mon sens il faut oublier l’approche tout Jeedom. Ce qui compte c’est que Jeedom connaisse l’état d’un équipement. En effet, prenons l’exemple d’un interrupteur Ikea qui va allumer une ampoule Philipps. On configure la chose depuis Phoscon de façon très simple, ça fonctionne sans Jeedom mais ça n’empêche pas Jeedom d’agir, par exemple dans le cadre d’un scénario plus évolué. L’idée est que ce qui pourra être géré dans Phoscon déchargera Jeedom. La passerelle Phoscon remplace simplement toutes les passerelles propriétaires (Ikea, Hue, etc..), et Jeedom (ou d’autres solutions domotique) viens s’y connecter en IP via une API.

Un autre avantage est que Phoscon se connecte directement et facilement (et gratuitement) avec Alexa / Google Home, ce qui n’est pas le cas de Jeedom qui nécessite un plugin et un abonnement obligatoire (12 € / an, même après avoir acheté un Service Pack Power Ultimate, moi qui pensait que ça incluait tous les plugins officiels). Et je ne parle même pas des connexions avec IFTTT, qui, si elles permettent pas mal d’interopérabilité, n’en sont pas moins compliquées à maintenir. Donc pour demander à Alexa d’allumer la lumière de la cuisine, autant limiter les intermédiaires, Alexa communiquera avec Phoscon / deCONZ plutôt qu’Alexa (en supposant qu’on ai ajouté Alexa à Jeedom) demande à Jeedom qui lui va demander à Phoscon / deCONZ d’allumer la cuisine…

Mobile

Phoscon ne dispose pas d’application mobile, mais la page est responsive et parfaitement utilisable sur un mobile ou une tablette. Cela étant c’est sans intérêt à l’usage si on lie Phoscon à Alexa ou Google Home car l’application mobile des assistant vocaux sera bien plus ergonomique. Je me disais d’ailleurs que lier Jeedom à Alexa présenterait au moins l’intérêt de disposer d’une interface mobile utilisable, en opposition à celle de Jeedom qui est une calamité. En attendant j’utilise Impérihome qui fonctionnait bien avec Jeedom, mais le plugin vient d’être retiré du Market Jeedom au profit d’une approche Impérihome sans plugin qui ne fonctionne pas. Je n’ai pas l’impression que Jeedom et Impérihome (ex ZiBase / ZiBlue & co.) soient très copains…

Intégration Jeedom

Pour revenir à Phoscon, tout ne semble pas géré dans la passerelle, si on peut créer des scènes et des associations, il y a d’autres équipements, les sondes de température par exemple ou d’ouverture de porte que l’on ne peut pas utiliser directement, mais généralement on n’en a besoin que dans Jeedom.

Le plugin remonte des valeurs propres à chaque équipement, on n’aura pas les classiques infos binaires ou numériques (on/off ouvert/fermé) mais un code numérique propre à chaque équipement. Par exemple une télécommande Ikea va envoyer 1002 si on appuie au centre, il n’y a plus ensuite qu’à traiter directement l’information (scénario, virtuel, etc…) pour créer une action dans Jeedom. En revanche les sondes (températures, humidité, pression) remontent bien les valeurs et sont exploitables directement.

Attention cependant aux capteurs, les Xiaomi, par exemple, ne supportent pas de perdre leurs parents, donc si vous changez de canal Zigbee ou si le maillage passe par une prise Zigbee que vous retirez, il vaudra mieux les réinclure (le maillage peut se voir sur l’application graphique deCONZ). De même il ne faut pas oublier qu'un objet Zigbee ne peut être inclut que une sur passerelle. Ainsi si vous incluez un objet avec Foscon alors qu'il est déjà inclut dans la passerelle Xiaomi, cet objet sortira du réseau géré par la passerelle Xiaomi afin de rejoindre celui géré par la passerelle Foscon.

Conclusion

Au départ j’hésitais à remplacer ma douzaine de sondes Oregon gérés par le RFPlayer (les sondes Oregon perdent leur identifiant lors de chaque changement de piles, il faut donc les appairer à nouveau, ça reste fastidieux, même si c'est prévu par le plugin. Et je passe sur toutes les déconvenues liées au RFPlayer que je ne recommande vraiment pas), par des sondes Xiaomi gérées par la ZiGate, mais comme la solution Combee II + plugin deCONZ fonctionne plutôt bien, je pense me tourner de ce côté rapidement. Je mettrait bien sur à jour cette page pour vous narrer mon expérience…

La Combee II + Phoscon sur un RPI (SD ready) peuvent servir de passerelle universelle Zigbee compatible avec les assistant vocaux et ainsi remplacer les passerelles des constructeurs (Ikea, Hue, etc...). Phoscon comme Jeedom avec le plugin DeCONZ s'appuient sur la couche deCONZ. 

Mise à jour

$ sudo systemctl stop deconz

# Mise à jour de la Combee II
$ wget http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF
$ sudo GCFFlasher_internal -d /dev/ttyACM0 -t 60 -f deCONZ_ConBeeII_0x26580700.bin.GCF

# Mise à jour Deconz
$ wget -N http://deconz.dresden-elektronik.de/raspbian/deconz-latest.deb
$ sudo dpkg -i deconz-latest.deb
$ sudo reboot

Bonus

Certains me demandent pourquoi j’utilise des RPI alors que j’ai un gros serveur VMWare ESXi dans le garage, ce qui faciliterait la manipulation des VM et leur sauvegarde. Simplement parce que je considère que la domotique gère des fonctions vitales de la vie courante (chauffage par exemple) et qu’elle ne doit dépendre de rien d’autre. Imaginez, le serveur se plante, il faut réparer le serveur sans chauffage… De plus les clés utilisées pour les divers protocoles ne seraient pas idéalement placées au fond du garage

Sources

• https://presentationdeconz.wordpress.com/
• https://jeedomiser.fr/article/vos-equipements-zigbee-avec-la-cle-conbee-ii-et-jeedom/
• https://phoscon.de/en/app/doc

La clé ZiGate permet d’utiliser le protocole Zigbee que l’on retrouve chez Ikea, Philips, Xiaomi et bien d’autres. Je l’utilise depuis ses débuts et ça fonctionne plutôt bien. 

Il y a une semaine, je me suis décidé de passer ma clé de 3.0d en 3.0f dans l’espoir de pouvoir inclure une prise et un inter IKEA. La chose devait être simple. 

Après la mise à jour de 3.0d en 3.0f et un redémarrage du plugin et mise à jour des dépendances, mes équipements sont toujours là mais aucune information ne remonte dans Jeedom, les interrupteurs sont inopérants et il est impossible d’associer quoi que ce soit. J’ai fini par mettre à jour la clé en 3.1a sans plus de succès. 

En désespoir de cause j’ai désinstallé le plugin Zigate pour le réinstaller. Là je peux inclure à nouveau mais plus aucune trace de mes 12 équipements. Donc je me refais les inclusions et les configuration (genre « temperature » à renommer en « Température », etc… cocher ce que je veux voir, changer les widget, bref, passionnant… et perte de temps). Certains capteurs qui fonctionnaient avant ne voulaient plus s’inclure. Résolu en changeant de pile (qui remontait pourtant bien les infos avant hier) et en rapprochant le capteur de la Zigate (On peut donc en déduire que pour associer un équipement vaut mieux que la pile soit en très bon état !). 

Et pour les équipements Ikea, c’est encore moins user friendly, le passage en groupe 0 ça va pour une prise mais pas vraiment exploitable pour plusieurs, ni à la portée de tout le monde. Inutile toutefois de débrancher la clé (comme recommandé sur le site Zigate), on peut passer par le mode terminal du plugin...

Commande : 0x0060

Les donnes à envoyer sont 02ABCD01010000 (ou ABCD est la short adresse de la prise IKEA)

Ensuite on peut associer l’inter livré avec la prise (facultatif) et on peut commander cette prise avec l’inter ou Jeedom, retour d’état compris. Si j’ai tout compris un inter commandera toutes les prises, alors que ces dernières sont adressables individuellement dans Jeedom. Pas réussit avec la télécommande qui semble dédiée aux ampoules suédoises. La solution Ikea / Zigate pour les prises est trop compliquée. Personnellement je recommande les prises Osram que l’on trouve régulièrement à 10 € sur Amazon si on veut absolument du Zigbee.

Cette mésaventure pose tout de même question. On sait tous que c’est du DIY et que ça comporte des risques inhérents à la pratique. Il n’en reste pas moins que les sondes de température relèvent du sensible dans une installation qui gère le chauffage. Donc manips à proscrire en plein hiver ! Il reste le cas de la panne à envisager. 

La clé ZiGate et ses plugins (ZiGate ou Abeille) sont en développement permanent et c’est normal pour du DIY. Dans mon aventure je ne sais pas ce qui a merdé (interaction entre la clé, sa mise à jour et/ou le plugin) ni comment j’aurais pu l’éviter. Que sauvegarder ? La clé contient des infos sur les équipements ? Que faut’ il sauvegarder ? Un petit topo sur les bonnes pratiques serait le bienvenu de la part des auteurs (qui sont certainement déjà bien surchargés…).

Énervé j’ai commandé dans la foulée une clé Combee II, je vais tester sans pour autant être persuadé que ce soit mieux, les deux solutions étant du RE (reverse engineering). A suivre ici...

EDIT 01/11/2019 : Suite à la dernière mise à jour du plugin ZiGate plus rien ne démarrait. J'ai donc retiré les équipement qui lui restaient associés et je les ai associés à la Combee II. Bref, ZiGate, c'est terminé, OFF et débranchée.