Ordnung in YAML

[henfri]

Hallo,

ich habe eine eigene YAML für knx.

Darin habe ich dann eine Sortierung nach Entität-Typ.

Jetzt wollte ich aber bei einem Gerät alles beisammen haben und habe unten dies hinzugefügt:

############## VPM Elternbad Diagnose ##########
sensor:
  - name: "VPM Elternbad Helligkeit"
    state_address: "6/2/8"
    type: illuminance

text:  
  - name: "VPM Elternbad Text Rückmeldung"
    address: "6/2/255"


switch:
  - name: "VPM Elternbad Präsenz"
    address: "5/2/11"
  - name: "VPM Elternbad Automatik Übersteuern"
    address: "1/2/20"
  - name: "VPM Elternbad Aktorstatus"
    address: "1/2/23"
  - name: "VPM Elternbad Sperre Aus"
    address: "5/2/12"
binary_sensor:
  - name: "VPM Elternbad Manuell/Automatisch"
    state_address: "5/2/13"
number:
  - name: "VPM Elternbad Szene"
    state_address: "10/2/2"
    address: "10/2/2"
    type: scene_number
  - name: "VPM Elternbad Dimmwert"
    state_address: "1/2/22"
    address: "10/2/2"
    type: percent​

Jetzt fehlen seitdem eine Menge entitäten.

Kann es sein, dass ein zweiter "sensor:" Eintrag das Vorherige überschreibt?

Wenn ja: Kann ich das Gewollte trotzdem irgendwie realisieren (z.B. durch eine eigene Datei für das Gerät)?

Gruß,
Hendrik

[meti]

Kann es sein, dass ein zweiter "sensor:" Eintrag das Vorherige überschreibt?

Ja.

Kann ich das Gewollte trotzdem irgendwie realisieren

Vielleicht mit Packages https://www.home-assistant.io/docs/c...tion/packages/

[Tom Bombadil]

2x sensor: ganz links im Root geht nicht, aber:

• Packages -wie von meti genannt- funktioniert tatsächlich prima. Nutze ich zB für mein Trovis-Projekt mit eigenem Verzeichnis. Beim Start werden die sensor: Einträge in den Packages auf den Haupteintrag sensor: im Root 'draufgemerged'.
• Oder Du hängst hinten noch ein Wort dran (sensor main:, sensor statistics:, sensor curves: ...). Geht aber nicht mit allen Domains (zB mit input_number usw nicht).

Hier mal meine config.yaml für eine Split-Configuration, wie sie Dir vorschwebt (mit Modbus - aber ohne KNX mangels grüner Kabel im Haus). Unbedingt die 2 Leerzeichen vor packages beachten, das Ding gehört unter `homeassistant:`. Hab ewig gebraucht, bis ich das Aufsplitten soweit hatte, wie ich es haben wollte:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes/

homeassistant:
  name: "Zu Hause"
  latitude: 08.15
  longitude: 08.15
  elevation: 8848
  unit_system: metric
  currency: EUR
  country: DE
  language: de
  temperature_unit: C
  time_zone: Europe/Berlin

  packages:
    trovis:
      input_number:      !include trovis557x/input_numbers.yaml
      input_datetime:    !include trovis557x/input_datetime.yaml
      sensor main:       !include trovis557x/template_sensors.yaml
      sensor statistics: !include trovis557x/statistics.yaml
      sensor curves:     !include trovis557x/heating_curves.yaml
      template triggers: !include trovis557x/trigger_actions.yaml
      automation start:  !include trovis557x/trigger_startup.yaml
      automation update: !include trovis557x/trigger_updates.yaml

    muell:
      waste_collection_schedule: !include conf/specific/muellkalender.yaml
      sensor waste_collection:   !include conf/specific/muell_templates.yaml

    espeasy:
      rest:              !include conf/specific/esps_feuchte_temp.yaml

    jahreskalender:
      template:          !include conf/specific/jahreskalender.yaml

modbus:
  - name: trovis
    type: !secret trovis_connection_type
    host: !secret trovis_ip
    port: !secret trovis_port
    sensors:        !include_dir_merge_list trovis557x/sensors/
    binary_sensors: !include_dir_merge_list trovis557x/binary_sensors/
    message_wait_milliseconds: 30
    timeout: 10
    delay: 5

# ab hier die Standard-Domains für einzelne Entitäten, für die sich keine eigene extra-YAML lohnt
# (aka "Grabbelkiste")

automation:   !include conf/automations.yaml
script:       !include conf/scripts.yaml
scene:        !include conf/scenes.yaml
sensor:       !include conf/sensors.yaml
rest:         !include conf/rests.yaml
template:     !include conf/templates.yaml
media_player: !include conf/media_players.yaml
input_select: !include conf/input_selects.yaml
input_number: !include conf/input_numbers.yaml

Aufbau der YAML-Dateien als Vorlage hier, aber da ändert sich gerade ständig was.

Viel Erfolg!

/tom

[henfri]

Danke Tom,

ich hab die Dokumentation zu packages dreimal gelesen und nicht kapiert...

Aber letztlich wird doch nur aus dem:

knx: !include knx.yaml

Ein

homeassistant:
  packages:
     wie_nenne_ich_dies:
        knx: !include knx/KWL.yaml
        knx: !include knx/Praesenzmelder.yaml
        knx: !include rest.yaml
​​

Richtig?

würde in den yaml-Dateien noch ein knx: vorkommen, oder würde die auf der Ebene darunter starten?

Du nutzt es aber nicht aus, dass gleiche Typen mehrfach vorkommen dürfen, richtig?

packages:
  trovis:
    sensor main: !include trovis557x/template_sensors.yaml  
    sensor statistics: !include trovis557x/statistics.yaml​

Das würde ja auch ohne packages gehen.

Gruß,
Hendrik

[Tom Bombadil]

Edit:
Gerade erst gesehen - siehe Antwort von Sebastian zum gleichen Thema im anderen Thread.
Da ist das am konkreten Beispiel nochmal kurz und knackig beschrieben.

--------

Nach meiner Kenntnis kannst Du die Namen der Packages wählen, wie Du lustig bist; er ist nur ein Platzhalter. Alles darunter wird beim Start von HA in den passenden Root-Eintrag 'reingemerged'. Die Namen im Beispiel oben habe ich frei gewählt (trovis, muell, espeasy, jahreskalender).

Wo steht denn knx: jetzt gerade - im root (ganz links) oder unter packages:? --> hab noch nie einen configuration.yaml mit knx: gesehen

Wenn im Root, also als Teil einer Integration mit ggf eigenen erweiterten Attributen, bringt Dir der Package-Ansatz vermutlich nichts. Tut es bei meinem 'Modbus' z.B. auch nicht (auch da gibt es Modbus-eigene Attribute, die die Integration mit sich bringt).

Dann wäre der richtige Weg, das 'knx: !include knx.yaml' gegen ein 'knx: !include_dir_merge_list verzeichnisname/' auszutauschen (ggf auch eines der anderen includedir* nehmen - abhängig davon, wie der 'Absprungpunkt' unter knx: aufgebaut ist). In das Verzeichnis kannst Du dann 10, 20, 20 eigene yaml_Dateien mit Configs reinwerfen (raumweise, funktionsweise, was_auch_immer), die beim HA-Start automatisch an der richtigen Stelle einsortiert werden.

Beispiel von oben (da hat sich im aktuellen Code gestern was geändert, daher hier nochmal):

modbus:
  - name: trovis
    sensors: !include_dir_merge_list trovis557x/registers/      # nur ein sensors: steht zur Verfügung
    binary_sensors: !include_dir_merge_list trovis557x/coils/   # nur ein binary_sensors: steht zur Verfügung

Ergebnis hier. Unter 'registers' und 'coils' nach Funktion und Heizkreis geordnet. Schön übersichtlich, oder? Dein derzeitiges !include holt halt beim Start nur eine einzige, konkrete Datei an, in der wirklich alles drinstehen muss - includedir* in seinen verschiedenen Variationen automatisch ganze Verzeichnisse mit *allen* darin enthaltenen yaml-Dateien.

Du nutzt es aber nicht aus, dass gleiche Typen mehrfach vorkommen dürfen, richtig?

Doch, sogar genau an der von Dir zitierten Stelle. Ob innerhalb eines Packages, oder als Rooteintrag, ist egal. Die jeweilige Domain/Integration muss das aber explizit unterstützen (bei weitem nicht alle tun das).

knx eins: # keine Ahnung, ob's geht - kein KNX, kann nicht testen
  <config_k1>

knx zwei:
  <config_k2>#

modbus eins: ### geht nicht, modbus Integration unterstützt kein multi-config
  <config1_m1>

modbus zwei:
  <config_m2>

sensors irgendein_gerät: ### geht, sensors unterstützt multi-config
  <diverse sensors>

sensors ein_anderes_gerät:
  <diverse andere sensors​>

input_number eins:  ### geht nicht, Domain input_number unterstützt kein multi-config
  <diverse andere sensors​>

input_number zwei:
  <diverse andere sensors​>​

Willst Du hier mehrere getrennte Dateien mit input_number: haben, musst Du halt den Weg über packages gehen; so kannst Du die Limitierung umschiffen.

Fand das auch alles sehr verwirrend am Anfang. Nach viel Ausprobieren hatte ich die obige config - sie läuft 1:1 so bei mir im System. Habe halt ungern riesige Config-Dateien und bin 'Ordnungsfetischist' (Dinge sollten nach Funktion, Montage-/Einsatzort etc separiert werden und so im Fehlerfall schnell auffindbar sein).

/tom