Blog

  • Bonjour tout le monde !

    Bienvenue sur WordPress. Ceci est votre premier article. Modifiez-le ou supprimez-le, puis commencez à écrire !

  • UPS Eaton 3s

    [toc]

    Définition :

    Un UPS (Uninterruptible Power Supply) est un dispositif électronique qui assure une alimentation électrique de secours en cas de panne de courant, protégeant ainsi les appareils contre les coupures et les fluctuations de tension.

    Principe :

    Le principe de base est très simple : en cas de coupure d’approvisionnement électrique de vos appareils, ces derniers (branchés à l’UPS) pourront toujours être alimentés, le temps que la batterie interne le permette.
    Il faut donc composer en fonction de la puissance* sous-tirée pour dimensionner son UPS afin d’avoir le temps nécessaire de se retourner en cas de coupure prolongée.

    Un calcul trop simpliste : 

    \[
    \text{Temps d’autonomie (en heures)} = \frac{\text{Capacité de la batterie (en Wh)}}{\text{Puissance consommée par l’équipement (en W)}}
    \]

    Si je prends par exemple le modèle que j’ai acheté Eaton 3S 550VA qui a une capacité de 330W (THEORIQUE) , à raison de 40W de puissance de mon homelab, j’obtiens une autonomie réel d’environ 45 minutes.
    On est donc bien loin de la théorie…!

    Informations de l’appareil dans home-assistant
    Autonomie actuelle exprimée en secondes

    Cette estimation affichée dans le tableau de home-assistant (une fois le service NUT paramétré) est réaliste et plus fiable qu’un rapide calcul ! Celui-ci tient compte de la courbe de décharge en fonction de la technologie de la batterie, de son état ainsi que de la puissance sous-tirée.

    • Sa petite consommation…

    Une chose à laquelle je n’avais pas pensé c’était le consommation électrique de l’UPS, car oui, il consomme environ 4,6Wh soit 110,4Wh/j ou encore 40,296kWh/an…

    Définition du besoin

    Il me fallait un UPS simple qui puisse rentrer dans un espace technique exiguë, pas trop onéreux mais surtout connecté afin d’avoir un retour dans home-assistant.
    Mes appareils, pour le moment, ne consomment pas beaucoup (environ 40W)
    Je me suis orienté vers la gamme de chez EATON (3S) et j’ai opté pour le plus petit modèle répondant à mes besoins : le Eaton 3S 550 FR.

    Sous 200W de consommation, il a une autonomie (théorique) maximale de 6 minutes, ce qui laisse le temps de lancer des automatismes en cas de détection de coupure prolongée.

    La batterie à l’intérieur est une 12V 5ah remplaçable généralement après quelques années seulement (technologie au plomb). Comptez entre 20 et 40€.

    Précision si besoin, la moitié des prises seulement sont protégées par la batterie. L’autre moitié est juste protégé des sur-intensités.

    C’est quoi NUT ?


    NUT = Network UPS Tools.
    C’est juste un petit service qui parle avecl’onduleur via USB, récupère son état (batterie, autonomie, mode secteur/batterie, etc.), et partage ces infos au réseau (Proxmox, Home Assistant, etc.).

    En gros :

    • Proxmox = le PC qui lit l’UPS (serveur NUT)
    • Home Assistant = le PC qui lit les infos du serveur NUT
    • L’UPS = la source d’infos


    Grandes lignes :

    • installer/configurer NUT sur Proxmox (il devient serveur NUT)
    • connecter Home Assistant dessus (client NUT)
    • ajouter des automatisations HA (notifications, arrêt propre, etc.)

    Proxmox

    Une fois le bloc UPS en place, relié, branché, on va installer ce qu’il faut sur l’hôte (et non un conteneur/VM).

    1. Vérifier que Proxmox voit l’UPS
      Connecte l’UPS → puis dans Proxmox (shell) :

    Shell – Linux

        lsusb   
                
                        
            

    Vous devriez voir une ligne type “Eaton” ou « UPS ».

    1. Installer NUT sur Proxmox
      Dans le shell Proxmox (ou via SSH) :

    Shell – Linux

        apt update
    apt install nut   
                
                        
            
    1. Configurer NUT en mode serveur
    • Éditez le fichier principal :

    Shell – Linux

        nano /etc/nut/ups.conf   
                
                        
            

    Ajoutez :

    Shell – Linux

        [eaton3s]
    driver = usbhid-ups
    port = auto
    desc = "Eaton 3S 550"   
                
                        
            

    Toujours dans le même fichier, on va en profiter maintenant pour modifier :

    Shell – Linux

        LISTEN 127.0.0.1 3493
       
                
                        
            

    En :

    Shell – Linux

        LISTEN 0.0.0.0 3493
       
                
                        
            

    Ca évite d’être limité au seul port local à écouter.
    Chez moi j’ai du le modifier ainsi sinon HA ne pouvait accéder à l’UPS…

    • Ensuite :

    Shell – Linux

        nano /etc/nut/nut.conf   
                
                        
            

    Remplacez la ligne par :

    Shell – Linux

        MODE=standalone   
                
                        
            
    • Puis :

    Shell – Linux

        nano /etc/nut/upsd.users   
                
                        
            

    Ajouter un utilisateur pour Home Assistant et Proxmox :

    Shell – Linux

        [homeassistant]
    password = 1234
    upsmon master 
     
    [monproxmox]
    password = 4321
    upsmon slave   
                
                        
            
    1. Activer les services

    Shell – Linux

        systemctl restart nut-server
    systemctl restart nut-monitor
    systemctl enable nut-server
    systemctl enable nut-monitor   
                
                        
            
    1. Pour tester :

    Shell – Linux

        upsc eaton3s   
                
                        
            

    → Vous devriez voir battery.charge, battery.runtime, ups.status, etc.
    S’il affiche “OL” = On Line (sur secteur).
    En coupure secteur → “OB” (On Battery).

    Shell – Linux

        battery.charge: 100
    battery.runtime: 600
    ups.status: OL
       
                
                        
            

    Home-assistant

    Maintenant que le serveur est fonctionnel, on va y connecter home-assistant afin qu’il y puise les informations !

    Module NUT

    Dans home-assistant on va commencer par installer une intégration du nom de… NUT !

    La saisie des information devrait être simple.

    • A la place de localhost vous indiquez l’adresse IP de votre machine Proxmox (ou son hostname)
    • Le port doit rester 3493
    • Le nom correspond à celui enregistré plus haut « homeassistant« 
    • Le mot de passe, selon l’exemple est 1234

    ✍️ N’hésitez pas à afficher les entités « Diagnostic » qui ne sont pas toute activées par défaut.

    Automatisation

    Maintenant que l’on a la remontée des informations, on va pouvoir en faire quelque chose !

    configuration.yaml

    Il est nécessaire de rajouter une instruction dans le fichier configuration.yaml.
    Nous verrons par la suite comment configurer l’accès SSH s’il n’est pas déjà activé.

    YAML

        # Extinction demandé du homelab
    shell_command:
      shutdown_proxmox: >
        ssh -i /config/ssh_keys/id_ed25519
        -o StrictHostKeyChecking=no
        root@192.168.0.11 "/root/shutdown_homelab.sh"   
                
                        
            

    Le coeur

    Voici directement le code yaml pour créer l’automatisme :

    YAML

        alias: Gestion complète UPS Eaton / Homelab
    description: Notifications + arrêt Proxmox si autonomie faible
    triggers:
      - id: coupure_30s
        entity_id:
          - sensor.eaton3s_code_d_etat
        to:
          - OB
        for:
          hours: 0
          minutes: 0
          seconds: 5
        trigger: state
      - id: autonomie_critique
        entity_id: sensor.eaton3s_code_d_etat
        to: ALARM OB OL
        for:
          seconds: 30
        trigger: state
      - id: courant_retour
        entity_id:
          - sensor.eaton3s_code_d_etat
        to:
          - OL
        trigger: state
      - id: check_remaining
        trigger: event
        event_type: mobile_app_notification_action
        event_data:
          action: CHECK_REMAINING
    conditions: []
    actions:
      - choose:
          - conditions:
              - condition: trigger
                id: coupure_30s
            sequence:
              - action: notify.mobile_app_sm_s928b
                data:
                  title: ⚠️ Coupure électrique détectée
                  message: >-
                    {% set s = states('sensor.eaton3s_autonomie_de_la_batterie') |
                    int(0) %} {% if s > 0 %}
                      {% set h = s // 3600 %}
                      {% set m = (s % 3600) // 60 %}
                      {% set sec = s % 60 %}
                      {% set end = (now() + timedelta(seconds=s)).strftime("%H:%M:%S") %}
                      L'UPS est sur batterie depuis plus de 30 secondes.  
                      **Autonomie restante : {{ "%02d:%02d:%02d" | format(h, m, sec) }}**  
                      **Extinction estimée à : {{ end }}**
                    {% else %}
                      L'UPS est sur batterie depuis plus de 30 secondes.  
                      Autonomie inconnue.
                    {% endif %}
                  data:
                    sticky: true
                    channel: UPS Alerts
                    importance: high
                    priority: high
                    actions:
                      - action: CHECK_REMAINING
                        title: Vérifier l'autonomie
                      - action: FORCE_SHUTDOWN
                        title: Forcer l'arrêt du homelab
          - conditions:
              - condition: trigger
                id: autonomie_critique
            sequence:
              - action: notify.mobile_app_sm_s928b
                data:
                  title: ⛔ Arrêt automatique homelab
                  message: >-
                    L'UPS signale un niveau de batterie < 20% (`ALARM OB OL`).
                    Extinction immédiate et propre du cluster Proxmox.
                  data:
                    sticky: true
                    clickAction: NONE
                    channel: UPS Alerts
                    importance: high
                    priority: high
              - delay:
                  seconds: 30
              - action: shell_command.shutdown_proxmox
          - conditions:
              - condition: trigger
                id: courant_retour
            sequence:
              - action: notify.mobile_app_sm_s928b
                data:
                  title: 🔌 Courant rétabli
                  message: >-
                    L'alimentation secteur est revenue. L'UPS fonctionne
                    normalement.
                                
                  data:
                    sticky: true
                    clickAction: NONE
                    channel: UPS Alerts
                    importance: high
                    priority: high
          - conditions:
              - condition: trigger
                id: check_remaining
            sequence:
              - action: notify.mobile_app_sm_s928b
                data:
                  title: 🔍 Autonomie actuelle
                  message: >-
                    {% set s = states('sensor.eaton3s_autonomie_de_la_batterie') |
                    int(0) %} {% if s > 0 %}
                      {% set h = s // 3600 %}
                      {% set m = (s % 3600) // 60 %}
                      {% set sec = s % 60 %}
                      {% set end = (now() + timedelta(seconds=s)).strftime("%H:%M:%S") %}
                      Check-in.  
                      **Autonomie restante : {{ "%02d:%02d:%02d" | format(h, m, sec) }}**  
                      **Extinction estimée à : {{ end }}**
                    {% else %}
                      **Autonomie : inconnue**.
                      **Extinction estimée à : inconnue**
                    {% endif %} **État UPS :** {{ states('sensor.eaton3s_etat') }}
                  data:
                    sticky: true
                    clickAction: NONE
                    channel: UPS Alerts
                    importance: high
                    priority: high
                    actions:
                      - action: FORCE_SHUTDOWN
                        title: Forcer l'arrêt du homelab
    mode: single
       
                
                        
            

    Ce que ça fait :

    3 déclencheurs différents pour 3 niveaux différent.

    • Niveau 1 : Avertissement

    Après 30 secondes de coupure d »alimentation (donc de décharge de l’UPS) une notification est envoyée sur le téléphone pour signaler la dite coupure et notifier du temps restant estimé.

    Un bouton d’action est présent pour demander l’arrêt (en douceur) immédiate des VM/LXC et arrêter le homelab.

    • Niveau 2 : Arrêt obligatoire

    Si le temps restant est inférieur à 5 minutes, l’arrêt de Proxmox est automatiquement déclenché ainsi qu’une notification sur le téléphone portble.

    • Niveau 3 : Reprise de l’alimentation

    Si le courant est rétabli avant l’extinction du homelab, une notification est envoyée.

    Si le homelab s’est éteint, aucune notification sera envoyée.

    Proxmox (arrêt doux)

    J’ai déjà paramétré l’ordre d’allumage et donc d’extinction des machines gérées par l’hyperviseur Proxmox.

    Mais il faut une petit script pour commander (via SSH) l’ordre effectif d’arrêt en douceur, propre et sans encombre.

    • Depuis le Shell (hôte) Proxmox, nous allons éditer un nouveau fichier :

    Shell – Linux

        nano /root/shutdown_homelab.sh   
                
                        
            

    Shell – Linux

        #!/bin/bash
    
    LOG=/var/log/proxmox_safe_shutdown.log
    echo "===== Shutdown triggered at $(date) =====" >> $LOG
    
    # Configuration Home Assistant
    HA_URL="http://192.168.0.100:8123"   # IP ou nom de la VM HA
    HA_TOKEN="TON_LONG_LIVED_ACCESS_TOKEN"   # Token persistant dans HA
    
    echo "[0/5] Arrêt propre de Home Assistant..." | tee -a $LOG
    HA_VM_ID=$(qm list | awk 'NR>1 {print $1, $2}' | grep "homeassistant" | awk '{print $1}')
    
    if [ -n "$HA_VM_ID" ]; then
        echo "→ Envoi stop à Home Assistant..." | tee -a $LOG
        curl -s -X POST -H "Authorization: Bearer $HA_TOKEN" \
             -H "Content-Type: application/json" \
             "$HA_URL/api/services/homeassistant/stop"
        echo "→ Attente 30s pour HA..." | tee -a $LOG
        sleep 30
    else
        echo "→ VM Home Assistant non trouvée, passage..." | tee -a $LOG
    fi
    
    echo "[1/5] Arrêt propre des VM..." | tee -a $LOG
    for vm in $(qm list | awk 'NR>1 {print $1}'); do
        echo "→ VM $vm : shutdown ACPI" | tee -a $LOG
        qm shutdown $vm --timeout 120 --skiplock 1
    done
    
    echo "[2/5] Attente arrêt complet des VM..." | tee -a $LOG
    for vm in $(qm list | awk 'NR>1 {print $1}'); do
        echo "→ Attente extinction VM $vm..." | tee -a $LOG
        qm wait $vm 2>>$LOG
    done
    
    echo "[3/5] Arrêt des conteneurs LXC..." | tee -a $LOG
    for ct in $(pct list | awk 'NR>1 {print $1}'); do
        echo "→ CT $ct : stop" | tee -a $LOG
        pct shutdown $ct --timeout 60 --forceStop 0
    done
    
    echo "[4/5] Attente arrêt complet des conteneurs LXC..." | tee -a $LOG
    for ct in $(pct list | awk 'NR>1 {print $1}'); do
        while pct status $ct | grep -q "running"; do
            echo "→ Attente extinction CT $ct..." | tee -a $LOG
            sleep 5
        done
    done
    
    echo "[5/5] Arrêt du nœud Proxmox..." | tee -a $LOG
    shutdown -h now
       
                
                        
            

    Il faut donc adapter les lignes :

    HA_URL="http://192.168.0.100:8123" # IP ou nom de la VM HA
    HA_TOKEN="TON_LONG_LIVED_ACCESS_TOKEN" # Token persistant dans HA
    Token persistant
    1. Pour en définir un, rendez-vous sur votre home-assistant et cliquez en bas à gauche sur votre avatar.
    2. Dans l’onglet « Sécurité » regardez dans la partie tout en bas : Jetons d’accès longue durée
    3. Cliquez sur Créer un jeton et nommez-le par exemple : Shutdown Proxmox
    4. Récupérez le jetons et insérez-le dans le fichier précédent.

    Connexion SSH

    1. Générer une clé SSH dans Home Assistant

    Depuis Home Assistant, il faut ouvrir un terminal.
    👉Le faire via le plugin Advanced SSH & Web Terminal.

    • Dans le terminal HA, saisir :

    Shell – Linux

        ssh-keygen -t ed25519   
                
                        
            

    Appuiez 3× Entrée (emplacement + mot de passe vide).

    La clé sera créée ici :

    /root/.ssh/id_ed25519
    /root/.ssh/id_ed25519.pub
    

    ☝️ Si on vous demande d’écraser un fichier déjà existant, c’est que vous aviez déjà généré un clé et il vaut mieux ne pas l’écraser sinon vous risqueriez d’être bloqué quelque part…

    1. Copier la clé publique dans Proxmox
    • Toujours dans le terminal HA :

    Shell – Linux

        cat /root/.ssh/id_ed25519.pub   
                
                        
            

    → Copiez TOUTE la ligne affichée (commence par ssh-ed25519 AAAA…).

    • Ensuite, dans la fenêtre de shell Proxmox et ajoute la clé via :

    Shell – Linux

        nano /root/.ssh/authorized_keys   
                
                        
            

    → Colle la clé → Enregistre (Ctrl+O / Ctrl+X)

    ☝️Si le fichier n’est pas nouveau ou vide, insérer le code sur une nouvelle ligne, tout simplement. Ne rien supprimer.

    • S’assure-toi d’avoir des droits minimaux :

    Shell – Linux

        chmod 600 /root/.ssh/authorized_keys
    chmod 700 /root/.ssh   
                
                        
            
    1. Tester la connexion SSH depuis home-assistant
    • Retour dans le Terminal HA :

    Testez SSH avec exactement la même commande que dans Home Assistant :

    Shell – Linux

        ssh -i /root/.ssh/id_ed25519 -o StrictHostKeyChecking=no root@192.168.0.11 "echo OK"   
                
                        
            

    Le résultat attendu est sobrement :

    OK

    Si ça fonctionne, bravo !

    Si ça demande un mot de passe → la clé n’est pas acceptée.

    Si “permission denied” → clé absente ou droits incorrects.

  • Allumer – Éteindre son PC (HAOS)

    [toc]

    Le but

    • Via un simple bouton (bascule) allumer ou éteindre son ordinateur derrière une prise connectée.

    Pré-requis 

    • Proxmox
    • HAOS sur une VM (192.168.0.100)
    • Conteneur LXC ID 105 (Debian)
    • Service Samba déjà installé et fonctionnel
    • Couple UserMdP défini sur le système (pve01 / pve01) et enregistré dans Samba
    • Windows 10/11
    • Dans HAOS, les plugins « Advanced Terminal & SSH » ainsi que « Local Files editor » sont un gros plus.

    Défis

    • Le bouton est juste un simple bouton switch (toggle) sans moyen de connaître son état donc.
    • La prise connectée alimente le PC ainsi que les écrans, petites lumières, enceintes etc
    • Ne pas couper brutalement l’ordinateur comme si on débrancherai la prise !
    • HAOS est un système très fermé donc le montage réseau exige une configuration via Samba et un montage depuis « Stockage » afin de faire reconnaître l’emplacement réseau.
    • Un service Windows devra surveiller en permanence la présence d’un « déclencheur » qui lui fera comprendre qu’une demande d’extinction est faite.

    Architecture / Synoptique 

    • La pression sur un simple bouton (Sonoff SNZB-01P) déclenchera une action conditionnée :
      • Allumer la prise connectée puis allumer le PC
      • Eteindre le PC puis couper la prise connectée.
    • Le réveil via le service WoL est très simple
    • L’extinction du PC demande un montage un peu plus… spécial.
      • HAOS écrit un fichier shutdow.txt dan un partage réseau monté :/mnt/share/pc_auto-shutdown
      • Ce partage est servi par un LXC Debian (ID 105) via Samba : \\192.168.0.105\pc_auto-shutdown.
      • Côté Windows, un script/planificateur surveille ce fichier et coupe la machine.

    Proxmox

    Étape 1 – Création, montage, réservation

    On va créer un dossier qui sera partagé par la suite.

    • Depuis le noeud Proxmox :

    Shell – Linux

        mkdir -p /mnt/share/pc_auto-shutdown   
                
                        
            
    • Vérifier les permissions :

    Shell – Linux

        ls -ld /mnt/share/pc_auto-shutdown   
                
                        
            
    • Vous devriez obtenir quelque chose de similaire à :
    drwxr-xr-x 2 root root 4096 Aug 26 14:56 /mnt/share/pc_auto-shutdown

    Étape 2 – Monter le dossier pour le conteneur 105

    Pour que le conteneur LXC 105 puisse accéder au dossier « pc_auto-shutdown » précédemment créé, il faut lui donner le chemin. C’est ce que l’on appel « monter un dossier ».

    1. Depuis le nœud Proxmox, éditez la conf du conteneur 105 :

    Shell – Linux

        nano /etc/pve/lxc/105.conf   
                
                        
            
    1. Ajouter cette ligne à la fin :

    Shell – Linux

        mp0: /mnt/share/pc_auto-shutdown,mp=/srv/pc_auto-shutdown
    
       
                
                        
            

    Explications :

    • mp0 « Montage Point #0 » Si vous aviez déjà d’autres points de montage, mettez simplement le numéro qui suit.
    • /mnt/share/pc_auto-shutdown est le chemin du partage.
    • mp=/srv/pc_auto-shutdown indique que ce partage (point de montage) doit être monté dans…
    1. Redémarrer le conteneur :

    Shell – Linux

        pct reboot 105
       
                
                        
            

    Étape 3 – Samba

    L’outil Samba doit être déjà installé et fonctionnel.
    L’utilisateur « pve01 » avec son mot de passe (identique) est déjà connu.

    • Depuis le conteneur LXC, vérifier l’état de fonctionnement de Samba :

    Shell – Linux

        systemctl status smbd   
                
                        
            

    Vous devriez voir en vert l’information « Active: active (running)« .

    On va à présent configurer Samba pour exposer notre point de montage sur le service.

    • Édition du fichier :

    Shell – Linux

        nano /etc/samba/smb.conf   
                
                        
            
    • Tout à la fin, ajoutez ceci :

    Shell – Linux

        [pc_auto-shutdown]
       path = /srv/pc_auto-shutdown
       browseable = yes
       read only = no
       guest ok = no
       valid users = pve01   
                
                        
            

    Enregistrez et quitter.

    • Vérifions l’UID/GID pour l’utilisateur sus-mentionné « pve01 » :

    Shell – Linux

        id pve01   
                
                        
            

    Vous devriez voir quelque chose comme :

    uid=1000(pve01) gid=1000(pve01) groups=1000(pve01),100(users)

    Notez bien ceci quelque part car si chez vous ces chiffres sont différents, il faudra en tenir compte pour la suite.

    • Permission sur le dossier partagé :

    Shell – Linux

        chown -R 1000:1000 /srv/pc_auto-shutdown
    chmod -R 775 /srv/pc_auto-shutdown   
                
                        
            

    Étape 4 – Chrony (service NTP)

    Hôte Proxmox [nœud pve01]

    On va synchroniser la définition des « temps » (heure) entre les machines en s’appuyant sur notre home-serveur (Proxmox) qui va servir à récupérer l’heure via le composant chrony pour servir de service NTP.
    Ce service sera alors la pierre angulaire pour redistribuer l’heure exact aux machines de votre réseau local (après configuration individuelle…) pour qu’elles soient toutes synchronisées à la seconde près.

    Donc l’hôte Proxmox aillant (normalement) déjà le composant chrony d’installé, nous allons le configurer puis configurer les clients (conteneur LXC Debian + Windows) afin que tout ce petit monde soit raccord.

    • Depuis l’hôte Proxmox, vérifier la présence de chrony :

    Shell – Linux

        # Vérifier si chrony est installé
    dpkg -l | grep chrony   
                
                        
            

    Si rien ne s’affiche c’est que le service est absent. Pour l’installer :

    apt update
    apt install chrony -y
    • Editer le configuration :

    Shell – Linux

        nano /etc/chrony/chrony.conf
       
                
                        
            
    • Ajouter/adaptez cette ligne pour correspondre à votre infrastructure réseau :

    Shell – Linux

        # Autoriser les clients du LAN à se synchroniser
    allow 192.168.0.0/24
       
                
                        
            
    • Toujours dans le même fichier, s’assurer d’avoir des serveurs NTP publics comme source. Exemple:

    Shell – Linux

        pool 2.debian.pool.ntp.org iburst
       
                
                        
            
    • Redémarrer/relancer/vérifier le service :

    Shell – Linux

        systemctl restart chrony
    systemctl enable chrony --now
    systemctl status chrony   
                
                        
            

    Le service doit apparaître en vert à l’état de « running ».

    • Vérifier qu’il écoute sur le port UDP 123 [0.0.0.0:123] :

    Shell – Linux

        ss -ulpn | grep 123
       
                
                        
            
    • Vérifier la synchronisation sur l’hôte :

    Shell – Linux

        chronyc sources
    chronyc tracking
    
       
                
                        
            
    Client LXC Debian [Conteneur 105]

    Maintenant que l’hôte reçoit une heure universelle, on va la récupérer sur notre client conteneur LXC Debian.

    • Installer le service Chrony sur le conteneur LXC :

    Shell – Linux

        apt update
    apt install chrony -y
       
                
                        
            
    • Éditer la configuration de chrony :

    Shell – Linux

        nano /etc/chrony/chrony.conf
       
                
                        
            
    • Ajoutez à la fin du fichier l’instruction correspondante à l’adresse IP de votre hôte Proxmox :

    Shell – Linux

        # Serveur NTP : l'hôte Proxmox
    server 192.168.0.11 iburst
       
                
                        
            
    • Redémarrer/relancer/vérifier le service :

    Shell – Linux

        systemctl restart chrony
    systemctl enable chrony --now
    systemctl status chrony   
                
                        
            
    • Vérifiez la synchronisation :

    Shell – Linux

        chronyc sources
    chronyc tracking
       
                
                        
            
    Windows

    Coté Windows, nous allons faire exactement la même chose : utiliser l’hôte Proxmox comme référent prioritaire à la synchronisation NTP de l’heure. En cas de soucis si l’hôte Proxmox ne répond pas, il y aura moyen de joindre les serveurs directement pour ne pas « crasher ».

    • Ouvrez une fenêtre terminal cmd Powershel en tant d’administrateur et collez ce qui suit :

    cmd – Powershell

        w32tm /config /manualpeerlist:"192.168.0.11,0.fr.pool.ntp.org,1.fr.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
    net stop w32time
    net start w32time
    w32tm /resync /rediscover
    w32tm /query /status
    w32tm /query /peers   
                
                        
            

    Explications :

    • 192.168.0.11 → serveur interne (celui de votre hôte Proxmox)
    • 0.fr.pool.ntp.org, 1.fr.pool.ntp.org, 2.fr.pool.ntp.org → serveurs publics comme backup
    • syncfromflags:manual → utilise uniquement les serveurs listés
    • reliable:yes → indique que ce PC peut être considéré comme une source fiable sur le LAN
    • update → applique immédiatement la configuration

    Windows va interroger dans l’ordre les adresse configurées donc si la première est HS, ils consultera la suivante puis celle d’après…

    HAOS

    Via l’interface

    • HAOS > Paramètres > Système > Stockage > Ajouter un stockage réseau
    • Renseigner les champs comme sur la capture d’écran ci-dessous :
    HAOS – Nouveau stockage réseau
    • Le dossier correspondant est automatiquement créé par HAOS.

    Pour retrouver exactement où HAOS à monté le dossier « PC_HA » il faut se diriger du coté du terminal SSH.

    • Envoyez la commande suivante :

    Shell – Linux

        mount | grep cifs   
                
                        
            

    Une liste (ou une seule ligne) apparaissent avec tous les détails comme par exemple :

    //192.168.0.105/pc_auto-shutdown on //192.168.0.105/pc_auto-shutdown on /share/PC_HA type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=pve01,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.0.105,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1) type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=pve01,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.0.105,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

    C’est assez imbuvable mais l’information que l’on cherche se trouve ici : /share/PC_HA

    Nous venons d’identifier l’emplacement exact où HAOS gère ce partage.
    Et il n’y a pas d’autres solution que d’en passer par l’utilitaire graphique pour que le « supervisor » accepte et gère convenablement les droits !

    Commande shell

    Maintenant que HAOS à un accès configuré pour aller y déposer un fichier (qui déclenchera l’arrêt du PC) nous allons écrire la commande qui effectuera à proprement parler cette tâche.

    • Dans le fichier de configuration.yaml :

    YAML

        # Moyen pour arrêter le PC
    shell_command:
      create_shutdown_file: "date '+%Y-%m-%dT%H:%M:%S%:z' > /share/PC_HA/shutdown.txt"   
                
                        
            
    • Enregistrez et redémarrez HAOS.

    La date est inscrite comme contenu du fichier et son format garanti une portabilité maximale.

    • Pour tester, HAOS > Outils de développement > Actions

    YAML

        service: shell_command.create_shutdown_file
    data: {}
       
                
                        
            

    Si vous obtenez une réponse différente de :

    YAML

        stdout: ""
    stderr: ""
    returncode: 0   
                
                        
            

    … c’est qu’il y aura eu un problème.

    • Pour vérifier la présence de ce fichier, via le terminal SSH :

    Shell – Linux

        ls -l /share/PC_HA   
                
                        
            

    Vous devriez voir apparaître le fichier shutdown.txt

    • Si vous consultez via l’explorateur de fichiers Windows l’adresse : \\192.168.0.105\pc_auto-shutdown vous devez aussi trouver le fichier bien visible.

    Window

    Outils

    Pour y parvenir, nous allons avoir besoin d’utiliser PowerShell Admin [CTRL + X > A] et d’installer quelques outils intermédiaires…

    Chocolatey

    Chocolatey est un peu comme une suite de mini logiciels/fonctions. Pur plus de facilité nous allons en passer par lui.

    • Vérification de sa présence éventuelle :

    cmd – PowerShell

        choco --version
       
                
                        
            

    Si vous obtenez un numéro de version, Chocolatey est déjà installé.
    Si c’est un message d’erreur, il faudra l’installer.

    • Installation de Chocolatey :

    cmd – PowerShell

        Set-ExecutionPolicy Bypass -Scope Process -Force; `
    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; `
    iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
       
                
                        
            

    Une fois l’installation terminée, fermez et rouvrez la fenêtre PowerShell pour vérifier avec la commande choco --version

    NSSM (Non-Sucking Service Manager)

    C’est ce logiciel que nous visions et son installation est plus aidée via Chocolatey. Donc ce dernier étant installé, nous allons procéder à l’installation de NSSM.
    C’est un petit logiciel, léger et sûre même si un peu ancien.

    • Vérification de la présence éventuelle de NSSM sur votre système :

    cmd – PowerShell

        nssm version
       
                
                        
            

    Vous vous recevez un numéro de version c’est bon. Sinon, en cas d’erreur, vous êtes bon pour l’installer.

    • Installation :

    cmd – PowerShell

        choco install nssm -y
       
                
                        
            

    Le -y répond automatiquement “oui” à toutes les confirmations.
    Chocolatey va télécharger NSSM et le placer dans son dossier (C:\ProgramData\chocolatey\bin par défaut).

    Normalement, Chocolatey ajoute automatiquement les exécutables à ton PATH.
    Si tu obtiens une erreur en tapant nssm, ajoute manuellement :

    1. Ouvre Paramètres > Système > Informations système > Paramètres système avancés > Variables d’environnement
    2. Dans Path, ajoute : C:\ProgramData\chocolatey\bin
    3. Redémarre PowerShell et teste à nouveau nssm version.

    Script Chocolatey + NSSM

    Pour ceux qui ont la flemme, le script suivant (copier/coller toujours dans une fenêtre PowerShell Admin) est fait pour vous !

    cmd – PowerShell

        # Vérifier si Chocolatey est installé
    Write-Host "Vérification de Chocolatey..."
    if (!(Get-Command choco -ErrorAction SilentlyContinue)) {
        Write-Host "Chocolatey n'est pas installé. Installation en cours..."
        Set-ExecutionPolicy Bypass -Scope Process -Force
        [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
        iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
    
        # Recharge la session pour activer choco
        refreshenv
    } else {
        Write-Host "Chocolatey est déjà installé."
    }
    
    # Vérifier la version de Chocolatey
    choco --version
    
    # Installer NSSM
    Write-Host "Installation de NSSM..."
    choco install nssm -y
    
    # Vérifier NSSM
    Write-Host "Vérification de NSSM..."
    nssm version
       
                
                        
            

    Le fichier exécutable se trouve ainsi installé à C:\ProgramData\chocolatey\bin

    Script de surveillance

    • Via le gestionnaire de fichiers de Windows, ajouter un fichier dans C:\Scripts\shutdown_watcher.ps1
    • A l’aide du bloc-note, éditez le fichier avec le contenu suivant :

    cmd – PowerShell

        # -----------------------------------------------------------------------------
    # Script de surveillance pour extinction du PC via fichier déclencheur (log amélioré)
    # -----------------------------------------------------------------------------
    
    Start-Sleep -Seconds 30
    
    # Monter le partage réseau (si nécessaire)
    net use \\192.168.0.105\pc_auto-shutdown /user:pve01 pve01 /persistent:yes
    
    $shutdownFile = "\\192.168.0.105\pc_auto-shutdown\shutdown.txt"
    $logFile = "C:\Scripts\shutdown_watcher.log"
    
    # --- Nettoyage automatique du log au démarrage ---
    if (Test-Path $logFile) {
        # Option 1 : vider le fichier
        Clear-Content $logFile
        # Option 2 : archive le fichier (décommenter si besoin)
        # Rename-Item $logFile ("C:\Scripts\shutdown_watcher_" + (Get-Date -Format "yyyyMMdd_HHmmss") + ".log")
    }
    
    # Fonction de log (préfixe les nouvelles lignes en haut du fichier)
    function Log {
        param([string]$msg)
        $timestamp = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss")
        $newLine = "$timestamp $msg`r`n"
        
        # Lire l'ancien contenu
        $old = ""
        if (Test-Path $logFile) { $old = Get-Content $logFile -Raw }
        
        # Écrire le nouveau bloc en haut
        Set-Content -Path $logFile -Value ($newLine + $old)
    }
    
    # Formats ISO8601 tolérés
    $formats = @(
        "yyyy-MM-ddTHH:mm:ssK",
        "yyyy-MM-ddTHH:mmK",
        "yyyy-MM-ddTHH:mm:ss"
    )
    
    Log "=== Script démarré ==="
    
    while ($true) {
        if (Test-Path $shutdownFile) {
            try {
                # Séparation des tentatives
                Log "----- Nouvelle tentative -----"
    
                $raw = Get-Content $shutdownFile -Raw
                $fileContent = ($raw -replace "^\uFEFF","").Trim()
    
                Log "Contenu brut    : [$raw]"
                Log "Contenu nettoyé : [$fileContent]"
    
                # Conversion tolérante
                $shutdownTime = New-Object DateTime
                if (-not [datetime]::TryParse($fileContent, [ref]$shutdownTime)) {
                    throw "Impossible de convertir l'horodatage : [$fileContent]"
                }
    
                $now = Get-Date
                $diff = ($now - $shutdownTime).TotalSeconds
    
                Log "Heure Windows       : $now"
                Log "Horodatage fichier  : $shutdownTime"
                Log "Ecart en sec        : $diff"
    
                # Tolérance : 45 secondes maximum, uniquement si le fichier est dans le passé
    			if ($diff -ge 0 -and $diff -le 45) {
    				Log "✅ Décision : Extinction demandée (écart $diff sec)"
    				Remove-Item $shutdownFile -Force
    				Start-Process "shutdown.exe" -ArgumentList "/s /f /t 0" -NoNewWindow
    				exit
    			}
    			else {
    				Log "❌ Décision : Ignoré, horodatage ancien ou futur (écart $diff sec)"
    				Remove-Item $shutdownFile -Force
    			}
            }
            catch {
                Log "⚠️ Erreur : $($_.Exception.Message)"
                Log "DEBUG brut : [$raw]"
                Remove-Item $shutdownFile -Force
            }
        }
    
        Start-Sleep -Seconds 5
    }
       
                
                        
            

    Explications :

    1. Le service de surveillance (watcher) va contrôler la présence du fichier shutdown.txt dans le répertoire réseau \\192.168.0.105\pc_auto-shutdown
    2. Pour y accéder, il a besoin du couple d’identifiants Samba ET d’un compte windows (à vous d’adapter le ligne !)
    3. En cas de présence du dit fichier :
      1. Va effectuer un contrôle par comparaison de date entre celle inscrite au sein du fichier (via la comande shell de HOAS) et celle actuelle dans un format « universelle ».
      2. Un écart fixé de 45 secondes est permis. Au delà, le fichier est supprimé et… rien d’autres.
      3. Mais si l’écart est inférieur à 45 secondes de décalage : suppression du fichier (pour éviter une boucle infini) et arrêt du PC.

    Cette « double vérification » fait suite à un constat que j’ai effectué lors de mes essais : si mon PC est déjà éteint mais que l’automatisme (ou autre) déclenche l’envoi du fichier shutdown.txt dans le dossier partager (Proxmox), lors de l’ouverture de la session Windows, le script de surveillance va tout de suite trouver le fichier et va alors arrêter le PC avant même que vous aillez eu le temps de vous logger !

    Un système de « log » est mis en place, c’est ce qui m’a permis de constater une différence dans l’horodatage. Du coup, impossible d’éteindre le PC. Nous avons mis en place un moyen de synchroniser les « temps » (service NTP) entre les machines donc vous ne devriez plus avoir de soucis.

    Mise en œuvre du script de surveillance

    Maintenant que tous les outils sont en place, nous allons installer un « watcher » grâce à NSSM.

    • Installer un nouveau service :

    cmd – PowerShell

        nssm install PCShutdownWatcher
       
                
                        
            
    NSSM – Nouveau service
    • Dans le champs « Chemin », inscrire :
      C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    • Dans le champs « Rép. de démarrage » inscrire :
      C:\Scripts
    • Dans le champs Paramètres, inscrire :
      -NoProfile -ExecutionPolicy Bypass -NoLogo -NonInteractive -File "C:\Scripts\shutdown_watcher.ps1"

    Tests

    • Pour démarrer le service sans plus attendre :

    cmd – PowerShell

        nssm start PCShutdownWatcher
       
                
                        
            

    Vérification

    • Pour voir le processus, faite [CTRL + ALT + Suppr] > Gestionnaire des tâches.
    • Recherchez « nssm »
    • Vous trouverez votre watcher.

    Pour information, ce service ne me prend que 1,4Mo de RAM. Autrement dit : rien !

    Essai grandeur nature

    Enregistrez tout votre travail car votre PC va s’arrêter à l’issue du test.

    Donc 2 possibilités :
    – Écrire manuellement le fichier « shutdown.txt » dans \\192.168.0.105\pc_auto-shutdown\
    – Faire écrire le fichier via une simulation d’action depuis HAOS

    Le premier cas étant d’une évidence enfantine, je ne vais pas la détailler préfèrent tester une simulation depuis HAOS.

    Reportez vous en fait au chapitre « Commande shell » qui explique exactement quoi faire.

    En cas de doute, vous pouvez redémarrer le service avec la commande PowerShell nssm restart PCShutdownWatcher

    HAOS – Automatisation

    Nous arrivons ENFIN à l’automatisation !

    Via le plugin « Local Files Editor » nous allons ajouter au fichier « automation.yaml » le bloc suivant pour commencer :

    YAML

        - id: '1756310101388'
      alias: PC - Toggle (allumer / éteindre)
      description: ''
      triggers:
      - domain: mqtt
        device_id: b9e8f93bf99b9c0b6366842e4e2db0f0
        type: action
        subtype: single
        trigger: device
      conditions: []
      actions:
      - choose:
        - conditions:
          - condition: and
            conditions:
            - condition: state
              entity_id: switch.prise_antela_ordinateur
              state: 'on'
            - condition: state
              entity_id: device_tracker.msi_pc_fixe_lan
              state: home
            - condition: numeric_state
              entity_id: sensor.prise_antela_ordinateur_puissance
              above: 90
              enabled: true
          sequence:
          - action: light.turn_on
            metadata: {}
            data:
              brightness_pct: 100
              rgb_color:
              - 255
              - 0
              - 0
            target:
              area_id: bureau
          - action: light.turn_on
            metadata: {}
            data:
              flash: long
            target:
              area_id: bureau
          - action: shell_command.create_shutdown_file
            metadata: {}
            data: {}
            enabled: true
          - delay:
              hours: 0
              minutes: 0
              seconds: 55
              milliseconds: 0
          - condition: numeric_state
            entity_id: sensor.prise_antela_ordinateur_puissance
            enabled: true
            below: 90
          - action: light.turn_off
            metadata: {}
            data: {}
            target:
              area_id: bureau
          - action: switch.turn_off
            metadata: {}
            data: {}
            target:
              device_id: 70ecb632ddad3328a7c11ddcd55024b7
            enabled: true
          alias: Eteindre le PC
        - conditions:
          - condition: or
            conditions:
            - condition: state
              entity_id: switch.prise_antela_ordinateur
              state: 'off'
            - condition: state
              entity_id: device_tracker.msi_pc_fixe_lan
              state: not_home
            - condition: numeric_state
              entity_id: sensor.prise_antela_ordinateur_puissance
              below: 45
          sequence:
          - action: switch.turn_on
            metadata: {}
            data: {}
            target:
              device_id: 70ecb632ddad3328a7c11ddcd55024b7
          - delay:
              hours: 0
              minutes: 0
              seconds: 4
              milliseconds: 0
          - action: wake_on_lan.send_magic_packet
            metadata: {}
            data:
              mac: D8:BB:C1:CA:A6:FF
          alias: Allumer le PC
      mode: single   
                
                        
            

    Bien évidement, cela correspond aux éléments qui sont présents chez moi avec leur nom et leur ID

    Cela, encore une fois répond à MON besoin qui était de couper l’alimentation électrique de la prise qui alimente mon PC avec les écrans et les lumières.
    Donc il fallait tenir compte de plusieurs facteurs ce qui a complexifier pas mal la chose.

    Pour la « déco » j’ai aussi mis un petit système de lumières qui s’animent en cas d’arrêt demandé. Bref, vous avez l’idée içi. A vous d’adapter.

  • Renvoi IR MOES UFO-R11 / ZS06

    [toc]

    Présentation

    Sous son air anodin, sa petite taille et se promesses aguichantes, se cache en réalité des mécanismes et des fonctions insoupçonnés. De la plus trivial à quelque chose de plus abouti.

    Je ne vais pas vous représenter en long, en large ni en travers l’objet ni même son utilisation rudimentaire.
    Cela ne m’intéresse pas et ce n’est pas le but.

      • Lisez cet article [FR] pour la présentation sommaire.
      • Lisez cet article [FR] pour une présentation un peu plus détaillée.
      • Lisez ce sujet du forum HACF.fr pour une utilisation plus détaillée.
      • Lisez cet article [EN] pour une présentation plus fine.

    Il existe en plusieurs versions (WiFi, Zigbee, Tuya), fonctionne avec 2 piles AAA (vendues séparément) avec la référence UFO-R11 (MOES).
    Une copie sans marque sous la référence ZS06 et trouvable mais elle est filaire (donc routeur Zigbee, c’est un avantage).

    Je vais vous emmener sur un terrain que je ne soupçonnais même pas lors de l’achat de ce boitier de renvoi de signaux infra-rouge.

    Mon modèle :

    • Fabricant : MOES
    • Références : UFO-R11
    • Protocoles : Zigbee
    • Alimentation : 2 piles AA (vendues séparément) 
    • Autonomie : <no_data>
    • Diffusion du signal : 360°
    • Portée : « suffisante »
    • Tarif : 18,19€ (30/06/2025)
    • Vendeur : Aliexpress
    • Intégration Z2M : Zigbee2MQTT.io
    • Led temoin d’action : Oui, toute petite bleu

    But initial

    Pouvoir piloter sa climatisation qui n’est pas « intelligente » (connectée) sauf via sa télécommande à infra-rouge.
    Au départ j’ai acheté ce boitier IR car il offre la possiblilité de capturer des signaux émis par une télécommande à proximité pour les enregistrer et les rejouer via sa box domotique (home-assistant).

    C’est largement documenté de part la toile et je m’apprêtais à reproduire bêtement la même chose.
    Ensuite, bah il fallait faire des boutons ainsi que tout le tralala… l’idée ne me réjouissait pas trop rien qu’au fait de penser que ça allait être « moche ».

    Le signal IR

    Comme beaucoup, je pensais que 1 bip = 1 code = 1 action. Quelque chose somme toute de basique.
    Sauf qu’en réalité le code IR renvoyé par de très nombreuses télécommandes de climatisation (ou appareils s’y afférant) est en réalité un savant mélange de toutes les fonctions (de leur réglages donc) mais compilées dans un seul code envoyé en une seule pression !

    Oui ! Il est faux de penser que le signal IR ne fait QUE une seule chose à la fois ! C’est certes vrai pour des appareils très simples comme les boitier led RGB à bas coût ou même pour les télécommandes des TV (lorsque l’on voyait encore la led IR s’illuminer dans le noir à chaque pression ^^).
    Pour des utilisations plus complexes, le code IR est plus complexe. C’est le cas de nos climatiseurs par exemple.

    En plus (ou plutôt en moins, c’est selon) le retour de l’information n’est pas assuré. Votre télécommande envoie un ordre et si cet ordre n’arrive pas, votre télécommande n’en saura rien et elle perdra sa « synchronisation » entre ce qu’elle affiche et ce qui est réellement pris en compte par votre climatiseur.
    Mais en cas de désynchronisation, il suffit d’appuyer sur une seule touche et c’est comme si vous renvoyez l’intégralité des fonctions de la télécommande. Je vous explique ça ci-dessous.

    Cas concret

    Septique ? Faites l’essai par vous même :

    1. Votre climatiseur est en marche.
      Il est configuré en mode climatisation à 25°C, vitesse du ventilateur à puissance minimum sans oscillation de la bouche de sortie.
    2. Cachez la télécommande pour ne pas que le signal soit reçu par votre climatiseur.
    3. Modifiez 2 voir 3 réglages.
      Votre télécommande va alors afficher des informations erronés car il n’y pas de retour d’état.
      => par exemple avec une température +2°C (27°C), une vitesse du ventilateur au maximum et l’oscillation activée.
    4. Toujours avec cette télécommande désynchronisée présentez face à votre climatisation.
    5. Sur votre télécommande, changez uniquement la température pour la faire passer disons de -1°C (26°C).
    6. Le signal part et votre climatisation va alors mettre à jour la température comme demandée (26°C) mais aussi le vitesse du ventilateur et l’oscillation.
      Tout ça juste avec un changement de la température !!!

    C’est la preuve que le code envoyé par la télécommande n’est pas « juste » un seul code pour une seule fonction.

    Mais cette conclusion, je m’en suis aperçue personnellement qu’après avoir commencé à m’intéresser au sujet au travers de ce boitier UFO-R11.

    Une fois dans Home-Assistant

    But premier : tester le boitier

    Pré-requis :

    • Boitier appairé et fonctionniel
    • Intégration via Z2M et MQTT
    • L’appareil répond au nom de « Télécommande IR« 
    Intégration UFO-R11 via MQTT

    Donc je vais commencer par capter les signaux pour les enregistrer dans un bête fichier texte et ainsi les intégrer plus tart.

    Apprentissage

    On se dirige au choix :

    • Vers l’intégration MQTT > On cherche son appareil.
    • On recherche directement l’appareil « Télécommande IR ».
    Page d’intégration MQTT de l’appareil UFO-R11

    La partie qui nous intéresse pour commencer est la zone ci-dessous.

    UFO-R11 – Apprentissage (MQTT)
    1. Cliquer sur l’icône icône flash
    2. Votre boitier une led bleu s’allume dans un coin supérieur de votre UFO-R11.
    3. Pointez votre télécommande et appuyez sur une touche.
    4. Le code apparaît sur votre page dans la section « Journal » mais aussi « Capteurs ».
      La led bleu s’éteint. Si ce n’est pas le cas, cliquez sur le bouton icône ha
    5. Notez ce code de votre coté dans un fichier texte.
    6. Dans la zone icône ha vous pouvez tester votre code car… parfois ça ne fonctionne pas.
      Pour savoir si ça fonctionne, votre boitier va réagir en allumant brièvement la petite led bleu.
    7. Répétez l’opération pour vos boutons, mais pas trop vite, je vais vous montrer… beaucoup mieux !

    Utiliser ces (ses) codes

    Bon là je ne vous serais d’aucune aide aujourd’hui. Il existe tellement de possibilité que… Au lieu d’implémenter les code pour les rendrent utilisables, je vous propose de vous amuser juste avec le la fonction d’envoi du code en utilisant Zigbee via MQTT afin de simuler l’envoie d’une commande avec votre code fraichement appris.
    Prêt ? C’est parti ! (après on verra mieux, promis)

    Récupérer les informations
    Page d’intégration MQTT de l’appareil UFO-R11

    Pour récupérer les information nécessaire, avec MQTT il nous faut connaître le sujet (topic) ainsi que le message (payload).

    En premier, nous utilisons la zone prévue à cet effet qui fonctionne, ultra simple (trop) mais fonctionnelle.

    MQTT – Contrôles
    • Dans le champs « Ir code to send » icône ha vous collez un code précédemment appris.
    • Cliquez simplement en dehors du champs pour valider l’envoi.
    • Si tout se passe bien, votre boitier va allumer brièvement une petite led bleu
    • Vous verrez surtout sur la droite une nouvelle entrée dans le journal.
    MQTT – Exposition / journalisation
    A la recherche de l’inconnu

    Nous venons de procéder à un envoie de commande via MQTT qui fonctionne mais nous ne savons pas comment ça a fonctionné au juste.
    Je vous propose de partir à la découverte de ce qu »il vient de se passer sous vos yeux.

    On va déjà fair ele point sur ce qui a fonctionné donc. Dirigeons nous vers le « journal ».

    • Cliquez sur l’entrée (en bleu) du journal concernant votre dernier apprentissage de code IR.
    • Une fenêtre s’ouvre [capture 1].
    • Cliquez en haut à droite sur le symbole icône ha
    • Dans la nouvelle fenêtre qui s’ouvre [capture 2], on voit notement l’information à la sauce home-assistant mais ça va nous être utile pour la suite.
      Ce qu’il faut voir c’est « ID d’identité » et qui chez moi vaut : sensor.telecommande_ir_ir_code_to_send
    • Ce qui nous intéresse surtout c’est la dernière parti du code (formaté à la sauce HA) qui est  ir_code_to_send
      Vous aurez aussi observer que ce n’est pas moins que le titre de la fenêtre aussi…!
      Notez cette information quelque part.
    Journalisation d’un évènement
    Home-assistant – Détail journal commande MQTT
    On cible notre recherche
    MQTT – Informations Appareil

    Pour ce faire, toujours depuis la page d’intégration de votre boitier UFO-R11 :

    • Cliquez sur icône ha MQTT Info (PAS sur les icône ha)
    • Une fenêtre s’ouvre avec tout un tas de lignes.
    • On recherche ce que plus haut nous venions de trouver comme information à savoir : ir_code_to_send
    • Plusieurs choix (3) s’offrent à nous.
    • Celle qui nous intéresse comporte un paramètre important : /set
    MQTT – Informations de débogage
    • Vous venez de trouver le sujet (topic) !

    zigbee2mqtt/Télécommande IR/set

    Notez que la dernière partie (ir_code_to_send) va être utilisée un peu différemment…

    Mais vous venez aussi de voir le Nom Familier (Friendly_name) inscrit en clair dans la commande du sujet ! Donc si vous renommez votre appareil via Z2M, il y a de fortes chances pour que tous vos scénarios ne fonctionnent plus car l’appareil sera… différent.
    Je ferais certainement un autre article sur le sujet

    Approfondissons

    Toujours depuis la même fenêtre, depuis le sujet (topic) zigbee2mqtt/<Friendly Name>/set/ir_code_to_send

    • On ouvre le menu déroulant et…
    MQTT – Détail – Transmitted messages
    • … on retrouve exactement notre information à savoir le code IR que l’on a envoyé en guise de « payload » (message).

    Donc maintenant, nous avons identifié avec certitude le sujet (topic) ainsi que le message (payload).

    Via les outils de développeurs

    Partons maintenant dans la phase expérimentale pour ceux qui n’ont jamais mis les pieds dans la machine.

    • Allez dans Home-Assistant > Outils de développement > Menu « Actions ».
    • Faites une recherche / Saisir : « mqtt.publish« 

    Outils de développement – Action : mqtt.publish

    • [Optionnel] Vous pouvez décocher les 3 cases, ce ne sera pas important dans notre cas.
    • Dans le champs « Sujet » inscrire : zigbee2mqtt/Télécommande IR/set
    • Cocher la case « Charge ».
    • Dans le champs « Charge » inscrire : {"ir_code_to_send": "<votre_code_IR>"}
      Nous retrouvons l’information ir_code_to_send en tête de ligne oui…
    • Cliquez sur « Exécuter l’action » et normalement vous devriez constater que votre boitier UFO-R11 émet une petite diode bleu pour confirmer qu’elle émet un signal (donc votre commande est bonne)

    Si vous passez en affichage Yaml, le code complet est : 

    YAML

        data:
      topic: zigbee2mqtt/Télécommande IR/set
      payload: >-
        {"ir_code_to_send":
        "<votre_code_ir>"}
    action: mqtt.publish
       
                
                        
            

    Via MQTT

    Le principe reste le même, c’est juste que l’on passe par l’outil depuis l’intégration MQTT.

    • Home-Assistant > Paramètres > Appareils et services > MQTT
    • Cliquer sur le symbole icône ha 
    MQTT – Publication paquet
    • Dans le champs « Sujet » inscrire : zigbee2mqtt/Télécommande IR/set
    • Dans le champs « Charge utile » inscrire : {"ir_code_to_send": "<votre_code_ir>"}
    • Cliquez sur « Publier »
    • Votre boitier UFO-R11 doit réagir et allumer brièvement sa led bleu symbole d’exécution d’une commande.

    Plugin « SmartIR »

    Une histoire de formatage…

    Avant de parler de l’application en elle-même, il faut bien comprendre une chose.

    Les codes capturés lors de la phase d’apprentissage par notre boitier MOES UFO-R11 sont au format « Tuya » !
    Pour preuve, un simple passage vers ce convertisseur en ligne va nous aider à les confondre.

    L’original

    Ce plugin génial répertorie pas moins de 120 références de télécommandes déjà prises en charge ! Et cerise sur le gâteau, une tuile (climate) ergonomique fonctionnel et en Français est proposée pour vos dasboards !

    Le plugin de base (dépôt Git) semble toujours maintenu en activité mais il souffre d’un gros déficit de fonctions pourtant proposées par la communauté (PR) mais le propriétaire rechigne à les intégrer.
    C’est le cas de la prise en charge de notre boitier de renvoie IR référence MOES UFO-R11

    Parmi la liste des télécommandes prise en charge, j’ai trouvé la mienne AR-REB1E  !
    Raison pour laquelle je me suis vite intéressé à ce plugin.

    SmartIR – Liste des télécommandes

    Ce plugin est une petite pépite et sa petite documentation vous explique comment fonctionne tout ça, depuis l’installation, la configuration et même pour adapter des codes voir carrément pour créer votre propre template si votre modèle n’est pas prise en charge nativement.

    Pour en revenir au cas qui nous intéresse on peut voir que la référence de ma télécommande (il y en a 3… j’ai opté pour la dernière, plus complète) réagis avec un Controller « Broadlink« .
    A la lecture de certains sujet, le MOES UFO-R11 ne semble pas compatible en l’état. SmartIR a bien une pull-request (du 28/09/23 – toujours ouverte) en ce sens mais… rien ne bouge hélas. On apprend par ce message qu’une personne à décidée de faire un fork pour accélérer les choses.

    Personnellement, même si je préfère toujours les originaux, j’ai décidé de faire confiance à ce dernier fork de litinoveweedle qui a l’avantage de mieux gérer les messages via MQTT face à l’original.

    SmartIR (fork – litinoveweedle)

    Alors c’est un fork (copie) fidèle qui stipule bien la prise en charge de notre boitier MOES UFO-R11 / Z06.
    A une exception prête tout de même… pour rendre l’ensemble compatible, les codes « Broadlink » devront être formatés !

    L’information est écrite noire sur blanc (ou l’inverse selon votre affichage lol). Lien.
    Le problème identifié semble être dû à l’échappement des caractères " dans le fichier json contenant les codes des télécommandes. Un script a été proposé puis amélioré par une autre personne. Je vais me baser sur ce dernier.
    Je vais vous détailler ci-bas la procédure complète.

    Installation

    Tout est indiqué sur la page de présentation du dépôt.
    Rien de bien sorcier.

    • Avoir HACS
    • Ajouter le dépot
    • Installer depuis HACS ou depuis la page du dépôt via le bouton d’intégration rapide.
    • Plugin « File Editor » pour modifier le fichier configuration.yaml ci-dessous.

    Ensuite, en fonction de la télécommande que vous ajoutez, il y aura du code à saisir dans votre fichier configuration.yaml (home-assistant). Documentation.
    Dans le cas qui nous intéresse, j’ai saisie :

    YAML

        # Module HACS SmartIR de litinoveweedle
    climate:
      - platform: smartir
        name: Clim Salon
        unique_id: clim_salon
        device_code: 1293
        controller_data:
          controller_type: UFOR11
          mqtt_topic: "zigbee2mqtt/Télécommande IR/set"
    #    temperature_sensor: sensor.temperature
    #    humidity_sensor: sensor.humidity
    #    power_sensor: binary_sensor.ac_power
    #    power_sensor_restore_state: true   
                
                        
            
    • A vous d’adapter le code ci-dessus selon votre installation mais pour l’exemple ici, ce sera notre base de travail.

    J’ai volontairement commenté les 4 dernière lignes car je ne me sert pas de ces fonctions (pour le moment).
    Aussi, je préfère ne pas avoir à les inclure pour l’instant, restons simple.

    • Pensez à redémarrer HAOS pour la prise en compte du moindre changement dans le code.

    Conversion Broadlink -> Tuya

    Du coup, comme évoqué plus haut, en l’état, le script SmartIR ne fonctionnera pas car les le boitier MOES UFO-R11 ne fonctionne qu’avec des codes format « Tuya » alors que le script ne me fourni que des codes au format « Broadlink ».

    Donc nous allons formater le fichier 1293.json (correspond à ma télécommande) pour le rendre utilisable et ce, sans hack ni modification qui seraient perdues en cas de montée de version du logiciel. Ce dernier intégrant un dossier spécial prévu à cet effet smartir/custom_codes/climate.

    Le script

    Pré-requis : Utilisation du plugin : « Advanced SSH and Web Terminal« .

    Maintenant mettons nous au travail.

    • Dans la fenêtre du terminal, vérifier la présence de Python sur HAOS
      python3 --version Si ce dernier n’est pas installé, installez-le avec apt install python3
    • Dans fenêtre de terminal, collez cette commande :

    Shell – Linux

        # Crée l'arborescence si elle n’existe pas
    mkdir -p /config/scripts/broadlink_to_tuya
    
    # Télécharge le script depuis le lien brut de GitHub
    wget -O /config/scripts/broadlink_to_tuya/broadlink_to_tuya_converter.py \
    https://raw.githubusercontent.com/Gotcha26/broadlink_to_tuya/main/broadlink_to_tuya_converter.py
       
                
                        
            
    • Pour utiliser le script, la commande est la suivante :

    Shell – Linux

        python3 /config/scripts/broadlink_to_tuya/broadlink_to_tuya_converter.py 1293 --type climate --controller UFOR11
       
                
                        
            

    Explications :

    • On appel le script python qui se trouve installlé sur HAOS à :
      /config/scripts/broadlink_to_tuya/broadlink_to_tuya_converter.py
    • On va chercher le fichier d’origine qui nous sert de modèle.
      </config/custom_components/smartir/codes/climate/>1293<.json>
    • [Invisible] On va installer le résultat dans un dossier personnalisé qui résistera aux montées de versions et qui reprend exactement le même nom que l’original.
      </config/custom_components/smartir/custom_codes/climate/>1293<.json>
    • On change le controller pour le passer à UFOR11 afin de le rendre pleinement compatible.
    • On précise qu’il s’agit d’un code type pour « climate« 
    • > Le fichier de destination est donc directement placé dan le bon répertoire et ne sera pas effacé (pas de hack).
    • > Le script est prévu pour s’arrêter en cas de pépin, message d’information en cas d’échec ou de succès, informe avec un écrasement du fichier de destination, à été optimisé comparé à la version d’origine. Commande d’appel simplifiée aussi.
    • > Le script comporte un argument --help pour de plus amples explications.
    Utilisation

    Voilà enfin la FIN et la découverte du panneau de contrôle rêvé pour votre climatisation intégrée à Home-Assistant sans (plus) de bidouillage hasardeux, de codes à recopier, de personnalisation complexe…

    Appareil thermostat – Clim Salon

    En plus, admirez, c’est déjà en Français car c’est une carte standard « Thermostat« .
    Lorsque vous envoyez une commande, vous envoyé en réalité une combinaison de TOUS les petits réglages en même temps. Ce n’est pas juste un simple code pour une simple fonction. Bref.

    • Cela apparait donc en tant qu’Entité (« Clim Salon »).
    • Pour vos dashboards il faut utiliser la carte « Thermostat« .

    Futur

    Utiliser complétement les possibilités offerte par un vrai thermostat car actuellement, j’ai préféré zappé cette partie dans le code yaml du fichier de configuration, mon climatiseur ne supportant pas de thermostat externe…

    Bilan

    La recherche d’une solution a été longue et périlleuse mais au final je ne m’attendais sérieusement à bénéficier d’un solution aussi bonne ! Je vais avoir un thermostat et sans bidouillages !
    Bon ok la partie conversion du controleur ce n’était pas le plus évident…

  • HAOS – Samba Backup

    [toc]

    Pré-requis :

    • HAOS sur hyperviseur Proxmox VE.
    • Freebox Ultra avec un disque dur déjà monté et accessible.
    • Dossier déjà présent pour recevoir vos sauvegardes de HA.
    • Le partage réseau de votre disque est fait avec protocole Samba/CIFS v2.
    • Vous avez créer un user + mdp pour le partage en réseau.

    Introduction

    Avec la Freebox Ultra et son disque dur qualifié de « NAS », il est possible de s’en servir afin de recevoir des fichiers et d’y stocker, par exemple, les sauvegardes de son Home-Assistant.
    Mais le problème c’est que par défaut, HAOS ne permet pas de parcourir les sous-dossiers ! n est donc ici contraint de déposer les fichiers de sauvegarde directement à la racine du stockage… c’est bof, moyen et pas fini comme solution !
    A défaut de la prise en charge de l’arborescence et donc des sous-dossier, il faut trouver une autre solution pour aller héberger ses fichiers sur son « NAS » Freebox.

    L’addon est assez minimaliste, plus vraiment mis à jour depuis longtemps mais il a le mérite de fonctionner et faire parfaitement ce pourquoi il a été conçu : réaliser des sauvegardes de son home-assistant avec quelques options ainsi que la planification nécessaire pour être utile.
    Ce qui lui manque c’est une page de suivi, une remontée d’informations sur l’exécution de la tâche, envoi de notifications/mails.

    Bref, il ne lui manque pas grand chose pour être parfait. A noter que je suis également tombé sur un autre article avec d’autres solutions qui méritent d’être étudiées.

    Installation

    Pour installer cet addon, dirigez vous :

    1. Home-Assisant
    2. Paramètres
    3. Modules complémentaires
    4. Boutique des modules complémentaires (bouton en bas à droite)
    5. Menu « hamburger » (3 boutons en haut à gauche)
    6. Cliquez sur « Dépôts »
    7. Dans le champs équivoque, inscrivez l’adresse du dépôt correspondante :
      https://github.com/thomasmauerer/hassio-addons
    8. Cliquez sur « Ajouter »
    9. Fermer
    • Dans le champs de recherche en haut de la page « Boutique des modules complémentaires » faites une recherche sur : Samba backup.
    • Vous devriez trouver l’addon à ajouter.
    Addon Samba Backup

    Configuration

    Dixit la documentation vous devriez assez facilement pouvoir paramétrer les différents champs selon votre cas.

    Config 1/2 Samba Backup
    Config 2/2 Samba Backup

    J’ai donc opté pour une sauvegarde complète tous les jours à 03h30 vers ma Freebox Ultra.
    Nom du volume partagé : Freebox_2To et sous dossiers jusqu’à Homelab\Backups\HAOS
    Je ne conserve aucune sauvegarde avec HAOS, seules des 14 derniers jours sont conservé sur le serveur Freebox.

    Bien évidement, après la configuration, ne vous reste plus qu’à démarrer le plugin, activer les options Lancer au démarrage et Chien de garde en cas d’interruption.

    Tests manuels

    Pour pouvoir vérifier la bonne exécution de la tâche dûment paramétré, vous pourriez simplement modifier l’heure de lancement mais il y a surtout un moyen plus élégant et plus… « hype » !

    Déclenchons manuellement l’exécution de la tâche.
    Ce n’est pas aussi simple que d’appuyer sur un simple bouton car ce bouton est… absent. Donc nous allons émuler son activation avec un tout petit peu de code. Cette information est aussi trouvée dans la documentation.
    Suivez le guide.

    • Home-Assistant
    • Menu « Outils de développement » en bas à gauche
    • Cliquez sur « Actions » sur le menu en haut
    • Dans le champs prévu, faites une recherche pour hassio.addon_stdin
    • Dans le champs « Modules complémentaire » sélectionnez : Samba Backup
    • Cliquez ensuite sur « Passer en mode Yaml »
      Le panneau s’ouvre laissant apparaître une zone pour saisir du code yaml.
    • Ajouter simplement la ligne « input: trigger » en respectant l’indentation.
      Doit ressembler à ceci :

    Yaml

        action: hassio.addon_stdin
    data:
      addon: 15d21743_samba_backup
      input: trigger   
                
                        
            
    • Enfin, il ne vous reste plus qu’à cliquer sur le bouton « EXÉCUTER L'ACTION« 
    • Fin, votre déclenchement manuel est effectif.
      Vous pouvez consulter le journal de l’addon et vérifier la présence de la sauvegarde dans le répertoire désigné.
    Déclenchement manuel via les outils de développement.
  • 3-2-1 : Sauvegardes

    [toc]

    Objectifs

    • Avoir une sauvegarde locale sur le poste de travail. (1)
    • Avoir une sauvegarde physiquement séparée sur un tout autre support de stockage. (2)
    • Avoir une sauvegarde sécurisée sur un service extérieur à votre habitation : service cloud. (3)

    Si réaliser un sauvegarde local sur son poste de travail (1) est généralement aisé et ne pose aucun soucis, il n’en va pas forcément de même dès lors que l’on souhaite un peu rassembler tout ce petit monde dans un même dossier accessible qui servira de « dossier de base » afin d’être plus facilement synchronisé vers vers d’autres supports (2)+(3).

    Du coup notre objectif consiste bien à :

    • Assurer le stockage vers 2 emplacements supplémentaire dont 1 dans le cloud.
    • Obtenir un retour par mail (optionnel).

    Stratégie

    1. Monter un dossier réseau depuis Proxmox (datacenter) accessible au serveur LXC comme à HAOS.
    2. Monter un serveur LXC rudimentaire (Debian) qui s’occupera d’héberger les services utiles à l’ensemble des opérations.
    3. Utiliser l’outil rclone pour Linux qui fait le lien pour synchroniser des dossiers avec un service cloud.
    4. Utiliser l’outil msmtp comme serveur SMTP afin d’envoyer des mails
    5. Programmer un outil maison (rclone_homelab) afin coordonner les instructions pour tout ces outils
    6. Avoir un rendu esthétique et synthétique de la synchronisation.
    7. Prévenir s’il y a un soucis dans processus. Chaque jour doit avoir à synchroniser des fichiers…

    Préparatifs

    Proxmox

    Étape 1 – Création du dossier partagé [Sous Proxmox]

    Mettez en place un dossier partagé depuis Proxmox qui recevra (notement) les sauvegardes automatiques de ce dernier mais aussi les futures sauvegardes de HAOS.

    1. Depuis votre nœud Proxmox, création physique du dossier :

    Shell – Linux

        mkdir -p /mnt/share/backup
       
                
                        
            
    1. Inscription/enregistrement/déclaration du montage :

    Shell – Linux

        echo "dir: homelab_backups
         path /mnt/share/backups
         content backup,vztmpl,iso
         shared 0" >> /etc/pve/storage.cfg
       
                
                        
            

    Explications :

    • dir: homelab_backups : Définit le type de stockage comme un répertoire et lui donne l’ID homelab_backups.
    • path /mnt/share/backups : Spécifie le chemin physique vers le répertoire.
    • content backup,vztmpl,iso : Définit le type de contenu que ce stockage peut contenir : sauvegardes, modèles de conteneurs et images ISO. Vous pourriez ne laisser que « backup ».
    • shared 0 : Indique que le stockage n’est pas partagé sur le réseau.
    • >> /etc/pve/storage.cfg : sortie vers le fichier de configuration.
    1. Vérifiez la configuration

    Après avoir ajouté ces lignes, vous pouvez vérifier que le fichier ait été correctement mis à jour en utilisant :

    Shell – Linux

        cat /etc/pve/storage.cfg
       
                
                        
            
    1. Recharger le service Proxmox :

    Pour que les modifications prennent effet, rechargez le service Proxmox :

    Shell – Linux

        systemctl restart pve-cluster
    systemctl restart pvedaemon
    
       
                
                        
            
    1. Vérifier dans l’interface web :

    Après avoir redémarré les services, connectez-vous à l’interface web de Proxmox et allez dans « Centre de données » puis dans « Stockage ». Vous devriez voir votre nouveau stockage homelab_backups listé.

    Stockages depuis le centre de données

    Étape 2 – Conteneur LXC dédié (105)

    Pour éviter de « polluer » l’instance Proxmox (le nœud) en installant des outils et en bidouillant quelques fichiers au risque de faire planter totalement votre installation (croyez moi j’ai dû formater 2 fois !), on va héberger et « isoler » nos outils via un conteneur LXC contenant simplement Debian.
    Ainsi, on évite de trop dénaturer le nœud Proxmox, on peut faire des sauvegarde avant chaque « chantier » et en cas de pépin ce n’est pas toute votre installation qui sera à jeter ! Vous aurez des sauvegardes et au pire, juste un conteneur à remonter.

    Une précision tout de même sur la sécurité, car le conteneur LXC devra être élevé avec un rang « privilégié » ce qui n’est pas sans risque sur la stabilité du nœud en cas de piratage/bidouillage profond.

    Le conteneur aura un ID de 105 et une adresse IP correspondante 192.168.0.105

    1. Installation d’un conteneur LXC Debian :

    Rien de bien sorcier, on va s’appuyer sur la puissance de déploiement d’un script prêt à l’emploi.

    Shell – Linux

        bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"   
                
                        
            

    Si vous préférez une autre méthode plus manuel, plus… et bah juste faites-le !

    1. Démarrez le conteneur si ce n’est pas déjà fait.

    Étape 3 – Sauvegarde de vérification

    Oui, déjà maintenant je vous recommande tout de suite de prendre l’habitude d’utiliser des sauvegardes car elles ne prennent vraiment pas longtemps à faire et à réinstaller et ça vous éviter de vous arrachez les cheveux.

    Ici ça va nous permettre de vérifier que tout fonctionne.

    1. Faites une sauvegarde vers le dossier fraichement créé pour l’occasion :

    Vous trouverez dans le menu « Sauvegarde » une zone (voir capture) permettant de sélectionner la destination de la sauvegarde. Vous devriez y trouver homelab_backups.

    Sauvegardes – Destination
    1. Votre sauvegarde apparait dans le dossier.
      Vous pouvez la consulter avec un logiciel tel que WinSCP.
      La sauvegarde se trouve dans un sous dossier nommé /dump.
      3 fichiers composent une sauvegarde :
      – .log (Ce sont juste les logs)
      – .tar.zst (C’est LE fichier compressé)
      – .notes (C’est le commentaire qui accompagne, bien pratique !)
    WinSCP – Sauvegardes

    A tout moment vous pouvez réaliser une sauvegarde. Encore une fois c’est simple, rapide et sécurisant !

    Étape 4 – Conteneur Privilégié

    1. Depuis le nœud Proxmox, vérification du status du conteneur 105 :

    Shell – Linux

        pct config 105 | grep unprivileged
       
                
                        
            

    Le retour sera certainement unprivileged: 0
    S’il est à 1, ne rien faire et passer l’étape suivante.

    1. Pour modifier ce rôle, édition du fichier :

    Shell – Linux

        nano /etc/pve/lxc/105.conf
       
                
                        
            

    Trouver la ligne correspondante et modifier la valeur de 0 à 1.

    1. Redémarrer le conteneur :

    Shell – Linux

        pct reboot 105
       
                
                        
            

    Étape 5 – Création du dossier partagé (bis)

    Ici on va s’attarder sur le sous dossier qui servira plus tard pour HAOS.

    1. Depuis le nœud Proxmox (pas dans le conteneur) :

    Shell – Linux

        mkdir -p /mnt/share/backups/haos
       
                
                        
            
    1. Vérifier les permissions :

    Shell – Linux

        ls -ld /mnt/share/backups /mnt/share/backups/haos
       
                
                        
            
    1. Vous devriez obtenir quelque chose de similaire à :
    drwxr-xr-x 3 root root 4096 ... /mnt/share/backups
    drwxr-xr-x 2 root root 4096 ... /mnt/share/backups/haos

    Étape 6 – Monter le dossier pour le conteneur 105

    Pour que le conteneur LXC 105 puisse accéder au dossier « backups » précédemment créé, il faut lui donner le chemin. C’est ce que l’on appel « monter un dossier ».

    1. Depuis le nœud Proxmox, éditez la conf du conteneur 105 :

    Shell – Linux

        nano /etc/pve/lxc/105.conf
       
                
                        
            
    1. Ajouter cette ligne à la fin :

    Shell – Linux

        mp0: /mnt/share/backups,mp=/srv/backups
    
       
                
                        
            

    Explications :

    • mp0 « Montage Point #0 » Si vous aviez déjà d’autres points de montage, mettez simplement le numéro qui suit.
    • /mnt/share/backups est le chemin du partage.
    • mp=/srv/backups indique que ce partage (point de montage) doit être monté dans…
    1. Redémarrer le conteneur :

    Shell – Linux

        pct reboot 105
       
                
                        
            
    1. Depuis le conteneur LXC, vérifier :

    Shell – Linux

        ls /srv/backups
    ls /srv/backups/haos
       
                
                        
            

    Vous devriez voir vos dossiers monté correctement.

    Étape 7 – Installation Samba

    L’outil (protocole) Samba va gérer le partage SMB/CIFS, nécessaire dans le cadre d’un partage de dossiers sur votre réseau. C’est pratique pour accéder à des dossiers directement depuis Windows Explorer ou aussi pour l’utilisation plus tard de la Freebox Ultra. En interne (Proxmox) ca va nous permettre d’héberger les fichiers de HAOS directement dans le bon dossier.

    Proxmox, au niveau du « Centre de données », ne permet pas que l’on puisse accéder à ses entrailles nativement. Donc on ne peut pas accéder au moindre fichier comme ça aussi facilement.
    C’est la raison pour laquelle nous devons en passer par Samba qui sera hébergé sur le conteneur LXC (Debian) afin d’isoler au mieux toute l’infrastructure. C’est via ce dernier que l’on va transférer les fichiers provenant de HAOS (via le protocole SMB) vers le « Centre de données ».

    HAOS ne permet le stockage réseau que via SMB/CIFS ou NFS. Le plus simple étant SMB (Samba). Le sauvegardes transiteront par Debian pour être stockées réellement au niveau du centre de données donc à la base de Proxmox à coté des sauvegardes régulières de ce dernier.

    Le serveur Debian (conteneur LXC ID:105) sert juste de passerelle et d’hébergeur pour les outils.

    Installation de Samba dans le conteneur
    1. Depuis le nœud Proxmox  se connecter au conteneur 105 :

    Shell – Linux

        pct enter 105
       
                
                        
            
    1. Installer l’outil (après une petite MAJ) :

    Shell – Linux

        apt install -y samba
    
       
                
                        
            
    1. Vérification de l’état :

    Shell – Linux

        systemctl status smbd
       
                
                        
            

    Vous devriez trouver une ligne verte avec la mention Active: active (running)

    Configuration de Samba (2 partages)

    Il est impératif et nécessaire de configurer 2 partages bien que celui de HAOS soit un sous-dossier direct du premier (Proxmox_backups). Pourquoi ? Parce que HAOS ne gère pas les sous-dossier ! Il lui faut directement un nom de dossier final et direct à atteindre. Donc nous sommes obligé de configurer le dossier parent (1) et le dossier enfant (2).

    1 – /mnt/share/backups             < va servir pour les sauvegardes de Proxmox puisque ce dernier va disposer de son propre sous dossier /dump
    2 –/mnt/share/backups/haos     < va servir pour les sauvegardes de HAOS.

    1. Depuis le conteneur LXC, sauvegarde préalable du fichier de configuration :

    Shell – Linux

        cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
       
                
                        
            
    1. Édition du fichier :

    Shell – Linux

        nano /etc/samba/smb.conf
       
                
                        
            
    1. Ajoute à la fin du fichier les deux partages suivants :

    Shell – Linux

        [backups]
       path = /srv/backups
       browseable = yes
       writable = yes
       guest ok = no
       valid users = pve01
       create mask = 0664
       directory mask = 0775
    
    [haos]
       path = /srv/backups/haos
       browseable = yes
       writable = yes
       guest ok = no
       valid users = pve01
       create mask = 0664
       directory mask = 0775
       
                
                        
            
    Redémarrer Samba et vérifier
    1. Toujours depuis le conteneur LXC :

    Shell – Linux

        systemctl restart smbd
    systemctl status smbd --no-pager
       
                
                        
            

    Vérifier qu’il n’y ait pas d’erreur.

    Ajouter un nouvel utilisateur
    • Depuis le conteneur, il faut commencer par le déclarer auprès du système :

    Shell – Linux

        adduser pve01   
                
                        
            

    Il vous sera demandé de définir un mot de passe que l’on souhaite identique au nom user, à savoir pve01.

    Malheureusement, Debian va le rejetter. A la question Try again? [y/N] faites N.
    Compléter le reste des information par… rien, laissez vide.

    • Ensuite, on peut l’inclure dans le configuration de Samba :

    Shell – Linux

        smbpasswd -a pve01   
                
                        
            

    Vous serrez invité à définir son mot de passe. Ici nous allons définir ce mot de passe identique à l’user, soit : pve01.

    Automatiser les permissions
    1. Dans le conteneur :

    Shell – Linux

        chown -R pve01:pve01 /srv/backups
    chmod -R 775 /srv/backups
    
       
                
                        
            
    Tester depuis Windows
    1. Ouvrez l’explorateur de fichiers et entrez dans la barre d’adresse :

    Shell – Linux

        \\192.168.0.105
       
                
                        
            

    La première connexion est un peu longue.
    Windows va vous demander le couple identifiant + mot de passe que nous avons défini chacun à pve01.

    Vous devriez voir les deux partages :

    • backups
    • haos

    Testez l’écriture en créant un fichier texte.
    Vous pouvez aussi tester la lecture en copier la copie de sauvegarde que nous avons faite à l’étape 3.

    Étape 8 – Installer Git

    Pour la suite, nous allons avoir besoin d’utiliser la fonction git qui n’est pas installée par défaut.
    Cette fonction permettra de récupérer des dépôts distant depuis Github, de faire des mises à jour des scripts ainsi téléchargés etc.

    • Vérifiez si git n’est pas déjà installé :

    Shell – Linux

        git --version
    
       
                
                        
            

    Si rien ne s’affiche ou que vous recevez une erreur c’est qu’il faut installer le paquet git.

    • Installer git :

    Shell – Linux

        apt install git -y
       
                
                        
            

    Proxmox – Sauvegardes

    Maintenant que nous avons un dossier dédié aux sauvegardes, identifié et partagé, nous allons nous ne servir pour y loger les sauvegardes que nous allons configurer.

    • Centre de données > Sauvegarde > Ajouter
    Proxmox – Ajouter des sauvegardes
    • Programmez selon vos propres règles. L’essentiel étant que le cycle des sauvegardes automatique soit terminé avant de lancer la synchronisation.
    Proxmox – Mes sauvegardes

    HAOS – Sauvegardes

    Je ne fais que des sauvegardes « légères » pour gagner en temps et en place car le reste est moins critique et cas de gros coup dur, une sauvegarde complète de la Machine Virtuelle est réalisée par Proxmox chez moi tous les dimanche matin. Pas plus pour éviter de saturer les espaces de stockage.

    Étape 1 – Configuration dossier réseau HAOS

    1. Dans Home Assistant → Paramètres → Système → Stockage → Ajouter un stockage réseau

    HAOS – Ajouter un stockage réseau

    Ne pas oublier le couple Identifiant + Mot de passe tout les 2 valent pve01.

    1. Ajouter ce nouvel emplacement dans options des sauvegardes.
      Home Assistant → Paramètres → Système → Sauvegardes → Configuration et historique
    HAOS – Emplacements de stockage

    Étape 2 – Faites une sauvegarde

    1. Faites une sauvegarde pour vérifier qu’il n’y a pas d’erreur et que le processus va jusqu’à son terme.
    2. Vous récupérez la sauvegarde (tels que configuré ci-dessus) à la fois :
      1. Localement dans HAOS, /backup
      2. Sur le réseau via SMB à l’adresse \\192.168.0.105\backups\haos
      3. Via SFTP à l’adresse /mnt/share/backups/haos

    Outil : rclone

    L’interface avec le service cloud

    Nous allons utiliser cet outil, véritable couteau Suisse de la gestion de synchronisation des fichiers avec Linux. Sont gros intérêt ici c’est qu’il permet de connecter facilement un disque local (réseau) à un service de cloud. Il possède des configuration pour 63 services !!

    Dans mon cas, je vais utiliser mon compte Microsoft Onedrive mais vous pourriez appliquer la méthode pour Google etc.

    Étape 1 – Pré-requis

    Accès root

    • Depuis le noeud Proxmox, connectez-vous au conteneur en root :

    Shell – Linux

        pct enter 105
    
       
                
                        
            
    • Depuis le conteneur LXC 105, créer un dossier temporaire de travail :

    Shell – Linux

        mkdir -p /mnt/tmp_rclone
       
                
                        
            

    Étape 2 – Installation de rclone

    Installer les dépendances

    Shell – Linux

        apt install -y curl unzip
       
                
                        
            

    Télécharger le script d’installation officiel

    Shell – Linux

        curl https://rclone.org/install.sh | bash
       
                
                        
            

    Vérification de l’installation

    Shell – Linux

        rclone version
       
                
                        
            

    Vous devriez voir une sortie du type :

    rclone v1.xx.x
    - os/type: linux
    - os/arch: amd64
    - go/version: go1.xx
    - ...

    Étape 3 – Configuration initiale de rclone

    Créer le répertoire de configuration

    Shell – Linux

        mkdir -p /root/.config/rclone
       
                
                        
            

    (Ce répertoire est utilisé par défaut par rclone pour stocker la config dans /root/.config/rclone/rclone.conf)

    Installation parallèle

    Une installation de l’outil rclone en parallèle du LXC est nécessaire car lors du processus de dialogue entre l’outil et le service cloud (Microsoft OneDrive) l’utilisation d’un navigateur web est obligatoire.
    Mon conteneur LXC 105 étant dépourvu de moyen graphique, nous allons utiliser rclone pour Windows.

    L’idée c’est d’obtenir un token via Windows afin de la transmettre à notre instance dans le conteneur LXC.

    Installation de rclone (Windows)

    Pour installer l’outil rclone sur Windows, suivez cet article :

    https://julien-moreau.fr/2025/08/03/installer-rclone-sur-windows/

    > Tutoriel vidéo de référence

    Youtube.

    Lancer l’assistant interactif de configuration (Linux / PowerShell)

    Shell – Linux

        rclone config
       
                
                        
            

    Vous verrez des options comme :

    Shell – Linux

        n) New remote
    s) Set configuration password
    q) Quit config
       
                
                        
            

    Ajouter un remote

    Choisir n pour « new remote », donnez-lui un nom (ex : onedrive_machin, gdrive_truc, dropbox_bidule, etc.), puis choisir le type de service.

    Vous pouvez dès maintenant en configurer qu’un seul (OneDrive par exemple), puis le système vous permettra d’en ajouter d’autres ultérieurement, très simplement.

    • Ensuite, répondez aux questions suivantes :
    1. N -> New remote
    2. onedrive_<un_nom> -> New remote name
    3. 38 -> Microsoft OneDrive
    4. <vide> -> client_id
    5. <vide> -> client_secret
    6. 1 -> Microsoft Cloud Global (global)
    7. <vide> -> tenant
    8. N -> Advanced config
    Linux
    1. N -> Use web browser

    Vous allez poursuivre sur Windows jusqu’à obtention du token à transmettre ici.

    Windows
    1. Y -> Use web browser
    2. Une nouvelle fenêtre dans votre navigateur internet doit s’ouvrir où Microsoft OneDrive vous invite à autoriser l’outil rclone à accéder à votre compte. Il faut accépter.
    Microsoft OneDrive – Accès
    1. ne page laconique blanche vous informe de la bonne prise en compte.
    Microsoft OneDrive – Succès
    1. De retour sur la fenêtre de prompt, le script nous demande quel type de connexion allons nous établir.
      Répondre 1.
    2. Le script nous propose une liste de… propositions (?)
      J’ai répondu par défaut avec le choix 1.
    3. Found drive « root » of type « personal »
      Le script nous informe avoir trouvé la racine de notre compte OneDrive et nous donne le lien cliquable pour vérifier si c’est bon.
      Dans l’affirmative, répondre Y.
    4. Le script affiche le token ainsi que diverses informations et nous demande si nous sommes toujours d’accord pour les inscrire en lien avec notre compte.
      COPIEZ BIEN CE TOKEN !!! Tout ce qu’il y a entre les crochets. (surlignez-clic droit)
      Répondre Y.
    5. Enfin, le script revient à son « menu » et vous pouvez ainsi quitter avec la touche Q.

    La configuration est ainsi enregistré sur votre Windows. Vous pouvez la laisser ou la supprimer en rappeler la commande rclone config > delete.

    Retour sur Linux

    Vous avez copié le token à l’étape 15 (Windows). Collez-le dans la fenêtre qui l’attend, puis, suivez les même étapes que pour Windows afin d’enregistrer la configuration dans le conteneur LXC.
    Le token est une longue suite de caractère en incluant les crochets.

    Étape 4 – Emplacement du fichier de config

    Vérifier l’existence du fichier

    Shell – Linux

        cat /root/.config/rclone/rclone.conf
       
                
                        
            

    Vous devriez voir une structure du type :

    Shell – Linux

        [onedrive]
    type = onedrive
    token = {...}
    drive_id = ...
    drive_type = ...
       
                
                        
            

    Étape 5 – Ajouter d’autres services (plus tard)

    • Vous pourrez par la suite (plus tard) toujours relancer la commande rclone config et ajouter d’autres services (ngdrive, dropbox, etc.).
      Chaque service sera ajouté comme un nouveau bloc [remote] dans le fichier rclone.conf.

    Étape 6 – Commandes de vérification

    Lister les remotes configurés :

    Shell – Linux

        rclone listremotes
       
                
                        
            

    Exemple :

    Shell – Linux

        onedrive:
    gdrive:
    
       
                
                        
            

     Tester la connexion à un remote (exemple pour OneDrive)

    Shell – Linux

        rclone lsd onedrive<un_nom>:
       
                
                        
            

    Cela liste les dossiers à la racine de votre OneDrive.

    Outil : msmtp

    Notification par email

    Pour être averti par email, que ce soit en cas de problème lors de copie des fichier vers votre cloud ou tout simplement pour conserver un œil sur l’exécution de la tâche cron, voici comment procéder.
    Le script rclone_homelab est déjà pré-paramétré pour fonctionner avec autre application msmtp.

    msmtp n’est autre qu’un service d’envoi de mail par SMTP. Il permet d’enregistrer plusieurs profiles.
    Nous allons en configurer qu’un seul.

    • Dans le conteneur LXC :

    Shell – Linux

        apt install msmtp msmtp-mta -y
       
                
                        
            

    A la question si on souhaite installer AppArmor j’ai répondu « Non ». Si je rencontre des problème on avisera.

    • On va créer le fichier de configuration du service msmtp

    Shell – Linux

        nano /etc/msmtprc
       
                
                        
            
    • On va le configurer afin que le serveur mail par défaut soit une adresse gmail.

    Shell – Linux

        defaults
    auth           on
    tls            on
    tls_trust_file /etc/ssl/certs/ca-certificates.crt
    logfile        /var/log/msmtp.log
    
    account        gmail_spambiengentil
    host           smtp.gmail.com
    port           587
    from           spambiengentil at gmail.com
    user           spambiengentil at gmail.com
    password       wqjjnjexsxsrzmka
    
    account default : gmail_spambiengentil   
                
                        
            

    Shell – Linux

        defaults
    auth           on
    tls            on
    tls_trust_file /etc/ssl/certs/ca-certificates.crt
    logfile        /var/log/msmtp.log
    
    account        gmail1
    host           smtp.gmail.com
    port           587
    from           ma_super_adresse_mail_Gmail
    user           ma_super_adresse_mail_Gmail
    password       ton-mot-de-passe-ou-app-password
    
    account default : gmail1
       
                
                        
            

    💡 Il vous faudra un mot de passe d’application (sans les espaces) avec un compte Gmail disposant du 2FA.

    Plusieurs comptes peuvent être définis mais un seul aura la qualité du « default ».

    • Protéger le fichier.

    Shell – Linux

        chmod 600 /etc/msmtprc   
                
                        
            
    • Tester le configuration :

    Shell – Linux

        echo "Test email" | msmtp <ma_super_adresse_at_mail.com>
       
                
                        
            

    Outil : rclone_homelab

    Script maison, coordinateur

    Le script pour rclone (rclone_homelab) va être le fichier exécutable qui va effectuer/coordonner les actions. C’est l’élément clé et le plus complexe.

    Il peut-être exécuté manuellement ou automatiquement via une tâche cron.
    Ce script est le pivot qui va gérer vos jobs, lancer rclone avec les options qu’il faut ainsi que la notification par email.

    Chaque outil étant indépendant, il est nécessaire de les avoir configurés AVANT d’exécuter rclone_homelab.

    Toutes les instructions relatives à ce script se trouvent sur la page Github dédiée au projet.

    Outil : Cron tab

    Exécution automatique

    Pour automatiser une exécution ou une tâche, nous utiliseront l’utilitaire Cron. Très simple à mettre en œuvre. Ce la tâche qui sera répétée selon un planning établi.

    • Édite la crontab root dans le conteneur LXC :

    Shell – Linux

        crontab -e
       
                
                        
            
    • Choisir l’option 1.
    • Ajoutez ceci pour une exécution journalière à 03h30 :

    Shell – Linux

        MAILTO=""
    
    0 4 * * * /bin/bash /opt/rclone_homelab/rclone_sync_main.sh --auto --mailto=quelleheureestilsvp at gmail.com; --dry-run >> /var/log/rclone_cron.log 2>&1   
                
                        
            

    Vérification du log généré par cron :

    Shell – Linux

        tail -n 50 /var/log/syslog | grep CRON   
                
                        
            

    Shell – Linux

        tail -f /var/log/rclone_cron.log
       
                
                        
            

    Shell – Linux

        30 3 * * * /opt/rclone_homelab/rclone_sync_main.sh --auto --mailto=<ma_super_adresse at email.com> /var/log/rclone_sync_cron_log.txt 2>&1   
                
                        
            
    • Fermer, enregistrer, valider.

    Pour information, chaque astérisque représente une unité de temps, dans l’ordre suivant : 

      • Minute (0 – 59)
      • Heure (0 – 23)
      • Jour du mois (1 – 31)
      • Mois (1 – 12)
      • Jour de la semaine (0 – 7, où 0 et 7 représentent dimanche)

    J’ai rajouté des options « communes » afin que aillez un exemple complet. Encore une fois, lisez la documentation fournie par le script rclone_homelab.

    Un fichier journal (log) est aussi créé via /var/log/rclone_sync_cron_log.txt 2>&1 afin de journaliser l’exécution de la tâche Cron.
    Pour consulter le log, utiliser la commande grep CRON /var/log/syslog

    Freebox Ultra

    Bien, voilà un point assez délicat car si la Freebox Ultra est présentée comme un « NAS » avec un disque dur, ce n’est en réalité qu’un pastiche !
    Au mieux c’est un disque dur réseau aux fonctions limitées, au pire c’est… un disque dur de stockage sur un réseau aux fonctions limitées ^^

    Étape 1 – Préparatifs

    Coté Freebox

    Activer le partage de fichiers

    Assurez-vous que le partage de fichiers est bien activé coté Freebox.

    • Freebox OS > Paramètres de la Freebox > Mode avancé > Partage Windows.
    • Il est toujours mieux d’utiliser un couple Utilisateur / Mode de passe.

    Freebox OS – Partage de fichiers

    Préparer un dossier de stockage

    Ce dossier sera un miroir ce qui veut dire qu’il sera comme un reflet. Donc il y a un risque de suppression. Aussi, ne mélangez pas ce dossier avec des sous-dossiers et/ou contenu autres que ceux qui font l’objet de la sauvegarde.

    • Freebox OS >Explorateur de fichiers > « Votre_disque_dur » > « Votre_chemin/vers/le_dossier »
    • Repérez le nom depuis la barre d’adresse du style ici : /Freebox_2To/Homelab_backups

    Freebox OS – Arborescence

    Coté Debian LXC

    ✍️ Toutes les commandes sont exécutées depuis le terminal Shell (console) à la racine root@debian

    • S’assurer que le paquet cifs-utils est installé :

    Shell – Linux

        dpkg -l | grep cifs-utils
       
                
                        
            

    Si rien ne vous est retourné, il faut installer le paquet via :

    Shell – Linux

        apt install cifs-utils -y
       
                
                        
            

    Etape 2 : Configurer un nouveau remote rclone

    C’est là que l’on mesure l’importance d’avoir un outil tel que rclone qui permet de configurer plusieurs remotes indépendamment.

    • Nous allons ici en ajouter un nouveau via l’outil de configuration inclus dans rclone :

    Shell – Linux

        rclone config
       
                
                        
            

    Étapes par étapes :

    1. N > New remote
    2. Nom :  Ma_Freebox_Ultra
    3. Storage : 49 > SMB / CIFS (smb)
    4. host : 192.168.0.254
    5. user : <votre_user_smb>
    6. port : 445
    7. Password : y
    8. password : <votre_password_smb>
    9. confirm : <votre_password_smb>
    10. domain : <laisser_vide_par_défaut>
    11. spn : <laisser_vide_par_défaut>
    12. use_kerberos : <laisser_vide_par_défaut>
    13. advanced config : n
    14. keep : y
    15. fin : q

    Là, votre remote porte le nom de Ma_Freebox_Ultra

    Shell – Linux

        [Ma_Freebox_Ultra]
    type = smb
    host = 192.168.0.254
    user = freebox
    pass = aLGRku-eLgMtt8bAow7WVWpTOq2DoOU
    port = 445   
                
                        
            

    Etape 3 : Inclure le job

    Maintenant que le remote est prêt, on va inscrire poursuivre de configurer notre job (liste des tâches) en précisant notement les dossiers <source> et <distant>.

    • Ajouter un nouveau job à la suite de notre liste :

    Shell – Linux

        nano /opt/rclone_homelab/rclone_sync_jobs.txt
       
                
                        
            

    Ajouter le job comme tel (en suivant mon exemple) :

    Shell – Linux

        /srv/backups|Ma_Freebox_Ultra:/Freebox_2To/Homelab/Backups   
                
                        
            

    Toujours selon le modèle : <source>|<remote>:<destination>

    Enregistrez, quittez.

    Bilan

    • Nous avons vu comment créer un dossier partagé sous Proxmox accessible entre autre à :
      • Conteneur privilégié (LXC) sous Debian
      • HAOS (VM)
    • Installer et configurer rclone pour :
      • Service cloud (Microsoft OneDrive)
      • Service d’envoi d’email
      • Script rclone_homelab pour la gestion global
      • Tâche cron pour la répétition du script à heure fixe
      • Ajouter un remote à rclone pour sauvegarder le dossier partagé de Proxmox vers un second support : « NAS » Freebox Ultra.

    rclone récupère donc les dossiers/fichiers issues des sauvegardes de Proxmox et HAOS pour les envoyer vers le cloud + Serveur Freebox Ultra, tâche répétée à heure fixe tous les jours avec l’envoi d’un rapport par email.

    Aides

    • Commande pour éditer le fichier de configuration de rclone :

    Shell – Linux

        nano ~/.config/rclone/rclone.conf
       
                
                        
            
    • Commande pour tester un remote : (toujours terminer avec le symbole « : »)

    Shell – Linux

        rclone lsd Ma_Freebox_Ultra:
       
                
                        
            

    Ou :

    Shell – Linux

        rclone tree Ma_Freebox_Ultra:
    
       
                
                        
            
    • En cas d’erreurs suite à des installation d’outils :

    Shell – Linux

        apt-get remove --purge man-db
    
       
                
                        
            

  • Installer rclone sur Windows

    Pour installer rclone sur Windows via PowerShell, vous pouvez suivre ces étapes :

    1. Ouvrir PowerShell : Vous pouvez ouvrir PowerShell en recherchant « PowerShell » dans le menu Démarrer et en sélectionnant « Windows PowerShell ».

    2. Télécharger rclone : Utilisez la commande suivante pour télécharger rclone. Cette commande utilise Invoke-WebRequest pour télécharger le fichier zip de rclone depuis le site officiel.

    PowerShell

        Invoke-WebRequest -Uri https://downloads.rclone.org/rclone-current-windows-amd64.zip -OutFile rclone-current-windows-amd64.zip   
                
                        
            
    1. Extraire le fichier zip : Utilisez PowerShell pour extraire le contenu du fichier zip téléchargé.

    PowerShell

        Expand-Archive -Path rclone-current-windows-amd64.zip -DestinationPath .   
                
                        
            
    1. Accéder au répertoire extrait : Déplacez-vous dans le répertoire où rclone a été extrait.

    PowerShell

        cd rclone-*-windows-amd64   
                
                        
            
    1. Installer rclone : Vous pouvez maintenant copier le binaire rclone dans un répertoire qui est dans votre variable d’environnement PATH, par exemple C:\Windows\System32.

    PowerShell

        Copy-Item rclone.exe C:\Windows\System32\   
                
                        
            
    1. Vérifier l’installation : Pour vérifier que rclone est installé correctement, vous pouvez exécuter la commande suivante :

    PowerShell

        rclone version   
                
                        
            

    Cela devrait afficher la version de rclone installée, confirmant que l’installation a réussi.

    Ces étapes devraient vous permettre d’installer et de configurer rclone sur votre système Windows via PowerShell.

  • Home Assistant – Le SSL

    [toc]

    Préambule

    Alors autant le dire tout de suite en préambule, je me me suis lancé dans une aventure folle et vous allez être les témoins de la chose !

    Le but est simple : Passer ma connexion en SSL pour améliorer ma sécurité, anticiper une possible exposition du serveur HA à internet, et être d’avantage conforme aux standards.

    Le hic, c’est que cette aventure se trouve être bien plus technique et coriace que ce que j’imaginais.

    Passer sa connexion en SSL alors que je suis (pour le moment) 100% local n’a pas trop de sens car le risque de piratage se trouve dans… dans votre foyer ou juste à coté : voisins.
    Certes, c’est possible… Mais le risque est bien moindre que les armées de bots sur internet qui scannent nuits et jours la moindre faiblesse de M. et Mme Michue !
    Donc le SSL en local, c’est overkil.

    Le réseau local est considéré comme sûre, c’est la raison pour laquelle certains mécanismes de sécurité sont levés et/ou n’ont pas de sens.

    Mais… c’est un bon challenge et ça va permettre de mettre en place certains systèmes qui serviront surtout plus tard. Donc je prends juste un peu d’avance en fait.

    Mise en situation – Illustration

    Imaginez deux machines, Alice et Bob, qui souhaitent communiquer de manière sécurisée sur un réseau domestique.

    1. Initiation de la communication : Alice, le client, souhaite envoyer une requête à Bob, le serveur. Cependant, au lieu de contacter Bob directement, elle envoie sa requête à un intermédiaire appelé Reverse Proxy. Ce Reverse Proxy agit comme un gardien, gérant les requêtes entrantes et les distribuant de manière efficace.

    2. Rôle du Reverse Proxy : Le Reverse Proxy reçoit la requête d’Alice. Il peut gérer plusieurs tâches, comme l’équilibrage de charge entre plusieurs serveurs, la mise en cache de contenu pour des réponses plus rapides, et surtout, il peut gérer le chiffrement SSL/TLS pour sécuriser les communications.

    3. Établissement de la connexion sécurisée : Pour sécuriser la communication, le Reverse Proxy utilise SSL/TLS. Alice envoie une demande de connexion sécurisée au Reverse Proxy. Le Reverse Proxy répond en envoyant son certificat numérique, qui a été émis par une Autorité de Certification (CA).

    4. Vérification du certificat : Alice vérifie le certificat numérique reçu. Ce certificat, émis par une CA de confiance, garantit que le Reverse Proxy est bien celui qu’il prétend être. Les CA sont des entités de confiance qui vérifient l’identité des serveurs et émettent des certificats pour le prouver.

    5. Chiffrement des données : Une fois le certificat vérifié, Alice et le Reverse Proxy établissent une connexion chiffrée en utilisant SSL/TLS. Toutes les données échangées entre Alice et le Reverse Proxy sont maintenant cryptées, assurant que même si quelqu’un interceptait les données, il ne pourrait pas les comprendre sans la clé de déchiffrement.

    6. Transmission des données : Le Reverse Proxy, après avoir reçu la requête chiffrée d’Alice, la déchiffre et la transmet à Bob, le serveur final. Bob traite la requête et envoie sa réponse au Reverse Proxy.

    7. Réponse sécurisée : Le Reverse Proxy reçoit la réponse de Bob, la chiffre à nouveau avec SSL/TLS, et l’envoie à Alice. Alice peut alors déchiffrer la réponse et obtenir les informations demandées de manière sécurisée.

    En résumé, le Reverse Proxy agit comme un intermédiaire sécurisé, utilisant SSL/TLS pour chiffrer les communications et des certificats émis par des CA pour vérifier l’identité des parties, assurant ainsi une communication sécurisée et efficace entre Alice et Bob.

    J’avais posée cette question à chat.mistral.ia :

    Est-ce que utiliser un reverse proxi (nginx proxy manager) est utile si notre serveur Proxmox n’est pas exposé publiquement sur internet ?

    Et puis à l’avenir, il y aura certainement quelques services qui seront ouverts à internet donc autant prendre le pas dès le début et éviter de bidouiller des certificats comme le suggère l’autre matou de ChatGPT….


    Point sur ma situation

    J’administre mon homelab relié à ma Freebox Ultra. Ce homelab sert d’hyperviseur Proxmox (192.168.0.11) lequel contient une VM pour Home-Assistant (192.168.0.100) mais aussi Pi-hole dans un conteneur LXC (192.168.0.101).

    • La connexion à home-assistant se fait pour le moment via les url :
      • http://192.168.0.11:8123
      • http://homeassistant.local:8123 (hostname)
    • Je n’utilise que mon PC (192.168.0.13) pour joindre Home-Assistant depuis un navigateur Firefox.
    • J’ai aussi mon téléphone portable Android (192.168.0.30) avec l’application officiel de HA.
    • Pour le moment tout est 100% local.
    • Dans le futur, d’autres terminaux se connecteront à HA.
    • Je passe par un VPN Wireguard intégré à ma Freebox pour joindre mon Home-Assistant au besoin depuis l’extérieur.
    • J’ai déjà paramétré un accès SSH pour faire fonctionner le SFTP et ainsi accéder aux fichiers de Home-Assistant.

    Résumé

    Auto-signer des certificats SSL et les incorporer à ses serveurs/sites/URL, ok a on sait faire et avec Windows en prime, le certificat du CA (organisme certificateur) est facile à prendre en compte.

    Mais là où c’est impossible, c’est avec Android (non root) dans le cadre d’une infrastructure 100% locale.

    Vous verrez comment trouver un compromis et comment mettre en place les différentes mesures nécessaire à mettre en oeuvre autour d’une sécurisation de votre connexion par protocole TLS/SSL.

    Android – SSL

    Le cas d’Android avec sa gestion scrict des certificats SSL est LE maillon important à prendre en considération lorsque l’on met en place une stratégie de se sécurisation entre clients/serveur.

    Parlons : protocoles SSL/TLS

    Préparons-nous à devoir faire un peu de paperasse… Accrochez vous car ce n’est forcément le plus facile et les pièges sont très nombreux. Je vous résume ci-dessous ce qui a fonctionné chez moi.

    Connexion non sécurisée (local)
    Installation de certificats SSL avec Nginx
    👉 TLS est l’évolution du SSL 👈
     

    Maintenant, il faut s’atteler aux certificats SSL/TLS pour venir… comme présenter ses papiers d’identité à un gendarme ^^
    Seulement, ces papiers, ce n’est pas tout le monde (non non) qui peut les obtenir. Il faut en passer par un organisme de certification, dénommé « CA« .

    Selon que notre site (adresse IP) se trouve accessible uniquement en local ou pas (www), le certificat ne sera pas le même car l’organisme de contrôle (CA) sera nécessairement différent.
    Pour des besoins uniquement limités et restreints en interne (développement, pré-production), un CA tel que mkcert sera suffisant car très permissif… A défaut d’une machine exposée sur internet (www) où l’exigence de sécurité et accrue et où mkcert est totalement décrédibilisé et non sécurisé. On lui préfèrera Let’s Encrypt (ou autres !) qui pour le coup, a besoin d’une ouverture vers l’extérieur pour fonctionner.

    Voici tout d’abord quelques notions à prendre en compte afin de comprendre ce que nous allons faire.

    L’art du compromis…

    • Ouvrir les ports de sa box pour laisser Let’s Encrypt (organisme CA reconnu par Android) : c’est comme ouvrir grand son portail et mettre un vigile juste devant la porte d’entrée. Pas sécurisé pour le reste des ouvertures et je ne suis même pas sûre que Let’s Encrypt certifie un nom de domaine .local (RFC 6762).
    • Le « challenge DNS » : c’est au prix d’un sous-domaine ou d’une dépendance à un tiers comme DuckDNS.org, CloudFlare ou tout autre organisme. Je perds mon adresse minimal bien sympa « homeassistant.local »
    • Faire cohabiter http (local) et https (distant) : c’est comme blinder sa porte d’entrée et laisser la petite porte de derrière ouverte avec les clé sur la serrure.
    • Ne rien faire et considérer le LAN comme étant une zone sûre : c’est faire l’autruche mais faute de solution à la hauteur, autant rester dans la simplicité (qui fonctionne !).
    • Ou alors… le meilleur de chaque solution :
      • Mettre en place un reverse proxi sur une url courte style homeassistant.local UNIQUEMENT pour le local.
        • Accès sécurisé : parfait mais exclue Android
        • Accès non sécurisé : on estime que le réseau LAN local = sûre donc pas besoin d’en faire des caisses.
      • Mettre en place un accès externe via
        • un challenge DNS
        • un VPN Wireguard ou ZeroTier.

    Une vidéo qui reprend ces différents points :

    Sécurisé sa connexion client/serveur

    Il n’y a pas 36 possibilités :

    1. Abandonner toute idée de sécurisé l’accès local via TLS/SSL (LAN = sécurisé)
    2. En passer par une ouverture des ports de sa box pour exposer son serveur afin de le consulter depuis n’importe où son serveur avec une connexion sécurisée. Mais c’est un risque important si on maîtrise mal ce que l’on fait !
    3. En passer par un tiers de confiance qui fera office de relais/tunnel.
    4. Ne faire confiance à personne mais avoir besoin que d’un Nom de Domaine pour la certification.

    On passe à la pratique : le certificat

    Vous décidez de sécuriser votre connexion.

    ATTENTION

    ✋🙅‍♂️🔥🛑🔞❌❗🚩

    Pour les utilisateurs d’Android, cette idée s’accompagne de limitations.

    Prennez-en connaissance avant !

    Android – SSL

    Le cas d’Android avec sa gestion scrict des certificats SSL est LE maillon important à prendre en considération lorsque l’on met en place une stratégie de se sécurisation entre clients/serveur.

    Comme mentionné précédemment, l’obtention d’un certificat peut se faire de 2 manières :

    1. Local, auto-signé avec son propre CA (incompatible Android).
      Les outils de développement tels que OpenSSl, mkcert, step-ca permettent d’obtenir facilement une chaine de certification mais cela ne fonctionne que pour un serveur accessible uniquement en local et hors Android.
    2. Distant, avec un organisme de certification reconnu.
      Le certificateur Let’s Encrypt (d’autres existent) nécessite un accès à un nom de domaine ou du moins à une zone DNS et donc une ouverture sur l’extérieur, plus délicat pour la sécurité.
      L’utilisation de certbot est alors indispensable.

    1/ LAN = sécurisé

    C’est bien souvent comme cela que ça se termine !
    On part du principe que les risques sont maîtrisés donc certaines solutions de sécurisation n’ont pas à être appliquées.

    Fin.

    2/ Ouvrir/redirection de ports de sa box

    Opération dans laquelle je ne vais pas aller.

    Il parait que c’est plus sûre car il n’y a pas de tiers qui rentre en ligne de compte mais c’est tout de même toucher à un point très stratégique de sa sécurité pour l’ensemble même de son réseau !

    3/ Service tier

    Puisque l’obtention d’un certificat TLS/SSL ne peut se faire que via une adresse IP publique (un serveur accessible à internet), nous devrons en passer l’intermédiaire d’un tiers qui lui va s’occuper de la partie « sécurisation » (CloudFlare) ou de simple prête-nom (DuckDNS.org). On parlera même de « challenge DNS« .

    • DuckDNS.org
      Fournis un sous-domaine.duckdns.org permettant d’avoir une adresse valide.
      Associé à un addon pour HA, ce moyen est populaire même si n’est pas le plus fiable.
    • Cloudflare
      Va ici servir de tunnel. Il faudra lui ajouter un nom de domaine que vous possédez déjà.

    Qu’est-ce qu’un « challenge DNS » ?

    Un challenge DNS consiste à prouver la propriété d’un domaine en ajoutant un enregistrement TXT temporaire dans la zone DNS, généralement **acme-challenge.<YOURDOMAIN>**, permettant à Let’s Encrypt de valider la possession du domaine.

    DuckDNS.org

    CloudFlare

    4/ Avoir son propre nom de domaine (NdD)

    • Avec un registar qui assure un renouvellement automatique du certificat (ex : OVH.com)
      La liste des registars (Organisme de délivrance des Nom de Domaines) compatibles avec Let’s Encrypt est consultable à ce lien.
    • Avec un registar qui ne permet pas le renouvellement automatique du certificat (ex: o2switch)
      Vous serrez obligé de créer manuellement votre certificat à l’aide de certbot et de le renouvellement manuellement tous les 3 mois.

    Service compatible

    OVH.com
    • Noms de sous-domaines illimités ChatGPT.
    • Vous pouvez suivre notement les informations contenues dans cette page :

    Configurer Home Assistant pour un accès externe avec un domaine OVH et Cloudflare

    Service non compatible

    O2switch.fr
    • Obtention du certificat SSL via Certbot (tâche cron non gérée sans API DNS cPanel).

    https://julien-moreau.fr/2025/07/28/ssl-outil-certbot/

    Résumé

    Pour la science, je m’y suis amusé et ça a fonctionné avec O2switch.fr. J’ai réussi à faire un certificat pour mon sous-domaine créé pour l’occasion et avec l’aide de ChatGPT j’ai pu certifier tout cela avec Let’s Encrypt via certbot et j’ai obtenu ce que je cherchais : un accès SSL mais via un NdD…

    Le problème, O2switch (cPanel) ne fourni aucune API ni méthode pour automatiser la modification manuelle d’information qu’exige le challenge DNS et du coup, il faut renouveler manuellement l’opération tous les 3 mois (durée de validée des certificats Let’s Encrypt).

    Petite anecdote :
    J’ai eu recours à certbot pour Windows (lien1) (lien2) et pour cela, il a fallu installer Python sur Windows (lien1) [via chat.mistral.ia] avant de se rendre compte qu’il suffisait d’installer certbot depuis le conteneur LXC de NPM !

    Pi-hole – Local DNS

    Si vous avez un serveur DNS tel que Pi-hole, apprenez à la configurer en fonction.

    https://julien-moreau.fr/2025/07/28/pihole-local-dns/

    NPN – Nginx Proxy Manager

    Dès lors que vous hébergez un serveur (dans un homelab ou autre) et que son accès est sécurisé par TLS/SSL, il faut mettre en place un reverse proxy qui lui va agir comme intermédiaire / serveur mandataire. C’est lui qui va redistribuer les ressources vers le serveur contacté avec plusieurs règles dont, la gestion des certificats TLS/SSL.

    https://julien-moreau.fr/2025/07/28/npm-nginx-proxy-manager/

    Installation du CA (Windows)

    En fonction de l’outil que vous avez employé pour auto-signer votre certificat SSL, vous devriez être en mesure de retrouver le certificat CA (celui pour l’autorité certificatrice de confiance) car c’est de lui dont il est question dans ce chapitre.

    Exécution

    Bien souvent il s’agit de simplement cliquer sur le fichier pour lancer son installation dans le magasin adéquat de Windows. Il doit être (normalement) ajouté systématiquement lors de la procédure d’obtention du certificat « serveur ».

    Pour information, le certificat CA (de l’organisme de certification de confiance) généré via mkcert se trouve dans :

    C:\Utilisateurs\Gotcha\mkcert\root.pem

    Sur Android

    Un article dévolue a été écrit pour ce point.

    https://julien-moreau.fr/2025/07/29/android-ssl/

    Tester

    En fonction de ce que vous avez fait, vous ne devriez plus besoin avoir de saisir l’adresse IP suivi du numéro de port, juste le nom de l’host.

    L’adresse http://192.168.0.100:8123 fonctionne toujours car on bypass tous les mécanismes mis en place. On interroge directement le serveur via son adresse IP ! Pi-hole ne peut rien faire car cette adressage n’est pas de son ressort. Unbound, pour lui, rien d’anormal (l’authenticité est direct). Quand au serveur reverse proxy Nginx il n’intercepte que les URL qu’on lui ont été programmées.
    Autrement dit, si on souhaite renforcer encore plus la sécurisation à l’accès de votre home-assistant, il faut rajouter une mesure drastique !

    HTTPS – homeassistant.local

    Dépannage

    Dans chaque chapitre, à chaque renvoie vers un article, ce dernier doit déjà contenir l’ensemble des informations nécessaire à la bonne compréhension et parfois même déjà une partie de « debugage ».

    Ci-après, quelques pistes.

    Erreur 502 :

    Vérifiez votre fichier configuration.yaml

    Erreur 400 :
    400: Bad Request

    Dialogue avec ChatGPT

    Vérifier certificats SSL, vérifier les URL, vérifier la configuration de NPM, forcer les en-têtes et du coté de HA, vérifier la présence du bloc :

    yaml

        http:
      ip_ban_enabled: true
      login_attempts_threshold: 5
      trusted_proxies:
        - 192.168.0.104 #Nginx
      use_x_forwarded_for: true   
                
                        
            

    Le bloc ci-après est juste là pour forcer la redirection mais aussi forcer les en-tête. Normalement vous n’en n’aurez pas besoin.

    cmd – Nginx

        # Redirige explicitement tout vers HTTPS (au cas où "Force SSL" échouerait)
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
    
    # Ajoute les entêtes de sécurité HTTPS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'self';" always;
       
                
                        
            
    Activer des logs de home-assistant :

    (Ils sont consultables ensuite dans /config/homa-assistant.log)

    yaml

        #Activer les debug-log de HA
    logger:
      default: info
      logs:
        aiohttp.access: debug
        homeassistant.components.http: debug
        homeassistant.components.http.forwarded: debug
       
                
                        
            
    Forcer les URL (HA)

    Le bloc homeassistant: avec internal_url et external_url permet à Home Assistant de savoir comment il est censé être contacté, en interne et en externe. Ces valeurs sont utilisées :

    • pour générer les liens dans les notifications (mobile, mail, etc.)
    • pour les intégrations qui envoient des callbacks à Home Assistant
    • pour déterminer quelle URL utiliser dans certaines automatisations

    Tu peux ajouter ce bloc uniquement si tu veux forcer Home Assistant à utiliser certaines URL, notamment si :

    • tu utilises Nginx Proxy Manager ou un autre reverse proxy
    • tu as une URL externe différente de l’URL locale
    • tu veux que les intégrations (comme Google Assistant, Nabucasa, etc.) utilisent la bonne URL

     
    Remarque utile :

    Si tu vas dans l’interface de Home Assistant :
    Paramètres → Paramètres généraux (Configuration → Paramètres système), tu peux aussi voir ou modifier les URLs internes/externes depuis l’UI.

    Mais si tu les définis dans configuration.yaml, ces champs deviennent grisés dans l’interface (priorité à la config YAML).

    yaml

        homeassistant:
      internal_url: "http://192.168.0.100:8123"
      external_url: "https://homeassistant.julien-moreau.fr"   
                
                        
            
    Securité

    Attention au faux sentiment de protection…

    Mes références :

    • HAFR Etape par étape mais avec un NdD
    • Novamostra (EN) Local, sans proxy, OpenSSL + Terminal, certificats sur le serveur.
    • ChatGPT, conversation complète sur le sujet.
    • Nviso Lab, module d’interception (root) des certificats. Profile Pro.
    • Shizuku, mais n’est pas efficace, ne va pas assez profondément dans la couche système.

  • Proxmox – hostname SSL local

    [toc]

    La problématique

    • Ne pas avoir à contacter votre serveur Proxmox VE via sont adresse IP suivi du numéro de son port.
    • Utiliser le hostname par défaut et déjà renseigné « proxmox.local ».
      Correspond au nœud du même nom.
    • Utilisation du reverse proxy NPM (Nginx)
    • Utilisation serveur DNS Pihole
    Proxmox – Nœud

    Pihole

    Rien de bien sorcier, il suffit d’inscrire le nom de notre hostmane (url) et d’indiquer l’adresse IP du reverse proxi NPM (Nginx) !

    • System > Settings > Local DNS Reccords
      • hostname proxmox.local
      • IP <IP_NPM>

    Proxmox – Certificats SSL

    Avant d’aller trop loin et de sa casser les dents sur cette fichue histoire de certificats SSL, sachez que Proxmox VE impose d’avoir une connexion chiffrées (SSL) pour fonctionner. Sans ça, vous n’iriez pas loin…

    Donc d’origine, Proxmox VE fourni sa propre chaine de confiance et vous aviez certainement ajouté une exception à votre navigateur préféré afin de faire fonctionner l’interface de Proxmox VE.
    L’exception est nécessaire car votre navigateur/système ne reconnait la l’origine de cet organisme de confiance (CA)…
    Toutes fois on peut voir que ce certificat (wildcards) couvre plusieurs nom DNS, dont celui qui nous intéresse dans le cadre du présent article : proxmox.local

    Informations certificat SSL proxmox.local

    Pour initier un connexion SSL il faut donc 3 choses :

    1. Certificat du CA
      Est installé sur la machine ou dans le magasin du navigateur. C’est la fameuse « exception » que l’on confirme pour pouvoir consulter des sites nom reconnu par défaut (et il y a une raison !).
    2. Certificat Serveur
      Est présenté au client lors de la connexion entre les parties. Il sera fourni par le proxy.
    3. La clé
      Accompagne le certificat serveur.

    Donc dans le cadre d’une connexion via un proxy comme c’est notre cas présentement, il nous faut soit :

    • Recréer tout une chaine de confiance.
    • Réemployer ce qui fonctionne déjà.

    Nous allons opter pour cette dernière option !
    Pourquoi ? Car le certificat CA est déjà installé puisque vous utilisez déjà certainement Proxmox VE via votre navigateur. Il nous reste donc à trouver les 2 autres fichiers…

    Où se trouvent les fichiers ?

    La réponse est donnée dans la documentation officielle. Celle là même qui indique comment configurer Nginx.

        /etc/pve/local/pve-ssl.pem;
        /etc/pve/local/pve-ssl.key;

    Voilà, vous savez où récupérer ces fichiers via votre logiciel SFTP pour les enregistrer sur votre disque dur avant de passer à la suite.

    NPM – Nginx

    SSL Certificates

    On va commencer par enregistrer les certificats SSL en bonne et due forme.

    • Onglet « Certificates SLL »
    • Cliquez « Add SSL Certificate » > Custom
    • Saisir un nom reconnaissable
    • Ajouter la clé dans le champs « Certificate Key »
      Il s’agit du fichier pve-ssl.key
    • Ajouter le certificat serveur « Certificate »
      Il s’agit du fichier pve-ssl.pem
    • Enregistrez. La pastille reste rouge, c’est normal, ce certificat n’est pas encore utilisé.

    Hosts

    Dernière étape de nos paramétrages, le configuration du host.

    • Ouvrez l’onglet »Hosts » > « Proxy hosts »
    • Cliquez sur « Add Proxy Host »

    Une petite fenêtre s’ouvre.

    Onglet « Details »
    • Dans le champs « Domain Names« 
      Donnez bien l’adresse « proxmox.local » et validez la saisie en appuyant sur la touche entrée.
    • Dans le champs « Scheme« 
      On ouvrira une connexion https
    • Dans le champs « Forward Hostanme / IP« 
      Saisir l’adresse <IP> de votre nœud Proxmox.
    • Dans le champs « Forward Port« 
    • Saisir le numéro de port, par défaut 8006
    • Cochez les options
      • Block Common Exploits
      • Websockets Support
    Onglet SSL
    • Dans le champs « SSL Certificate« 
      Sélectionnez le certificat que vous aviez ajouté précédemment.
    • Cochez les options :
      • Force SSL
      • HTTP/2 Support
    NPM – Host Details

    NPM – Host SSL

    Fin

    Voilà, normalement tout devrez fonctionner.
    Vous devrez « encore » ajouter une règle d’exception à votre navigateur pour accepter ce certificat pour établir la connexion.

    Ne pas hésitez à fermer/ouvrir et vider les caches de nos navigateur, redémarrer si besoin blablabla.

    Si vous obtenez une erreur 401 : No ticket après l’ouverture de votre panneau d’administration de Proxmox, cela signifie qu’il y a un soucis avec votre certificat SSL.

  • Proxmox – NPM – Error 1006

    Si vous venez de mettre ne place un hostname pour votre serveur Proxmox et que suite à cela vous rencontre une erreur au niveau de la console Shell mentionnant :

    undefined (Code : 1006)
    Proxmox – Error 1006

    Si en plus de cela que veniez tout juste ou récemment mettre en place une résolution de nom d’url grâce à un hostname via NPM (Nginx) alors la solution est toute trouvée !

    Dans le détail de votre « proxy host » sur NPM, veuillez à cocher la case « Websockets Support ».

    Proxmox – Websockets Support option

    Normalement c’est suffisant. Source.

    A noter que cette fonction est responsable aussi dans d’autres scripts/fonctions tel que Zigbee2MQTT !