Miq19
11. Juni 2024 um 09:02
1
Ich wühle mich gerade in YAML ein. Ich bin ein erfahrener C++ - Programmierer, aber das YAML-Konzept von HA entzieht sich mir noch etwas.
Ich versuche gerade, >10 gleichartige Modbus-Geräte zu konfigurieren, ohne dass ich jedes Mal alle Attribute neu schreiben muss. Deswegen möchte ich das Anchor-/Merge-Konzept benutzen.
Meine modbus.yaml wird in configuration.yaml mit der Zeile modbus: !include modbus.yaml eingebunden und sieht derzeit so aus:
- common_parts: &common_p
device_address: 1
address: 1
write_type: holding
verify:
input_type: holding
address: 1
- name: Treppenlicht
type: tcp
host: 192.168.178.47
port: 502
timeout: 2
lights:
- name: PW_Treppenlicht
unique_id: TreppenlichtSW
<<: *common_p
- name: Sofalicht
type: tcp
host: 192.168.178.48
port: 502
timeout: 2
lights:
- name: PW_Sofalicht
unique_id: SofalichtSW
<<: *common_p
- name: Fensterlicht
type: tcp
host: 192.168.178.44
port: 502
timeout: 2
lights:
- name: PW_Fensterlicht
unique_id: FensterlichtSW
<<: *common_p
- name: Kugellicht
type: tcp
host: 192.168.178.49
port: 502
timeout: 2
lights:
- name: PW_Kugellicht
unique_id: KugellichtSW
<<: *common_p
- name: Anlage
type: tcp
host: 192.168.178.41
port: 502
timeout: 2
lights:
- name: PW_Anlage
unique_id: AnlageSW
<<: *common_p
Hier motzt HA bei der Prüfung aber:
Ich muss gestehen, das verstehe ich nicht… Wie muss ich den gemeinsamen Teil schreiben, damit er bei den einzelnen Geräten eingebunden werden kann?
Miq19
11. Juni 2024 um 09:15
3
Himmel… Die Frage hat doch nix mit Modbus an sich zu tun?
Ich möchte die YAML-Syntax für das Einbinden einer immer wieder gleichen Teilkonfiguration lernen.
Habe noch nie damit gearbeitet, aber hilft dir das weiter?
1 „Gefällt mir“
Miq19
11. Juni 2024 um 09:51
5
Im Online-YAML-Checker (https://codebeautify.org/yaml-editor-online ) funktioniert mein Code wie gewünscht, nur stört sich HA daran, dass der “geankerte” Abschnitt nicht sinnvoll für modbus: ist - vermute ich.
Irgendwie fehlt mir die Eingebung, wie man solche Abschnitte schreiben kann, ohne dass sie gleich in der aktuellen Struktur mitinterpretiert werden.
Hast du es mal so versucht?
- name: Treppenlicht
type: tcp
host: 192.168.178.47
port: 502
timeout: 2
lights:
- name: PW_Treppenlicht
unique_id: TreppenlichtSW
<<: &common_p
device_address: 1
address: 1
write_type: holding
verify:
input_type: holding
address: 1
- name: Sofalicht
type: tcp
host: 192.168.178.48
port: 502
timeout: 2
lights:
- name: PW_Sofalicht
unique_id: SofalichtSW
<<: *common_p
- name: Fensterlicht
type: tcp
host: 192.168.178.44
port: 502
timeout: 2
lights:
- name: PW_Fensterlicht
unique_id: FensterlichtSW
<<: *common_p
- name: Kugellicht
type: tcp
host: 192.168.178.49
port: 502
timeout: 2
lights:
- name: PW_Kugellicht
unique_id: KugellichtSW
<<: *common_p
- name: Anlage
type: tcp
host: 192.168.178.41
port: 502
timeout: 2
lights:
- name: PW_Anlage
unique_id: AnlageSW
<<: *common_p
oder so?
- <<: &common_p
device_address: 1
address: 1
write_type: holding
verify:
input_type: holding
address: 1
- name: Treppenlicht
type: tcp
host: 192.168.178.47
port: 502
timeout: 2
lights:
- name: PW_Treppenlicht
unique_id: TreppenlichtSW
<<: *common_p
- name: Sofalicht
type: tcp
host: 192.168.178.48
port: 502
timeout: 2
lights:
- name: PW_Sofalicht
unique_id: SofalichtSW
<<: *common_p
- name: Fensterlicht
type: tcp
host: 192.168.178.44
port: 502
timeout: 2
lights:
- name: PW_Fensterlicht
unique_id: FensterlichtSW
<<: *common_p
- name: Kugellicht
type: tcp
host: 192.168.178.49
port: 502
timeout: 2
lights:
- name: PW_Kugellicht
unique_id: KugellichtSW
<<: *common_p
- name: Anlage
type: tcp
host: 192.168.178.41
port: 502
timeout: 2
lights:
- name: PW_Anlage
unique_id: AnlageSW
<<: *common_p
Miq19
11. Juni 2024 um 15:17
8
Nein, geht leider beides nicht. Beim ersten kommt die Modbus-Struktur durcheinander:
Beim zweiten kommt eine quasi identische Fehlermeldung zu meinem Versuch.
Selbstantwort: es geht, aber nur mit Ankern, die innerhalb einer gültigen Struktur definiert werde. Beispiel:
- name: Treppenlicht
type: tcp
host: 192.168.178.47
port: 502
timeout: 2
lights:
- name: PW_Treppenlicht
unique_id: TreppenlichtSW
<<: &common_p
device_address: 1
address: 1
write_type: holding
verify:
input_type: holding
address: 1
- name: Sofalicht
type: tcp
host: 192.168.178.48
port: 502
timeout: 2
lights:
- name: PW_Sofalicht
unique_id: SofalichtSW
<<: *common_p
- name: Fensterlicht
type: tcp
host: 192.168.178.44
port: 502
timeout: 2
lights:
- name: PW_Fensterlicht
unique_id: FensterlichtSW
<<: *common_p
- name: Kugellicht
type: tcp
host: 192.168.178.49
port: 502
timeout: 2
lights:
- name: PW_Kugellicht
unique_id: KugellichtSW
<<: *common_p
- name: Anlage
type: tcp
host: 192.168.178.41
port: 502
timeout: 2
lights:
- name: PW_Anlage
unique_id: AnlageSW
<<: *common_p
Hier ist Treppenlicht vollständig beschrieben. Das <<: &common_p klammert dabei den nachher mehrfach zu referenzierenden Block und fügt ihn gleich ein.
In den nachfolgenden Definitionen wird der Block dann jeweils mit <<: *common_p eingefügt.
Okay, das entspricht in etwa wie ich es in Lösung 1 versucht hätte. Schön das es jetzt funktioniert.
Miq19
11. Juni 2024 um 16:15
10
Ja, nur die Einrückung des geankerten Blocks fehlte. Hat mich auch eine Weile gekostet, das herauszufinden
