[HA] Scinder Config KNX

[filou59]

Hello

Pour une fois c'est moi qui pose les question   

Pour les pro de HA
Je supose que vous avez des config KNX assez evoluer maintenant avec pas mal de point qui remonte dans HA.

Je souhaiterais scinder mes config dans plusieurs fichiers, vous utiliser quel méthode ?
J'ai vue quelques pistes sur le forum HA mais je sais pas trop laquelle choisir

Idealement j'aurais envisagé :
Un Fichier yaml pour :

• les données météo
  
• l'eclairage
  
• les VR
  
• les Données Conso
  
• ...
  

Sur le forum HA j'avais trouvé ca :

Code :

knx:

binary_sensor: !include knx_binary_sensor.yaml
climate: !include knx_climate.yaml
cover: !include knx_cover.yaml
event: !include knx_event.yaml
expose: !include knx_expose.yaml
light: !include knx_light.yaml
sensor: !include knx_sensor.yaml
switch: !include knx_switch.yaml

Mais cette exemple se prete bien pr les VR ou les lampes, mais pas forcément pour mes données meteo qui mélange plusieurs choses ?

Comment vous ferriez ? ou comment vous faites ?

[filou59]

J'ai trouvé une solution.

Les packages :

Dans configuration.yaml

Code :

homeassistant:
 packages: !include_dir_named packages

Ensuite on ajoute un dossier , ici "packages"

Puis on peut créer des fichiers :
knx_meteo.yaml

Code :

knx:
  sensor:
    - name: "Soleil Azimut"
      state_address: "0/0/12"
      type: angle_deg
    - name: "Soleil Elevation"
      state_address: "0/0/13"
      type: angle_deg
    - name: "Luminosite"

[babychou]

J'ai trouvé une solution.

Les packages :

Dans configuration.yaml

Code :

homeassistant:
 packages: !include_dir_named packages

Ensuite on ajoute un dossier , ici "packages"

Puis on peut créer des fichiers :
knx_meteo.yaml

Code :

knx:
 sensor:
   - name: "Soleil Azimut"
     state_address: "0/0/12"
     type: angle_deg
   - name: "Soleil Elevation"
     state_address: "0/0/13"
     type: angle_deg
   - name: "Luminosite"

C'est effectivement la meilleure méthode !
Après, le yaml tend à disparaitre dans HA... fait attention à ne pas trop l'utiliser quand la configuration est possible via l'interface graphique.

[filou59]

Après, le yaml tend à disparaitre dans HA... fait attention à ne pas trop l'utiliser quand la configuration est possible via l'interface graphique.

Et, c'est bien dommage je trouve...
Interface graphique c'est bien mais c'est beaucoup plus chronophage a faire que de faire de copier de coller de code et ajustement a la main....

Pour moi il faut les 2.
Il faut pouvoir tout faire a la main en fichier de config.
Ensuite tu ajoutes une interface graphique qui te traduit ca en texte.

[babychou]

Après, le yaml tend à disparaitre dans HA... fait attention à ne pas trop l'utiliser quand la configuration est possible via l'interface graphique.

Et, c'est bien dommage je trouve...
Interface graphique c'est bien mais c'est beaucoup plus chronophage a faire que de faire de copier de coller de code et ajustement a la main....

Pour moi il faut les 2.
Il faut pouvoir tout faire a la main en fichier de config.
Ensuite tu ajoutes une interface graphique qui te traduit ca en texte.

Je suis bien d'accord avec toi, reste que si tu veux rendre le produit le plus simple possible pour qu'il soit à la portée de tout le monde, pas le choix que de sortir du yaml... et c'est la voie qui est suivi. Heureusement, quand ils ont annoncés cela y a quelques années, y a eu une levée de bouclier pour conserver la possibilité d'utiliser le yaml. Ca tiendra combien de temps ?

[filou59]

Je suis bien d'accord avec toi, reste que si tu veux rendre le produit le plus simple possible pour qu'il soit à la portée de tout le monde, pas le choix que de sortir du yaml... et c'est la voie qui est suivi. Heureusement, quand ils ont annoncés cela y a quelques années, y a eu une levée de bouclier pour conserver la possibilité d'utiliser le yaml. Ca tiendra combien de temps ?

Je suis d'accord qu'une interface graphique permet de démocratisé le truc et de rendre accessible ca au plus de monde. On commence tous comme ca le plus souvent.
Mais il ne faut pas que ce soit au détriment du fichier de conf.

Si on fait un parallèle avec Proxmox, si on revient en arrière de 3 a 5 ans.
Interface pas très élégante mais qui fait le minimum syndicale.
Ensuite il fallait sortir la ligne de commande.

De nos jours l'interface est de plus en plus conviviale, et on peut faire de plus en plus de chose.
Mais en // on a toujours la ligne de commande qui est la référence.
On peut tout faire en ligne de cmd.
Et on peut faire de plus en plus de chose via l'interface graphique.

En sachant que l'on pourra toujours faire des choses plus poussées via la ligne de cmd.

Il faut que les 2 soit complémentaire et ne pas chercher a en avoir un au détriment de l'autre.

[richardpub]

Pour ma part, j'ai choisi cette méthode dans le fichier configuration/

Code :

homeassistant:
 packages: !include_dir_named knx/

Ensuite j'ai un dossier knx avec un dossier pour chaque type d'éléments en KNX:
un dossier pour chacun:
knx_climate.yaml
knx_cover.yaml
knx_event.yaml
knx_expose.yaml
knx_light.yaml
knx_sensor.yaml
knx_switch.yaml


ainsi si tu veux rajouter un autre type d'élément, tu crée un nouveau dossier spécialisé dans ton dossier KNX

[filou59]

@richardpub : pas bête Merci

[babychou]

Pour ma part, j'ai choisi cette méthode dans le fichier configuration/

Code :

homeassistant:
 packages: !include_dir_named knx/

Ensuite j'ai un dossier knx avec un dossier pour chaque type d'éléments en KNX:
un dossier pour chacun:
knx_climate.yaml
knx_cover.yaml
knx_event.yaml
knx_expose.yaml
knx_light.yaml
knx_sensor.yaml
knx_switch.yaml


ainsi si tu veux rajouter un autre type d'élément, tu crée un nouveau dossier spécialisé dans ton dossier KNX

le knx_ est alors superflu : vu que c'est dans le dossier knx.

[richardpub]

Pour ma part, j'ai choisi cette méthode dans le fichier configuration/

Code :

homeassistant:
 packages: !include_dir_named knx/

Ensuite j'ai un dossier knx avec un dossier pour chaque type d'éléments en KNX:
un dossier pour chacun:
knx_climate.yaml
knx_cover.yaml
knx_event.yaml
knx_expose.yaml
knx_light.yaml
knx_sensor.yaml
knx_switch.yaml


ainsi si tu veux rajouter un autre type d'élément, tu crée un nouveau dossier spécialisé dans ton dossier KNX

le knx_ est alors superflu : vu que c'est dans le dossier knx.

Tout dépend de ce que tu veux faire par la suite:
Pour moi knx_climate.yaml c'est pour les cover en KNX, et si plus tard tu veux utiliser un climate non KNX dans HA, tu placera le code des climate.yaml non KNX au même niveau que configuration.yaml, et donc directement reconnu comme dans un code de HA.
Merci à Ives qui a vraiment dégrossi le sujet.

[XeNo]

Climate ce n'est pas pour des covers, c'est pour des thermostats.

On a toutes les précos knx de HA ici :
https://www.home-assistant.io/integrations/knx/

Il faut créer un fichier de chaque type, c'est plus simple.
Pour les regroupements spécifiques (type calcul d'energie tempo et autre), il faut utiliser un include package spécifique pour plus de lisibilité et de facilité de modifications.

[babychou]

Climate ce n'est pas pour des covers, c'est pour des thermostats.

On a toutes les précos knx de HA ici :
https://www.home-assistant.io/integrations/knx/

Il faut créer un fichier de chaque type, c'est plus simple.
Pour les regroupements spécifiques (type calcul d'energie tempo et autre), il faut utiliser un include package spécifique pour plus de lisibilité et de facilité de modifications.

De mon côté, pour bien faire les choses, j'ai des fichiers dans un folder KNX qui servent uniquement pour les "imports" de données et un autre fichier par thème pour les "calculs" sur les valeurs brutes récupérées.

Je trouve ça plus simple pour s'y retrouver après. Si c'est une valeur "complexe", i.e. non issus directement d'un capteur, c'est dans un fichier calcul, sinon c'est dans un fichier knx.

[richardpub]

Pour ma part, j'ai choisi cette méthode dans le fichier configuration/

Code :

homeassistant:
 packages: !include_dir_named knx/

Ensuite j'ai un dossier knx avec un dossier pour chaque type d'éléments en KNX:
un dossier pour chacun:
knx_climate.yaml
knx_cover.yaml
knx_event.yaml
knx_expose.yaml
knx_light.yaml
knx_sensor.yaml
knx_switch.yaml


ainsi si tu veux rajouter un autre type d'élément, tu crée un nouveau dossier spécialisé dans ton dossier KNX

le knx_ est alors superflu : vu que c'est dans le dossier knx.

Tout dépend de ce que tu veux faire par la suite:
Pour moi knx_climate.yaml c'est pour les cover en KNX, et si plus tard tu veux utiliser un climate non KNX dans HA, tu placera le code des climate.yaml non KNX au même niveau que configuration.yaml, et donc directement reconnu comme dans un code de HA.
Merci à Ives qui a vraiment dégrossi le sujet.

J'ai gardé le KNX_ pour différencier un KNX_climate d'un climate non KNX.
C'est juste une histoire convention pour s'y retrouver quand le code de HA grossit.   

[richardpub]

Climate ce n'est pas pour des covers, c'est pour des thermostats. 

On a toutes les précos knx de HA ici :
https://www.home-assistant.io/integrations/knx/

Il faut créer un fichier de chaque type, c'est plus simple.
Pour les regroupements spécifiques (type calcul d'energie tempo et autre), il faut utiliser un include package spécifique pour plus de lisibilité et de facilité de modifications.

Climate ce n'est pas pour des covers, c'est pour des thermostats. 
Evidement!!!

Il faut créer un fichier de chaque type, c'est plus simple.
c'est bien ce que je fais. Je mets juste ces fichiers KNX dans un même folder. Quand le code grossit, ca devient vite illisible sinon. Sans parler de la reprise du code par quelqu'un d'autre dans quelques temps