Generator für .conf-Files

[firefox]

Hallo Waldemar,

gepatched .... wunderbar. Danke.

Mir sind jetzt beim Testen noch paar Kleinigkeiten aufgefallen. Stört nicht weiter, nur zum Festhalten:

- $order --> Prüfung und Code completion funktioniert in Templates nicht.
- $delete --> dito im Hauptfile
- as_repeat_actions --> fehlt in der Code completion
- as_set_..... --> fehlt in der Code completion

Wenn du mir noch einen kleinen Hinweis gibst wo ich suchen muss setzte ich mich am WE mal hin, versuche das einzubauen und sende dir einen Pull Request.

Gruß Thomas

[mumpf]

Mir sind jetzt beim Testen noch paar Kleinigkeiten aufgefallen. Stört nicht weiter, nur zum Festhalten:

- $order --> Prüfung und Code completion funktioniert in Templates nicht.

Code completion kann ich so nicht bestätigen, habe ich eben ausprobiert - würde mich interessieren, in welchem Fall das bei Dir passiert. Ich hatte schon Fälle, bei dem der Editor die Code-Completion aufgegeben hat, wenn das JSON vor der Cursorposition so kaputt bzw. fehlerhaft war, dass er nicht mehr wusste, was für ein Objekt jetzt dran ist. Und dann kommt auch keine Code-Completion.
Geprüft wird bei $order nichts, das ist nur ein virtuelles Property, das für die Reihenfolge der Items unterhalb seines Parent sorgt. Doppelte Werte und Lücken sind explizit erlaubt, damit es keine Kollisionen beim Merge von Templates gibt. Was für Prüfungen würdest Du erwarten?

- $delete --> dito im Hauptfile

Delete könnte natürlich eine Prüfung vertragen, ob es das Property wirklich gibt. Allerdings funktioniert wiederum die Code-Completion bei mir, ich verwende es ausschließlich im Hauptfile und bin mir nicht sicher, dass es in Templates läuft - habe es einfach noch nicht gebraucht.

- as_repeat_actions --> fehlt in der Code completion

Richtig, habe ich bei mir schon, es fehlt noch der Push, ich will noch alle Neuerungen von offline ins Schema integrieren. Mach einfach in autoblind_plugin.json hinter den startup_delay folgendes:

                        "as_startup_delay": {
                            "description": "Zeit bis zur ersten Auswertung in Sekunden",
                            "type": "integer",
                            "minimum": 1
                        },
                        "as_repeat_actions": {
                            "description": "Hiermit wird die wiederholte Ausführung von Aktionen unterdrückt, es werden nur aktionen ausgeführt, wenn sich der Wert geändert hat",
                            "enum": [ false ],
                            "default": true
                        },

- as_set_..... --> fehlt in der Code completion

Auch das hab ich bei mir schon drin, wieder im autoblind_plugin.json (such nach "leave" mit Anführungsstrichen, das ist eindeutig):

                "leave": {
                    "description": "Ausgangsbedingungen, um den Zustand zu verlassen",
                    "$ref": "#/definitions/condition"
                },
                "as_trigger_*": {
                    "description": "Triggert eine Logik, wenn der Zustand erreicht ist im Format Logikname:Wert",
                    "type": "string"
                },
                "as_set_*": {
                    "description": "Setzt ein Item, wenn dieser Zustand erreicht worden ist (* muss durch Namen ersetzt werden)",
                    "type": "string"
                },
                "as_byattr_*": {
                    "description": "Setzt ein Item mit dem Wert des Attributs, wenn dieser Zustand erreicht worden ist (* muss durch Namen ersetzt werden)",
                    "type": "string"
                },
                "as_delay_*": {
                    "description": "Verzögerung: Zeit (in s), die vergehen muss, bevor eine Änderung ausgeführt wird",
                    "type": "number"
                }

Wenn du mir noch einen kleinen Hinweis gibst wo ich suchen muss setzte ich mich am WE mal hin, versuche das einzubauen und sende dir einen Pull Request.

Gerne, für $delete musst Du nur in ConvertJson2Conf.cs nach $delete suchen. Ich gebe zu, das Coding ist nicht der letzte Schrei...
Bei $order sollten wir uns noch unterhalten, was Du da erwartest.

Gruß, Waldemar

[firefox]

Hallo Waldemar,
ok, klappt alles jetzt. Was $order angeht hab ich mal zwei Bildchen geschossen. Vielleicht reden wir ja nur aneinander vorbei.

1. $order in einem JSON Hauptfile funktioniert problemlos:
bild1.jpg

2. $order in einem Template File. Code completion list down kommt nicht und $order ist nach dem Speichern grün unterstrichen mit dem HInweis "Eigenschaftname für das Schema unzulässig".
bild2.jpg

[mumpf]

Hi firefox,

ja wir haben aneinander vorbei gesprochen. Im prinzip geht $order überall, unabhängig vom Template- oder Hauptfile. Innerhalb des Schema für das Autoblind-Plugin habe ich aber zugunsten der Übersichtlichkeit nicht alle Item-Eigenschaften an alle Items rangehängt, weil sie nicht überall Sinn machen (wie z.B. die einzelnen enter* und leave* Items). Und beim Status habe ich wohl auch nur die "notwendigsten" dran gehängt, sorry. Hatte nicht wirklich erwartet, dass irgendjemandem die Reihenfolge für die States wichtig wäre, ich habe den State-Teil vom Autoblind bei mir in einem Unter-Template, so dass ich diese Definition schon lange nicht mehr angefasst bzw. gesehen habe.

Falls Du das Korrigieren willst: Im autoblind_plugin.json such mal nach "suspended": (mit Anführungsstrichen und Doppelpunkt) und füge dort $order hinzu

            "properties": {
                "$order": {
                    "$ref": "ItemSchema.json#/definitions/smarthome_basic/properties/%24order"
                },
                "suspended": {
                    "description": "Staus: Automatik ist durch manuellen Eingriff deaktiviert",
                    "$ref": "ItemSchema.json#/definitions/item"
                },

All diese Änderungen werden in meinem nächsten Push drin sein, dauert nur noch etwas... Wie gesagt, innerhalb der Unteritems vom Autoblind könnte es noch einige Stellen geben, an denen $order nicht geht, da könntest Du überall dieses $order hinzufügen. Bei den Zuständen (Unteritems von Rules) geht es auf jeden Fall, dafür habe ich es eigentlich eingeführt.

Gruß, Waldemar

[firefox]

Ah .... so langsam dämmert mir wie die Prüfung funktionert. Coole Sache.

Noch weitere Vorschläge im Autoblind Schema:

"stateStore": {
            "description": "Letzter angesteuerter Zustand (Item)",
            "type": "object",
            "additionalProperties": false,
            "required": [
                "type",
                "cache"
            ],
            "properties": {
                "type": {
                    "enum": [ "str" ]
                },
                "visu_acl": {
                    "enum": [ "ro" ]
                },
              "cache": {
                "enum": [ true ]
                },
              "name": {
                "type": "string",
                "description": "Aufgabe dieser State-Engine"
                }
            }
        },

ergänzt um "name".

Gruß Thomas

[mumpf]

Hi Thomas,

jetzt versteh ich, was Du mit "Prüfung" meinst... dafür kann ich nichts

Konzeptionell habe ich "nur" ein json Schema entworfen, dass sich an die Item-Syntax von Marcus conf-Files anlehnt. Visual Studio hat einen Json-Schema-Basierten Editor, der das Schema auswertet und entsprechende Code-Completion-Vorschläge und Prüfungen macht. Deswegen habe ich auch auf die Art der Meldungen keinen Einfluss. Natürlich brauchte ich dann einen Übersetzter von json nach conf, und nachdem ich den hatte, kamen nach und nach die relative Adressierung und die Templates hinzu. Aber angefangen hat das, weil ich einen besseren Editor haben wollte und nicht dauernd in der Doku nachschauen wollte, wie denn jetzt welches Attribut genau geschrieben wird...

Wenn ich von "Prüfung" spreche, dann meine ich das, was nach der Übersetzung von json2conf am Ende in den Messages steht, das mach ich nämlich selbst. Das sind derzeit die "vertippten" Items oder die falsch referenzierten (bei relativer Adressierung). Und da könnte man natürlich Attribute, die durch $delete gelöscht werden sollen und die nicht existieren (als Warunung, grundsätzlich ist das kein Problem, was nicht da ist kann nicht gelöscht werden).

Mein Vorschlag ist, dass Du die Erweiterungen, die Dir vorschweben, sammelst (außer es ist nur die eine oben) und wirklich einen pull-Request machst. Dann sehe ich zu, dass ich das passend integriere.

Gruß, Waldemar

[firefox]

Noch eine Frage zur Logik. Hat das einen Grund dass eigentlich alle Items mit einem Großbuchstaben beginnen müssen, aber die Items unter Autoblind klein sind? (lock, suspended, stateId,....)
Das finde ich nicht wirklich stringent.

[mumpf]

Hi,

sorry für die späte Antwort, hab das hier irgendwie übersehen...

Das Ganze ist nicht so einfach zu erklären, meine Regel "Items müssen mit einem Großbuchstaben beginnen" war der Versuch, technische Gegebenheiten in eine "einfache" Regel zu übersetzen.

Erstmal grundsätzlich: Der json2conf-Konverter übernimmt alles, was in json erstellt worden ist, unabhängig von Groß-/Kleinschreibung, ins conf-File. Aber nur Bezeichner, die den vorgegebenen Regeln genügen, werden zusätzlich geprüft.

Ich wollte im Editor eine Editier-Hilfe haben, dazu zählten neben der code-completion durch die DropDowns auch die Syntax-Ergänzung:

• Anführungsstriche um JSON-Objekt-Properties,
• automatische geschweifte Klammern um JSON-Objekte,
• eckige Klammern um JSON-Arrays
• und einige weitere kleinigkeiten, die der Editor mehr oder minder automatisch macht

Damit das klappt, musste ich im JSON-Schema Regeln vergeben, welche Bezeichner generisch (also vom User/Entwickler) vergeben werden, und welche statisch sind, also exakt so geschrieben werden müssen, damit die damit verbundene Funktion ausgeführt wird (z.B.: knx_send).

Am Anfang war es einfach: Alle Attribute eines Items sind statisch und alle Items selbst sind generisch. Die einfachste Unterscheidung war die Attribute mit Kleinbuchstaben beginnen zu lassen und die Items groß.

Dann kam Autoblind... da gab es dann plötzlich neben statischen Attributen (as_min_day, as_value_day, as_max_day) auch noch generische, die sich auf ein Item beziehen können (as_set_<generisch>, as_value_<generisch>, as_min_<generisch>, as_max_<generisch>). Dadurch brauchte ich auch eine Regel, in der generische Bezeichner mit Kleinbuchstaben beginnen können, und da ich sowieso überprüfen können wollte, ob es zu jedem as_value_*, as_min_*, as_max_* auch ein as_set_* gibt, habe ich die Regel eingeführt, dass für diese Attribute der <generisch>-Teil mit einem Großbuchstaben beginnen muss.

Und dann gab es im Autoblind noch Items, die eher statischen Charakter hatten, wie eben lock, suspended, itemId, etc... Die wollte ich nicht jedesmal schreiben müssen, sondern diese direkt in der DropDown vorgeschlagen haben. Und in JSON-Schema konnte ich nicht eine Regel definieren, die besagt "diese Paar Bezeichner sollen statisch sein, obwohl sie mit einem Großbuchstaben beginnen". Also habe ich definiert, dass diese (statischen) Items eben mit einem Kleinbuchstaben beginnen müssen.

Ergibt folgende Kombinatorik:

• Item, selbst vergebener Bezeichner -> generisch -> muss mit Großbuchstaben beginnen
• Attribut, vorgegebener Bezeichner -> statisch -> muss mit Kleinbuchstaben beginnen
• Attribut, selbst vergebener Bezeichner -> generisch -> der generische Teil (nach einem Präfix) muss mit einem Großbuchstaben beginnen
• Item, vorgegebener Bezeichner -> statisch -> muss mit einem Kleinbuchstaben beginnen

Langer Rede kurzer Sinn: Ohne diese lange Erklärung, die sowieso kaum jemand versteht, kann ich nicht einfach erklären, wie das mit den Items läuft, als habe ich gesagt, dann Items immer groß geschrieben sein müssen, Attribute klein - und Autoblind ist eben was "besonderes".

Gruß, Waldemar

P.S.: So gesehen ist es stringent, nur ist die dahinterliegende Regel nicht so einfach

[firefox]

ich meine es verstanden zu haben

btw du müsstest einen pull request von mir bekommen haben. Ich bin jetzt nicht so der git Experte. Hab ich alles richtig gemacht?

[mumpf]

Hihi, da haben sich 2 getroffen... Ich bin auch nicht der Git-Experte... Bin allerdings mitten in meinem Dachboden-Ausbau, deswegen hab ich noch nicht rein geschaut. Hab aber ein Mail bekommen, dass ein pull da ist. Da nächste Woche unser Kind geboren wird - zumindest wenn es sich an den Plan hält- werde ich wohl nicht vor Ostern dazu kommen, am Konverter was zu machen.

Sorry, aber das ist der Stand der Dinge,
Gruß Waldemar