Konfiguration von DIY-Geräten

[l0wside]

Formatvorschlag

Ich habe jetzt mal einen Kompromiss versucht, mit dem hoffentlich jetzt jeder leben kann.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<device-description version="1.0"> 
    <manufacturer-id>0xFADE</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. -->
            <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>
            <condition depends-on="use-channel-a" value="1"/>
        </commobject>
        <commobject id="12">
            <description>Absolutwert Kanal A</description>
            <dpt>5</dpt>
            <pdt>UNSIGNED_CHAR</pdt>
            <condition depends-on="use-channel-a" value="1"/>
        </commobject>
    </commobjects>

    <!--
        Parameter des Geräts, ggf. gruppiert.
        Legt deren Speicherort fest und zeigt Default-Werte
    -->
    <parameters>  
        <parameter id="device_object_type" location="properties" object-id="0x00" property-id="0x01" offset="0x01" access="Read">
            <pdt>UNSIGNED_INT</pdt>
            <default>0x00</default>
        </parameter>
        <parameter id="device_control" location="properties" object-id="0x00" property-id="0x0E" offset="0x01" access="ReadWrite">
            <pdt>GENERIC01</pdt>
            <default>0x00</default>
        </parameter>
        <parameter id="service_control" location="properties" object-id="0x00" property-id="0x08" offset="0x01" access="ReadWrite">        
            <pdt>UNSIGNED_INT</pdt>        
            <default>0x00</default>        
        </parameter>        

        <!-- Mit Memory Location statt Property -->
        <parameter id="application_run_state_control" location="memory" address="0x60" access="ReadWrite">        
            <pdt>CONTROL</pdt>        
        </parameter>   

        <!-- usw. -->
        
        <!-- Parameter mit Long Name und Auswahlmöglichkeit -->
        <parameter id="after-busvoltage-failure" location="properties" object-id="11" property-id="1" access="ReadWrite">
            <description>Verhalten nach Busspannungsausfall</description>
            <pdt>UNSIGNED_CHAR</pdt>
            <dpt>5</dpt>
            <parameter-type>pt-bus-voltage-failure</parameter-type>
            <default>2</default>
        </parameter>
            
        <parameter id="brightness-after-busvoltage-failure" location="properties" object-id="11" property-id="2" access="ReadWrite">
            <description>Helligkeitswert nach Busspannungsausfall in %</description>
            <pdt>UNSIGNED_CHAR</pdt>
            <dpt>5</dpt>
            <default>50</default>
            <parameter-type>pt-brightness</parameter-type>
        </parameter>
            
        <parameter id="brightness-after-busvoltage-return" location="properties" object-id="11" property-id="3" access="ReadWrite">
            <description>Helligkeitswert nach Busspannungswiederkehr</description>
            <pdt>UNSIGNED_CHAR</pdt>
            <dpt>5</dpt>
            <default>50</default>
            <parameter-type>pt-brightness</parameter-type>
        </parameter>
            
        <parameter id="use-channel-a" location="properties" object-id="12" property-id="1" access="ReadWrite">
            <description>Kanal A verwenden</description>
            <pdt>UNSIGNED_CHAR</pdt>
            <dpt>1</dpt>
            <default>0</default>
        </parameter>

        <parameter id="dimspeed-a" location="properties" object-id="20" property-id="1" access="ReadWrite">
            <description>Dimmgeschwindigkeit</description>
            <pdt>KNX_FLOAT</pdt>
            <dpt>9</dpt>
            <parameter-type>pt-dimspeed</parameter-type>
            <default>100.0</default>
            <disabled-default>10.0</disabled-default>
            <condition depends-on="use-channel-a" value="1"/>
        </parameter>
    </parameters>

    <parameter-types>
        <parameter-type name="pt-bus-voltage-failure">
            <enum text="Aus" display-order="0" value="0"/>
            <enum text="An" display-order="1" value="1"/>
            <enum text="Letzter Wert" display-order="2" value="2"/>
            <enum text="Helligkeitswert" display-order="3" value="3"/>
        </parameter-type>
        <parameter-type name="pt-brightness">
            <min-value>0</min-value>
            <max-value>100</max-value>
        </parameter-type>
        <parameter-type name="pt-dimspeed">
            <min-value>10.0</min-value>
            <max-value>100.0</max-value>
        </parameter-type>
    </parameter-types>
            
    <resources>
        <resource name="GroupAddressTable" location="memory" address="0xC000" size="8" access="ReadWrite"/>
        <resource name="GroupObjectTable" location="properties" object-id="0xF0" property-id="0x01" offset="1" size="4" access="ReadWrite"/>
        <resource name="GroupAssociationTablePtr" location="properties" object-id="0xF0" property-id="0x02" offset="1" size="1" access="Read" access="read"/>
        <resource name="GroupAssociationTable" location="memory" reference="GroupAssociationTablePtr" size="4" access="ReadWrite"/>
        <resource name="AccessKey" location="value">DE AD BE EF</resource>
    </resources>
    
<!-- Alternativ für die "Property 0"-Variante -->    
    <resources>
        <resource name="GroupAddressAssociations" location="properties" access="ReadWrite"/>
        <resource name="GroupObjectTable" location="properties" object-id="0xF0" property-id="0x01" offset="1" size="4" access="ReadWrite"/>
        <resource name="AccessKey" location="value">DE AD BE EF</resource>
    </resources>

</device-description>

Ziel war weniger, die knxprod mehr oder weniger wörtlich zu übernehmen, sondern einigermaßen die Struktur zu imitieren, ohne dabei die Lesbarkeit ganz aus den Augen zu verlieren. Wenn das so klappt, lässt sich in Zukunft die komplette knxprod wie von Alex vorgeschlagen mit einem Importfilter relativ einfach anbauen, ohne die Objektstruktur über den Haufen zu werfen.

• Der <devices>-tag ist dringeblieben. Meinetwegen machen wir ihn optional.
• Bei den Communication Objects sind PDT und DPT verpflichtend. Im Moment haben sie aber keine praktische Bedeutung hier, sie könnten Stand heute auch entfallen oder optional werden.
• PDT ist auf den Property-Werten geblieben. Mir wird das sonst zu kompliziert, wenn ich noch zwischen uInt8 und UNSIGNED_CHAR unterscheiden muss.
• Für die verschachtelten Anzeigen bin ich beim <condition>-Tag geblieben. Der knxprod-Ansatz ist um Größenordnungen aufwändiger.
• Die Parameter-Beschreibung selbst orientiert sich in der Struktur grob an der knxprod, allerdings habe ich ein bisschen mehr in Child Nodes geschoben.
  • Was per Memory gelesen/geschrieben wird, hat "location=memory address=xxxx" als Tags.
  • Bei Property-Zugriff gilt "location=properties object-id=xx property-id=yy offset=zz"
  • Access ist durchgehend entweder "Read" oder "ReadWrite"
  
  
• Für Wertebeschränkungen oder Dropdowns bin ich bei "parameter-type" geblieben. Diese sind an einer eigenen Stelle, auch wenn Alex davon nicht begeistert sein wird.
• Die Parameter-Types haben entweder eine enum-Liste oder min-value und max-value. Komplexere Bedingungen würde ich nicht zulassen. Grund: so kann ich per Tooltip eine verständliche Hilfe einblenden ("Zulässig: 0...100"). Mit einer Regex wird das schwieriger.
• Bei den Tabellen habe ich wieder bei der knxprod stibitzt. Dort heißen sie "resources", was ja nicht falsch ist. Hier gibt es einen ganzen Strauß an Möglichkeiten:
  • <resource name="GroupAddressTable" location="memory" address="0xC000" size="8" access="ReadWrite"/> - der GroupAddresstable hat 8 Einträge an Speicheradresse 0xC000
  • <resource name="GroupObjectTable" location="properties" object-id="0xF0" property-id="0x01" offset="1" size="4" access="ReadWrite"/> - der gesamte GroupObjectTable ist als Property abgelegt (Object F0, ID 1, Einträge 1...4).
  • <resource name="GroupAssociationTablePtr" location="properties" object-id="0xF0" property-id="0x02" offset="1" size="1" access="Read" access="read"/> - die Adresse des Association Tables ist in Object F0, Property 02 an Index 1 abgelegt. Mit dieser Adresse wiederum kann der Table dann ausgelesen und geschrieben werden.
    Ob man diese Verweismöglichkeit braucht, lässt sich diskutieren. Ich könnte auch ganz gut ohne, aber für knxprod-Unterstützung wäre es sowieso nötig.
  • <resource name="GroupAssociationTable" location="memory" reference="GroupAssociationTablePtr" size="4" access="ReadWrite"/> - der eigentliche Association Table ist im Speicher an der Adresse, die durch GroupAssociationTablePtr (vorheriger Eintrag) festgelegt wird.
  • <resource name="AccessKey" location="value">DE AD BE EF</resource> - den Key (fixer Wert, dafür steht "location=value") habe ich gleich hier mit abgebildet.
  • <resource name="GroupAddressAssociations" location="properties" access="ReadWrite"/> - das ist der Verweis auf die Property 0.
  
  

Kommentare (am liebsten "ja, so machen wir das und lassen nur den Table-Verweis weg" ) willkommen.
Hat jemand eine Dokumentation, wie der Standard die Flags ablegt? Dann würde ich das noch imitieren. Die "Property 0"-Variante ist auch nicht der Traum in Tüten.

Max

[l0wside]

Reichen 2 weitere IDs nicht? Du hattest was von 3 weiteren geschrieben?!

Sorry, ich schulde dir ja noch eine Antwort hierauf. Ich komme auf:
* Manufacturer ID
* deviceid (uint16)
* revision (uint8)
* Mask Revision

Max

[tuxedo]

Hallo Max,

es kommt wie es kommen musste: Ich hab wieder etwas zu "motzen" ;-)

        <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. -->
            <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>

Mal davon abgesehen dass du geschrieben hast dass dpt/pdt hier optional werden könnten: An dieser Stelle wird doch nur beschrieben was das KO für einen Typ benötigt um "angesteuert" zu werden. In der ETS ist an dieser Stelle klar und einzig DPT aufgeführt. Ganz nebenbei DPT1 = weder UNSIGNED_CHAR noch GENERIC01. Sondern 1 byte in dem nur das niederste bit benutzt wird. Eben DPT1. Aber gut, vielleicht ist das an dieser Stelle auch Meckern auf hohem Niveau.

<condition object="5" property="1" min_value="1" max-value="5"/>

Finde die Condition in den <commobject> Knoten ganz okay. Aber ich würde hier ausschließlich auf eine parameter-id referenzieren, und nicht direkt in den Property-Speicher.

<condition depends-on="use-channel-a" value="1"/>

Finde ich besser. Allerdings, um es eindeutiger und selbsterklärender zu machen, würde ich es so formulieren:

<condition parameter-id="use-channel-a" value="1"/>

Dann sieht man sofort wo man nachschlagen muss. Macht es vielleicht insgesamt lesbarer/verständlicher.
Die Variation min_value="1" max-value="5" <-> value="1" finde ich gut.

Die ETS hat für die KOs zwei Beschreibende Spalten:

Name + Funktion. Vielleicht wollen wir das auch so machen?

Beispiel:

        <commobject id="11">
            <name>Dimmkontrolle Kanal A</name>
            <function>Relativ Dimmen</function>
            <dpt>3</dpt>
            <pdt>UNSIGNED_CHAR</pdt>
            <condition depends-on="use-channel-a" value="1"/>
        </commobject>

Was meinst du dazu?

Ein Punkt noch zum Speicherort der GAs für die KOs:

Ich hätte mir gewünscht wenn man jedem KO sagen kann wo es gespeichert wird. Ich nehme mal an du hast das hierüber gelöst:

    <resources>
        <resource name="GroupAddressTable" location="memory" address="0xC000" size="8" access="ReadWrite"/>
        <resource name="GroupObjectTable" location="properties" object-id="0xF0" property-id="0x01" offset="1" size="4" access="ReadWrite"/>
        <resource name="GroupAssociationTablePtr" location="properties" object-id="0xF0" property-id="0x02" offset="1" size="1" access="Read" access="read"/>
        <resource name="GroupAssociationTable" location="memory" reference="GroupAssociationTablePtr" size="4" access="ReadWrite"/>
        <resource name="AccessKey" location="value">DE AD BE EF</resource>
    </resources>

Deine Beschreibung dazu klingt kompliziert (vielleicht komplizierter als es tatsächlich ist?). Ergänzend kommt folgendes dazu:

<parameter id="device_object_type" location="properties" object-id="0x00" property-id="0x01" offset="0x01" access="Read">

Ganz ehrlich: Ich blick's nicht. Zum einen scheinen die Parameter schon über ihre Attribute den Speicherort zu kennen, und zum anderen ist das nochmal bei den Resources irgendwie definiert?!

Dazu kommt dass es vermutlich ein schlechtes XML Design ist, wenn im Parameter-Knoten ein Attribut ("location") die Präsenz und Verwendung von weiteren Attributen (object, property, offset) bestimmt.

Da mein Ansatz einen reinen Property-Ansatz verfolgt, hätte ich in jedem <parameter> und jedem <commobject> einfach die Attribute object="0x00" property="0x01" (ohne Suffix "-id") benutzt.
Um deinem Resources-Ansatz gerecht zu werden und dennoch das System für die Arduino-Fraktion einfach zu halten, habe ich diesen Vorschlag:

1) Weder <commobject> noch <parameter> haben Attribute oder Kind-Knoten die den Speicherort verraten
2) Stattdessen kommt dein <resources> Knoten zum Einsatz.
3) Dort gibt's die "komplizierte" Variante wo GA-Tabelle etc. definiert wird und die AVR-pur Fraktion dann alles im Speicher hintereinander ablegen kann
4) Und für die Arduino-Fraktion gibt's eine alternative Auslegung der Resourcen. Bsp:

<resources>
	<resource name="GroupAddressPropertyMapping">
		<mapping commobject-id="1" object="0xF0" property="0x01">
		<mapping commobject-id="2" object="0xF0" property="0x02">
		<mapping commobject-id="3" object="0xF0" property="0x03">
	</resource>
	<resource name="ParameterPropertyMapping">
		<mapping parameter-id="1" object="0xF1" property="0x01">
		<mapping parameter-id="2" object="0xF1" property="0x02">
		<mapping parameter-id="3" object="0xF1" property="0x03">
	</resource>
</resources>

Damit hätte man deinen Ursprungs-Ansatz mit den Tabellen für die AVR-Fraktion erhalten und einen recht einfachen und lesbaren Ansatz für die Arduino-Fraktion

Auch wenn der "Standard" von "parameter-type" spricht:

        <parameter id="dimspeed-a" location="properties" object-id="20" property-id="1" access="ReadWrite">
            <description>Dimmgeschwindigkeit</description>
            <pdt>KNX_FLOAT</pdt>
            <dpt>9</dpt>
            <parameter-type>pt-dimspeed</parameter-type>
            <default>100.0</default>
            <disabled-default>10.0</disabled-default>
            <condition depends-on="use-channel-a" value="1"/>
        </parameter>

In diesem Block gibt es nun schon DREI (!!!) Typen... PDT, DPT und Paramater-Type.

Besonders Problematisch finde ich "parameter-type"... Es ist ja kein wirklicher Typ, sondern nur eine Art Einschränkung/Limitierung des Typs. Ich versuche gerade krampfhaft einen besseren Namen zu finden. "options" War ja die Erstüberlegung. Trifft es aber nur, wenn es tatsächlich um "Optionen" für eine Auswahlliste geht. "Type" passt - Sorry@Standard - so finde ich gar nicht ins Bild. Aktuell würde ich deshalb zu "parameter-options" tendieren. Denn das ist es was das Ding macht: Es definiert Optionen für den Parameter.. Entweder ein Emum, oder eine Limitierung.

Und wenn wir schon dabei sind:

        <parameter-type name="pt-bus-voltage-failure">
            <enum text="Aus" display-order="0" value="0"/>
            <enum text="An" display-order="1" value="1"/>
            <enum text="Letzter Wert" display-order="2" value="2"/>
            <enum text="Helligkeitswert" display-order="3" value="3"/>
        </parameter-type>

Prinzipiell ganz gut. Hat nur einen Haken:

        <parameter-type name="pt-brightness">
            <min-value>0</min-value>
            <max-value>100</max-value>
        </parameter-type>

Passt nicht so doll zu einem guten XML Design. Ist schwer zu erklären. Ich mach mal ein Gegenvorschlag:

<parameter-type name="pt-bus-voltage-failure">
    <enum>
        <item text="Aus" display-order="0" value="0"/>
        <item text="An" display-order="1" value="1"/>
        <item text="Letzter Wert" display-order="2" value="2"/>
        <item text="Helligkeitswert" display-order="3" value="3"/>
    </enum>
</parameter-type>	
<parameter-type name="pt-brightness">
    <limit min="0" max="100">
</parameter-type>

Meinungen?

Und um auf die drei Typen innerhalb des Parameters zurück zu kommen:

Du musst mir jetzt wirklich mal hieb und stichfest erklären wieso das hier nicht doppelt-gemoppelt ist:

<pdt>KNX_FLOAT</pdt>
<dpt>9</dpt>

DPT9 ist doch ein KNX-Float?!

Und:

<dpt>1</dpt>  <!-- DPT 1 ist Schalten -->
<pdt>UNSIGNED_CHAR</pdt> <!-- DPT1 kann IIRC auf UNSIGNED_CHAR und auf GENERIC01 abgebildet werden. -->

Wie würde man denn ein DPT1 sonst ablegen? Nach KNX Definition ist DPT1 ein einziges Bit lang, wird aber laut Spec in einem einzigen Byte gespeichert, nämlich im niedersten Bit des Bytes. Wozu muss man da noch "unsigned_char" dazu schreiben?! Und UNSIGNED_CHAR ist das gleiche wie GENERIC01 ... Nur die Sichtweise ist ggf. unterschiedlich, aber genau das löst DPT1 mit einer präzisen Definition.

<pdt>UNSIGNED_CHAR</pdt>
<dpt>5</dpt>

Hier das gleiche Spiel: DPT5 ist laut KNX Spec ein 8bit Unsigned Wert. Die Ergänzung um "UNSIGNED_CHAR" macht es doch nicht präziser?!

Zusammengefasst:

Deine PDT Angabe alleine für sich ist zu unpräzise. Man wüsste im Falle von "true/false" nicht unbedingt (auch wenn man es erahnen kann) wo dieses Bit im UNSIGNED_CHAR zu finden ist. DPT1 hingegen beschreibt es exakt.

Da der DPT den Type des Werts beschreibt und der Wert auch einen Standardwert haben kann, hätte ich diesen Vorschlag im Angebot:

<parameter id="after-busvoltage-failure" location="properties" object-id="11" property-id="1" access="ReadWrite">
	<description>Verhalten nach Busspannungsausfall</description>
	<parameter-option>pt-bus-voltage-failure</parameter-option>
	<value dpt="5" default="2"/>
</parameter>

oder sogar

<parameter id="after-busvoltage-failure" location="properties" object-id="11" property-id="1" access="ReadWrite">
	<description>Verhalten nach Busspannungsausfall</description>
	<value dpt="5" default="2" value-option="pt-bus-voltage-failure"/>
</parameter>

wobei mir sogar letzteres besser gefällt und ich meinen obigen Vorschlag "Parameter-Option" in "Value-Option" korrigieren würde. Denn es ist hier doch eine Option auf den Wert der Option. Und das attribut aus Variante2 "parameter-option" nennen wenn der Knoten "value" heißt sieht komisch aus. Thematisch passt es aber als Attribut sehr gut. Ein extra Knoten müsste es in meinen Augen nicht sein.

Sorry, ich schulde dir ja noch eine Antwort hierauf. Ich komme auf:
* Manufacturer ID
* deviceid (uint16)
* revision (uint8)
* Mask Revision

Die ersten Drei kann ich einordnen.

DeviceID sagt um welches Gerät es sich handelt. Revision sagt welche Hardware-Revision des Geräts es ist.
Und was sagt Mask-Revision?

Und wo hättest du die Werte gerne im XML?
Mein Vorschlag war als Attribut im Root-Knoten (der bei mir "anx" hieß und bei dir jetzt "device-description" heisst).

So, genug Text für den Moment. Jetzt bist du dran ;-)

[Bernator]

Ok ich kapituliere, hier noch irgendwie auf den Standard rücksicht zu nehmen hat keinen Sinn mehr, ist schon zu weit weg. Macht nichts ich klinke mich mal aus, zu viele Köche verderben den Brei

[l0wside]

Hallo Alex,

zwei Hinweise vorab:

• Die Duplizität DPT/PDT habe ich nicht erfunden. Ich werde sie aber im Qt-Tool so durchziehen, um langfristig auch knxprod unterstützen zu können. Wenn das für dich inakzeptabel ist, dann ist das schade, aber eben so. Mein Maßstab ist nicht die GUI der ETS, sondern der Unterbau aus der knxprod.
• Mir liegt daran, bei den sich abzeichnenden Tools keinen Wildwuchs zu haben; mir liegt aber mehr daran, Bernhard an Bord zu halten, der das Tool aktiv nutzt und auch Code beisteuert. Das limitiert meine Kompromissbereitschaft etwas.

<condition object="5" property="1" min_value="1" max-value="5"/>

Finde die Condition in den <commobject> Knoten ganz okay. Aber ich würde hier ausschließlich auf eine parameter-id referenzieren, und nicht direkt in den Property-Speicher.

Richtig, war auch so beabsichtigt. Tippfehler meinerseits.

<condition depends-on="use-channel-a" value="1"/>

Finde ich besser. Allerdings, um es eindeutiger und selbsterklärender zu machen, würde ich es so formulieren:

<condition parameter-id="use-channel-a" value="1"/>

Dann sieht man sofort wo man nachschlagen muss. Macht es vielleicht insgesamt lesbarer/verständlicher.

Bin anderer Ansicht als du, habe aber keine tieferen Neigungen in die eine oder andere Richtung.

Ganz ehrlich: Ich blick's nicht. Zum einen scheinen die Parameter schon über ihre Attribute den Speicherort zu kennen, und zum anderen ist das nochmal bei den Resources irgendwie definiert?!

Es gibt drei Möglichkeiten der Ablage:

• Einzelwerte als Property
• Einzelwerte als Speicherstelle
• Komplette Tabellen mit eigener Struktur (z.B. Object Table), diese sind nur per Speicherzugriff les-/schreibbar.

Auch das habe ich nicht erfunden, sondern orientiere mich an der Struktur der BCU2.

Dazu kommt dass es vermutlich ein schlechtes XML Design ist, wenn im Parameter-Knoten ein Attribut ("location") die Präsenz und Verwendung von weiteren Attributen (object, property, offset) bestimmt.

Das ist mir, mit Verlaub, piepegal.

Ansonsten werde ich bei der bisherigen Auslegung der Speicherorte bleiben. Die Variante am Ende meines Vorschlags war schon der Versuch, deinem "Properties Only"-Ansatz gerecht zu werden.

Auch wenn der "Standard" von "parameter-type" spricht:
[...]

Ich sehe den großen Vorteil nicht, hier vom knxprod-Format abzuweichen. Dito mit den enums - hier habe ich aus dem knxprod schlicht abgeschrieben und werde dabei auch bleiben.

DeviceID sagt um welches Gerät es sich handelt. Revision sagt welche Hardware-Revision des Geräts es ist.
Und was sagt Mask-Revision?

Mask Revision gibt eigentlich den Firmware-Stand des Busankopplers an, wird aber praktisch dazu verwendet, aus der knxprod die richtige Beschreibung herauszusuchen und gibt auch an, welches Speicher-/Konfigurationsmodell verwendet wird.

Max

[Bernator]

Hallo Max,
vielleicht hab ich mich etwas zu "hart" ausgedrückt, natürlich meinte ich damit nicht das ich mich komplett verabschiede.
Nur hab ich persönlich jetzt nicht das Große Interesse an einer neuen "einfach" Variante da ich für mich schon eine habe die ich jetzt aus Zeitgründen auch erst mal so belassen muss. Und damit ihr hier auch weiter kommt überlasse ich das euch.....
Die Diskussion hat mir auch gezeigt das sich der Standard nicht wirklich in relevanter Tiefe in einer "einfach" Variante integrieren lässt. Daher ist es auch einfacher das getrennt zu behandeln und später im Konfig Tool irgendwie zusammen zu führen.

Wie vorher schon mal erwähnt ist für mich .knxproj interessant welches ich angehen werde sobald es die Zeit zulässt. Wenn bis dahin die neue "einfach" Variante im Qt Tool integriert ist bastle ichs halt da dazu....

[tuxedo]

Hallo Alex,

zwei Hinweise vorab:
* Die Duplizität DPT/PDT habe ich nicht erfunden. Ich werde sie aber im Qt-Tool so durchziehen, um langfristig auch knxprod unterstützen zu können. Wenn das für dich inakzeptabel ist, dann ist das schade, aber eben so. Mein Maßstab ist nicht die GUI der ETS, sondern der Unterbau aus der knxprod.

Dass du das nicht erfunden hast weiß ich. Hattest du ja mehrfach erwähnt.
Aber bei einem Dateiformat, das so oder so nicht 100% kompatibel zu den knxprod Files ist: Welchen Sinn macht es PDT und DPT aufzuführen, wenn DPT alleine schon ausreicht und PDT keinen Mehrwert bringt? Die interne Struktur wird dabei ja nicht gleich inkompatibel in Bezug auf die weiterentwicklung zum 100% kompatiblen Format.

* Mir liegt daran, bei den sich abzeichnenden Tools keinen Wildwuchs zu haben; mir liegt aber mehr daran, Bernhard an Bord zu halten, der das Tool aktiv nutzt und auch Code beisteuert. Das limitiert meine Kompromissbereitschaft etwas.

Ich werfe hier einfach nochmal in den Raum: Ein halb-kompatibles Format hilft keinem. Wichtig ist die interne Struktur der Anwendung, so dass diese mit unterschiedlichen Dateiformaten (gerne als Plugins) klar kommt.

Bin anderer Ansicht als du, habe aber keine tieferen Neigungen in die eine oder andere Richtung.

War ja auch wieder "meckern auf hohem niveau" von mir ;-)

Es gibt drei Möglichkeiten der Ablage:

• Einzelwerte als Property
• Einzelwerte als Speicherstelle
• Komplette Tabellen mit eigener Struktur (z.B. Object Table), diese sind nur per Speicherzugriff les-/schreibbar.

Auch das habe ich nicht erfunden, sondern orientiere mich an der Struktur der BCU2.

Alles klar. Aber Schade dass du nicht auf meinen Vorschlag eingegangen bist.

Das ist mir, mit Verlaub, piepegal.

Jedem das Seine. Der XML-Standard sieht die Verwendung eben anders vor. An Conventionen kann man sich halten, muss man aber nicht.

Ansonsten werde ich bei der bisherigen Auslegung der Speicherorte bleiben. Die Variante am Ende meines Vorschlags war schon der Versuch, deinem "Properties Only"-Ansatz gerecht zu werden.

Ich sehe den großen Vorteil nicht, hier vom knxprod-Format abzuweichen. Dito mit den enums - hier habe ich aus dem knxprod schlicht abgeschrieben und werde dabei auch bleiben.

Auch hier wieder: Ganz, oder gar nicht. Mit "ein bisschen" ist keinem geholfen. Und mein Vorschlag hätte die interne Struktur nicht inkompatibel gemacht, dafür aber die XML-Struktur eher am XML-Standard bzw. der Convention gehalten.

Nun gut. Dann werden sich unsere Wege eben trennen müssen.

[l0wside]

Hallo Alex,

wenn du dich verabschieden willst, kann ich dich nicht halten. Das ist schade, ich bin nach wie vor der Überzeugung, dass die Übereinstimmungen größer als die Differenzen sind und dass Doppelarbeit uns nicht weiter bringt.

Wenn aber die Punkte

• Duplizität DPT und PDT
• Mögliche Abweichung vom XML-Standard (wenn die Abhängigkeit der Attribute tatsächlich nicht XML-konform ist, denke ich gerne noch mal drüber nach)
• Namensgebung von Tags
• Zusätzliche Verschachtelungsebene bei den TypeProperties

für dich tatsächlich Grund genug sind, einen komplett eigenen Weg zu gehen, bedaure ich das. Vielleicht ergibt sich woanders ja mal eine Möglichkeit zur Zusammenarbeit.

Max

[tuxedo]

Meine Anforderungen waren von Anfang an: KISS. Mehr und mehr bläst sich aber das XML-Konstrukt auf.
Ich sehe absolut 0 (in Worten NULL) Mehrwert sich in der XML-Struktur teilweise an .knxprod zu orientieren, nur damit man sich daran orientiert und einen Teil der Struktur nachahmt.
Defacto ist es so, dass die programminterne Struktur möglichst so gewählt werden sollte, dass man sich später vielleicht kein Bein ausreissen muss nur um .knxprod Files supporten zu können.

Das Schema hinter .knxprod ist nicht der heilige Gral wenn es um das "passende" XML Format geht. Es ist EIN Weg. Es ist nicht der beste, und es ist nicht der optimalste, und schon gar nicht ist es der Weg mit den wenigsten Fehlern.

Und solange die jetzige Anforderung nicht "100% support von .knxprod Files" heisst, solange macht es keinen Sinn die gleichen Fehler (das mag jetzt größer klingen als es ist) nochmal zu machen.

Die Sache mit DPT/PDT Duplizität... Das mag kleinkariert sein. Aber solange es keinen wichtigen Grund gibt beides aufzuführen, solange kann man PDT auch weglassen und, wenn man möchte, lediglich intern in der Struktur weiter mitführen.

Abweichung vom XML-Standard: Nun. Es gibt da vielfältige Meinungen dazu. Ich bin auch kein XML Experte. Aber nach ein wenig Recherche wie man am besten eine Struktur aufbaut und wie die Verwendung von Knoten und Attributen "gedacht" ist, hab ich schon Abweichungen zu den hier vorgestellten Formaten entdeckt. Der Höhepunkt war dann aber dass ein Attribut von einem anderen Attribut im gleichen Knoten abhängt (bzw. ist Attribut A vorhanden kann/darf es attribut B und C geben. Ist A nicht vorhanden gibt es stattdessen nur noch Attribut D und E ...). Sowas wird, meinen Recherchen zufolge, in getrennten Knoten behandelt.

Das was ich da gefunden hab mag vielleicht keine Standard Spec sein. Vielleicht ist es auch nirgendwo in einem XML Standrad vorgeschrieben. Aber der gesunde Entwicklerverstand muss doch erkennen dass diese Attributabhängigkeit innerhalb eines Knotens nicht so toll ist?! Aber vielleicht bin ich zu sehr Software-Engineer als Hardware-Mensch?!

Namensgebung von Tags... Namen sind Schall und Rauch. Theoretisch. Wer aber in der Praxis das XML anschauen muss und eigentlich nur die ETS kennt, der wird sich freuen wenn er möglichst identische Namen und Muster im XML wieder findet UND das File noch strukturell überschaubar ist. Auch hier wieder: KISS Prinzip.

Die Zusätzliche Verschachtelung: Meckern auf hohem niveau. Aber mein Entwickler-Perfektionismus sagt mir, dass das vorgeschlagene Beispiel gut in die Schublade mit den voneinander abhängigen Attributen passt.

Und dann gibt's noch drei Punkte die wieder untergegangen sind:

1) Das Speichern der Einstellungen/Parameter im XML-Format... Auch wenn ich hier alleine stehe und mir eine Position/Stelle aussuchen kann weil andere parser das nicht kennen/brauchen: Absprechen sollte man sich ggf. schon. Denn sonst läuft vielleicht der eine oder andere Anwender in eine Parser-Exception.

2) Das Ablegen der GAs pro KO als Property. Ich denke hier bin ich durchaus kompromissfähig, und mein Vorschlag hat sicherlich in keinster Weise das von dir geplante Speicher-Verhalten (als Nicht-Property) beeinflusst, und hätte der Arduino-Fraktion ein einfaches, lesbares Format geliefert und der AVR-Seite unverändert das etwas aufwendigere Format gegönnt. Dennoch wurde mit keinem Wort drauf eingegangen. Stattdessen lese ich zwischen den Zeilen wieder knxprod-Standard-Argumente, die - da das Format eh nicht 100% kompatibel ist - eigentlich irrelevant sind.

3) Auch das mag wieder nach erbsenzählen klingen. Aber noch bevor das Format fertig/entschieden ist, sollte a) ein Name dafür existieren und b) eine Registrier-Seite für die Manufacturer-ID fertig sein. Denn sonst gibt's hier und da ein Wildwuchs an IDs die sich ggf. überschneiden. Aber irgendwie ist keiner drauf angesprungen.

[greentux]

Klingt doch alles danach, als das man mal "in der Mitte" nen Whiteboard und nen Kasten Bier organisieren müsste

[l0wside]

knxcfg2 ist da!

Hallo zusammen,

ein erster Wurf der Version 2 des Config Tools ist fertig und unter http://kalassi.de/download/knxcfg2.zip zu finden. Eine .device-Datei, die dazu passt, findet sich im Anhang. Sie ist weitgehend identisch zu meinen letzten Vorschlägen.
Compiliert ist das Tool für Win64, es braucht die VC2010-Runtime und die Falcon-Treiber. Diverse Bugs sind noch drin, ein paar Features fehlen noch (wichtigstes: Schreiben von memory-based parameters).
Die Konfigurationsdateien sind zur alten Version nicht kompatibel. Der Aufwand für einen eigenen Importfilter hätte in keinem Verhältnis zum Nutzen gestanden.

Wenn das Programm so weit ist, dass es einigermaßen stabil läuft und keine wichtigen Features mehr fehlen, stelle ich es unter GPL und schiebe es auf Sourceforge (Gegenvorschläge willkommen).

Gesucht: Jemand, der das Programm fit für Linux macht, indem er einen eibd-Treiber schreibt. Das sollte keine Hexerei sein. Zugang zum Repository vorerst auf Anfrage.

Klingt doch alles danach, als das man mal "in der Mitte" nen Whiteboard und nen Kasten Bier organisieren müsste

Ich hatte in der Zwischenzeit mal eine Instanz von OpenMeetings so halbwegs am Laufen. Sieht zwar recht bloatig aus (Java und Flash in einem Paket), machte bzgl. Fumktionalität sonst aber einen guten Eindruck. Weil mein vServer damit aber überfordert war, ist´s wieder runtergeflogen. Mag es jemand hosten? Alex, ist root1.de ein richtiger Rootserver? Wenn ja, hättest du Ambitionen?

[tuxedo]

Alex, ist root1.de ein richtiger Rootserver? Wenn ja, hättest du Ambitionen?

Er war es. Mittlerweile ist es ein vRoot. Der läuft zwar recht gut mit Java-Zeugs drauf, aber Jenkins "stresst" ihn schon etwas, weswegen OpenMeetings wohl keine so tolle Sprünge machen würde...

[l0wside]

Er war es. Mittlerweile ist es ein vRoot. Der läuft zwar recht gut mit Java-Zeugs drauf, aber Jenkins "stresst" ihn schon etwas, weswegen OpenMeetings wohl keine so tolle Sprünge machen würde...

Schade. Magst du es nicht wenigstens auf einen Versuch ankommen lassen?
Zu deinem letzten Post:

• Könntest du dir den aktuellen Stand des Tools mal anschauen, ob du nicht doch damit leben kannst? Die KOs als Property zu speichern, ist aktuell nicht implementiert, ist aber schnell nachgerüstet.
• Speichern im XML-Format: am besten schaust du dir einfach an, wie es jetzt praktisch gelöst ist. Die Unterschiede zwischen .device und .project sind minimal (Vorteil: ich kann für .device und .project den gleichen Parser verwenden).
• Registrier-Seite für die Manufacturer-ID: ich denke, wir paar Nasen hier werden uns auch so einig. Eine Massenbewegung der DIY-Produzenten ist eher nicht zu befürchten.
  Wenn´s ganz wichtig ist, machen wir es so: Geburtsdatum sechsstellig schreiben, nach Hex konvertieren und mit 0xFFFF maskieren. Dann hätte ich 0x746A

Auch wenn es kein Java ist: vielleicht wirfst du ja mal einen Blick darauf, ob du den eibd-Treiber übernehmen kannst. Der sollte innerhalb eines Tages wenigstens rudimentär zum Laufen zu bekommen sein.

Max (in den letzten sechs Monaten mit C, C++/Qt, Python, PHP, Perl, Java und Matlab unterwegs gewesen)

[tuxedo]

Schade. Magst du es nicht wenigstens auf einen Versuch ankommen lassen?

Mal angenommen du weisst dass du aktuell mit 200 Sachen über die Landstraße bretterst. Du weisst dass die auf dich zukommende Kurve mit 190 noch gut, mit 210 gar nicht mehr zu nehmen ist.

Wozu sollte man es dann wenigstens auf einen Versuch ankommen lassen auf 220 zu beschleunigen?

Was ich damit sagen will: Der vRoot läuft mit seinen vielen Diensten (mehrere Webseite, darunter der Speicherfressende Jenkins, Sonatype Nexus, ...), SMTP/IMAP, VPN, SSH, ... schon am oberen Limit seines 1GB kleinen RAMs. Noch ein Speicherfresser und ich kann beim Aufruf der Jenkins Seite nicht nur Kaffee trinken gehen, nein, ich werde wohl locker Kaffeebohnen anbauen und ernten können.

Zu deinem letzten Post:
[LIST]
* Könntest du dir den aktuellen Stand des Tools mal anschauen, ob du nicht doch damit leben kannst? Die KOs als Property zu speichern, ist aktuell nicht implementiert, ist aber schnell nachgerüstet.

Anschauen kostet nix, außer Zeit. Wenn ich die neben dem gerade aufkommenden "endlich fertig werden damit man noch vor Weihnachten einziehen kann"-Stress finde, schau ich rein.

* Registrier-Seite für die Manufacturer-ID: ich denke, wir paar Nasen hier werden uns auch so einig. Eine Massenbewegung der DIY-Produzenten ist eher nicht zu befürchten.
Wenn´s ganz wichtig ist, machen wir es so: Geburtsdatum sechsstellig schreiben, nach Hex konvertieren und mit 0xFFFF maskieren. Dann hätte ich 0x746A

[ ] du hast gelesen und verstanden worum es mir ging
[ ] du hast nicht verstanden worum es ging, oder hast es nur überflogen.

Klar werden wir fünf Pappnasen uns einig. Wenn die Sache mit Arduino + KNX aber anläuft und die Einstiegshürde klein wird (und dazu ist sie auf dem besten Wege), kann es sehr gut sein dass da noch deutlich mehr kommt. Und besser man ist da vorbereitet als dann hinterher den Wildwuchs zu haben.

Auch wenn es kein Java ist: vielleicht wirfst du ja mal einen Blick darauf, ob du den eibd-Treiber übernehmen kannst. Der sollte innerhalb eines Tages wenigstens rudimentär zum Laufen zu bekommen sein.

Na wenn es so wenig Arbeit ist, dann kannst du da ja "mal eben" basteln, oder? Bis ich eine funktionierende Entwicklungsumgebung habe geht auch ein wenig Zeit ins Land. Und aktuell habe ich eher weniger Zeit mich noch in andere Dinge einzuarbeiten.

Max (in den letzten sechs Monaten mit C, C++/Qt, Python, PHP, Perl, Java und Matlab unterwegs gewesen)

[/quote]

Alex (der hier mit mehr Sprachen klotzen könnte, aber dem die Zeit fehlt alles gleichzeitig auf hohen Niveau zu machen, und sich deshalb auf ein eher kleines Subset konzentriert)

[l0wside]

[ ] du hast gelesen und verstanden worum es mir ging
[ ] du hast nicht verstanden worum es ging, oder hast es nur überflogen.
[...]
Na wenn es so wenig Arbeit ist, dann kannst du da ja "mal eben" basteln, oder? Bis ich eine funktionierende Entwicklungsumgebung habe geht auch ein wenig Zeit ins Land. Und aktuell habe ich eher weniger Zeit mich noch in andere Dinge einzuarbeiten.

Ich glaube nicht, dass wir auf diese Weise einig werden. Es ist ja auch nicht so, dass mir die Aufgaben ausgingen. Wenn die Entwicklung eines eigenen Java-Tools aus deiner Sicht effizienter ist, halte ich dich nicht ab.
Ich diskutiere gerne in einem anderen Thread über andere Themen mit dir. Hier sehe ich aktuell keinen Sinn mehr darin. Schade.

Max