Jean-Christian Paul Denis - Mot-clé - vm

Ma domotique X : Teleinfo

Jean-Christian Denis — Fri, 26 Apr 2024 10:44:00 +0200

Ah la téléinfo, la première donnée que j'ai voulu suivre dans ma maison !

La téléinfo est la remonté d'informations du compteur EDF, elle transmet des données tels que la consommation instantanée, le tarif en cours ou encore le total des heures pleines. La consommation électrique d'un foyer est une des pierres angulaires de la domotique et la téléinfo en est la base. Couplé à des outils comme Grafana, elle permet un suivi et une analyse dans le temps de la consommation global du foyer, c'est un outil très important dans la recherche d'efficacité énergétique.

Exemple de graphique du Linky sous Grafana, avr. 2024

Aillant déjà un câble telefino arrivant du compteur vers le tableau électrique qui servait au contact jour/nuit, j'ai pris comme coordinateur un module de tableau électrique avec sortie USB mais il existe plein de modèles différents. (Le plus simple aujourd'hui serait un module zigbee directement sur le compteur.) Et j'utilise la passerelle telefino2mqtt de fmartinou.
Certaines fonctions de ma domotique exploitent directement ses valeurs comme le changement de tarif qui coupe ou met en marche certains appareils gros consommateur d'énergie (chauffe eau) ou encore pour le délestage qui coupe le chauffage si on consomme trop.

Installation du serveur telefinfo

Reportez vous aux billet précédents (ici et là ) pour en savoir plus sur ma configuration Proxmox et Docker.

On se rend dans le shell de notre serveur Proxmox et on créer notre machine virtuelle à partir du template docker et on lui adresse une IP fixe :

qm clone 910 116 --name telefino
qm set 116 --ipconfig0 ip=10.1.4.116/23,gw=10.1.4.1

Dans Proxmox, on va aller dans la configuration Hardware de la VM et lui ajouter le module USB teleinfo, il est bien reconnu par proxmox, pas de soucis de ce coté:

Installation Zwave bouton Add, avr. 2024

Ajout du module USB teleinfo, avr. 2024

On peut démarrer notre VM.
Maintenant on se rend dans l'interface web de Portainer, on lie notre VM, et on ajoute Stack qui ressemble à ça :

version: '3'

services:
  teleinfo2mqtt:
    image: fmartinou/teleinfo2mqtt
    container_name: teleinfo2mqtt
    restart: always
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    environment:
      - EMIT_INTERVAL=0
      - TIC_MODE=history
      - TZ=Europe/Paris
      - MQTT_URL=mqtt://10.1.44.111:1883
      - MQTT_USER=jeanjean
      - MQTT_PASSWORD=jeanjean

Le stack configure tout ce qu'il faut pour fonctionner, comme le serveur MQTT. Les trames devraient directement atterrir dans MQTT.
Exemple de données décodées :

{
  "ADCO": {
    "raw": "062061429523",
    "value": 62061429523
  },
  "OPTARIF": {
    "raw": "HC..",
    "value": "HC"
  },
  "ISOUSC": {
    "raw": "45",
    "value": 45
  },
  "HCHC": {
    "raw": "019581292",
    "value": 19581292
  },
  "HCHP": {
    "raw": "029104904",
    "value": 29104904
  },
  "PTEC": {
    "raw": "HP..",
    "value": "HP"
  },
  "IINST": {
    "raw": "005",
    "value": 5
  },
  "IMAX": {
    "raw": "090",
    "value": 90
  },
  "PAPP": {
    "raw": "01220",
    "value": 1220
  },
  "HHPHC": {
    "raw": "A",
    "value": "A"
  }
}

Il y a plus qu'à exploiter ces valeurs !
Voila pour le protocole teleinfo.

Ma domotique IX : Rfxcom

Jean-Christian Denis — Fri, 26 Apr 2024 09:40:00 +0200

Le Rfxcom est un des plus anciens protocoles domotique que je connaisse.

Le Rfxcom est généralement utilisé pour du matériel simple, le plus souvent sur pile. Par exemple, chez moi je l'utilise pour les capteurs d'humidité et de température avec une durée de vie des piles de plus de 3 ans ! Mais il peut être utilisé sur des interrupteurs, des contacts ou encore des équipements d'alarme avec un code tournant. L'inconvénient est que vous recevez les trames de tous les appareils à proximité, même ceux des voisins (et donc l'inverse est vrai), sympa pour savoir la température chez lui.
J'utilise la clé USB RFXtrx433XL comme coordinateur. La version XL embarque plus de sous-protocoles matériels. (marques) Il est possible de la mettre à jour et d'activer ou désactiver des sous protocoles mais je ne l'ai jamais fait, aillant tout ce qu'il me faut de base. Le bridge rfxcom2mqtt se charge de décoder les trames en quelque chose de lisible à traves la librairie MQTT.js

Installation du serveur Rxfcom

qm clone 910 120 --name rfxcom
qm set 120 --ipconfig0 ip=10.1.4.120/23,gw=10.1.4.1

Dans Proxmox, on va aller dans la configuration Hardware de la VM et lui ajouter la clé USB Rxfcom, la clé est bien reconnu par proxmox, pas de soucis de ce coté:

Installation Zwave bouton Add, avr. 2024

Ajout de la clé USB RFXtrx433XL, avr. 2024

On peut démarrer notre VM.
Maintenant on se rend dans l'interface web de Portainer, on lie notre VM, et on ajoute Stack qui ressemble à ça :

version: '3.8'
services:
  rfxcom2mqtt:
    container_name: rfxcom2mqtt
    image: rfxcom2mqtt/rfxcom2mqtt
    restart: unless-stopped
    volumes:
      - data:/app/data
    environment:
      - TZ=Europe/Paris
      - MQTT_SERVER=mqtt://10.1.4.111:1883
      - MQTT_USER=bobby
      - MQTT_PASSWORD=youpin
      - RFXCOM_USB_DEVICE=/dev/ttyUSB0
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
volumes:
  data:

Le stack configure tout ce qu'il faut pour fonctionner, comme le serveur MQTT. Les trames devraient directement atterrir dans MQTT.

Trames Rfxcom dans MQTT Explorer, avr. 2024

Maintenant il va falloir reconnaitre l'identifiant des appareils pour les utiliser dans Nodered…

Voila pour le protocole Rfxcom, dans le prochain billet on ajoutera la VM teleinfo.

Ma domotique VIII : Zigbee

Jean-Christian Denis — Thu, 25 Apr 2024 10:02:00 +0200

Le protocole Zigbee a bien évolué et est en train de devenir prépondérant dans ma domotique.

Le Zigbee est un protocole très répandu ces temps dans le monde de la domotique pour tous, il est sans fil, faible consommation, faible bande passante et utilise le maillage réseau pour étendre sa portée. Par rapport au Zwave, il est moins onéreux, plus simple à configurer et plus simple à appairer. En contrepartie les appareils ne sont pas certifiés, il y a de très bonnes marques comme Schneider Electric et de moins bonnes chinoiseries. Je rappelle qu'on parle de notre maison et qu'en matière d'électricité il ne faut pas faire n'importe quoi, comme piloter un chauffe eau avec un appareil sous dimensionner ou pas aux normes. Pour la petite histoire, j'ai eu un module Zwave qui a explosé, il était dans une poche d'encastrement murale aux normes, le module étant lui aussi aux normes, et bien tout s'est bien passé il n'a pas pris feu et la maison est toujours entière. Ne négligez pas la sécurité de vos appareils, jamais.
La passerelle, communément appelé coordinateur, entre les appareils Zigbee et ma domotique est une clé USB de 3ème génération de la marque SONOFF et j'utilisais précédemment une clé Conbee II. Bien que tout fonctionnait avec la seconde génération, la 3ème me parait plus stable et moins consommatrice. J'ai mis en place des répéteurs qui ont bien participé à la stabilité de l'ensemble, je n'ai pas eu de perte d'éléments depuis leurs mise en place. Coté passerelle informatique, j'utilise un conteneur Docker avec le logiciel Zigbee2mqtt, il est pour l'instant suivi et régulièrement mise à jour car beaucoup de logiciel de domotique passe par lui. Attention, tous les matériels ne sont pas reconnus dans Zigbee2mqtt, une liste plus ou moins à jour est disponible sur le site.

Installation du serveur Zigbee

qm clone 910 114 --name zigbee
qm set 114 --ipconfig0 ip=10.1.4.114/23,gw=10.1.4.1

Dans Proxmox, on va aller dans la configuration Hardware de la VM et lui ajouter la clé USB Zigbee, la clé est bien reconnu par proxmox, pas de soucis de ce coté:

Installation Zwave bouton Add, avr. 2024

Ajout de clé Zigbee à Proxmox, avr. 2024

On peut démarrer notre VM.
Maintenant on se rend dans l'interface web de Portainer, on lie notre VM, et on ajoute Stack qui ressemble à ça :

version: '3.8'
services:
  zigbee:
    container_name: zigbee
    image: koenkk/zigbee2mqtt:latest
    restart: unless-stopped
    volumes:
      - data:/app/data
      - /run/udev:/run/udev:ro
    ports:
      - 80:8080
    environment:
      - TZ=Europe/Paris
    devices:
      - /dev/ttyUSB0
volumes:
  data:

Maintenant on se rend dans l'interface web du serveur Zigbee, dans l'exemple ce sera http://10.1.4.114. Dans l'onglet Paramètres, on va ajouter la clé USB :

Configuration de la clé USB, avr. 2024

Et on va configurer le serveur MQTT :

Configuration du server MQTT, avr. 2024

On redémarre directement depuis l'interface de zigbee2mqtt et on peut vérifier dans MQTT Explorer par exemple que le topic zigbee a bien été créé..

Pour ajouter un appareil, il faut activer l'appairage en haut de la fenêtre et suivre les instructions de la notice de l'appareil. (Tous ne s'incluent pas de la même manière.)

Voila pour le protocole Zigbee, dans le prochain billet on ajoutera la VM RFXCom.

Ma domotique VII : Zwave

Jean-Christian Denis — Sun, 07 Apr 2024 09:44:00 +0200

Aujourd'hui on va parler du protocole Zwave qui était (au passé) un de mes préférés.

Le Zwave est un protocole sans fil, faible consommation, faible bande passante qui utilise le maillage réseau pour étendre sa portée. Financièrement les matériels Zwave sont un peu plus cher que leurs homologues Zigbee. Mais il permet une plus grande configuration du matériel.

Configuration d'un appareil Zigbee, avr. 2024

Configuration appareil Zwave, avr. 2024

Les appareils peuvent être appairés sans passerelle, par exemple directement relié un interrupteur Zwave à une ampoule Zwave., un appareil peut gérer sa propre scène et piloter un autre appareil. Je n'utilise pas du tout cette fonctionnalité, je passe par une passerelle qui est une clé USB branché sur le serveur Promox. Le plus pénible avec le Zwave et qui fait qu'aujourd'hui je le délaisse un peu dans mes choix est qu'il faut que l'appareil soit contre la clé lors de la phase d'appairage, super pas pratique. Le jour ou la clé rend l'âme ça va être sympa d'aller chercher les 80 appareils disséminés dans les murs…
A noter que la technologie Zwave n'est pas libre, tous les appareils Zwave utilisent la même puce de chez Sigma Designs et sont certifiés.

Installation du serveur Zwave

qm clone 910 123 --name zwave
qm set 123 --ipconfig0 ip=10.1.4.123/23,gw=10.1.4.1

Dans Proxmox, on va aller dans la configuration Hardware de la VM et lui ajouter la clé USB Zwave, comme on peut le voir elle n'est pas complètement reconnu, on va l'ajouter par Vendor/ID :

Installation Zwave bouton Add, avr. 2024

Installation Zwave choix clé USB, avr. 2024

On peut démarrer notre VM.
Maintenant on se rend dans l'interface web de Portainer, on lie notre VM, et on ajoute Stack qui ressemble à ça :

version: '3.7'
services:
    zwave-js-ui:
        container_name: zwave-js-ui
        image: zwavejs/zwave-js-ui:latest
        restart: always
        tty: true
        stop_signal: SIGINT
        environment:
            - ZWAVEJS_EXTERNAL_CONFIG=/usr/src/app/store/.config-db
        networks:
            - zwave
        devices:
            - '/dev/ttyACM0'
        volumes:
            - zwave:/usr/src/app/store
        ports:
            - '80:8091'
            - '3000:3000'
networks:
    zwave:
volumes:
    zwave:
        name: zwave

Maintenant on se rend dans l'interface web du serveur Zwave, dans l'exemple ce sera http://10.1.4.123. Dans l'onglet Settings, on va ajouter la clé USB :

Ajout de la clé USB Zwave, avr. 2024

Et on va configurer le serveur MQTT :
(Attention, la configuration dans la capture d'écran ne correspond pas au serveur MQTT de nos tutos.)

Configuration du serveur MQTT, avr. 2024

Pour le réglage de la Gateway (cf capture ci dessus) j'ai choisie ValueID topics et Payload Just value, plus pratique mais incompatible avec Home assistant.
On relance le conteneur Docker et on retourne dans l'interface web Zwave pour voir qu'il a bien trouvé la clé USB et le serveur MQTT.

Pour ajouter un appareil, il faut suivre l'icone Manage nodes depuis l'icone en bas à droite puis sélectionner Inclusion et suivre les instruction de la notice de l'appareil. (Tous ne s'incluent pas de la même manière.)

Inclusion d'un matériel, avr. 2024

Voila pour le protocole Zwave, dans le prochain billet on ajoutera la VM Zigbee.

Ma domotique V : Node-RED

Jean-Christian Denis — Sat, 06 Apr 2024 09:02:00 +0200

J'ai par le passé testé diffèrents logiciels de domotique comme par exemple Jeedom ou Home-Assistant pour ne citer qu'eux et un jour je me suis dit : ce n'est pas compliqué la domotique, c'est marche/arrêt, jour/nuit, on/off, je suis sure de pouvoir le faire.

Et je l'ai fait… et refait !

J'aurai pu choisir n'importe qu'elle langage de programmation pour le faire, mais je suis fainéant et le temps me manque pour apprendre un nouveau langage, du coup je me suis rabattu sur Nore-RED, parfait pour moi, prendre des nœuds et les déplacer dans une fenêtre c'est à mon niveau. Je vous laisse visiter le site officiel pour savoir ce qu'est Node-RED. Parmi les avantages, une large palette de modules complémentaires, d'exemples, une facilité de bricolage, de débogage, la connexion native à MQTT et à bien d'autres outils utiles à ma domotique, etc...
L'écriture de la première version du cœur de ma domotique en Node-RED m'a pris 1 an, la seconde version 4 mois. (Je ne l'ai pas encore terminé mais ça tourne en prod.) donc même si c'est simple, ça prend du temps. Et encore je suis très loin de ce que je voudrais notamment un système d'ajout automatique de matériel, ça sera pour la prochaine version peut-être.

Exemple d'interface d'administration Node-RED, avr. 2024

Fonctionnement de ma domotique

Lorsque dans le suite du billet ou même des prochains articles je parle du cœur (ou kernel) de ma domotique, ça sera le partie centrale du code, le flow sous Node-RED qui gère ma domotique.

Comme rapidement évoqué dans le billets précédents, ma domotique est basée sur la transmission de messages à 4 niveaux. Le message est composé d'un chemin appelé topic ou path dans le cœur de ma domotique et ce topic propage une valeur correspondante. Par exemple, pour l'information d'une lampe en court de traitement dans le coeur, ce sera :

iotnode/douche/lumiere/plafonnier = true

Le premier niveau n'est pas spécialement important (ou que rarement) il correspond à l'outil que génère ce topic, sa source.
Le seconde niveau est la pièce de ma maison dans laquelle se situe l'élément, dans le cœur on l'appel bucket
Le troisième niveau est le type d'élement, dans le coeur on l'appel measurement
Le quatrième niveau est l'élement, dans le coeur on l'appel field

Ce qui donne :

source / bucket / measurement / field = value

A y regarder de plus près, ça ressemble à ce qu'on retrouve dans des outils comme InfluxDB et Grafana, et qu'on appelle des metric, ce n'est pas par hasard car 100% des valeurs générées par ma domotique sont stockées dans une base de données InfluxDB de laquelle j'extrais de jolis graphiques grâce à Grafana. On en reparlera dans de prochains billets

Le cœur de ma domotique va simplement faire une boucle avec ce topic et chaque élément relié au cœur va pouvoir lire ce message est l'utiliser si besoin. Par exemple, lorsque la lampe s'allume un nouveau minuteur va se lancer et tenter de l'éteindre dans xx minutes. Mais là ou cela devient fou c'est que ce même minuteur génère un message qui va être lu par un scenario qui à son tour dira de ne pas l'éteindre mais de prolonger le minuteur car il y a eu un mouvement dans la pièce, etc... Mais du coup, les boucles peuvent s'empiler et devenir difficile à gérer, par exemple pour la gestion du chauffage ou des volets avec de nombreux éléments à prendre en compte comme les ouvertures, la présence, l'heure, la température, la lumière etc... Du coup il faut quand même mettre des garde-fou en place pour éviter des boucles infinies. Finalement une idée simple fini en casse tête. Voila pour le préambule à la gestion de ma domotique, il faut simplement retenir qu'on fait une boucle avec un message.

Un élément (ou metric) à l'entrée du cœur doit également suivre des règles bien précises. Il doit être enregistré dans le cœur avant de pouvoir être utilisé correctement. En effet un lampe peut-être simplement en tout ou rien, mais elle peut également être dimmable (valeur entre 0 et 99 par exemple) il faut donc l'expliquer au cœur. Lorsqu'on enregistre un nouvel élément il doit donc renseigner :

sa pièce : bucket (douche)
son type : measurement (lumiere)
son nom : field (plafonnier)
son type de valeur : format (boolean)
sa valeur par défaut : default (true)

Avec ça le cœur saura comment nettoyer et retransmettre une représentation propre de l'élément. Par exemple si un élément tiers demande d'allumer la lampe avec un ordre true mais que ma lampe est dimmable, le cœur saura transformer cette valeur en 99 et la retransmettre.
Dans la seconde version du cœur de ma domotique j'ai ajouté un début de gestion commune de certains appareils, en effet j'ai par exemple des interrupteurs connectés de même modèle un peu partout, donc au lieu répéter du code dans chaque pièce, j'utilise une base commune, pour cela j'ai ajouté dans l'enregistrement d'un élément la possibilité de renseigner un modèle :

protocol : le protocole utilisé par l'élément (ex: zigbee)
model : le model de l'élément (ex: snbz-02 pour un capteur zigbee)
id : l'identifiant dans le protocole (zwave c'est un nombre, zigbee c'est arbitraire dans zigbee2mqtt, etc)
option : une option entre 1 et 3, utile si un élément à deux fonctions identiques (ex double interrupteur) ou un changement de comportement (capteur d'ouverture sur un interrupteur Qubino)

Avec ça on est quasi paré à toutes éventualités.

On continue de s'éloigner du cœur et on va aller voir comment fonctionne un élément de ma domotique dans Node-RED.
On vient de voir la première fonction de l'élement qui est d'enregistrer dans le cœur sa définition.
La seconde fonction est de transmettre les informations du matériel vers le cœur. Pour cela j'ai simplifié la tache en ajoutant des portes de/vers chaque protocole de ma domotique dans Node-RED. En effet tous mes protocoles domotiques atterrissent dans MQTT il est donc simple de les lire dans Node-RED. Si je reprend l'exemple de ma lampe, son élément va se relier à l'entrée Zwave du cœur et lire les informations dont elle a besoin dans son topic dédié, comme l'état de la lampe dans /zwave/10/37/0/currenValue qu'il va retransmettre au cœur dans /device/douche/lumiere/plafonnier = true.
La troisième fonction, vous l'aurez sans doute devinez, est transmettre les ordres du cœur vers le matériel. Ici on fait le travail inverse de la seconde fonction, on écoute le cœur pour attraper l'ordre d'allumer la lumière qui sera le message /ionode/douche/lumiere/plafonnier = true et on le transmet à la sortie Zwave du cœur dans le message /zwave/10/37/0/targetValue/set = true. La théorie est très simple.
J'ai ajouté une quatrième fonction qui permet d'afficher dans une interface web ces informations. Pour ma lampe un bouton pour l'allumer ou l'éteindre. Node-RED a une extension dashboard qui est une interface web, encore une fois le travail est ici facilité. A noter que je n'ai pas poussé la mise en page de cette interface car pour moi la domotique doit fonctionner toute seule et être transparente au quotidien et de plus je n'ai pas assez de temps pour jouer avec cette partie design.

Exemple de dashboard Node-RED, avr. 2024

Voila avec tout ça, un élément représentant un matériel physique (ou une partie de matériel) est géré dans le cœur de ma domotique.

Maintenant commence le vrai rôle de la domotique, animer tout ça. Pour cela j'utilise des nœuds de scénario, que ce soit l'ouverture des volets, la gestion du chauffage, l'éclairage des escaliers, ou le rappel pour sortir les poubelles, le principe reste le même. Un scénario écoute les messages transmis en boucle par le cœur et va attraper ceux qui l'intéressent. Par exemple pour le volet du salon, je vais écouter les messages de mode Jour/Nuit, ceux des ouvertures de la baie vitrée, ceux de mouvement et même ceux du capteur de luminosité, ben oui si le soleil tape trop fort j'ajoure le volet ! Je ferais des billets plus précis plus tard avec des exemples concrets et complets, ici je présente juste le principe.

Ce fût long et pourtant je n'ai quasi rien montré de concret du code. Je vais m'arrêter là pour ces premières explications, mais il y a bien d'autres choses dans ce cœur. Il y a les agendas, les assistants vocaux, les graphiques, un peu de configuration, etc. On verra si j'arrive à avancer dans mes billets de présentation pour pousser plus loin les explications…

Installation du server Node-RED

qm clone 910 122 --name nodered
qm set 122 --ipconfig0 ip=10.1.4.122/23,gw=10.1.4.1

On peut démarrer notre VM.
Maintenant on se rend dans l'interface web de Portainer, on lie notre VM, et on ajoute Stack qui ressemble à ça :

version: "3.8"
services:
  nodered:
    container_name: nodered
    image: nodered/node-red:latest
    restart: always
    environment:
      - TZ=Europe/Paris
    ports:
      - "80:1880"
      - "3456:3456"
    networks:
      - net
    volumes:
      - data:/data
networks:
  net:
volumes:
  data:

On va modifier le mot de passe de Node-RED , comme pour MQTT cela se fait dans le Docker. Pour cela on va dans la console Proxmox de la VM, et on ouvre une session docker :

docker exec -it nodered /bin/bash

On demande de hacher notre mot de passe avec :

node-red admin hash-pw le_mot_de_passe

On obtient en retour notre mot de passe crypté qu'il va falloir mettre dans le ficher de configuration de Node-Red. On retourne dans la console Proxmox (ou en SSH) de la VM et on va modifier la configuration de node-RED :

sudo nano /var/lib/docker/volumes/nodered_data/_data/settings.js

le fichier doit ressembler à ça :

module.exports = {
    flowFile: 'flows.json',
    credentialSecret: false,
    flowFilePretty: true,
    adminAuth: {
        type: "credentials",
        users: [{
            username: "bob",
            password: "le_mot_de_passe_crypté",
            permissions: "*"
        }]
    },
    httpAdminRoot: '/admin',
    httpNodeRoot: '/',
    diagnostics: {
        enabled: true,
        ui: true,
    },
    runtimeState: {
        enabled: false,
        ui: false,
    },
    logging: {
        console: {
            level: "info",
            metrics: false,
            audit: false
        }
    },
    contextStorage: {
        default: {
            module: "localfilesystem"
        },
        memoryOnly: {
            module: "memory"
        },
    },
    exportGlobalContextKeys: false,
    externalModules: {
    },
    editorTheme: {
        palette: {
        },
        projects: {
            enabled: false,
            workflow: {
                mode: "manual"
            }
        },
        codeEditor: {
            lib: "monaco",
            options: {
            }
        },
        markdownEditor: {
            mermaid: {
                enabled: true
            }
        },
    },
    functionExternalModules: true,
    functionTimeout: 0,
    functionGlobalContext: {
    },
    ui: { path: "" },
    debugMaxLength: 1000,
    mqttReconnectTime: 15000,
    serialReconnectTime: 15000,
}

Par rapport au fichier d'origine, on a ajouté le login, modifié les URI qui finiront par /admin pour la partie administration (la fenêtre de développement de Node-RED) et à la racine pour l'interface web. On indique également d'utiliser deux sortes de mémoire : une vive et une en fichier. (Qui va permettre de garder certaines valeurs lors d'un redémarrage, ou coupure de courant.)
On relance le conteneur et notre instance Node-Red est accessible sur http://10.1.4.122/admin.

Dans le prochain billet, on va faire une petite pause et parler plus généralement de la domotique et de ce qu'on peut en tirer.

Ma domotique IV : MQTT

Jean-Christian Denis — Wed, 03 Apr 2024 21:24:00 +0200

Le protocole MQTT est un des piliers de ma domotique, toutes les informations relatives la gestion de ma maison passent par lui.

MQTT signifie Message Queuing Telemetry Transport, c'est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP. Ses avantages sont sa rapidité, sa légèreté, la possibilité de gérer de multiple sessions, ou encore de retenir ou non les messages. Bref il est parfait pour la domotique.
Chacun de mes protocoles domotique va publier ses messages vers un topic dédié du serveur MQTT central :

Zigbee avec zigbee2mqtt vers le topic /zigbee
Zwave avec zwave-js-ui vers le topic /zwave
RfxCOM avec rfxcom2mqtt vers le topic /rfxcom2mqtt
TiC avec teleinfo2mqtt vers le topic /telefinfo
Bluetooth avec theengsgateway vers le topic /ble
Monitoring avec des scripts perso vers le topic /monitoring
Noyau domotique Node-RED vers le topic /iotnode
Assistant vocal local avec Rhasspy vers les topic /hermes et /rhasspy

Et oui MQTT transporte même les échantillons audio !
Chacun de ces protocoles domotiques est géré par un conteneur docker sur un VM dédié, cela permet de bien cloisonner les choses et de mettre en place, sauvegarder ou modifier uniquement la partie souhaiter sans casser le reste. Avec le temps je me suis rendu compte que de multiplier les VM ne surchargeait pas plus que ça le serveur Proxmox, couplé à des templates de VM, la mise en œuvre est ultra rapide.
Un logiciel tel MQTT Explorer va permettre de facilement voir tout ce qu'il s'y passe.

Exemple de topic dans le logiciel MQTT Explorer, mars 2024

Le noyau domotique (que j'ai nommé iotnode) va écouter tous ces topics et en récupérer les informations utiles, les traiter et les republier en version propre sur le topic MQTT /ionode, j'ai ainsi une vue simple de l'état de ma domotique. Le noyau va également se charger de publier les ordres vers chacun de ces protocoles.
Par exemple, le noyau va publier la valeur true vers le topic /zwave/10/37/0/targetValue/set pour allumer une lampe. Et il va écouter le topic /zwave/10/37/0/currentValue pour savoir si la lampe est allumée. Il va également reporter cette information dans le topic /iotnode/douche/lumiere/plafonnier ce qui est plus lisible pour le commun des mortels :)

Exemple de valeur dans le logiciel MQTT Explorer, mars 2024

Installation du serveur MQTT

Dans le précédent billet sur la virtualisation, on a vu comment j'utilise mes machines virtuelles ainsi que l'installation du gestionnaire de Docker nommé Portainer. On va ici cloner un template de VM et utiliser Portainer pour installer notre Docker contenant le serveur MQTT.

On se rend dans le shell de notre serveur Proxmox et on créer notre machine virtuelle à partir du template docker et on lui adresse une IP fixe :

qm clone 910 121 --name mqtt
qm set 121 --ipconfig0 ip=10.1.4.121/23,gw=10.1.4.1

On peut démarrer notre VM.
Maintenant on se rend dans l'interface web de Portainer (cf billet précédent). Dans le menu de gauche Environements ou clique en haut à droite sur Add environement,.

Portainer, menu ajout d'environnement, avr. 2024

On choisie le type Docker Standalone puis Start wizard.

Portainer, sélection nouvel environnement, avr. 2024

Et on indique un nom et l'adresse de liaison qui sera l'IP de la VM sur le port 9001 et on clique sur Connect. Rien besoin de faire sur la VM puisque notre template est déjà prêt.

Portainer, configuration agent, avr. 2024

Notre VM Docker est désormais liée à Portainer d'où on gèrera le conteneur.
Maintenant on va créer notre conteneur MQTT toujours depuis Portainer. Pour cela on se rend dans le menu Stacks de notre environnement fraichement créé, et on clique sur Add stack, on lui donne un nom et on va remplir la fenêtre d'édition avec la configuration nécessaire à notre Docker MQTT :

Portainer, ajout de stack, avr. 2024

Le configuration sera celle ci-dessous. Puis on clique sur Update the stack. Notre serveur est en fonction.

version: "3.8"
services:
  mosquitto:
    image: eclipse-mosquitto:latest
    container_name: mqtt
    restart: always
    volumes:
      - config:/mosquitto/config
      - data:/mosquitto/data
      - log:/mosquitto/log
    ports:
      - 1883:1883
      - 8883:9001
volumes:
  config:
  data:
  log:

Quelques explications, on lui donne l'image docker du serveur mqtt qu'on désire eclipse-mosquitto:latest, le conteneur se nommera mqtt, il redémarrera dans tous les cas, et il écoutera sur les ports 1883 et 8883 (le port 9001 étant déjà utilisé par l'agent Portainer), ensuite on lui indique les différents volumes à utiliser, ici config, data et log. Ces volumes seront accessible dans la VM dans /var/lib/docker/volumes/mqtt_config/_data/xxx. A noter qu'on va faire en sorte à chaque création de configuration que ce chemin d'accès soit identique pour toutes les VMs cela évite de chercher on se trouve les fichiers de config d'une installation à une autre. ET cela peut-être utile pour des sauvegardes, mais personnellement je sauvegarde la VM entière.
On va aller modifier le fichier de configuration du serveur MQTT pour coller au besoin de notre domotique. Pour cela on se rend dans la console Proxmox de notre VM (ou par ssh) et on édite le fichier de configuration :

sudo nano /var/lib/docker/volumes/mqtt_config/_data/mosquitto.conf

Il doit contenir cela :

listener 1883
listener 9001
protocol websockets
persistence true
persistence_location /mosquitto/data
allow_anonymous false
password_file mosquitto/config/mqtt_passwd

Pour faire simple, on écoute sur les port 1883 et 9001, ici on est dans le conteneur donc le port d'écoute est bien le 9001 à l'intèrieur de conteneur alors qu'à l'extèrieur on écoute le port 8883. On autorise les websockets. on interdit les connexions anonymes et on utilise un fichier pour les mots de passe de connexions. Ce fichier de mot de passe est encrypté par le serveur MQTT il faut donc passer par lui pour le créer, pour cela toujours depuis notre console VM, on lance une session docker :

docker exec -it mqtt sh

Pour ajouter un login/mot de passe, on exécute la commande :

mosquitto_passwd mosquitto/config/mqtt_passwd un_login

Il va nous demander un mot de passe pour ce login. Ensuite on sort de la session en tapant exit.
Pour prendre en compte ces changement on relance le conteneur MQTT depuis Portainer depuis le menu de notre environement Containers -> mqtt -> Restart.
Voila notre serveur MQTT domotique prêt. Et vous incollable sur Portainer.
Ne pas hésiter à se promener dans les menus de Portainer et voir tout ce qu'il est possible de faire comme mettre à jour le stack, une image ou modifier un conteneur.

Dans le prochaine billet on va voir l'installation et le début de programmation du cœur de ma domotique sous Node-RED.

Ma domotique III : Virtualisation

Jean-Christian Denis — Tue, 02 Apr 2024 21:57:00 +0200

Au début de ma domotique j'étais réfractaire à tout ce qui était virtuel, installant une distribution sur une machine pour chaque besoin, mais ça c'était avant !

Lorsque j'ai commencé la domotique, j'utilisais des Raspberry Pi (W, 2 ou 3), j'installais la distribution Linux qui allait avec et je me tapais des lignes et des lignes de commande pour tenter d'installer le moindre truc et je recommençais du début à chaque plantage. J'étais borné, ne voulant pas entendre parler de machine virtuelle ou de conteneur, croyant que tout serait plus solide si j'installais tout moi même sur une base solide. Bon, ben j'avais tord, quelques années plus tard je ne jure que par des VM et des conteneurs. Bigre.

La virtualisation a pleins d'avantages, facile de sauvegarder, supprimer, restaurer, modifier. Aujourd'hui un petit bout de config, 2 clics et une ligne de commande suffisent à lancer tout ce qu'il faut pour gérer un protocole. Alors dans l'absolue il a fallu préparer en amont des templates et avoir un gestionnaire de container fonctionnel, mais j'ai pris le temps et aujourd'hui je gagne du temps.

Mes choix se sont portés sur la distribution de gestion de VM nommé Proxmox VE dans sa version public, la construction de template de VM à base de Debian, le système de container Docker et le gestionnaire Portainer. J'empile même les deux en mettant un Docker dans un VM. Simple et efficace pour compartimenter les protocoles domotique et pour sauvegarder tout ça. Ces deux gestionnaires ont une interface web plutôt bien réussi ce qui facilite encore plus leurs utilisations.

Exemple d'interface web de la distribution Proxmox VE, mars 2024

Exemple d'interface web du gestionnaire Portainer, mars 2024

Aujourd'hui pour faire tourner ma domotique j'ai 12 machines virtuelles embarquant chacune un ou plusieurs Docker, et avec tout ça le processeur de mon serveur n'atteint même pas les 1% d'utilisation. (bon il a 28 cœurs mais quand même) C'est juste hallucinant. L'accumulation de tous ces avantages fait que je ne reviendrais jamais en arrière et que je ne peux que vous conseiller de prendre ce chemin dès le départ.

Avant de commencer les screenshots et les lignes de commande pour préparer tout ça, je vais faire un mini rappel sur certains termes utiliser précédemment :

Proxmox : Gestionnaire de machines virtuelles (VM)
Debian : Distribution Linux, composée presque exclusivement de logiciels libres
Docker : Outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé
Portainer : Gestionnaire de conteneur Docker

Vous êtes prêt pour un bon gros pavé ? C'est partie, avec à la fin de ce billet un premier exemple d'utilisation en 3 lignes de commande.

Installation de Proxmox

Proxmox est fait pour travailler en cluster, c'est à dire que vous avez plusieurs machines physiques sur lesquels chaque machine virtuelle est dupliquée. On ne va pas utiliser cette fonctionnalité car on n'en a pas besoin et surtout nous avons besoin des ports USB pour les clefs Zigbee, Zwave et autres, ce qui rend la duplication impossible.
Il existe des centaines du tuto se ressemblant les uns les autres expliquant l'installation de Proxmox. Je vais quand même m'y coller juste pour le plaisir de faire les captures d'écran depuis l'installation de Proxmox sur un VM Proxmox !
Il faut commencer par télécharger l'ISO de Proxmox VE sur le site de Proxmox et la graver sur une clef USB, pour cela j'utilise le logiciel BalenaEtcher. Ensuite insérer la clef USB dans un port du serveur et démarrer le serveur. La procédure d'installation commence.

Promox VE install 01, avr. 2024

On accepte les termes et on choisie le disque. La seule difficulté que j'avais lors de l'installation et d'avoir choisi un raid matériel depuis le bios de ma carte mère et ensuite le faire reconnaitre lors de l'installation de Proxmox. Il a fallu que je choisisse dans les options le Raid 1 zfs en sélectionnant mes deux disques. Rien de bien méchant.

Promox VE install 02, avr. 2024

On choisi la zone horaire.

Promox VE install 03, avr. 2024

On indique le mot de passe root et un email.

Promox VE install 04, avr. 2024

On sélectionne l'interface réseau, le nom de la machine et les IPs. Sur les captures je suis dans un VM de mon réseau de test donc à adapter selon votre configuration.

Promox VE install 05, avr. 2024

On vérifie les informations et on procède à l'installation.

Promox VE install 06, avr. 2024

Une fois l'installation terminé, le serveur reboot. On en a fini avec le serveur. On peut se connecter à l'interface web depuis notre PC. L'IP du serveur est celle vu pendant l'installation auquel il faut ajouté le port 8006. Une alerte nous informe que la connexion n'est pas sécurise, pas grave la machine n'est pas accessible hors de la maison. On entre nos identifiant root et voila.

Promox VE install 07, avr. 2024

Une alerte indique que nous avons pas de licence valide, normal on utilise la version libre. On va tout de suite modifier les sources pour les mises à jour pour ajouter le dépôt No-Subscription et enlever le dépôt Entreprise. Ces réglages sont dans Datacentre -> notre machine -> Updates -> Repositories -> Add.

Promox VE install 08, avr. 2024

Promox VE install 09, avr. 2024

Une fois les dépôts configurer, on remonte dans Updates on clique sur Refresh puis sur Upgrade. Notre machine est à jour. Si le noyau est modifié il faudra surement redémarrer le serveur.

Promox VE install 10, avr. 2024

Voila pour la partie serveur. Il faudra ajouter la gestion des backups. Je ferais peut-être un billet sur l'utilisation de Proxmox Backup Server tel que je l'utilise. C'est bien pratique.

Création du template Debian

Pour ma domotique, j'utilise un template de VM qui me permet de créer des VM en 2 minutes, la base est toujours la même, seuls l'IP et le conteneur Docker changent. Je vais faire dans un premier temps un template uniquement de la distribution puis je le dupliquerais pour faire un second template avec ce qu'il faut pour Docker.
Dans l'interface web de Proxmox, On va dans Datacentre -> notre machine, on clic droit dessus pour ouvrir son menu et on fait Create VM.

PVE Template, bouton de création VM, avr. 2024

On paramètre maintenant notre machine virtuelle. Dans l'onglet General, on change le VM ID, on va en mettre un assez élevé pour ne pas le mélanger aux autres, je prend 900 pour ce template et on va la nommé, ici ce sera template-debian.

PVE Template, Onglet général, avr. 2024

Ensuite dans l'onglet OS, on lui indique de ne pas utiliser de média (on va le faire de manière spéciale un peu plus tard), le reste ne change pas.

PVE Template, Onglet OS, avr. 2024

Ensuite dans l'onglet System, on garde tout par défaut, on va juste cocher la case Qemu Agent.

PVE Template, Onglet System, avr. 2024

Ensuite dans l'onglet Disks, on va supprimer le disque par défaut. (on va l'ajouter de manière spéciale un peu plus tard)

PVE Template, Onglet Disks, avr. 2024

On ne touche pas aux onglet CPU et Memory, on pourra les modifier lors de la création de nos VM. Dans l'onglet Network on choisie le Brigde réseau à utiliser et on décoche la case Firewall.

PVE Template, Onglet Network, avr. 2024

On vérifie que tout est bon et on clic sur Finish.

PVE Template, Onglet Confirm, avr. 2024

On passe à la seconde phase de la création du template, il va falloir lui ajouter un disque Cloud-init. Pour cela on se rend dans Datacentre -> notre machine -> norte VM (900) -> Hardware, on déroule le menu Add et on sélectionne CloudInit Drive, on utilise le Bus IDE 0 et le Storage local-lvm.

PVE Template, menu Add hardware, avr. 2024

Toujours sur notre VM 900 on se rend dans la partie Cloud-init et on va modifier le User et son Password. Ces identifiant serviront à se connecter à la machine en SSH par exemple, cette utilisateur aura les droits sudo.

PVE Template, paramètres Cloud-init, avr. 2024

Dans cette partie on va également configurer le réseau pour utiliser DHCP, même si on le verra par la suite on va assigner une IP à chaque machine virtuelle avant de la démarrer.

PVE Template, config DHCP, avr. 2024

Maintenant on va ajouter le disque. On utilise le shell de norte interface web Proxmox mais on pourrait utiliser un client SSH.

PVE Template, node shell, avr. 2024

Et on va enchainer quelques commandes :

Tout d'abord on télécharge l'image de l'OS Debian pour KVM
On redimensionne l'image (je mets 16G par defaut, on pourra ensuite changer pour chaque machine)
On autorise la console (le 900 est le numero de notre template)
On importe le disque dans la VM template
On scanne les volumes pour les prendre en compte

Ce qui donne dans le shell :

wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2
qemu-img resize debian-12-generic-amd64.qcow2 16G
qm set 900 --serial0 socket --vga serial0
qm importdisk 900 debian-12-generic-amd64.qcow2 local-lvm
qm rescan

On retourne dans la partie dédiée à notre template, dans Hardware il faut ajouter le disque qu'on vient de créer en cliquant dessus puis Add.

PVE Template, Add unused disk, avr. 2024

Le disque apparait maintenant normalement. Hard Disk (scsi0).

PVE Template, hardware with disk, avr. 2024

On se déplace dans le menu Options et on va modifier l'ordre de boot en passant le disque scsi0 en second et en cocher sa case Enabled.

PVE Template, Boot order, avr. 2024

Tout est prêt pour un premier démarrage du template, on se rend dans la console de la VM 900 et on démarre la machine. Ca mouline un moment puis plus rien, il suffit de taper entrer et l'invite de commande apparait.

PVE Template, console, avr. 2024

Le login et le mot de passe sont ceux indiqués dans la configuration de Cloud-init. On va :

Mettre à jour l'OS
Installer Qemu
L'ajouter au boot

Ce qui donne dans la console :

sudo apt update && sudo apt upgrade -y
sudo apt install qemu-guest-agent
sudo systemctl enable qemu-guest-agent

Sur les dernières versions de Debian, le service SSH n'est pas activé, je l'utilise, donc je vais l'activer de suite :

sudo systemctl enable ssh
sudo systemctl start ssh

Maintenant on va faire un reset de l'ID du template et nettoyer les informations d'initialisation.
A chaque démarrage de la VM de template pour y apporter des modifications, il sera obligatoire de refaire ces lignes de commandes !

sudo su -
cat /dev/null > /etc/900
cat /dev/null > /var/lib/dbus/900
cloud-init clean

Il ne reste plus qu'à arrêter notre template avec un joli :

shutdown -h now

Voila la VM de template Debian est prête à être cloné.

Création du template contenant Docker

Pour la création du second template Docker contenant les outils pour Portainer on va cloner le template Debian qu'on vient de créer et lui apporter les modifications nécessaires.

Pour cela on clic droit sur le template Debian pour afficher le menu et on choisi Clone.

PVE Template, Docker clone, avr. 2024

On choisi un numéro ID de Vm, comme précédement on en prend un élevé ici 910 puis on lui donne un nom, ici template-docker. On valide. Le clonage prend un peu de temps puis on lance la console de notre nouvelle VM, l'utilisateur et le mot de passe sont ceux donner dans le template Debian.

PVE Template, Docker console, avr. 2024

On va ensuite enchainer les commandes pour ajouter Docker :

Ajout du répertoire de clés pgp
Ajout du logiciel pgp
Téléchargement de la clé
Ajout de la clé
Mise à jour des dépôts
Installation de Docker et de tout ce qu'on aura besoin pour nos VM
Ajout des droits de l'utilisateur sur Docker
On se délogue pour prendre en compte les droits

Ce qui donne dans la console :

sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
exit

On se relogue sur la console et on ajoute l'agent Portainer qui nous servira sur les futurs VM :

docker run -d -p 9001:9001 --name portainer_agent --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes portainer/agent:2.19.4

Comme on a modifié le template il faut à nouveau le nettoyer :

sudo su -
cat /dev/null > /etc/900
cat /dev/null > /var/lib/dbus/900
cloud-init clean
shutdown -h now

Et voila notre seconde template dédié à docker prêt.

Création de la machine virtuelle Portainer

Ca va aller vite grâce à nos templates !

On va cloner le Template Docker et ensuite lui assigner une IP fixe dans notre réseau. Pour ma part quand c'est possible, l'ID de ma VM sera également l'IP de la machine virtuelle. Pour cela on se rend dans le shell de notre serveur Proxmox (ou en SSH) et on enchaine les deux commandes suivantes :

qm clone 910 120 --name portainer
qm set 120 --ipconfig0 ip=10.1.4.120/23,gw=10.1.4.1

Je clone mon template d'ID 910 vers le VM d'ID 120 que je nomme portainer
J'assigne à la VM 120 l'IP 10.1.4.120 dans mon réseau

Je ne touche ni à la taille du disque, ni à la taille de la mémoire, ni au nombre de processeur de ma futur VM, les valeurs par défaut du template iront très bien. Maintenant on démarre la VM et on se connecte à la console (ou en SSH vers l'IP qu'on vient d'assigner) le login et le mot de passe sont ceux indiqués lors de la création du tout premier template.
Et on exécute un docker de Portainer :

docker run -d -p 80:8000 -p 443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Et voila, le gestionnaire de Docker de notre domotique est fonctionnel et est accessible par interface web à l'adresse http://10.4.1.120. (sur le port 80)

Magique.

Dans le prochain billet je présente la VM MQTT qui est le centre d'échange d'informations de ma domotique et l'utilisation de Portainer pour ce premier cas.

Upcrack

Jean-Christian Denis — Tue, 24 Oct 2023 20:00:00 +0200

Comme chaque année avant le début de l'hiver, enfin de ce qui devrait l'être, je fais un petit tour de mon installation domotique.

L'eau - Le ciel - 09/2023

Ma domotique gérant le chauffage de la maison, les premiers froids me poussent chaque année à faire une vérification de l'ensemble de l'installation, histoire que madame ne me mette pas à l'amende en cas de panne impromptue. Comme chaque année cela se traduit par un changement de pile des capteurs en limite, une mise à jour des machines virtuelles et un contrôle visuel des chauffages et capteur de portes. Jusque là tout semble se dérouler parfaitement, je suis toujours agréablement surpris que mon installation et programmation perso de tout ça ronronne aussi bien. (Proxmox, Nodered, MQTT, c'est tellement génial.)
Du coup j'ai voulu enchainer sur la mise à jour de mon PC Windows qui en réalité est une VM distante dont je me sers partout. Paf, le drame, mise à jour planté, même après 10 tentatives, même après nombre de lectures et tuto sur cette erreur connue. Il m'a fallu la moitié de l'après-midi pour trouver la parade, et donc pour une simple mise à jour, il a fallu que je change de processeur virtuel, que j'augment la taille du disque virtuel et que j'écrase la version courante par une installation... (Qui heureusement a gardé mes programmes fonctionnels.)

Rendez-vous l'année prochaine pour une mise à jour.

En boucle

Jean-Christian Denis — Mon, 16 Jan 2023 22:47:00 +0100

Bon, ça y est, je crois que je viens de me calmer sur le bricolage de mon réseau maison. Après un excès de folie vendredi soir à vouloir passer tous mes liens de 10Gb vers 2x10Gbs entre routeur, LAN, VM, NAS, etc... J'ai mis 3 jours à revenir en arrière. Ouais, ça calme. Surtout pour un exercice de style qui ne sert absolument à rien à part épater la galerie. Même pas. Aux vues de mes stats IPv6, je n'ai pas manqué à grand monde !
Bref, c'est bon je vais pouvoir retourner à mon bricolage de Dotclear.

Haproxy

Jean-Christian Denis — Thu, 28 Jul 2022 20:40:00 +0100

L'ami Franckpaul m'avait donné l'envie d'utiliser un proxy pour rendre accessible mes serveurs locaux depuis les internets. Comme d'habitude je suis partie de son exemple pour le transformer en usine à gaz.

Je vais essayer de poser les bases de manière simple, ce n'est pas gagné !
Tout d'abord petit rappel de ce qu'est haproxy: C'est un logiciel open source qui gère le load balancing et le reverse proxy. Pour ma part je n'utilise que la partie reverse proxy. Depuis une seule adresse IP je vais redistribuer des noms de domaines vers mes serveurs internes. Enfin, deux adresses IP, une IPv4 et une IPv6.
J'ai au préalable configurer chez mon hébergeur (qui n'héberge plus rien) plusieurs noms de domaine ou sous-domaine, soit en DynHost pour les Ipv4, soit en champs AAAA pour les IPv6, avec en plus un champs CAA pour Let's Encrypt:

chez IN CAA 128 issue "letsencrypt.org"
chez IN AAAA xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Ensuite mon routeur-firewall redirige les ports 80 et 443 vers mon serveur haproxy. En réalité c'est un peu plus compliqué que cela, aillant viré la Livebox au profit d'une VM sous Mikrotik Cloud Hosted Router qui sert de passerelle à la fois vers quelques VM et vers mon routeur domotique qui fait lui aussi passerelle vers quelques VM ! Bref, je m'y retrouve c'est l'important. Je parle de ça car par exemple pour la VM OpenVpn les port 80 et 443 passe par la VM haproxy mais les ports 993 et 1194 passe par le routeur domotique. Pour faire simple tout ce qui est port 80 et 443 est dirigé vers haproxy, peut-importe le nom de domaine devant.

;;; exemple simpliste en Nat qui permet de tester rapidement

;;; vers haproxy en http
/ip firewall nat chain=dstnat action=dst-nat to-addresses=10.1.5.111 to-ports=80 protocol=tcp in-interface=WAN dst-port=80 log=no log-prefix=""
;;; vers haproxy en https
/ip firewall nat chain=dstnat action=dst-nat to-addresses=10.1.5.111 to-ports=443 protocol=tcp in-interface=WAN dst-port=443 log=no log-prefix=""
;;; vers openvpn
/ip firewall nat chain=dstnat action=dst-nat to-addresses=10.1.10.111 to-ports=1194 protocol=udp in-interface=WAN dst-port=1194 log=no log-prefix=""

Ensuite haproxy gère donc la distribution des sites web en fonction du nom de domaine appelé. Il gère aussi tout les certificats SSL de ces machines, c'est très pratique et ça simplifie la création de Virtual Host ensuite. J'ai dit tous les certificat SSL ? Non. Tous sauf un, celui de OpenVpn qui est géré par la VM OpenVpn elle même car elle l'enregistre en dur dans sa base de donnée… C'est là que tout se complique dans la configuration de haproxy: Savoir gérer les certificats SSL de certains sites mais d'en laisser d'autres être gérés par leurs VM.
Pour les certificats utilisés par haproxy je suis passé par Cerbot, Let's Encrypt et un petit script Bash de renouvellement et compactage.
Je ne vais pas expliquer comment installer une VM, haproxy, configurer un nom de domaine, etc, ce n'est pas le sujet ici qui est uniquement de me faire un mémo sur le fichier de configuration /etc/haproxy/haproxy.cfg. Let's go !

# Configuration valable pour haproxy 2.2.x

# Section global
global
        # Configuration des logs, de l'utilisateur system, des statistiques.
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket :9999 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Configuration des niveaux de certificats acceptés pour SSL.
        # Ces niveaux sont ceux de la certification A+ à juillet 2022.
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA>
        ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
        ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-R>
        ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

# Section defaults
defaults
        # Par default on travail en layer 7 (http)
        mode    http
        option  httplog
        log     global
        option  dontlognull

        # Par default on transmet l'IP cliente
        option forwardfor

        # On configure divers options de timeout et d'erreurs
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

# Section stats
# On peut complètement enlevé les stats ce n'est pas nécessaire au fonctionnement du proxy.
# On écoute sur http://mon_ip:22222/haproxy?stats
listen stats
        mode http
        bind :22222
        stats enable
        stats uri            /haproxy?stats
        stats realm          Haproxy\ Statistics
        stats auth           un_utilisatuer:un_mot_de_passe
        stats refresh        30s

# Frontend HTTP
frontend frontend_http
        # On écoute sur le port 80 en IPv4 et IPv6
        bind :::80 v4v6

        # On regarde si c'est une vérification pour un renouvèlement de certificat dédié à OpenVpn
        acl acl_domain_openvpn hdr_end(host) -i openvpn.mondomaine.fr

        # On regarde si c'est une vérification pour un renouvèlement de certificat haproxy
        acl acl_letsencrypt_ha path_beg /.well-known/acme-challenge/

        # On utilise le backend spécial OpenVpn
        use_backend backend_openvpn_http if acl_domain_openvpn

        # On utilise le backend spécial Let's Encrypt
        use_backend backend_letsencrypt_ha if acl_letsencrypt_ha !acl_domain_openvpn

        # On redirige tout les reste vers HTTPS
        redirect scheme https code 301 if !acl_letsencrypt_ha !acl_domain_openvpn

# Frontend HTTPS
frontend frontend_https_all
        # On écoute sur le port 443 en IPv4 et IPv6
        bind    :::443 v4v6

        # On travail en layer 4 (tcp) pour outrepasser les certificats non géré par haproxy
        mode    tcp
        tcp-request     inspect-delay 5s
        tcp-request     content accept if { req_ssl_hello_type 1 }

        # On utilise un bakcend pour OpenVpn
        use_backend     backend_proxy_https_openvpn if { req_ssl_sni -i openvpn.mondomaine.fr }

        # Sinon on utilise un backend pour haproxy
        default_backend backend_proxy_https_ha

# Backend proxy pour OpenVpn en HTTPS
backend backend_proxy_https_openvpn
        mode    tcp

        # On utilise haproxy lui-même comme serveur
        server  loopback-for-tls abns@haproxy_openvpn send-proxy-v2

# Backend proxy pour tout le reste en HTTPS
backend backend_proxy_https_ha
        mode    tcp

        # On utilise haproxy lui-même comme serveur
        server  loopback-for-tls abns@haproxy_ha send-proxy-v2

# Frontend proxy OpenVpn en HTTPS
frontend frontend_https_openvpn
        # On dit a haproxy que ça vient de lui-même
        bind    abns@haproxy_openvpn accept-proxy
        mode    tcp
        option  tcplog
        log     global
        tcp-request inspect-delay 5s
        tcp-request content accept if { req.ssl_hello_type 1 }

        # On redirige vers le backend OpenVpn sans vérifier de certificat
        use_backend backend_openvpn_https if { req.ssl_sni -i openvpn.mondomaine.fr }

frontend frontend_https_others
	# On écoute en provenence du proxy et on utilise les certificat haproxy
        bind    abns@haproxy_ha accept-proxy ssl crt /etc/haproxy/certs/ alpn h2,http/1.1

        # On nettoie et ajoute quelques entête à signaler à nos serveurs web
        http-request del-header X-Forwarded-For
        http-request add-header X-Forwarded-Proto https
        http-response set-header Strict-Transport-Security "max-age=16000000; includeSubDomains; preload;"

        # Petite astuce pour CalDav de nextcloud
        acl     acl_nextcloud_url_discovery path /.well-known/caldav /.well-known/carddav
        http-request redirect location /remote.php/dav/ code 301 if acl_nextcloud_url_discovery

        # On distribue nos noms de domaines
        use_backend backend_openvpn_https	if { hdr_end(host) -i openvpn.mondomaine.fr }
        use_backend backend_a_mondomaine_fr	if { hdr_end(host) -i a.mondomaine.fr }
        use_backend backend_b_mondomaine_fr	if { hdr_end(host) -i b.mondomaine.fr }
        use_backend backend_mondomaine_com	if { hdr_end(host) -i z.mondomaine.com }
        use_backend backend_multidom		if { hdr_reg(host) ^xyz.tld|a.xyz.tld|c.mondomaine.fr$ }

        default_backend backend_mondomain_com

# Backends
# Pour les domaines certifiés par haproxy on utilise que le port 80

# server a
backend backend_a_mondomaine_fr
    description Blablabla a.domaine.fr
    server server_a_domaine_fr 10.1.5.120:80 check

# server b
backend backend_b_mondomaine_fr
    description Blablabla b.domaine.fr
    server server_b_domaine_fr 10.1.5.121:80 check

# server c
backend backend_mondomaine_com
    description Blablabla domaine principal
    server server_b_domaine_fr 10.1.5.122:80 check

# server d
backend backend_multidom
    description Multi domaines
    server server_multidom 10.1.5.123:80 check

# Cas particuliers

# renouvelement letsencrypt certbot
backend backend_letsencrypt
        description Cerbot renew
	# On utilise le server certbot qu'on a crée sur le même serveur que haproxy
        server server_letsencrypt 127.0.0.1:8888

# renouvelement letsencrypt openvpn sur sa machine dédié
backend backend_openvpn_http
        description Openvpn certbot renew
        server server_openvpn_http 10.1.10.222

# server openvpn (web GUI) qui gère son propre certificat SSL
backend backend_openvpn_https
        description Openvpn web UI
        mode tcp
        option ssl-hello-chk
        server server_openvpn_https 10.1.10.222:443

C'est une version très simplifié de mon fichier de configuration il y a surement quelques erreurs que vous ne manquerez pas de me signaler. Et j'essayerais de mettre à jour en fonction de mes avancement en connaissance sur haproxy.

Roule ma poule

Jean-Christian Denis — Thu, 28 Apr 2022 09:19:00 +0100

Hier j'ai voulu changer le disque dur de mon serveur, ce qui impliquait de le réinstaller complètement. Sachant que ce serveur est utilisé comme box internet, serveur domotique, serveur de blogs, etc... Il ne fallait pas que ça foire.

C'est donc un peu dans le stress et profitant que la foule soit dehors, au soleil, que j'ai entrepris de changer le disque système de mon serveur (un nvme) par deux disques (ssd) configuré en raid1 (miroir) dans le bios. Sauvegarde de toutes les machines virtuelles, sauvegarde de la config du serveur (presque), ouverture du châssis 1U contenant tout le bazar, démontage du disque nvme, mise en place (jeté entre les câbles) des deux disques ssd, reboot, config bios du raid1, reboot installation de Proxmox, reboot, renommage de l'instance (node, machine, peu importe comment ça s'appelle), et de la config, reboot, récupération des sauvegardes de VMs sur le NAS, reboot, échec.

Raa, c'était presque parfait. Juste oublié que dans la config sauvegardée il n'y avait pas les éléments de réseaux, ici 2 fibres + 2 RJ45 + LAN virtuel… On repart pour un tour, remontage du nvme, reboot, récupération des informations oubliées, démontage du nvme, redémarrage, renseignement à la mano des interfaces réseaux, reboot et tadaaaa TOUT FONCTIONNE. Je suis épaté. J'avais même noté quelques commandes par hasard qui m'ont bien servi ! Et j'en ai également profité pour mettre à jour quelques machines virtuelles et mettre en place un backup automatiques des VMs.

J'adore quand ça se passe comme ça. Entre les coupures de courant, la réinstallation du serveur, les mises à jours, ma domotique fonctionne et repart à chaque fois à merveille. Je dois avouer que le monde des machines virtuelles est vraiment pratique.

Non partagé

Jean-Christian Denis — Thu, 25 Mar 2021 09:42:00 +0000

Dans un précédent billet j'expliquais que mon fournisseur d'accès internet proposait une offre à 2Gpbs partagé, jouant sur les mots, en réalité 99% des gens n'avait au final que 1Gpbs, ce qui en soit est largement suffisant, mais comme toujours quand on nous propose quelque chose même inutile, on aime le vérifier.

Pour en revenir à l'offre Open Up elle même, Orange propose 2Gpbs en réception mais partagé, c'est à dire que si vous avez une Livebox inferieur à la 5, vous n'avez que 1Gps point barre, et oui on peut prendre l'offre Open Up sans prendre la dernière Livebox, on y reviendra. Pour la plupart de gens cela est largement suffisant pour regarder la TV, des vidéos, du surf et un peu de téléchargement, tout ça en même temps… Et de toute façon les équipements de votre maison ne savent surement pas encore dépasser cette vitesse, les switch et autres wifi grand public aillant des ports 1Gps...
Ensuite si vous avez la dernière Livebox, Orange à coup de bricolage à réussi à intégrer un switch permettant de partager plus de 1Gps entre chaque port de la Livebox. Chaque port Ethernet de leur boite est limité à 1Gpbs mais l'arrivé fibre elle délivre 2,5Gpbs. Le problème est que Orange a tellement intégré les composants et bridé sa box qu'il n'est quasi rien possible de faire en dehors du très basique de monsieur toutlemonde...
Du coup certains curieux ont eu envie de pousser un peu leur connexion et également de profiter de routage plus technique sur leur réseau interne. Je suis curieux. J'ai voulu savoir. J'ai donc commencé à chercher sur la toile si des moyens existaient, je suis d'abords tombé sur des forums étrangers ou les utilisateurs avaient la même problématique avec leur fournisseur (chose marrante le matériel avait la même provenance, historiquement, Orange) On y parlait d'arbre GPON, de SFP, de norme HSGMII, de contrôleur Broadcom, etc... Des heures de lectures, ne comprenant qu'un mots sur 10, puis je suis tombé sur un sujet du forum lafibre.info, une mine d'or. J'ai lu, j'ai participé, j'ai appris, j'ai vaincu.
La solution n'est pas évidente, quoi que facilité chez moi aillant gardé ma vieille Livebox avec ONT externe, et peu de gens auront envie de se lancer. Si vous n'avez pas déjà un peu de matériel cela peu couter cher, sans compter qu'il n'y a d'intérêt que si votre réseau local dépassent le gigabit.

Bref, aujourd'hui j'ai un connexion supérieur à 2Gpbs, passant par un SFP tiers, un routeur logiciel installé sur une VM, et répartie comme bon me semble sur mon réseau interne à 10Gpbs, en IPv4 et IPv6. Sans Livebox. Orange aime compliquer la tache.

Houra

Jean-Christian Denis — Sat, 05 Dec 2020 09:49:00 +0000

Dois-je crier victoire ?

Après de multiples tentatives, de fausses victoires, de ratés et de déceptions, une fois de plus je constate que je ne suis pas un spécialiste de l'hébergement web. Je viens de passer une semaine, à coup de 5 minutes par-ci par-là, à tenter de passer mon hébergement web local en ssl et je crois que j'ai enfin réussi, en tout cas mes tentatives ont abouties sans que mes navigateurs ne couinent, c'est déjà bon signe.

Reste à voir si il en est de même pour vous.

Local

Jean-Christian Denis — Fri, 27 Nov 2020 21:51:00 +0000

En cette période de pandémie, il faut faire travailler le commerce local... Ben je vais plutôt faire travailler personne !

Autrement dit, ça va être local mais tellement local que ça va rester chez moi. Mais de quoi parle-je ?

Tout simplement de l'hébergement de ce blog. Au lieu de le faire disparaitre une fois de plus de manière volontaire, je me dis qu'en l'hébergeant chez moi il disparaitra au détour d'un bricolage hasardeux. Bref tout ça pour dire que vu qu'il me restait une pièce de libre dans mon serveur perso, je l'ai aménagé pour ce blog.
Si ça ne répond pas c'est que c'est tout cassé !