Umstellung Konfigurationsdateien von .conf in .yaml

[schuma]

Ich habe gerade mal die Konfigurationsdateien umgestellt.
Die ersten Dateien habe ich von Hand gemacht (Plugin.conf und smarthome.conf).
Danach habe das Konvertierungstools benutzt, da ich kein Beispiel für eine Logic.yaml mit mehreren Einträgen in einem watch_item Eintrag gefunden habe.

Das Ergebnis sieht nun so aus:

fehlermeldungen:
    filename: fehlermeldungen.py
    visu_acl: 'yes'
    watch_item:
      - '*.*.*.*.Temperaturalarm'
      - '*.*.*.*.Lastalarm'
      - GLOBAL.ALARMMELDUNG.*

Die Frage:
Ist das mit den Anführungszeichen bei '*.*.*.*.Temperaturalarm' und '*.*.*.*.Lastalarm' so richtig ?
Und warum braucht es dann keine Anführungszeichen bei GLOBALE.ALARMMELDUNG.* ?

Grüße, Marc

[psilo]

schuma es wäre sicher hilfreich, das ORIGINAL zu sehen

[Msinn]

Das ist so in Ordnung. Strings brauchen in YAML keine Quotes (die Qoutes für Strings sind optional). Da die ersten beiden Listeinträge jedoch mit einem Sonderzeichen anfangen, müssen Quotes verwendet werden um den Eintrag als String zu kennzeichnen.

Nachtrag:

Das yes hat Quotes, da in YAML v1.1 yes ohne Quotes nicht als String, sondern als Boolean Wert interpretiert wird. Das ändert sich erst mit dem Einsatz von YAML v1.2, dann ist yes ein String wie andere Strings auch.

Aktuell arbeitet SmartHomeNG allerdings noch mit YAML v1.1.

[mumpf]

Hi, auch wenn etwas OT, ich hätte eine Frage zum hier verwendeten Selektor

*.*.*.*.Temperaturalarm

Gibt es einen Unterschied zum *.Temperaturalarm? Wird mit obigem Selektor wirklich nur auf Level 5 der Item-Hierarchie gesucht, wogegen mein Selektor einfach alle Blätter findet?

Gruß, Waldemar

[schuma]

mumpf : ja,ja
Msinn : Vielen Dank, dann kann es ja weiter gehen.

[schuma]

Ich habe da noch eine Frage:

Kann man die Leerzeilen vor den Sektionsnamen weglassen?

GLOBAL:

    Zeit:

        Tag:
            type: num
            knx_dpt: 1
            knx_send: 5/1/5
            knx_reply: 5/1/5
            eval: sh.env.location.day()
            eval_trigger: env.location.day

        Nacht:

Ich würde das Ganze gerne etwas zusammenrücken.

Marc

[Msinn]

Das kann man tun. Die sind nur aus Leesbarkeitsgründen drin.

In kommenden Versionen von SmartHomeNG werden sie allerdings wieder eingefügt, falls man die Routined zur Pflege der Konfigurationsdaten z.B. Im Backend Plugin nutzt.

[schuma]

OK, Danke!
Dann werde ich mir darüber noch mal ein paar Gedanken machen und das Für und Wieder noch einmal abwägen....

[Msinn]

Ich nehme an, Du wirst mir zustimmen, dass in Konstellationen wie zwischen eval_trigger: und Nacht: eine Leerzeile der Lesbarkeit hilft..

Ob mann in Konstellationen wie zwischen GOBAL: und Zeit: und Zeit: und Tag: eine Leerzeile sein muss kann man sicherlich diskutieren.

[schuma]

Ja, genau so hätte ich es jetzt auch geändert.
Die Leerzeilen zwischen GLOBAL/Zeit/Tag weg.
Und die zwischen eval und Nacht gelassen.

Also Abteilungen innerhalb eines Zweiges mit Leerzeilen trennen.
Alles andere nicht.

[henfri]

Hallo,

wie sind denn die Erfahrungen mit dem Converter?
Ich scheue mich da sehr...
Ich kann zwar konvertieren. Aber alles manuell checken, wird nix. Ich meine: Da könnte ich manuell drauf gucken und würde wohl Fehler/Probleme übersehen, oder ich würde alles ausprobieren -was ewig dauern würde.

Gruß,
Hendrik

[schuma]

Also bei mir hat es geklappt.

[ratzi82]

wie sind denn die Erfahrungen mit dem Converter?

Bis jetzt habe ich keine Probleme festgestellt und ich wollte auch nicht mehr auf das alte .conf Format zurück.
Das Syntax Highlighting und die bessere Lesbarkeit des .yaml Formats sind für mich ein enormer Vorteil.

Als Editor verwende ich Atom ( https://atom.io/ ) oder Notepad++ ( https://notepad-plus-plus.org )

Gruß,
Henning

[yachti]

wie sind denn die Erfahrungen mit dem Converter?

Ich habe den Converter benutzt umfangreich getestet und keine Probleme festgestellt

21 Items-conf und plugin.conf ca. 3000 Zeilen Code
Die Konvertierung hat funktioniert wie es soll, keine Nachbearbeitung

[Msinn]

Das einzige mir bisher bekannte Problem betrifft Item Attribute für das Onewire Plugin. Es kann seltene Fälle geben, bei denen eine ow_addr Konfiguration fehlinterpretiert wird.

Das Plugin erwartet Strings als Input. Es kann aber vorkommen, dass die Sensor Adressen als Float interpretiert werden weil sie ausser Ziffern nur einen Punkt und ein 'E' enthalten. Das E wird als Exponent einer Float interpretiert.

Die Abhilfe ist einfach: Bei sensor Adressen, die keinen Buchstaben oder nur ein 'E' enthalten, die Sensor Adresse in Hochkommata einschließen. Normalerweise brauchen Strings in YAML keine Hochkomma, wenn jedoch keine Hochkommata da sind, versucht YAML den Datentyp zu interpretieren.

Abhilfe
statt:

    ow_addr: 28.42901E030000

eifach

    ow_addr: '28.42901E030000'

schreiben.