Konfiguration von DIY-Geräten

[Bernator]

Hab mir das Ganze nochmal genauer angeschaut und je länger ich nachdenke umso mehr treibt es mich in Richtung "Standard" und damit weiter weg von der "Selbsterklärenden" XML Struktur.

Gründe:
- sobald es ein wenig komplexer wird werden "unmengen" KO's benötigt
- im "Standard" ist bereits viel KnowHow reingeflossen den man einfach verschenken würde
- Anfangs überblickt man meist nicht die gesamte Tragweite bestimmter Konventionen, daher ist es oft so das nachträglich Sachen reingepfuscht werden die es wieder unübersichtlich machen
- selbst eine einfache Struktur ist warscheinlich nicht selbsterklärend daher brauchts eine Dokumentation, beim "Standard" schon vorhanden

Nachteile:
- Anfangs hoher Aufwand bis auch nur die simplen Sachen funktionieren
- es müssen auch Teile im XML berücksichtigt werden die evtl. gar keine Verwendung im Tool finden
- für Selbermacher mit weniger Einblick sicher abschreckend

Fazit:
für die Arduino Fraktion sicher overpowered daher macht jeder sein "Ding", das Parsen einer anderen XML Struktur kann dann ja immer noch implementiert werden um Kompatibilität zu erlangen....

Persönlich lebe ich mal mit der aktuellen Qt Version (speichern vom Projekt werd ich noch rudimentär anpassen). Wenn ich wieder etwas Luft habe werde ich mich evtl am "Standard" versuchen aber das ist eher auf Lange Sicht realistisch....

[l0wside]

Auch wenn das eine oder andere matched: Dein bisheriger Format-Vorschlag ist ein wenig fülliger und - so finde ich subjektiv - schwerer zu lesen.
Ich hab mir Mühe gegeben es wirklich auf das wesentliche zu reduzieren.

Ich fände es trotzdem gut, wenn das Qt-Tool wenigstens deine Beschreibungsdateien lesen könnte. Auch umgekehrt müsste es möglich sein, ggf. steht dann eben nicht der ganze Funktionsumfang zur Verfügung. Und ich sehe nicht, dass nur "das eine oder andere matched" - wie dargelegt, halte ich die Formate für recht ähnlich.

Die Options auslagern: Hatte ich auch darüber nachgedacht. Aber dann muss man an der Parameter-Stelle nochmal auf die jweilige Option referenzieren. Das macht es nicht wirklich leserlicher.
Wenn es jetzt mehr als ein halbes Dutzend Stellen gäbe wo mehr als ein Dutzend Optionen verwendet werden.. Ja, dann würde es vllt. Sinn machen Redundante Optionen zu verhindern.

Du hast doch deinen Sechskanaldimmer, d.h. sechs Mal die gleichen Parameter. Willst du dann sechs Mal Copy&Paste machen?

Kannst du nochmal kurz drauf eingehen warum KO10 auf Objekt10 steht? Wäre das "Pflicht" oder eine "Konvention" die man zur Not auch im XML anders belegen kann?

Bei mir ist es im Moment Pflicht. Unumgänglich ist es allerdings nur für die Flags (die sind fix an Property 0, Index 0 des jeweiligen Objekts). Auch die Property-Schnittstelle für die GAs verwendet diese Festlegung.

Zu 1)
Kannst du hierzu mal einen konkreten Vorschlag machen?
Meine Benennung der Nodes und Optionen habe ich nach Möglichkeit versucht an die ETS anzulehnen, so dass man zur Not auch ohne GUI und Entwickler-Wissen die Einträge in der File "wiedererkennt".
Würde mich freuen wenn wir die Benennung in diese Richtung bekämen.

Ich habe jetzt mal versucht, deine Ansätze mit meinen zu verheiraten.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<device-description version="1.0"> 
    <manufacturer-id>0x001</manufacturer-id>
    <!-- Lesbarer Name des Herstellers, Optional -->
    <manufacturer>root1.de</manufacturer>
    <!-- Liste kompatibler Devices, Order code: 10 byte hex, mask version: 2 byte hex, app version: 5 byte hex -->
    <devices>
        <device order-info="0xCAFE4711AB1234567890" mask-version="0x0701" app-version="0x0102030405">
        <device order-info="0xCAFE4711AB1234567890" mask-version="0x0701" app-version="0x0211ABFA1C">
        <device order-info="0x123456789ADEAFBEAD00" mask-version="0x0201" app-version="0x0176234EAF">
    </devices>
    <!-- Lesbarer Gerätename, Optional -->
    <name>6CH KNX PWM LED Controller</name>  
    <!-- 
        Beschreibt die KOs (informell für den Anwender) und 
        legt den Speicherort der zugehörigen GAs fest
    -->
    <commobjects>
        <commobject id="10">
            <description>Schalten Ein/Aus Kanal A</description> <!-- In Anlehnung an die "Kommunikationsobjecte" Spalte unter "Geräte" in der ETS -->
            <dpt>1</dpt>  <!-- DPT 1 ist Schalten -->
            <pdt>UNSIGNED_CHAR</pdt> <!-- DPT1 kann IIRC auf UNSIGNED_CHAR und auf GENERIC01 abgebildet werden. -->
            <property name="flags" id="0"> <!-- Der Teil kann bei dir mit fixen Flags auch einfach entfallen -->
                <type>GENERIC01</type>
                <read_access>FREE</read_access>
                <write_access>CONFIG</write_access>
            </property>
            <condition object="5" property="1" min_value="1" max-value="5"/>  <!-- Optional. Communication Object steht nur zur Verfügung, wenn Object 5, Property 1 >= 1 und <= 5 ist.  -->
        </commobject>
        <commobject id="11">
            <description>Dimmkontrolle Kanal A</description>
            <dpt>3</dpt>
            <pdt>UNSIGNED_CHAR</pdt>
            <property name="flags" id="0">
                <type>GENERIC01</type>
                <read_access>FREE</read_access>
                <write_access>CONFIG</write_access>
            </property>
        </commobject>
        <commobject id="12">
            <description>Absolutwert Kanal A</description>
            <dpt>5</dpt>
            <pdt>UNSIGNED_CHAR</pdt>
            <property name="flags" id="0">
                <type>GENERIC01</type>
                <read_access>FREE</read_access>
                <write_access>CONFIG</write_access>
            </property>
        </commobject>
    </commobjects>

    <!--
        Parameter des Geräts, ggf. gruppiert.
        Legt deren Speicherort fest und zeigt Default-Werte
    -->
    <properties>  <!-- "Parameter" gibt es m.W. bei KNX nicht, der Standard spricht von "Properties" -->
        <!-- 
            <group> = Gruppierung der Parameter, z.B. in einem 
            Parameter-"Baum" in der Anwendung. Könnte man theoretisch auch 
            ineinander verschachteln: "group in group"
        -->
        <!-- Die folgenden Properties sind notwendig, um die Gerätedaten an der passenden Stelle abzurufen.
             Alternativ könnte man sie hart kodieren, das fände ich aber unschön. -->
        <property name="device_object_type" object="0x00" id="0x01">
            <type>UNSIGNED_INT</type>
            <read_access>FREE</read_access>
            <default>0x00</default>
        </property>
        <property name="device_control" object="0x00" id="0x0E" dynamic="true">
            <type>GENERIC01</type>
            <read_access>FREE</read_access>
            <write_access>CONFIG</write_access>
            <default>0x00</default>
        </property>
        <property name="service_control" object="0x00" id="0x08">        
            <type>UNSIGNED_INT</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
            <default>0x00</default>        
        </property>        
        <property name="firmware_revision" object="0x00" id="0x09">        
            <type>UNSIGNED_CHAR</type>        
            <read_access>FREE</read_access>        
            <default>0x01</default>        
        </property>        
        <property name="serial_number" object="0x00" id="0x0B">        
            <type>GENERIC06</type>        
            <read_access>FREE</read_access>        
        </property>        
        <property name="manufacturer_id" object="0x00" id="0x0C">        
            <type>UNSIGNED_INT</type>        
            <read_access>FREE</read_access>        
        </property>        
        <property name="order_info" object="0x00" id="0x0F">        
            <type>GENERIC10</type>        
            <read_access>FREE</read_access>        
        </property>        
        
        <property name="manufacture_id" object="0x00" id="0x13">        
            <type>GENERIC04</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        

        <property name="addrtable_load_state_control" object="0x01" id="0x05">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="assoctable_load_state_control" object="0x02" id="0x05">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="application_load_state_control" object="0x03" id="0x05">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="application_run_state_control" object="0x03" id="0x06">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="app_version" object="0x03" id="0x0D">        
            <type>GENERIC05</type>        
            <read_access>FREE</read_access>        
        </property>        
        
        
        <group name="Allgemein"> 
                
            <!-- options = mit '|' getrennte key=value Liste. Nutzbar für DropDown Listen etc. -->
            <property name="object="11" id="1">
                <description>Verhalten nach Busspannungsausfall</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
            
            <property object="11" id="2">
                <description>Helligkeitswert nach Busspannungsausfall (0=0%, 255=100%)</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="127" min="0" max="100"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
            
            <property object="11" id="3">
                <description>Verhalten nach Busspannungswiederkehr</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>

            <property object="11" id="4">
                <description>Helligkeitswert nach Busspannungswiederkehr (0=0%, 255=100%)</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="127"/> <!-- kein Mapping, dafür gibt es die DPTs -->
                <condition object="11" id="3" value="3"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
            
            <property object="12" id="1">
                <description>Kanal A verwenden</description>
                <value pdt="UNSIGNED_CHAR" dpt="1" default="0"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
        
        </group>
        
        <group name="Kanal A">
            <condition object="12" id="1" value="1"/>  <!-- Nur zeigen, wenn aktiviert -->
            <property object="20" id="1">
                <description>Dimmgeschwindigkeit</description>
                <value pdt="UNSIGNED_CHAR" dpt="9" default="10.0 min="1.0" max="100.0"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>
            </property>
            <property object="20" id="2">
                <description>Maximale Helligkeit</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="255"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>
            </property>
        </group>
        <group name="Kanal B">
        </group>
        <group name="Kanal C">
        </group>
        <group name="Kanal D">
        </group>
        <group name="Kanal E">
        </group>
        <group name="Kanal F">
        </group>
    </properties>
    <tables location="memory">
        <addr-table entries="4" address="0xD000"/>
        <assoc-table entries="8" address="0xE000"/>
    </tables>
<!-- Alternative -->
    <tables location="properties"/>
    <key>00 DE AD BE EF</key>
</device-description>

• Ich habe einige deiner Ideen näher an den Standard geschoben ("uint8"->"UNSIGNED_CHAR").
• Meine Strukturierungsebene "Objekt" ist entfallen.
• Die Device-Info am Anfang entspricht dem, was in der BCU2 definiert ist.
• Für Umrechnungsvorschriften gibt es die DPTs, da möchte ich nichts hinzuerfinden. Deine Skalierung ist deswegen rausgeflogen, ggf. müsstest du auf DPT9 gehen, um 0-100 realisieren zu können.
• Für Dropdowns habe ich deinen Ansatz übernommen. Bernhards Idee, das aufs Objekt zu beziehen, macht mich nicht glücklich; hier werden m.E. zwei Dinge vermischt, die nicht zusammengehören.
• Deine Idee mit den Gruppen habe ich ebenfalls eingebaut. Es gibt hier zusätzlich noch die "Condition". Properties werden nur dann angezeigt, wenn die entsprechende Condition erfüllt ist.
  Geschachtelte Gruppen würde ich nicht implementieren, ich habe keine rechte Lust auf rekursive Funktionen.
• Aus deinem Vorschlag zu den Tables bin ich nicht so recht schlau geworden. Ich habe jetzt einfach etwas eingeführt, wobei ich den Ansatz "alles in Objekt=KO, Property 0" beibehalten habe.
• Mit der Speicherung in diesem Format habe ich mich nicht beschäftigt. Ich schlage vor, dass du einen eigenen Tag (z.B. "saved-data") einführst. Im Qt-Tool würde ich das beim Lesen einfach ignorieren.

Leider bist du auf meine Nachfrage wieso das nicht ganz optimal ist (noch) nicht eingegangen. Deshalb hier nochmal explizit danach gefragt.

Sorry, wenn das nicht rüberkam. Ich hatte PDT (Datentyp) und DPT (Umrechnungsvorschrift) gemeint. Der Standard trennt beides. Ich hätte es bevorzugt, wenn man beides in eines kombiniert hätte.

Hab mir das Ganze nochmal genauer angeschaut und je länger ich nachdenke umso mehr treibt es mich in Richtung "Standard" und damit weiter weg von der "Selbsterklärenden" XML Struktur.

Kann ich voll und ganz nachvollziehen. Würden wir es schaffen, alternativ zu o.g. Vorschlag das XML-Format der .knxprod zu lesen?

Hätte als Vorteil, dass man die ETS nicht mehr bräuchte

Max

[Bernator]

Kann ich voll und ganz nachvollziehen. Würden wir es schaffen, alternativ zu o.g. Vorschlag das XML-Format der .knxprod zu lesen?

Ich würd sogar sagen .knxproj, dann muss man sich nicht mal mehr überlegen wo man die Sachen hinschreibt
Im Prinzip ist alles Obige in irgend einer Form vorhanden, teilweise sind zwar Elemente deren Nutzen ich noch nicht nachvollziehen kann aber die könnte man Anfangs auch einfach mal ignorieren.

Hättest du mir das Dokument mal vorher gezeigt :P Btw. wo saugst du dir das immer her, gibts da noch mehr?

Hab immer noch nicht verstanden was an KNX offen ist und was nicht

[l0wside]

Hättest du mir das Dokument mal vorher gezeigt :P Btw. wo saugst du dir das immer her, gibts da noch mehr?

Welches Dokument? Der Vorschlag oben ist aus eigenem Hirnschmalz sowie dem Input aus Köglers BCU2, Alex´ Format, deinen Ideen, diversen .knxprod und meinen früheren Ansätzen entstanden.

Max

[Bernator]

Die xml Doku von der Konnex hab ich gemeint....

[l0wside]

Die xml Doku von der Konnex hab ich gemeint....

Ach so.
Bei Siemens oder MDT oder wem auch immer eine .knxprod (für ETS4) runterladen - das sind einfache Zip-Dateien ohne Passwort. Darin liegen diverse XML-Dateien, in denen die Konfiguration dokumentiert ist.

Man muss das nur noch verstehen.

Max

[Bernator]

Ja das hab ich auch schon rausgefunden, gibts davon noch mehr?

[l0wside]

Ja das hab ich auch schon rausgefunden, gibts davon noch mehr?

Keine Ahnung, bin per Google dorthin gekommen, indem ich nach einem der Stichworte im knxprod gesucht hatte. Viel mehr scheint es aber dort nicht zu geben, google mal nach "pdf site:http://www.knx.org/fileadmin/support_files/"
Ein bisschen was steht auch noch hier.

Max

[tuxedo]

Gründe:
- sobald es ein wenig komplexer wird werden "unmengen" KO's benötigt

Und wo steht dass ein eigenes Format das nicht sauber handhaben kann?

- im "Standard" ist bereits viel KnowHow reingeflossen den man einfach verschenken würde
- Anfangs überblickt man meist nicht die gesamte Tragweite bestimmter Konventionen, daher ist es oft so das nachträglich Sachen reingepfuscht werden die es wieder unübersichtlich machen

Genau die Erfahrung hab ich gemacht. Und zwar in den letzten 10 Jahren bei 3 Firmen. Weißt du wie oft ich schon "ist historisch so gewachsen" hab hören müssen? Ich kann mir nicht vorstellen dass das bei der Konnex anders läuft. Schon gar nicht wenn man seit "Jahrzehnten" ein System kompatibel halten muss.

Es ist also nicht gesagt dass der KNX Standard das non-plus-ultra ist.

- selbst eine einfache Struktur ist warscheinlich nicht selbsterklärend daher brauchts eine Dokumentation, beim "Standard" schon vorhanden

Das ist jetzt nicht dein ernst? Hast du dir mal angeschaut wie komplex die .knxprod/.knxproj Files sind? Und wieviele Seiten Doku es dazu gibt?

Unsere bisherigen Formatvorschläge sind in 5min erklärt. Die Doku, damit man weiß wie das Format aussieht passt sicher auf 2 DinA4 Seiten.

Du hast doch deinen Sechskanaldimmer, d.h. sechs Mal die gleichen Parameter. Willst du dann sechs Mal Copy&Paste machen?

6 Identische Options sind noch überschaubar. Eine weitere Objektreferenz und -struktur ist IMHO nicht mehr so schnell zu überschauen. Bei einem 20 oder 50 Kanal Dimmer würde ich dir aber sofort recht geben.

Bei mir ist es im Moment Pflicht. Unumgänglich ist es allerdings nur für die Flags (die sind fix an Property 0, Index 0 des jeweiligen Objekts). Auch die Property-Schnittstelle für die GAs verwendet diese Festlegung.

Schau ich mir dann nochmal an.

Ich habe jetzt mal versucht, deine Ansätze mit meinen zu verheiraten.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<device-description version="1.0"> 
    <manufacturer-id>0x001</manufacturer-id>
    <!-- Lesbarer Name des Herstellers, Optional -->
    <manufacturer>root1.de</manufacturer>
    <!-- Liste kompatibler Devices, Order code: 10 byte hex, mask version: 2 byte hex, app version: 5 byte hex -->
    <devices>
        <device order-info="0xCAFE4711AB1234567890" mask-version="0x0701" app-version="0x0102030405">
        <device order-info="0xCAFE4711AB1234567890" mask-version="0x0701" app-version="0x0211ABFA1C">
        <device order-info="0x123456789ADEAFBEAD00" mask-version="0x0201" app-version="0x0176234EAF">
    </devices>
    <!-- Lesbarer Gerätename, Optional -->
    <name>6CH KNX PWM LED Controller</name>  
    <!-- 
        Beschreibt die KOs (informell für den Anwender) und 
        legt den Speicherort der zugehörigen GAs fest
    -->
    <commobjects>
        <commobject id="10">
            <description>Schalten Ein/Aus Kanal A</description> <!-- In Anlehnung an die "Kommunikationsobjecte" Spalte unter "Geräte" in der ETS -->
            <dpt>1</dpt>  <!-- DPT 1 ist Schalten -->
            <pdt>UNSIGNED_CHAR</pdt> <!-- DPT1 kann IIRC auf UNSIGNED_CHAR und auf GENERIC01 abgebildet werden. -->
            <property name="flags" id="0"> <!-- Der Teil kann bei dir mit fixen Flags auch einfach entfallen -->
                <type>GENERIC01</type>
                <read_access>FREE</read_access>
                <write_access>CONFIG</write_access>
            </property>
            <condition object="5" property="1" min_value="1" max-value="5"/>  <!-- Optional. Communication Object steht nur zur Verfügung, wenn Object 5, Property 1 >= 1 und <= 5 ist.  -->
        </commobject>
        <commobject id="11">
            <description>Dimmkontrolle Kanal A</description>
            <dpt>3</dpt>
            <pdt>UNSIGNED_CHAR</pdt>
            <property name="flags" id="0">
                <type>GENERIC01</type>
                <read_access>FREE</read_access>
                <write_access>CONFIG</write_access>
            </property>
        </commobject>
        <commobject id="12">
            <description>Absolutwert Kanal A</description>
            <dpt>5</dpt>
            <pdt>UNSIGNED_CHAR</pdt>
            <property name="flags" id="0">
                <type>GENERIC01</type>
                <read_access>FREE</read_access>
                <write_access>CONFIG</write_access>
            </property>
        </commobject>
    </commobjects>

    <!--
        Parameter des Geräts, ggf. gruppiert.
        Legt deren Speicherort fest und zeigt Default-Werte
    -->
    <properties>  <!-- "Parameter" gibt es m.W. bei KNX nicht, der Standard spricht von "Properties" -->
        <!-- 
            <group> = Gruppierung der Parameter, z.B. in einem 
            Parameter-"Baum" in der Anwendung. Könnte man theoretisch auch 
            ineinander verschachteln: "group in group"
        -->
        <!-- Die folgenden Properties sind notwendig, um die Gerätedaten an der passenden Stelle abzurufen.
             Alternativ könnte man sie hart kodieren, das fände ich aber unschön. -->
        <property name="device_object_type" object="0x00" id="0x01">
            <type>UNSIGNED_INT</type>
            <read_access>FREE</read_access>
            <default>0x00</default>
        </property>
        <property name="device_control" object="0x00" id="0x0E" dynamic="true">
            <type>GENERIC01</type>
            <read_access>FREE</read_access>
            <write_access>CONFIG</write_access>
            <default>0x00</default>
        </property>
        <property name="service_control" object="0x00" id="0x08">        
            <type>UNSIGNED_INT</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
            <default>0x00</default>        
        </property>        
        <property name="firmware_revision" object="0x00" id="0x09">        
            <type>UNSIGNED_CHAR</type>        
            <read_access>FREE</read_access>        
            <default>0x01</default>        
        </property>        
        <property name="serial_number" object="0x00" id="0x0B">        
            <type>GENERIC06</type>        
            <read_access>FREE</read_access>        
        </property>        
        <property name="manufacturer_id" object="0x00" id="0x0C">        
            <type>UNSIGNED_INT</type>        
            <read_access>FREE</read_access>        
        </property>        
        <property name="order_info" object="0x00" id="0x0F">        
            <type>GENERIC10</type>        
            <read_access>FREE</read_access>        
        </property>        
        
        <property name="manufacture_id" object="0x00" id="0x13">        
            <type>GENERIC04</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        

        <property name="addrtable_load_state_control" object="0x01" id="0x05">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="assoctable_load_state_control" object="0x02" id="0x05">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="application_load_state_control" object="0x03" id="0x05">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="application_run_state_control" object="0x03" id="0x06">        
            <type>CONTROL</type>        
            <read_access>FREE</read_access>        
            <write_access>CONFIG</write_access>        
        </property>        
        <property name="app_version" object="0x03" id="0x0D">        
            <type>GENERIC05</type>        
            <read_access>FREE</read_access>        
        </property>        
        
        
        <group name="Allgemein"> 
                
            <!-- options = mit '|' getrennte key=value Liste. Nutzbar für DropDown Listen etc. -->
            <property name="object="11" id="1">
                <description>Verhalten nach Busspannungsausfall</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
            
            <property object="11" id="2">
                <description>Helligkeitswert nach Busspannungsausfall (0=0%, 255=100%)</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="127" min="0" max="100"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
            
            <property object="11" id="3">
                <description>Verhalten nach Busspannungswiederkehr</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>

            <property object="11" id="4">
                <description>Helligkeitswert nach Busspannungswiederkehr (0=0%, 255=100%)</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="127"/> <!-- kein Mapping, dafür gibt es die DPTs -->
                <condition object="11" id="3" value="3"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
            
            <property object="12" id="1">
                <description>Kanal A verwenden</description>
                <value pdt="UNSIGNED_CHAR" dpt="1" default="0"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>
        
        </group>
        
        <group name="Kanal A">
            <condition object="12" id="1" value="1"/>  <!-- Nur zeigen, wenn aktiviert -->
            <property object="20" id="1">
                <description>Dimmgeschwindigkeit</description>
                <value pdt="UNSIGNED_CHAR" dpt="9" default="10.0 min="1.0" max="100.0"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>
            </property>
            <property object="20" id="2">
                <description>Maximale Helligkeit</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="255"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>
            </property>
        </group>
        <group name="Kanal B">
        </group>
        <group name="Kanal C">
        </group>
        <group name="Kanal D">
        </group>
        <group name="Kanal E">
        </group>
        <group name="Kanal F">
        </group>
    </properties>
    <tables location="memory">
        <addr-table entries="4" address="0xD000"/>
        <assoc-table entries="8" address="0xE000"/>
    </tables>
<!-- Alternative -->
    <tables location="properties"/>
    <key>00 DE AD BE EF</key>
</device-description>

So auf den ersten Blick kommen wir uns näher ;-)

* Ich habe einige deiner Ideen näher an den Standard geschoben ("uint8"->"UNSIGNED_CHAR").

Ist okay. Aber so richtig verstanden habe ich nicht warum ich das doppelt angeben muss.

* Die Device-Info am Anfang entspricht dem, was in der BCU2 definiert ist.

Damit kann ich leben.

* Für Umrechnungsvorschriften gibt es die DPTs, da möchte ich nichts hinzuerfinden. Deine Skalierung ist deswegen rausgeflogen, ggf. müsstest du auf DPT9 gehen, um 0-100 realisieren zu können.

Die Skalierung hab ich mittlerweile auch entsorgt. Lieber nehme ich den vollen Datentyp-Range und rechne selbst um.

* Für Dropdowns habe ich deinen Ansatz übernommen. Bernhards Idee, das aufs Objekt zu beziehen, macht mich nicht glücklich; hier werden m.E. zwei Dinge vermischt, die nicht zusammengehören.

Super.

* Deine Idee mit den Gruppen habe ich ebenfalls eingebaut. Es gibt hier zusätzlich noch die "Condition". Properties werden nur dann angezeigt, wenn die entsprechende Condition erfüllt ist.
Geschachtelte Gruppen würde ich nicht implementieren, ich habe keine rechte Lust auf rekursive Funktionen.

Deine Conditions habe ich nur halb verstanden.

<condition object="12" id="1" value="1"/>  <!-- Nur zeigen, wenn aktiviert -->
            <property object="20" id="1">
                <description>Dimmgeschwindigkeit</description>
                <value pdt="UNSIGNED_CHAR" dpt="9" default="10.0 min="1.0" max="100.0"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>
            </property>

Ich nehme an "object=12" meint --> Objekt mit ID 12, sowie "id=1" meint --> Property mit ID 1.
Vorschlag:

<condition objectid="12" propertyid="1" value="1"/>

Und was schaltet die Condition jetzt frei? Basierend auf einem Property-Wert eine andere Property? Oder basierend auf einem Property-Wert ein CommObject? Brauchen könnte man ggf. beides?

* Aus deinem Vorschlag zu den Tables bin ich nicht so recht schlau geworden. Ich habe jetzt einfach etwas eingeführt, wobei ich den Ansatz "alles in Objekt=KO, Property 0" beibehalten habe.

Du hast es explizit geläst (table location)... Mein Ansatz wäre ein impliziter gewesen:

Entweder

<tables>
        <addr-table entries="4" address="0xD000"/>
        <assoc-table entries="8" address="0xE000"/>
    </tables>

ist angegeben, dann gibt es kein weitere angabe von property/object. Oder eben dieser Abschnitt fehlt, dann ist an anderen besagten Stellen Object/Property angegeben.

Aber ich denke damit könnte ich auch leben.

* Mit der Speicherung in diesem Format habe ich mich nicht beschäftigt. Ich schlage vor, dass du einen eigenen Tag (z.B. "saved-data") einführst. Im Qt-Tool würde ich das beim Lesen einfach ignorieren.

War ja schon mein Vorschlag in meinem letzten Formatvorschlag.

Sorry, wenn das nicht rüberkam. Ich hatte PDT (Datentyp) und DPT (Umrechnungsvorschrift) gemeint. Der Standard trennt beides. Ich hätte es bevorzugt, wenn man beides in eines kombiniert hätte.

Ich muss wohl auf dem Schlauch stehen. Wenn ich mir die DPT Doku anschaue, dann habe ich bei den "ganzzahligen" DPTs (z.B. 1) eine exakte Beschreibung des Datentyps und wie dieser in den einzelnen Bits kodiert ist. Dann gibt's untergeordnete Beschreibungen wie der besagte Typ nun verwendet wird (z.B. 1.001).
Unterm Strich reicht doch das "ganzzahlige"?!

Kann ich voll und ganz nachvollziehen. Würden wir es schaffen, alternativ zu o.g. Vorschlag das XML-Format der .knxprod zu lesen?

Hätte als Vorteil, dass man die ETS nicht mehr bräuchte

Die Doku hab ich mir schon einmal reingezogen. Furchtbar schwere Kost. Wäre zwar unheimlich toll wenn man das Format vollständig lesen könnte (auch .knxproj) und somit eine ETS Alternative hätte (endlich keine Windows VM mehr für die ETS ...). Aber solange man nicht eine ETS Alternative kommerziell an den Mann bringen will (für sagen wir die hälfte des Preises damit's auch attraktiv ist) muss man sich fragen: Lohnt sich der Aufwand?
Wir reden hier immer noch von Bastel-Projekten die keine KNX Zertifizierung erlangen und höchstens in Kleinstückzahl verschachert wird. Da wäre der eigene Formatansatz in meinen Augen der geschicktere Weg.

Aber seeehr langfristig gesehen wäre es schon toll .knxprod/.knxproj lesen und schreiben zu können.

Ich verschwinde dann mal wieder auf der Baustelle... die Fliesen in der Küche warten auf mich.

Gruß
Alex

[Bernator]

Und wo steht dass ein eigenes Format das nicht sauber handhaben kann?

Natürlich kann das auch ein eigenes Format aber das ist dann auch nicht mehr einfach lesbar. Stichwort: Objektreferenzen

Genau die Erfahrung hab ich gemacht....kann mir nicht vorstellen dass das bei der Konnex anders läuft.

Läuft überall gleich, kann ich bestätigen aber das ist für mich kein Argument dagegen!

Das ist jetzt nicht dein ernst? Hast du dir mal angeschaut wie komplex die .knxprod/.knxproj Files sind? Und wieviele Seiten Doku es dazu gibt?

Ja habe ich und ich gebe zu sie sind umfangreich aber komplexes hab ich nicht gefunden?

Unsere bisherigen Formatvorschläge sind in 5min erklärt. Die Doku, damit man weiß wie das Format aussieht passt sicher auf 2 DinA4 Seiten.?

Du musst hier nichts verteidigen, ich sehe ja ein das es für "simple" Sachen einfacheres gibt und wenn dein Ziel ein schlankes, lesbares xml ist dann ist das hier sicher schon der richtige Weg.
Wie gesagt sind die beiden Ansätze nicht wirklich "kompatibel" daher machen 2 Formate durchaus Sinn und im ersten Schritt ist das "einfache" sicher schneller erreicht von daher finde ich das schon gut.

Trotzdem hier eine kurze Gegenüberstellung:

<properties>  <!-- "Parameter" gibt es m.W. bei [URL="http://redaktion.knx-user-forum.de/lexikon/KNX/"][U][COLOR=#0066cc]KNX[/COLOR][/U][/URL] nicht, der Standard spricht von "Properties" -->
        <property name="object="11" id="1">

stimmt eigenlich nicht, dort schauts so aus:

<Parameters>
    <Parameter Id="P-1" Name="Busspannungsausfall" ParameterType="PT-2" Text="Verhalten nach Busspannungsausfall" Value="2" Access="ReadWrite">
       <Property ObjectIndex="11" PropertyId="1" Offset="0" BitOffset="0" Occurrence="0" />

wobei hier die Auswahlmöglichkeiten des Parameter nicht direkt definiert werden sondern nur ein "Link" auf einen ParameterType angegeben wir welcher dies dann beschreibt und wie folgt ausschaut:

<ParameterTypes>
 <ParameterType Id="PT-2" Name="AuswahlBusspannungsausfall" InternalDescription="">
  <TypeRestriction Base="Value" SizeInBit="8">
    <Enumeration Text="Aus" Value="0" Id="PT-2_EN-1" DisplayOrder="0" />
    <Enumeration Text="An" Value="1" Id="PT-2_EN-2" DisplayOrder="1" />
    <Enumeration Text="letzter Wert" Value="2" Id="PT-2_EN-3" DisplayOrder="2" />
    <Enumeration Text="Helligkeitswert" Value="3" Id="PT-2_EN-4" DisplayOrder="3" />
  </TypeRestriction>   
 </ParameterType>

Die Paramter tauchen nicht direkt im Menü auf sondern nur songenannte ParameterReferenzen welche wie folgt definiert werden:

<ParameterRefs>
 <ParameterRef Id="P-1_PR-1" RefId="P-1"/>
 <ParameterRef Id="P-1_PR-2" RefId="P-1"/>
 ....

Die Menüstruktur ist kein "Child" der Parameters sondern taucht anderweitig auf und schaut dann so aus:

<ParameterBlock Id="CH-0_PB-1" Name="Allgemein" ParamRefId="PR-4" Access="ReadWrite">
 <choose ParamRefId="PR-4">
  <when default="true"> <!-- Dummy Auswahl die immer true ist -->
   <ParameterRefRef RefId="P-1_PR-1" /> <!-- Parameter Referenzen AuswahlBusspannungsausfall angezeigen -->
   <choose ParamRefId="P-1_PR-1"> <!-- Parameterwert auswerten -->
    <when test="0" default="false"> <!-- Aus Ausgewählt -->
    </when>
    <when test="1" default="false"> <!-- An Ausgewählt -->
    </when>
    <when test="2" default="false"> <!-- letzter Wert Ausgewählt -->
    </when>
    <when test="2" default="false"> <!-- Helligkeitswert Ausgewählt -->
    </when>
   </choose>
  </when>
 </choose>
</ParameterBlock>
<ParameterBlock Id="CH-0_PB-2" Name="Digital Output 1" ParamRefId="PR-4" Access="ReadWrite">
...
...

Parametertypen etc. können damit öfter verwendet werden und es ist nahezu überall möglich div. Angaben zu machen (Text="xxx") welche dann in der Hierachiesturkur nach oben hin niedrigere Prioritäten bekommen fals doppelt angegeben.

Die ID's sind übrigends im gesamten xml eindeutig und bauen sich aus parentID_ID zusammen, ist hauptsächlich bei der Übersetztung praktisch weil somit jedes Element (egal wo) eindeutig identifiziert werden kann und somit die Language Struktur flach bleiben kann.

[tuxedo]

Ja habe ich und ich gebe zu sie sind umfangreich aber komplexes hab ich nicht gefunden?

Okay. Komplex ist relativ. Umfangreich in dem Maße würde ich aber mit komplex gleichsetzen.

Du musst hier nichts verteidigen

Na wenn wie uns einig sind dass es 2Welten gibt dann passt das ja.

Trotzdem hier eine kurze Gegenüberstellung:

<properties>  <!-- "Parameter" gibt es m.W. bei [URL="http://redaktion.knx-user-forum.de/lexikon/KNX/"][U][COLOR=#0066cc]KNX[/COLOR][/U][/URL] nicht, der Standard spricht von "Properties" -->
        <property name="object="11" id="1">

stimmt eigenlich nicht, dort schauts so aus:

<Parameters>
    <Parameter Id="P-1" Name="Busspannungsausfall" ParameterType="PT-2" Text="Verhalten nach Busspannungsausfall" Value="2" Access="ReadWrite">
       <Property ObjectIndex="11" PropertyId="1" Offset="0" BitOffset="0" Occurrence="0" />

Super. Dann lag ich nicht so falsch.
@l0wside
Wie siehts aus? Lässt du dich nun überzeugen?
Parameter wäre standard und dem Benutzer schon aus ETS bekannt ;-)

[l0wside]

Es ist also nicht gesagt dass der KNX Standard das non-plus-ultra ist.

Das ist er sicher nicht, aber andererseits haben sich da ein paar schlaue Leute ziemlich genau die Gedanken gemacht, die wir uns gerade machen.

Das ist jetzt nicht dein ernst? Hast du dir mal angeschaut wie komplex die .knxprod/.knxproj Files sind? Und wieviele Seiten Doku es dazu gibt?

Hast du die Doku dazu? Ich habe sie nicht.

Ich fände es nicht schlecht, vorläufig auch nur ein Subset der .knxprod lesen zu können, das man nach und nach auf eine volle Version erweitern könnte. Priorität hat aber, überhaupt mal etwas ans Laufen zu bekommen.

Unsere bisherigen Formatvorschläge sind in 5min erklärt. Die Doku, damit man weiß wie das Format aussieht passt sicher auf 2 DinA4 Seiten.

Schreibst du die Doku?

Ist okay. Aber so richtig verstanden habe ich nicht warum ich das doppelt angeben muss.

Genau das meinte ich mit "Standard ist nicht optimal". Aber ich kann damit leben; das Qt-Tool prüft beim Import, ob die Paarung DPT/PDT zulässig ist.

Deine Conditions habe ich nur halb verstanden.

Nein, du hast sie ganz richtig verstanden. Auf Basis einer Property wird eine andere Property oder ein Kommunikationsobjekt freigeschaltet.
Ich würde die Benennung wie folgt machen:

<property name="device_object_type" object-id="0x00" property-id="0x01">

Wie wir die Tables lösen, ist mir ziemlich egal. Eine explizite Angabe hat den Vorteil, dass Tippfehler o.ä. keine seltsamen side effects produzieren, das war´s aber auch.

Ich muss wohl auf dem Schlauch stehen. Wenn ich mir die DPT Doku anschaue, dann habe ich bei den "ganzzahligen" DPTs (z.B. 1) eine exakte Beschreibung des Datentyps und wie dieser in den einzelnen Bits kodiert ist. Dann gibt's untergeordnete Beschreibungen wie der besagte Typ nun verwendet wird (z.B. 1.001).
Unterm Strich reicht doch das "ganzzahlige"?!

Ich verwende zusätzlich noch DPT9. Meine Kritik bezog sich auf den Standard, nicht auf deine Vorschläge.
Vermutlich könnte man die PDTs auch implizit aus den DPTs ableiten. Ich versuche mal wieder, mich am Standard zu orientieren.

Ich verschwinde dann mal wieder auf der Baustelle... die Fliesen in der Küche warten auf mich.

Ah, daher die Motivation zur reichlich trockenen Formatdiskussion. Ich habe irgendwo noch einen Hunderterpack Fliesenkreuze, die nie benutzt wurden - aber du kannst das sicher auch ohne

Wie gesagt sind die beiden Ansätze nicht wirklich "kompatibel" daher machen 2 Formate durchaus Sinn und im ersten Schritt ist das "einfache" sicher schneller erreicht von daher finde ich das schon gut.

Ich würde im Moment trotzdem eher auf das eigene Format setzen. Es spricht nichts dagegen, dass das Qt-Tool langfristig beide Formate lesen kann. Vollständige Unterstützung der .knxprod steht in meiner Prioritätenliste aber ziemlich weit hinten, genaugenommen noch hinter "Produkt zertifizieren und eigene Produktdatenbank erstellen".

Was "Properties" vs. "Parameters" angeht: welches Schweinderl hätten´s denn gern? Es ist mir völlig egal, das ist per Search&Replace in ein paar Minuten geändert.

Zu den Dropdown-Verknüpfungen: auch hier sehe ich keine grundlegende Schwierigkeit, beides zu unterstützen. Das könnte dann z.B. so aussehen:

            <property name="object="11" id="1">
                <description>Verhalten nach Busspannungsausfall</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </property >
            <property object="11" id="3">
                <description>Verhalten nach Busspannungswiederkehr</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" optionlist="busspannungsfehler"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>

<optionlists>
  <optionlist name="busspannungsfehler">
    <option name="Aus" value="0"/>
    <option name="An" value="1"/>
    <option name="Letzter Wert" value="2"/>
  </optionlist>
</optionlists>

Das ist jetzt nur ein schneller Schuss, es geht sicher auch besser und knxprod-ähnlicher als mit der "optionlist".

Gruß,

Max

[tuxedo]

Das ist er sicher nicht, aber andererseits haben sich da ein paar schlaue Leute ziemlich genau die Gedanken gemacht, die wir uns gerade machen.

Hast du die Doku dazu? Ich habe sie nicht.

Ja, die haben sich schon Gedanken gemacht. Die haben aber auch ein gewachsenes System. Unter Umständen würde man, wenn man "from scratch" anfängt so einiges anders machen, was aber nicht geht weil man abwärtskompatibel bleiben muss.

Die Spec für die KNX XML Files hatte ich mal irgendwo rumfahren. Muss mal schauen wo ich das archiviert habe ...

Ich fände es nicht schlecht, vorläufig auch nur ein Subset der .knxprod lesen zu können, das man nach und nach auf eine volle Version erweitern könnte. Priorität hat aber, überhaupt mal etwas ans Laufen zu bekommen.

Ja erst hat es unterste Prio, und dann wäre vorläufig ein Subset davon "brauchbar". Ja wie denn nun? Oder bezieht sich das "vorläufig" auf "in Zukunft mal"?

Schreibst du die Doku?

Nach aktueller Lage wäre die ja nicht allzu umfangreich. Wenn das Format steht, dokumentier ichs gerne.

Genau das meinte ich mit "Standard ist nicht optimal". Aber ich kann damit leben; das Qt-Tool prüft beim Import, ob die Paarung DPT/PDT zulässig ist.

Öhm....

Aber so richtig verstanden habe ich nicht warum ich das doppelt angeben muss.

Das bezog sich auf dein Format. Da muss man's zweimal angeben... Wieso? DPT finde ich schon präzise genug. Oder kennst du mehrere Möglichkeiten z.B. DPT5 zu kodieren?

Nein, du hast sie ganz richtig verstanden. Auf Basis einer Property wird eine andere Property oder ein Kommunikationsobjekt freigeschaltet.
Ich würde die Benennung wie folgt machen:

<property name="device_object_type" object-id="0x00" property-id="0x01">

Ich muss Tomaten auf den Augen haben. Hast du jetzt Condition mit Property verwechselt?

<condition objectid="12" propertyid="1" value="1"/>

Ich komm mit deiner benennung einfach nicht klar... Nenn mich einen Erbsenzähler. Aber wenn deine Parameter "Properties" und nicht "Parameter" heissen und über Objekte und Properties abgelegt werden und Attribute die "object" heissen dann KOs meint (oder auch nicht?)...Da krieg ich einen Knoten in meinen Hirnwindungen.


Ich versuch's mal zu sortieren:

Wenn man bei den KOs (egal wie man sie jetzt im XML nennt) im jeweiligen KO Knoten eine Bedingung hat, dann wird diese Bedingung sich auf einen Parameter beziehen.

Dann wäre es doch sinnvoll das so zu machen:

<condition parameterid="1" minvalue="1" maxvalue="5"/>

Ich hab das Attribut mal ganz frech "parameterid" genannt. Da jeder Parameter idealerweise auch eine ID hat, muss man ja nicht objekt/property referenzieren.

minvalue/maxvalue ... Vielleicht fällt uns hier noch etwas praktischeres ein. Eine Art Beschreibungssprache statt mehrere Attribute kombinieren zu müssen. value="between(1-5)" oder sowas?! Wäre ggf. flexibler. Für den Anfang käme ich aber wohl auch nur mit einem Fixwert aus (value=3).


Und wenn eine Condition in einem Parameter-Knoten sitzt, dann heisst das: Dieser Parameter ist bedingt durch einen bestimmten Wert eines anderen Parameters. Format wie eben genannt.
Vielleicht hattest du auch genau das gemeint (abgesehen von der "kurzen" Referenzierung über die Parameter-Id) und ich hab das nach der Inhalation von zu viel Lösungsmittel beim Streichen der Stahlwangentreppe (war nach den Fliesen dran) einfach übersehen?!

Wie wir die Tables lösen, ist mir ziemlich egal. Eine explizite Angabe hat den Vorteil, dass Tippfehler o.ä. keine seltsamen side effects produzieren, das war´s aber auch.

Okay, dann bleiben wir mal bei deinem Vorschlag.

Ich verwende zusätzlich noch DPT9. Meine Kritik bezog sich auf den Standard, nicht auf deine Vorschläge.
Vermutlich könnte man die PDTs auch implizit aus den DPTs ableiten. Ich versuche mal wieder, mich am Standard zu orientieren.

Ähm... Wo ist jetzt nochmal der Unterschied DPT <-> PDT?

Weil: DPT9 = 2 byte float value ...
In deinem XML steht noch ergänzend dabei pdt="unsigned_char" ... Beisst sich doch.

Entweder du brauchst ein 2 byte float Wert, oder du brauchst unsigned_char... Das in DPT gesprochen 1 byte und das noch unsigned... Also DPT5 ...
Entweder, oder. Beides passt für mich nicht zusammen.

Ah, daher die Motivation zur reichlich trockenen Formatdiskussion. Ich habe irgendwo noch einen Hunderterpack Fliesenkreuze, die nie benutzt wurden - aber du kannst das sicher auch ohne

Trocken ist anders :-) Heute war's eher kurz. In der kurzen Verschnaufpause auf der Baustelle mit dem Smartphone der Diskussion beizuwohnen war nicht ganz einfach. Deshalb war's etwas kürzer.
Fliesenkreuze hab ich zu genüge. Und nein, ohne Fliesenkreuze komm ich als fliesenlegender Informatiker nicht wirklich klar ;-)

Was "Properties" vs. "Parameters" angeht: welches Schweinderl hätten´s denn gern? Es ist mir völlig egal, das ist per Search&Replace in ein paar Minuten geändert.

Da die Kommobjekte schon "commobject" heißen, und sowohl in der ETS als auch in deren Format die Parameter "parameter" heißen, plädiere ich als Ersenzähler für "parameter" bzw "parameters".

Zu den Dropdown-Verknüpfungen: auch hier sehe ich keine grundlegende Schwierigkeit, beides zu unterstützen. Das könnte dann z.B. so aussehen:

            <property name="object="11" id="1">
                <description>Verhalten nach Busspannungsausfall</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </property >
            <property object="11" id="3">
                <description>Verhalten nach Busspannungswiederkehr</description>
                <value pdt="UNSIGNED_CHAR" dpt="5" default="2" optionlist="busspannungsfehler"/>
                <read_access>FREE</read_access>        
                <write_access>CONFIG</write_access>        
            </parameter>

<optionlists>
  <optionlist name="busspannungsfehler">
    <option name="Aus" value="0"/>
    <option name="An" value="1"/>
    <option name="Letzter Wert" value="2"/>
  </optionlist>
</optionlists>

Das ist jetzt nur ein schneller Schuss, es geht sicher auch besser und knxprod-ähnlicher als mit der "optionlist".

Find ich gut. würde nur <optionlist name=".... zu <optionlist id=".... machen. Ob man dann eine ID-Zahl, oder eine textuelle ID wählt ist Geschmackssache. Hat beides seine Vorteile. Nur eindeutig sollte es unter den optionlists sein. Wobei mit ein Integer als ID lieber wäre. Macht den Code ein wenig "besser" (Achtung: Meckern auf hohem Niveau).

Gruß
Alex

[l0wside]

Hallo Alex,

am liebesten würde ich ja ein großes Whiteboard nehmen und uns zu dritt davorstellen, aber das ist geografisch vor allem für Bernhard blöd. Für uns beide wäre Heilbronn vermutlich halbe Strecke. Alternativ ginge auch Openmeeting o.ä. - kann das jemand aufsetzen?

Ja, die haben sich schon Gedanken gemacht. Die haben aber auch ein gewachsenes System.
[...] Die Spec für die KNX XML Files hatte ich mal irgendwo rumfahren. Muss mal schauen wo ich das archiviert habe ...

Ich denke, das Format bei der ETS4 ist komplett neu? Oder ist nur die Kodierung verändert?
An der Spec wäre ich interessiert, falls du sie irgendwo also finden solltest...

Ja erst hat es unterste Prio, und dann wäre vorläufig ein Subset davon "brauchbar". Ja wie denn nun? Oder bezieht sich das "vorläufig" auf "in Zukunft mal"?

Das war nach dem Motto: wenn ich nicht überzeugen kann, verwirre ich einfach
Prio 1: Ein lauffähiges Konfigurationstool für meine Multisensoren, mit dem auch ein Windows-Nutzer zurechtkommt.
Prio 2: Möglichst geringe Abweichung vom Standard. In ferner Zukunft sollen meine Geräte mit der ETS konfigurierbar sein, dafür will ich aber nicht die halbe Firmware neu schreiben müssen.
Prio 3: Möglichst weitgehend gemeinsame Entwicklung mit anderen Teilnehmern hier im DIY-Forum, um wenig Arbeit doppelt zu machen.
Prio 4: Verwenden des knxprod-Formats, um mit dem Tool auch Fremdkomponenten konfigurieren und damit die ETS ablösen zu können. Ein Einstieg darin kann auch die Unterstützung eines Subsets des knxprod-Formats sein; das korrespondiert dann mit Prio 2.

Zu PDT/DPT: das habe ich in Calimero ebenfalls so vorgefunden, daran hatte ich mich orientiert. Der KNX-Standard unterscheidet auch zwischen beidem. Siehe Prio 2. Hier geht mir Standardkonformität vor Effizienz. Du kannst ja alternativ, wenn kein PDT angegeben ist, einen Defaultwert aus dem DPT ableiten.
Was machst du aber z.B. bei einer Bitmaske, zu der es gar keinen DPT gibt? Auch bei Strings bin ich mir nicht sicher (zum Nachsehen bin ich gerade zu faul).

Ich muss Tomaten auf den Augen haben. Hast du jetzt Condition mit Property verwechselt?

Nein, das war wieder meine Verwirrungstaktik - zwei Themen in einem Absatz.

• Die Conditions an sich sollten hoffentlich nun verständlich geworden sein.
• Die Benennung der properties bzw. parameters habe ich in Anlehung an deine Ansätze abgeändert

Ich komm mit deiner benennung einfach nicht klar... Nenn mich einen Erbsenzähler. Aber wenn deine Parameter "Properties" und nicht "Parameter" heissen und über Objekte und Properties abgelegt werden und Attribute die "object" heissen dann KOs meint (oder auch nicht?)...Da krieg ich einen Knoten in meinen Hirnwindungen.

Ich habe die Duplizierung von "Kommunikationsobjekt" und "Objekt" (bei den Properties) nicht erfunden. Ich hatte anfangs ja versucht, "KO" = "Property-Objekt" für manche Properties zu setzen, das im letzten Vorschlag aber aufgegeben.

<condition parameterid="1" minvalue="1" maxvalue="5"/>

Ich hab das Attribut mal ganz frech "parameterid" genannt. Da jeder Parameter idealerweise auch eine ID hat, muss man ja nicht objekt/property referenzieren.

Ja, die Referenzierung über eine eigene ID ist sinnvoller als über Object/Property, da hast du recht. Gut, dass wir das diskutiert haben.
Ich würde als ID aber den ohnehin vorhandenen "name" verwenden, auch aus Gründen der Lesbarkeit. Eine integer-ID ist zwar im Lookup im Dict ein bisschen schneller, aber das sollte auf einem aktuellen PC völlig egal sein.
Ein bisschen lesbarer wäre vielleicht

<condition depends-on="after-busvoltage-failure" value="3"/>

Was die Beschreibungssprache angeht: ich kann deinen Drang nach Flexibilität nachvollziehen . Andererseits ist das dann wieder eine Sprache in der anderen, und ich bin mit meinen Codegeneratoren (python erzeugt C, früher auch mal: PHP erzeugt HTML/Javascript) eigentlich schon restlos bedient.
Bernhard, wie ist deine Sicht der Dinge? Vielleicht bringt der Blick auf die Alpen ja noch einen anderen Aspekt?

Und wenn eine Condition in einem Parameter-Knoten sitzt, dann heisst das: Dieser Parameter ist bedingt durch einen bestimmten Wert eines anderen Parameters. Format wie eben genannt.

Exakt. Wenn die Bedingung nicht erfüllt ist, wird der Parameter auf seinen Default-Wert gesetzt. Der muss dann eben entsprechend passen. Oder brauchen wir einen eigenen Default-Wert für "disabled"?

Entweder du brauchst ein 2 byte float Wert, oder du brauchst unsigned_char... Das in DPT gesprochen 1 byte und das noch unsigned... Also DPT5 ...
Entweder, oder. Beides passt für mich nicht zusammen.

Das bezog sich auf "Unterm Strich reicht doch das "ganzzahlige"?!". Forget it.

Ansonsten: "Parameter" statt "Property" und "id" statt "name" sind für mich ok. Ich passe es an. Angepasste Variante kommt.

Max

[Bernator]

Bernhard, wie ist deine Sicht der Dinge? Vielleicht bringt der Blick auf die Alpen ja noch einen anderen Aspekt?

Möglich
Ich denke mit <group>,<condition>, <optionlist> etc. sind wir auf dem besten Weg das Rad neu zu erfinden, brauchts das bei der "einfachen" Konfiguration?
Wenn ja schmeiß ich halt wieder ein das es das im Standard schon in ähnlicher Form gibt also warum nicht gleich so übernehmen?

<group> = <ParameterBlock>
<condition> = <choose><when>
<optionlist> = <ParameterTypes>

Der Einfachheit halber kann man ja auf die <ParameterRefs> und <ComObjectRefs> verzichten und im <ParameterBlock> direkt die Parameter bzw. KOs anführen....
auch könnte man die relevanten Knoten Bezeichnungne übernehemen aber die Struktur flacher halten:

<?xml version="1.0" encoding="UTF-8"?>
<ManufacturerData> 
 <Manufacturer Id="0x001" Name="root1.de"> <!-- Kombination aus Master+ManufactuererData Manufacturer -->
  <ApplicationProgram Id="xy" Name="6CH KNX PWM LED Controller" ApplicationVersion="1" MaskVersion="MV-0021">
   <Code>
    <AbsoluteSegment Id="addr-table" Address="0xD000" Size="4" />
    <AbsoluteSegment Id="assoc-table" Address="0xE000" Size="8" />
   </Code>
    <!--ersetzt die option List-->
   <ParameterTypes>
    <ParameterType Id="PT-1" Name="device_info">
     <TypeNumber SizeInBit="8" Type="unsignedInt" />
    </ParameterType> 
    <ParameterType Id="PT-2" Name="Busspannungsfehler">
     <TypeRestriction SizeInBit="8">
      <Enumeration Text="Aus" Value="0" Id="PT-2_EN-1" DisplayOrder="0" />
      <Enumeration Text="An" Value="1" Id="PT-2_EN-2" DisplayOrder="1" />
      <Enumeration Text="letzter Wert" Value="2" Id="PT-2_EN-3" DisplayOrder="2" />
      <Enumeration Text="Helligkeitswert" Value="3" Id="PT-2_EN-4" DisplayOrder="3" />
     </TypeRestriction>   
    </ParameterType>
   </ParameterTypes>

    <!--Parameter des Geräts, Legt deren Speicherort fest und zeigt Default-Werte-->
   <Parameters>
    <Parameter Id="P-1" Name="device_object_type" Text="" ParameterType="PT-1" Access="ReadWrite" Value="0x00">
     <Property ObjectIndex="0x00" PropertyId="0x01" /> <!-- Speicherort des Parameters -->
    </Parameter>
    <Parameter Id="P-2" Name="device_control" Text="" ParameterType="PT-2" Access="ReadWrite" Value="0x00">
     <Property ObjectIndex="0x00" PropertyId="0x0E" /> <!-- Speicherort des Parameters -->
    </Parameter>
    <Parameter Id="P-3" Name="Busspannungsausfall" Text="Verhalten nach Busspannungsausfall" ParameterType="PT-1" Access="ReadWrite" Value="2">
     <Property ObjectIndex="11" PropertyId="1" /> <!-- Speicherort des Parameters -->
    </Parameter>
   </Parameters>

    <!-- Beschreibt die KOs -->
   <ComObjectTable>
    <ComObject Id="10" FunctionText="Kanal A" Text="Schalten Ein/Aus" DatapointType="1" ObjectSize="1 Bit" Priority="Low" CommunicationFlag="Enabled" ReadFlag="Enabled" ReadOnInitFlag="Disabled" TransmitFlag="Enabled" UpdateFlag="Enabled" WriteFlag="Enabled"  />
    <ComObject Id="11" FunctionText="Kanal A" Text="Dimmkontrolle" DatapointType="3" ObjectSize="4 Bit" Priority="Low" CommunicationFlag="Enabled" ReadFlag="Enabled" ReadOnInitFlag="Disabled" TransmitFlag="Enabled" UpdateFlag="Enabled" WriteFlag="Enabled"  />
    <ComObject Id="12" FunctionText="Kanal A" Text="Absolutwert" DatapointType="5" ObjectSize="1 Byte" Priority="Low" CommunicationFlag="Enabled" ReadFlag="Enabled" ReadOnInitFlag="Disabled" TransmitFlag="Enabled" UpdateFlag="Enabled" WriteFlag="Enabled"  />
   </ComObjectTable>

   <ParameterBlock Id="PB-1" Name="Allgemein">
    <ParameterRefRef RefId="P-3" />   <!-- Parameter anzeigen -->
    <choose ParamRefId="PR-4"> 
     <when test="0" default="false"> <!-- "Aus" Ausgewählt -->
     </when>
     <when test="1" default="false"> <!-- "An" Ausgewählt -->
     </when>
    </choose>
   </ParameterBlock>
  </ApplicationProgram>
 </Manufacturer>
<ManufacturerData>

Die <devices> Liste hab ich mal rausgenommen, sowas hab ich im Standard nirgends gefunden. Denke auch das dies im Device abgebildet werden muss über die MaskVersion odg. denn sonst müsste jedesmal das xml erweitert werden wenn ein neues Device hinzukommt? Oder hab ich das falsch verstanden?

Die DatapointType Angabe bei den KOs ist im Standard optional, Pflicht ist die Angabe von ObjectSize! Priority ist ebenfalls optional.

Den Speicherort für die Flags gibts in der Form (Property 0) auch nicht, glaub das ist aber eine "Erfindung" von Max oder? Wo wirds denn im Standard abgelegt? (ObjectTable?) Wenns immer in Property 0 soll dann muss es eigentlich nicht explizit jedesmal angegeben werden sondern man machts einfach immer so. Es gibt auch noch sowas wie <LoadProcedures> evtl. kann mans da irgendwie rein packen?

Auch die Zugriffsberechtigungen über die Keys etc. hab ich im Standard noch nicht entdeckt, wird evtl. auch anderst gehandhabt....

Doku dazu würd mich auch interessieren, kenne nur das von Max verlinkte pdf....