Nouveau passionné domotique & sécurité - Bonjour à tous !

[Seb_IoT]

Bonjour à toute la communauté !  

Moi c'est Seb, je suis dans l'informatique et les réseaux depuis quelques années, et je mets enfin sérieusement les mains dans le cambouis de la domotique.

Je rejoins le forum car je suis en pleine phase d'apprentissage sur le standard KNX. J'ai longtemps bidouillé avec des solutions sans fil grand public, mais je veux passer à un système robuste et pérenne pour mon projet d'installation.

Mon petit "tic" professionnel, c'est la cybersécurité. Du coup, en abordant le KNX, je m'intéresse énormément à la façon dont on sécurise les accès distants, comment on isole le réseau domotique du réseau internet classique, et la gestion de KNX Secure. C'est fascinant de voir comment le monde du bâtiment et celui de l'IT se rejoignent !

J'ai déjà parcouru pas mal de vos anciens sujets (une vraie mine d'or, bravo aux contributeurs), mais je risque de vous embêter bientôt avec des questions un peu pointues sur la sécurisation des passerelles IP. 

Au plaisir d'échanger avec vous et d'apprendre de vos retours d'expérience !

[Ives]

Bonjour et bienvenue sur le forum.

Avec un superviseur comme Home Assistant (avec Nabu Casa ou autre système de tunnel), l'accès distant direct à la passerelle IP/KNX n'a aucun intérêt. Elle reste isolée sur le réseau local, invisible depuis Internet (aucun port d'ouvert). Seul le superviseur, via un tunnel sécurisé et authentifié, communique avec elle.
Le pilotage quotidien se fait via l'interface du superviseur. L'accès direct à la passerelle ne servirait qu'à une programmation ETS à distance, rarement nécessaire.

Le protocole KNX Secure est souvent superflu en maison individuelle en isolant les participants extérieurs (détecteurs, station météo) sur une ligne dédiée via un coupleur de ligne avec table de filtrage ; on empêche toute prise de contrôle du bus depuis l'extérieur de la maison.... et depuis l'intérieur de la maison, on peut supposer qu'une personne entrée par effraction aura autre chose à faire que de pirater le KNX !
On évite ainsi la complexité de gestion des clés de sécurité sans sacrifier la fiabilité.

Le KNX Secure reste alors une option réservée au tertiaire ou aux environnements à haut risque d'intrusion physique interne.

[Seb_IoT]

Bonjour Ives et merci beaucoup pour l'accueil et ces précisions !

C'est exactement le genre de retour d'expérience pragmatique que je venais chercher. C'est vrai que venant du monde IT (où l'on traque au quotidien les menaces pour la sécurité des données), j'ai le réflexe "Zero Trust" chevillé au corps et j'ai tendance à vouloir tout chiffrer par défaut (d'où mon focus initial sur KNX Secure).

Mais ton argument sur l'isolation physique via un coupleur de ligne et une table de filtrage pour les participants extérieurs est implacable. Ça fait parfaitement sens en résidentiel : pourquoi complexifier avec des clés de sécu si l'architecture réseau elle-même bloque le risque. Ça m'aide beaucoup à comprendre la "philosophie" KNX.

Pour l'accès distant, on est 100% en phase. Je prévois justement d'utiliser Home Assistant comme superviseur. L'idée est de passer par un tunnel sécurisé sans jamais ouvrir le moindre port de la box vers la passerelle IP. L'accès direct restera sagement en local pour les rares sessions ETS.. Et là après je pourrai faire le fier lol. En tout cas, merci derechef pour l'accueil.

[Ives]

Je prévois justement d'utiliser Home Assistant comme superviseur.

Quelques idées ici

[Seb_IoT]

Je prévois justement d'utiliser Home Assistant comme superviseur.

Quelques idées ici

Wahou... Je viens d'aller jeter un œil au fil. Ton dashboard est absolument impressionnant 
Le travail sur l'ergonomie, la gestion des pop-ups pour alléger l'interface et le rendu responsive, c'est du très haut niveau. Venant plutôt du monde du back-end et de la sécu, je suis souvent une bille absolue quand il s'agit de faire un "front-end" propre et intuitif. Voir une telle installation tourner de manière aussi fluide sous Home Assistant, ça laisse rêveur. J'ai vu que tu gérais aussi des automatisations poussées avec Node-RED en coulisses, ça me parle déjà plus !  
Je me mets ton topic en favori direct. Ça va me servir de bible pour la phase de création de mon interface, dès que j'aurai fini de consolider mes fondations réseau et mon infrastructure KNX de base.
Merci beaucoup pour le partage et pour tout le travail de documentation que tu as fait dessus !

[Ives]

J'ai vu que tu gérais aussi des automatisations poussées avec Node-RED en coulisses, ça me parle déjà plus !  

Je n'ai pas d'automatisations avec Node-Red mais seulement le relevé des index des divers compteurs et notamment le "tri" des index des 6 options tarifaires du TEMPO.



Ce n’est pas une obligation de passer par Node-RED, mais initialement je l’utilisais dans une VM Proxmox afin de conserver une certaine indépendance vis-à-vis de Home Assistant. Depuis, je suis toutefois revenu en arrière avec l’abandon de la virtualisation au profit de HAOS.

Il reste néanmoins un avantage à Node-RED : en cas de réorganisation des adresses de groupe, on conserve l’historique, contrairement à Home Assistant qui crée alors une nouvelle entité.

Plus généralement, dans une installation KNX, il est préférable de privilégier les automatisations directement réalisées dans un contrôleur logique évolué (ABA/S1.2.1, Gira, etc.). Cela permet de conserver les avantages fondamentaux du KNX : fiabilité, pérennité et autonomie de fonctionnement, sans dépendance à une box/NUC, à un cloud, au web ou à des mises à jour logicielles.

Home Assistant reste très intéressant pour des automatisations secondaires ou non critiques (notifications, scénarios de confort, supervision, etc.), mais il repose sur une infrastructure informatique plus sensible aux pannes, mises à jour ou problèmes matériels.

[Seb_IoT]

J'ai vu que tu gérais aussi des automatisations poussées avec Node-RED en coulisses, ça me parle déjà plus !  

Je n'ai pas d'automatisations avec Node-Red mais seulement le relevé des index des divers compteurs et notamment le "tri" des index des 6 options tarifaires du TEMPO.



Ce n’est pas une obligation de passer par Node-RED, mais initialement je l’utilisais dans une VM Proxmox afin de conserver une certaine indépendance vis-à-vis de Home Assistant. Depuis, je suis toutefois revenu en arrière avec l’abandon de la virtualisation au profit de HAOS.

Il reste néanmoins un avantage à Node-RED : en cas de réorganisation des adresses de groupe, on conserve l’historique, contrairement à Home Assistant qui crée alors une nouvelle entité.

Plus généralement, dans une installation KNX, il est préférable de privilégier les automatisations directement réalisées dans un contrôleur logique évolué (ABA/S1.2.1, Gira, etc.). Cela permet de conserver les avantages fondamentaux du KNX : fiabilité, pérennité et autonomie de fonctionnement, sans dépendance à une box/NUC, à un cloud, au web ou à des mises à jour logicielles.

Home Assistant reste très intéressant pour des automatisations secondaires ou non critiques (notifications, scénarios de confort, supervision, etc.), mais il repose sur une infrastructure informatique plus sensible aux pannes, mises à jour ou problèmes matériels.

Hello, super flow pour le TEMPO au passage ! Et bien vu l'astuce de Node-RED comme "tampon" pour conserver l'historique face aux caprices de Home Assistant. Sur le fond, on est 100% raccord. Dans mon jargon IT, c'est ce qu'on appelle éviter le "SPOF" (Single Point of Failure). Garder la supervision/confort sur HA, mais laisser le cœur critique (lumières, volets) 100% autonome sur le bus KNX, c'est la seule vraie façon d'avoir une architecture saine. Si le serveur HA crashe suite à une mise à jour, la maison doit continuer de tourner.  

C'est d'ailleurs cette robustesse industrielle qui me fait basculer sur KNX aujourd'hui. Merci pour ces conseils, ça valide exactement la direction que je voulais prendre pour mon projet. 

[richardpub]

si tu repart de zéro, il peut être intéressant de se pencher avec HA comme superviseur, sur la partie KNX de HA, car elle me semble plutôt complète pour créer les entités HA directement dans HA, à partir du module KNX dans Paramètres de HA.
La plus part d'entre nous ont créé leur entité KNX dans le Yaml de HA, et notre HA est stable actuellement et je ne crois pas que l'un d'entre nous soit passé par cette méthode.

[Ives]

Comme le montre cette video, sauf pour 3 catégories d'entités (light, switch et binary sensor) il faut encore passer par les fichiers yaml.

L'intégration KNX est actuellement dans une phase de transition ("en chantier") entre le tout-code (YAML) et le tout-automatique (UI).

Dans l'état actuel de l'intégration, il me semble que la meilleure approche est :

• l'import ETS du fichier knxproj pour le confort du diagnostic (évite l'obligation d'utiliser le moniteur de groupe d'ETS) ; il présente l'avantage d'afficher dans  le moniteur de bus de  Home Assistant, pas seulement la GA (1/2/30) mais sa désignation comme "Salon - Plafonnier - État".
  
• rester en YAML pour éviter une configuration fragmentée (moitié dans l'interface, moitié dans le code) et garder ainsi une vue d'ensemble cohérente (à noter qu'avec le copier/coller la création des fichiers yaml est assez rapide)
  

L'approche sera différente lorsque l'UI gèrera toutes les catégories d'objets...

Ce n'est que mon avis et je le partage ! 

[Seb_IoT]

si tu repart de zéro, il peut être intéressant de se pencher avec HA comme superviseur, sur la partie KNX de HA, car elle me semble plutôt complète pour créer les entités HA directement dans HA, à partir du module KNX dans Paramètres de HA.
La plus part d'entre nous ont créé leur entité KNX dans le Yaml de HA, et notre HA est stable actuellement et je ne crois pas que l'un d'entre nous soit passé par cette méthode.

Salut richardpub et merci du conseil ! C'est vrai qu'en partant d'une page blanche, la tentation de passer par l'interface graphique (UI) est forte pour se simplifier la vie.

[Seb_IoT]

Comme le montre cette video, sauf pour 3 catégories d'entités (light, switch et binary sensor) il faut encore passer par les fichiers yaml.

L'intégration KNX est actuellement dans une phase de transition ("en chantier") entre le tout-code (YAML) et le tout-automatique (UI).

Dans l'état actuel de l'intégration, il me semble que la meilleure approche est :

• l'import ETS du fichier knxproj pour le confort du diagnostic (évite l'obligation d'utiliser le moniteur de groupe d'ETS) ; il présente l'avantage d'afficher dans  le moniteur de bus de  Home Assistant, pas seulement la GA (1/2/30) mais sa désignation comme "Salon - Plafonnier - État".
  
• rester en YAML pour éviter une configuration fragmentée (moitié dans l'interface, moitié dans le code) et garder ainsi une vue d'ensemble cohérente (à noter qu'avec le copier/coller la création des fichiers yaml est assez rapide)
  

L'approche sera différente lorsque l'UI gèrera toutes les catégories d'objets...

Ce n'est que mon avis et je le partage ! 

Ives, ton argument résonne complètement avec mes "tocs" d'informaticien, et la vidéo de Torben Ledermann l'illustre à la perfection.

À la minute 13:52 si je ne me trompe pas, quand on le voit obligé de basculer sur Visual Studio Code Server pour configurer son volet roulant ("cover") dans son fichier `knx.yaml` car l'UI ne le gère pas, ça saute aux yeux. Dans l'IT, on déteste les configurations hybrides (une moitié cliquée dans l'interface et l'autre codée en dur).

C'est souvent un cauchemar pour le débogage à long terme. Le 100% YAML me rassure énormément : c'est ce qu'on appelle de l'"Infrastructure as Code". On peut faire du chercher/remplacer en masse, et surtout ça se sauvegarde et se versionne proprement (un petit backup sur un repo local et on dort tranquille).

Je vais donc suivre cette voie et rester sur le YAML en attendant que l'intégration UI gère vraiment tous les objets. D'ailleurs, l'import du `.knxproj` pour avoir les noms en clair directement dans le moniteur de bus HA dont tu parles, c'est une astuce en or massif !

Grand merci à tous les deux pour cet éclairage, ça m'évite de tomber dans mon premier piège d'architecture sur Home Assistant. 

[Ives]

Je vais donc suivre cette voie et rester sur le YAML en attendant que l'intégration UI gère vraiment tous les objets.

Dans ce cas il est préférable de créer dans config un dossier knx puis, dans ce dossier, un fichier yaml par type d'appareil :



sans oublier d'ajouter cette ligne dans le configuration.yaml

knx: !include_dir_merge_named knx/

Il suffit ensuite dans chaque fichier de lister les différents appareils. En exemple le début des fichiers light et climate :

#########################################################
# Eclairages
#########################################################
light:
# Lingerie
  - name: 'lingerie'
    address: '0/2/5'
    state_address: '0/2/6'
  - name: 'lingerie_ext'
    address: '0/2/10'
    state_address: '0/2/11'
  
  - name: 'cellier'
    address: '0/2/0'
    state_address: '0/2/1'

# Cuisine
  - name: 'cuisine_plafond'
    address: "0/2/15"
    state_address: "0/2/16"
    brightness_address: "0/2/18"
    brightness_state_address: "0/2/19"


###########################################################
# Thermostats
###########################################################
climate:
# Lingerie
  - name: lingerie.temperature
    temperature_address: "3/2/0"
    temperature_step: 0.5
    target_temperature_address: "3/2/1"
    target_temperature_state_address: "3/2/2"
    operation_mode_address: "3/2/3"
    operation_mode_state_address: "3/2/4"
    min_temp: 7.0
    max_temp: 32.0
# Cuisine
  - name: cuisine.temperature
    temperature_address: "3/2/10"
    temperature_step: 0.5
    target_temperature_address: "3/2/11"
    target_temperature_state_address: "3/2/12"
    operation_mode_address: "3/2/13"
    operation_mode_state_address: "3/2/14"
    min_temp: 7.0
    max_temp: 32.0

[richardpub]

[img][/img]

[img][/img]

[img][/img]
tout a fait d'accord sur la struxture avec Ives, mais je m'étonne que la partie Paramères KNX Entités avec son nouvel aspect ne soit pas fonctionnel

[richardpub]

pourtant ca semble beau

[Seb_IoT]

Je vais donc suivre cette voie et rester sur le YAML en attendant que l'intégration UI gère vraiment tous les objets.

Dans ce cas il est préférable de créer dans config un dossier knx puis, dans ce dossier, un fichier yaml par type d'appareil :



sans oublier d'ajouter cette ligne dans le configuration.yaml

knx: !include_dir_merge_named knx/

Il suffit ensuite dans chaque fichier de lister les différents appareils. En exemple le début des fichiers light et climate :

#########################################################
# Eclairages
#########################################################
light:
# Lingerie
  - name: 'lingerie'
    address: '0/2/5'
    state_address: '0/2/6'
  - name: 'lingerie_ext'
    address: '0/2/10'
    state_address: '0/2/11'
  
  - name: 'cellier'
    address: '0/2/0'
    state_address: '0/2/1'

# Cuisine
  - name: 'cuisine_plafond'
    address: "0/2/15"
    state_address: "0/2/16"
    brightness_address: "0/2/18"
    brightness_state_address: "0/2/19"


###########################################################
# Thermostats
###########################################################
climate:
# Lingerie
  - name: lingerie.temperature
    temperature_address: "3/2/0"
    temperature_step: 0.5
    target_temperature_address: "3/2/1"
    target_temperature_state_address: "3/2/2"
    operation_mode_address: "3/2/3"
    operation_mode_state_address: "3/2/4"
    min_temp: 7.0
    max_temp: 32.0
# Cuisine
  - name: cuisine.temperature
    temperature_address: "3/2/10"
    temperature_step: 0.5
    target_temperature_address: "3/2/11"
    target_temperature_state_address: "3/2/12"
    operation_mode_address: "3/2/13"
    operation_mode_state_address: "3/2/14"
    min_temp: 7.0
    max_temp: 32.0

Salut Yves,
génial l'astuce du !include_dir_merge_named !

C'est exactement la bonne pratique de découpage qu'on utilise en développement logiciel. Avoir un seul fichier monolithique de 2000 lignes, c'est le meilleur moyen de faire une erreur d'indentation fatale. Avec cette structure par domaine (light, climate, cover...), c'est ultra clean, modulaire et hyper facile à maintenir. Je valide à 100% et je vais structurer mon dossier config exactement comme ça dès le premier jour !

[img][/img]

[img][/img]

[img][/img]
tout a fait d'accord sur la struxture avec Ives, mais je m'étonne que la partie Paramères KNX Entités avec son nouvel aspect ne soit pas fonctionnel

Hello richardpub, j'avoue l'interface de tes captures est vraiment belle, épurée et très "user-friendly".

Mais c'est un grand classique dans la refonte des logiciels : on a l'impression que c'est fini parce que le "Front-end" (le visuel) est prêt et s'affiche bien, mais sous le capot (le "Back-end"), le code n'arrive pas encore à traiter correctement toute la complexité et les types de données (DPT) spécifiques au KNX.

pourtant ca semble beau

C'est extrêmement prometteur pour l'avenir, et ça deviendra sûrement la norme absolue d'ici quelques grosses mises à jour de Home Assistant. Mais en attendant que les devs finalisent toute la "tuyauterie" interne, la méthode d'Ives reste notre meilleur filet de sécurité, enfin si je ne dis pas n'import quoi les gars. 

Merci à vous deux en tout cas, j'ai l'impression d'avoir gagné 3 mois de tatonnements en quelques messages