Konfiguration von DIY-Geräten

[l0wside]

Bin aber nicht so der Freund von Windows (habs nur im Büro) und bastle das dann eben "nochmal" mit Java und Calimero. Dann läuft's mit Windows, Linux, Mac und wenn ich mal ganz viel Zeit hab auch mit Android.
Aber für's erste ist die Kommandozeilen-Version dran.

Mein Calimero-Ansatz ist mit seltsamen Problemen (konnte keine Properties schreiben) steckengeblieben, ich bin dann ziemlich fluchend auf Qt/Falcon umgestiegen.

Dein XML-Format ähnelt meinem bisherigen sehr stark. Mal schauen ob ich das so übernehme.

Würde mich freuen, notfalls können wir über Änderungen diskutieren. Ich werde noch eine Erweiterung einbauen, um auch Properties ansprechen zu können, die über eine Speicheradresse angesprochen werden - BCU2 bzw. BIM lassen grüßen.

"Kalassi Device Configuration Utility cannot be installed on Windows XP/Vista/Windows 7/Windows 8 x64/Windows 8.1 x64"

Problem ist bekannt und im aktuellen Build gefixt - kann ich aber erst heute Abend online stellen.

Max

[tuxedo]

Mein Calimero-Ansatz ist mit seltsamen Problemen (konnte keine Properties schreiben) steckengeblieben

Also ich habs noch nicht mit einem Gerät getestet. Aber das was Calimero schreibt ist laut Busmonitor identisch mit dem was ich mit eibd zu schreiben versucht habe. Bin da guter Dinge. Wenn nicht, wird halt ein Bugfix für Calimero gebastelt.

Würde mich freuen, notfalls können wir über Änderungen diskutieren.

Gerne ...

Problem ist bekannt und im aktuellen Build gefixt - kann ich aber erst heute Abend online stellen.

Alles klar. Dann schau ich später nochmal danach. Heute Abend geht's erst mal wieder auf die Baustelle. Komme dann frühestens Sonntag oder so dazu.

Ein paar Fragen noch zu deinem XML-Format:

<property name="interval" verbose="Humidity Transmission Interval" unit="s" dpt="42" id="1">
<type>UNSIGNED_INT</type>
<read_access>FREE</read_access>
<write_access>CONFIG</write_access>
<default>0</default>
</property>

1) Wenn du oben schon den "dpt" angibst, wozu dann unten nochmal den type?! Definiert der dpt nicht schon eindeutig den Typ?

2) Die "type"s ... Was gibt's da bei dir für welche und was steckt dahinter (z.B. GENERIC06???)

3) read_access und write_access "riechen" nach Flags. Passen aber irgendwie nicht ganz. Kannst du das ein wenig erklären? Welches deiner Flag ist für was?

4) "default" ist, so nehme ich an, der Default-Wert, also die "Werksvorgabe"?

5) Warum unterscheidest du auf oberer Ebene zwischen "commobjects" und "comm-properties"? Wenn ich das richtig verstanden habe landet doch eh alles als Property im Gerät? Ist das für die Trennung der Properties in der GUI?!

6) Wo steht in der XML welches KO mit welcher GA arbeitet?

Mein aktuelles Format (erster, rudimentärer Ansatz, hab mich da von Robert's EIBD-ShellScript inspirieren lassen) sieht wie folgt aus (Dummy-Beispiel):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<config>
    
    <!-- Name des Herstellers-->
    <manufacturer>ich</manufacturer>
    
    <!-- Gerätename -->
    <name>6CH KNX PWM LED Controller</name>  
    
    <!-- ID des Gerätetyps -->
    <id>0001</id>
   
    <!-- 
        value types: tells the processing software how to interpret the given value

        ga      GroupAddress    '1/2/3'   2 bytes encoded
        pa      PhysicalAddress '1.2.3'   2 bytes encoded
        uint8   integer         0..255          1 byte
        int8    signed integer  -128..127       1 byte
        uint16  integer,        0..65535        2 byte
        int16   signed integer  -32768..32767   2 byte
        uint32  integer         0..4294967295   4 byte
        int32   signed integer  −2147483648..2147483647 4 byte
        uint64  integer, 8 byte
        int64   signed integer, 8 byte

    -->            
    <objects>
        <object id="10" name="addresses">
            <property id="1">
                <description>GA für KO #0</description>
                <value type="ga">1/1/1</value>
            </property>
            <property id="2">
                <description>GA für KO #1</description>
                <value type="ga">1/1/2</value>
            </property>
        </object>
        
        <object id="11" name="parameters">
            <property id="1">
                <description>Verhalten nach Busspannungsausfall [(0) Aus, (1) An, (2) letzter Wert*, (3) Helligkeitswert]</description>
                <value type="uint8">2</value>
            </property>
            <property id="2">
                <description>Helligkeitswert nach Busspannungsausfall [0..127*..255]</description>
                <value type="uint8">127</value>
            </property>
            <property id="3">
                <description>Verhalten nach Busspannungswiederkehr [(0) Aus, (1) An, (2) letzter Wert*, (3) Helligkeitswert]</description>
                <value type="uint8">2</value>
            </property>
            <property id="4">
                <description>Helligkeitswert nach Busspannungswiederkehr [0..127*..255]</description>
                <value type="uint8">127</value>
            </property>
        </object>
    </objects>
</config>

Default-Werte sind bis auf weiteres wie folgt gehandhabt:

Die XML wird initiell vom "Hersteller" erstellt und mit Werten gefüllt. Die Werte ("value") entsprechen dann dem in der Beschreibung beschriebenen Bereich. Dort ist der Default-Wert mit einem * gekennzeichnet.
Ist nicht extrem schön, aber einfach und pragmatisch.

Was bei mir noch nicht wirklich gut gelöst ist, ist der "value type". Hab hier bisher keine Brücke zum Standard geschlagen, da die Typen bei mir meist nur unterschiedlich groß aber ganzzahlig, signed oder unsigned sind.
In einer KNX Doku (Link zum PDF gerade verlegt) habe ich aber gelesen dass die DPTs auch für die Properties angewendet werden können. Die Calimero-Lib bietet hier eigentlich passende Klassen zum Hin und Her Konvertieren (Java Typen<->DPT Typen) an. Mal schauen.
Die aktuelle Idee dahinter ist jedoch:

1) Die (meisten) Werte sollten in lesbaren und ohne Taschenrechner editierbaren Format drin stehen. Grund: Mal eben schnell "remote" über eine Shell eine Konfiguration anpassen und per Kommandozeilentool auf das Gerät schieben

2) Der "type" sagt der Software wie "value" zu interpetieren ist. Intern wird nur mit byte-arrays gearbeitet. D.h. beim Einlesen der File wird entsprechend des "type" der "value" geparst. Beim tatsächlichen Schreiben ist der Typ ja egal. Die Property-Schnittstelle behandelt ja eh nur byte(-Arrays). Die ggf. passende Konvertierung muss dann ggf. im Geät erfolgen und ist Sache der Firmware-Entwicklung.

Was ebenfalls noch fehlt ist ggf. eine Beschreibung der benutzbaren KOs. Bis dato sind nur die GAs für die KOs behandelt:

            <property id="2">
                <description>GA für KO #1</description>
                <value type="ga">1/1/2</value>
            </property>

Aber es fehlt ja eigentlich die hilfreiche Info welche KO-Nr. für was ist, und was das KO an Daten verträgt. Zumindest als "Beschreibung" der KOs könnte ich mir sowas vorstellen:

[l0wside]

Also ich habs noch nicht mit einem Gerät getestet. Aber das was Calimero schreibt ist laut Busmonitor identisch mit dem was ich mit eibd zu schreiben versucht habe. Bin da guter Dinge. Wenn nicht, wird halt ein Bugfix für Calimero gebastelt.

Wäre schön, immer her damit. Ich bin mit Qt und vor allem Falcon ganz und gar nicht verheiratet.
Zu deinen Fragen:
1) Wenn du oben schon den "dpt" angibst, wozu dann unten nochmal den type?! Definiert der dpt nicht schon eindeutig den Typ?
Nein, hier ist der KNX-Standard m.E. nicht ganz optimal. Siehe ftp://85.214.247.170/Download/Datapoint.pdf und die immer hilfreiche CHM-Datei von Martin Kögler.

2) Die "type"s ... Was gibt's da bei dir für welche und was steckt dahinter (z.B. GENERIC06???)
Siehe oben bei Martin Kögler. Die GENERICxx sind einfach xx Bytes lang, der Rest entspricht so ziemlich deinen value types.

3) read_access und write_access "riechen" nach Flags. Passen aber irgendwie nicht ganz. Kannst du das ein wenig erklären? Welches deiner Flag ist für was?
Nein, das sind keine Flags, das definiert, mit welchen Rechten bestimmte Properties gelesen und geschrieben werden dürfen. Wird aber aktuell im Programm nicht verwendet (dafür umso ausführlicher auf Device-Seite).

4) "default" ist, so nehme ich an, der Default-Wert, also die "Werksvorgabe"?
Genau.

5) Warum unterscheidest du auf oberer Ebene zwischen "commobjects" und "comm-properties"? Wenn ich das richtig verstanden habe landet doch eh alles als Property im Gerät? Ist das für die Trennung der Properties in der GUI?!
Die commobjects definieren zweierlei: zum einen die KOs, zum anderen die zugehörigen Properties. Beispiel: KO 10 = Temperatur, in Object 10 sind dann die Properties zur Temperatur (Sendeintervall, Offset) hinterlegt.
Die comm-properties sind unglücklich benannt, common-properties wäre treffender gewesen. Das sind Properties, die das gesamte Gerät betreffen und nicht KO-spezifisch sind.

6) Wo steht in der XML welches KO mit welcher GA arbeitet?
Gar nicht. Das steht in Association Table und Address Table. Detailliert bei Kögler, grob: die Address Table listet alle relevanten GAs auf, in der Association Table stehen dann Wertepaare KO/Pointer in Address Table.
Mein Tool merkt sich vergebene GAs zwar schon, aber in einer eigenen Projektdatei. Die XML-Datei, auf die du referenziert hast, beschreibt das Gerät an sich - und da kann ich keine Default-GA vorgeben.

Dein Format schaue ich mir heute abend an. Auf den ersten Blick trennst du nicht zwischen Gerätebeschreibung und Speicherung der gesetzten Werte - habe ich anders gelöst und würde auch gerne dabei bleiben.

Gruß,

Max

[tuxedo]

Hmm, okay. Scheint so als hätten wir zwei leicht unterschiedliche Ansätze.

Meine XML umfasst quasi die ganze Geräte-Konfiguration, inklusive allgemeiner Properties und KO-spezieller Properties (welche gleichbehandelt werden und sich nur in der Beschreibung unterscheiden), sowie dem Mapping KO<->GA.

Ist dein XML denn dazu gedacht dass der Benutzer, der Änderungen an den Geräteeinstellungen macht, diese wieder im XML speichert? Oder stehen da nur ala KNX Produktdatenbank "die möglichkeiten und defaultwerte" drin?

Bei meinem Ansatz wäre das wie gesagt so gelöst, dass die Ursprungs-XML vom "Hersteller" kommt und mit Defaultwerten "Allgemein Gerät" und "KO-spezifisch" (außer GA<->KO mapping) gefüllt ist.
Der Anwender kann die File dann anpassen (entweder mit einem Editor oder einem GUI-Tool), ins Gerät schreiben und das ganze komplett in dieser einen XML wieder abspeichern. Somit ließen sich fertig benutzbare Beispielkonfigurationen in einer einzigen File verschicken oder im Forum posten.

Dadurch dass die meisten Werte in lesbaren Datentypen in der File stehen und die File recht einfach gehalten ist, ist auch schnelle Hilfe per Email oder Forum möglich, ohne ein Tool starten zu müssen dass den Inhalt "aufbereitet".

Denke bei unseren DIY Projekten könnte das recht praktisch sein.

Was ich definitiv übernehmen würde ist der default Wert. Das reine kodieren des Defaults in der Beschreibung ist nicht besonders praktisch. Das Tag/Attribut wäre aber auf jeden Fall Optional.

Nein, hier ist der KNX-Standard m.E. nicht ganz optimal. Siehe ftp://85.214.247.170/Download/Datapoint.pdf und die immer hilfreiche CHM-Datei von Martin Kögler.

Kannst du das genauer erläutern? Ich sehe da, ohne jetzt gaaanz tief einzusteigen, erstmal nur, dass es verdammt viele Optionen und Eventualitäten gibt. Das ist genau das was mich ein wenig von "Standard" abgeschreckt hat und weswegen ich es gerne auf's nötige reduzieren würde. Für die Parametrisierung des Geräts reicht ja normalerweise eine Hand voll Typen + die "Spezialfälle" GA+PA:

* int / uint, in verschiedenen Längen
* float
* "text"
* boolean
* byte, bzw ein array davon

Nein, das sind keine Flags, das definiert, mit welchen Rechten bestimmte Properties gelesen und geschrieben werden dürfen. Wird aber aktuell im Programm nicht verwendet (dafür umso ausführlicher auf Device-Seite).

Ah, okay. Kann mir da - gerade weil's im Programm keine Anwendung findet?? - noch keinen wirklichen Reim drauf machen was das Device damit macht?! Kannst du ein kurzes Beispiel nennen?

Die commobjects definieren zweierlei: zum einen die KOs, zum anderen die zugehörigen Properties. Beispiel: KO 10 = Temperatur, in Object 10 sind dann die Properties zur Temperatur (Sendeintervall, Offset) hinterlegt.
Die comm-properties sind unglücklich benannt, common-properties wäre treffender gewesen. Das sind Properties, die das gesamte Gerät betreffen und nicht KO-spezifisch sind.

Ah, okay. Da hab ich mich vom Namen irritieren lassen :-)
Im Endeffekt markierst du die einen Properties als "Allgemein" und die anderen Properties als "KO-spezifisch". Intern ist es aber doch das Selbe: Properties. Also doch nur eine Unterscheidungsmöglichkeit für die GUI?

Das ist ein wenig verwand mit "Code-Duplizierung". Nur eben nicht Code, sondern Struktur. Find' ich noch nicht ganz optimal. Hab aber auch noch keinen Alternativ-Vorschlag (bis vielleicht auf eine geschicktere Namenswahl).

Vielleicht ein Attribut im Tag <object> --> "related" oder so...

<object name="temp" id="10" related="CO#10">
....
</object>

oder

<object name="foobar" id="9">
....
</object>

Wenn keine Relation angegeben ist, ist es allgemein. Alles andere ist dann KO relevant, und referenziert z.B. an so eine Stelle:

    <commobjects>
        <commobject id="10">
            <name>Eine Beschreibung</name>
            <description>Eine Beschreibung</description>
            <dpt>7</dpt>
        </commObject>
    </commobjects>

Diese würde dann - als Hilfe für den Benutzer - gleich noch beschreiben was das für ein KO ist, was es kann (DPT), und welche Nummer es hat. Könnte praktisch sein beim belegen der GAs mit anderen KNX-Geräten in ETS. So als Hilfe zum "Nachschauen" welcher DPT passt.


Was mir noch einfällt:

Mein Ansatz unterstützt keine vollständige Eingabevalidierung. Ich hab zwar einen Typen, welchen ich prüfen kann. Aber was wenn als zulässiger Wert nur 1..5 erlaubt ist und jemand 6 einträgt?! Hmmpf. Vllt. noch ein Validierungs-Attribut für "value" mit RegEx-Inhalt mit dessen Hilfe man den Wert checken/weiter einschränken kann?! Wobei RegEx bei Zahlen eher ungeschickt ist um Ranges oder Mengen zu definieren.

Hier mal mein erweiterter XML Ansatz mit den eben genannten Ideen:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<config>
    
    <!-- Name des Herstellers-->
    <manufacturer>root1.de</manufacturer>
    
    <!-- Gerätename -->
    <name>6CH KNX PWM LED Controller</name>  
    
    <!-- ID des Gerätetyps -->
    <id>0001</id>

    <!-- bei DIY Projekten wirklich benötigt? -->
    <!-- Diese Konfig passt zu folgenden HW versionen: -->
    <versions>
        <version>012345678901</version>
        <version>012345678902</version>
    </versions>

	<!-- Beschreibt die möglichen und vorhandenen KOs -->
    <commobjects>
        <commobject id="0"> <!-- id=KO-Nummer-->
            <name>Eine KO-Name</name>
            <description>Eine Beschreibung</description>
            <dpt>7</dpt>
        </commObject>
		<commobject id="1"> 
            <name>Eine anderer KO-Name</name>
            <description>Eine andere Beschreibung</description>
            <dpt>7</dpt>
        </commObject>
    </commobjects>


    
    <!-- 
        value types: tells the processing software how to interpret the given value

        ga      GroupAddress    '1/2/3'   2 bytes encoded
        pa      PhysicalAddress '1.2.3'   2 bytes encoded
        uint8   integer         0..255          1 byte
        int8    signed integer  -128..127       1 byte
        uint16  integer,        0..65535        2 byte
        int16   signed integer  -32768..32767   2 byte
        uint32  integer         0..4294967295   4 byte
        int32   signed integer  -2147483648..2147483647 4 byte
        uint64  integer, 8 byte
        int64   signed integer, 8 byte
        .....to be continued.....

    -->            
    <objects>
        <object id="10" name="addresses">
            <property id="1" related="CO#0"> <!-- CO#0 referenziert commobject id="0", siehe oben -->
                <description>GA für KO #0</description>
                <value type="ga">1/1/1</value>
            </property>
            <property id="2" related="CO#1">
                <description>GA für KO #1</description>
                <value type="ga">1/1/2</value>
            </property>
        </object>
        
        <object id="11" name="parameters">
            <property id="1" related="COMMON"> <!-- related hier eigentlich überflüssig -->
                <description>Verhalten nach Busspannungsausfall [(0) Aus, (1) An, (2) letzter Wert*, (3) Helligkeitswert]</description>
                <value type="uint8" default="2" validation="????Welches Validierungsformat?????">2</value>
            </property>
            <property id="2">
                <description>Helligkeitswert nach Busspannungsausfall [0..127*..255]</description>
                <value type="uint8" default="127">127</value>
            </property>
            <property id="3">
                <description>Verhalten nach Busspannungswiederkehr [(0) Aus, (1) An, (2) letzter Wert*, (3) Helligkeitswert]</description>
                <value type="uint8" default="2">2</value>
            </property>
            <property id="4">
                <description>Helligkeitswert nach Busspannungswiederkehr [0..127*..255]</description>
                <value type="uint8" default="127">127</value>
            </property>
        </object>
    </objects>
</config>

[l0wside]

Hmm, okay. Scheint so als hätten wir zwei leicht unterschiedliche Ansätze.

Meine XML umfasst quasi die ganze Geräte-Konfiguration, inklusive allgemeiner Properties und KO-spezieller Properties (welche gleichbehandelt werden und sich nur in der Beschreibung unterscheiden), sowie dem Mapping KO<->GA.

Hier sind wir grundsätzlich unterschiedlich unterwegs. Ich habe eher den Ansatz der ETS gewählt:
Ein neuer Baustein muss angelegt werden, dazu muss die XML-Beschreibung vorliegen. Diese wird dann (in einem etwas anderen Format, aber auch XML) in der Projektdatei gespeichert. In der stehen dann auch die Werte. Allerdings kann die Projektdatei dann natürlich mehrere Bausteine enthalten.
Deine Überlegung kann ich nachvollziehen, aber du hast (wieder als Programmierer gesprochen) Deklaration und Definition in einem.

Zu den Datentypen: ich habe folgende umgesetzt (müsste vollständig sein). Der Code ist aus meinem C-Code-Generator (in Python geschrieben) und enthält jeweils die ID des Datentyps (hex) und die Länge in Bytes (dez).

    proptypes = {'CONTROL':[0x00,1], \
                 'CHAR':[0x01,1], \
                 'UNSIGNED_CHAR':[0x02,1],\
                 'INT':[0x03,2],\
                 'UNSIGNED_INT':[0x04,2],\
                 'EIB_FLOAT':[0x05,2],\
                 'DATE':[0x06,3],\
                 'TIME':[0x07,3],\
                 'LONG':[0x08,4],\
                 'UNSIGNED_LONG':[0x09,4],\
                 'FLOAT':[0x0A,4],\
                 'DOUBLE':[0x0B,8],\
                 'CHAR_BLOCK':[0x0C,10],\
                 'POLL_GROUP_SETTING':[0x0D,3],\
                 'SHORT_CHAR_BLOCK':[0x0E,5],\
                 'GENERIC01':[0x11,1],\
                 'GENERIC02':[0x12,2],\
                 'GENERIC03':[0x13,3],\
                 'GENERIC04':[0x14,4],\
                 'GENERIC05':[0x15,5],\
                 'GENERIC06':[0x16,6],\
                 'GENERIC07':[0x17,7],\
                 'GENERIC08':[0x18,8],\
                 'GENERIC09':[0x19,9],\
                 'GENERIC10':[0x1A,10]}

CONTROL - bitte bei Kögler nachschauen, Stichwort "Load/State Control"
CHAR - 8 bit signed
UNSIGNED_CHAR - 8 bit unsigned
INT - 16 bit signed
UNSIGNED_INT - 16 bit unsigned
EIB_FLOAT - DPT9
DATE - selbsterklärend
TIME - selbsterklärend
LONG - selbsterklärend
UNSIGNED_LONG - selbsterklärend
FLOAT - IEEE lässt grüßen
DOUBLE - dito
CHAR_BLOCK - 10 Bytes
SHORT_CHAR_BLOCK - 5 Bytes
GENERIC01 - 1 Byte
GENERIC02 - 2 Bytes
GENERIC03 - ...
GENERIC04
GENERIC05
GENERIC06
GENERIC07
GENERIC08
GENERIC09
GENERIC10
GENERIC11
GENERIC12
GENERIC13
GENERIC14
GENERIC15
GENERIC16
GENERIC17
GENERIC18
GENERIC19
GENERIC20

Eigentlich reichen die CHAR- und INT-Typen sowie ein GENERIC01 für irgendwelche Flags. Der Rest ist eher zum Spielen.

Die PA wird über einen eigenen Mechanismus geschrieben und hat weder PDT (Datentyp) noch DPT (Umrechnungsvorschrift). Die GA werden über das Memory-Interface geschrieben (obwohl ich auch noch ein Property-Interface dafür implementiert habe, aber das ist ein eigenes Thema) und haben auch weder PDT noch DPT.

Die Zugriffsrechte dienen zu zweierlei: erstens, damit man nicht aus Versehen an der Konfiguration herumbastelt. Zweitens kann man damit manche Properties zum Schreiben nur im Factory Mode freigeben - das betrifft z.B. die Zugriffs-Keys, aber auch potenziell Dinge wie in der SW freigeschaltete Features.
In DIY-Projekten kann das auch entfallen.

Zu den comm-objects: nein, ich sehe hier keine Duplizierung, die Daten sind ja nicht redundant. Es braucht eben jede Property ein Object, und die zu den KO gehörenden wollte ich genau dort stehen haben. Im Moment werden tatsächlich nur die KO-spezifischen in der GUI angezeigt, das ist aber preliminary. Es ist noch viel zu tun...
In den .knxproj-Dateien der ETS4 ist es übrigens anders, dort ist die Struktur flach.

Dein Vorschlag, Properties und KOs zu trennen, geht genauso, ob es letzendlich übersichtlicher wird, sei dahingestellt. Beim Einlesen im Programm läuft die gleiche Routine einmal über den einen, einmal über den anderen Block - fertig.

Den Communication Objects noch eine Beschreibung mitzugeben, wäre hilfreich. Ggf. habe ich sie auch schon implementiert, ich bin mir gerade unsicher. Wenn, dann dient dazu das Attribut "verbose".



Eingabevalidierung ist auch noch ein offener Punkt. Ich habe mal in einer .knxprod nachgeschaut, wie´s dort gemacht wird. Beispiel:

              <ParameterType Id="M-0083_A-0020-15-7F81_PT-en.5FdebounceTime" Name="en_debounceTime">
                <TypeRestriction Base="Value" SizeInBit="16">
                  <Enumeration Text="10 ms" Value="10" Id="M-0083_A-0020-15-7F81_PT-en.5FdebounceTime_EN-10" DisplayOrder="0" />
                  <Enumeration Text="30 ms" Value="30" Id="M-0083_A-0020-15-7F81_PT-en.5FdebounceTime_EN-30" DisplayOrder="1" />
                  <Enumeration Text="50 ms" Value="50" Id="M-0083_A-0020-15-7F81_PT-en.5FdebounceTime_EN-50" DisplayOrder="2" />
                  <Enumeration Text="60 ms" Value="60" Id="M-0083_A-0020-15-7F81_PT-en.5FdebounceTime_EN-60" DisplayOrder="3" />
                  <Enumeration Text="120 ms" Value="120" Id="M-0083_A-0020-15-7F81_PT-en.5FdebounceTime_EN-120" DisplayOrder="4" />
                </TypeRestriction>
              </ParameterType>

                <TypeRestriction Base="Value" SizeInBit="8">
                  <Enumeration Text="1Byte Value [0...255]" Value="0" Id="M-0083_A-0020-15-7F81_PT-en.5FValueSelect_EN-0" DisplayOrder="0" />
                  <Enumeration Text="Scene Number" Value="1" Id="M-0083_A-0020-15-7F81_PT-en.5FValueSelect_EN-1" DisplayOrder="1" />
                </TypeRestriction>

Ich habe mich gerade noch durch zwei .knxprod durchgeackert. Die einzige gefundene Restriction für numerische Werte ist aber SizeInBit. Vielleicht gibt es noch mehr, da fehlt mir aber die Doku.

Max

[tuxedo]

Hier sind wir grundsätzlich unterschiedlich unterwegs. Ich habe eher den Ansatz der ETS gewählt:
Ein neuer Baustein muss angelegt werden, dazu muss die XML-Beschreibung vorliegen. Diese wird dann (in einem etwas anderen Format, aber auch XML) in der Projektdatei gespeichert. In der stehen dann auch die Werte. Allerdings kann die Projektdatei dann natürlich mehrere Bausteine enthalten.
Deine Überlegung kann ich nachvollziehen, aber du hast (wieder als Programmierer gesprochen) Deklaration und Definition in einem.

Jepp, Deklaration+Definition in einer Klasse... Das ist mein persönlicher Kompromiss :-) Ich denke die Vorteile einer einzigen File "könnten" überwiegen. Gerade bei DIY Projekten. Wieso hab ich ja schon geschrieben.

Zu den Datentypen: ich habe folgende umgesetzt (müsste vollständig sein).
...
Eigentlich reichen die CHAR- und INT-Typen sowie ein GENERIC01 für irgendwelche Flags. Der Rest ist eher zum Spielen.

Seh ich genau so.

Die PA wird über einen eigenen Mechanismus geschrieben und hat weder PDT (Datentyp) noch DPT (Umrechnungsvorschrift). Die GA werden über das Memory-Interface geschrieben (obwohl ich auch noch ein Property-Interface dafür implementiert habe, aber das ist ein eigenes Thema) und haben auch weder PDT noch DPT.

Würde hier gerne bei den Properties bleiben. Dann brauche ich im mittlerweile doch recht knappen Arduino-Speicher nicht noch einen Mechanismus.

Die Zugriffsrechte dienen zu zweierlei: erstens, damit man nicht aus Versehen an der Konfiguration herumbastelt. Zweitens kann man damit manche Properties zum Schreiben nur im Factory Mode freigeben - das betrifft z.B. die Zugriffs-Keys, aber auch potenziell Dinge wie in der SW freigeschaltete Features.

Ist das nicht nur eine Schein-Sicherheit? Wer die Werte "testweise" ändert, der kann auch dein Zugriffslevel testweise ändern und so die Konfiguration verbasteln. Oder wie würdest du diese Manipulation sicherstellen?

Zu den comm-objects: nein, ich sehe hier keine Duplizierung, die Daten sind ja nicht redundant.

Ich wusste dass ich mit "Code Duplizierung" den Wind in die falsche Richtung wehen lassen. Da hat auch mein Hinweis auf "Struktur-Duplizierung" nicht geholfen :-)

Es braucht eben jede Property ein Object, und die zu den KO gehörenden wollte ich genau dort stehen haben.
...
Dein Vorschlag, Properties und KOs zu trennen, geht genauso, ob es letzendlich übersichtlicher wird, sei dahingestellt. Beim Einlesen im Programm läuft die gleiche Routine einmal über den einen, einmal über den anderen Block - fertig.

Wenn ich mir's recht überlege: Hast recht. Kann man drüber streiten ob es so oder andersrum besser ist. Mal schauen und mal ne Nacht drüber schlafen...

Eingabevalidierung ist auch noch ein offener Punkt. Ich habe mal in einer .knxprod nachgeschaut, wie´s dort gemacht wird. Beispiel:
....

Das habe ich auch schon gesehen. Wenn ich das aber richtig verstanden habe wird nur die Range des Typs kontrolliert. Das hab ich schon umgesetzt.

Was aber wenn ich den Typ uint8 habe (erlaubt 0..255), aber das Device kann nur mit 0, 1, 2 und 3 umgehen und kann mit 4..255 nix anfangen?
Ich denke hier an die Drop-Down-Felder diverser KNX Geräte in der ETS bei der Parametrisierung... Wenn ein Drop-Down-Feld nur 4 Einträge/Auswahlmöglichkeiten hat, ist der naheliegendste Typ uint8.. Aber selbst der ist noch zu groß, weshalb ich mit einer ergänzenden, Anwendungs/Gerätespezifischen Validierung gerne nochmal den Wert prüfen möchte ob der Anwender eine korrekte Eingabe gemacht hat

Nur ist RegEx nicht wirklich geeignet um Zahlenbereiche zu prüfen... Der Ausdruck wird furchtbar schnell unleserlich. Und ich würde das XML auch gerne ohne GUI lesen können.



So beim Schreiben fällt mir gerade auf:

Bei solch kleinen Dingen wo es nur eine Hand voll Optionen gibt ist RegEx mit der Angabe einer Menge noch übersichtlich:

(0|1|2|3)

Der Fall würde also gehen.

Das Einschränken eines Zahlentyps auf einen etwas kleineren Bereich... Macht vielleicht keinen Sinn. Wird wohl besser sein die Gerät-Software so zu stricken dass das nicht nötig ist. z.B. (doofes Beispiel, aber was besseres fällt mir gerade nicht ein) 0-100% nicht auf 0..100 sondern auf 0..255 abbilden.

Hmm. Dann wäre RegEx doch wieder zu gebrauchen...



[update]

Um das Thema "nur eine File" etwas abzumildern, hätte ich noch folgende Idee:

Die initielle vom Hersteller zu erstellende Datei hat irgendwo in einem Tag einen "Schlüssel", einen Fingerabdruck, eine Signierung. Will man die Datei mit den geänderten Werten und selbst eingepflegten GAs etc. wieder speichern, so ist man - sofern man nicht den Generalschlüssel hat um einen neuen Schlüssel zu erzeugen - gezwungen die Datei als neue Datei OHNE SCHLÜSSELINFORMATION zu speichern.

Damit ließe sich auch "verhindern" dass eine Datei im Texteditor geändert wird und als gültige Hersteller-Datei ausgegeben wird. Damit hätte man die Unterscheidung zwischen "Werkseinstellung" und "Benutzereinstellung" sichergestellt.

[update2]

Das Stichwort ist hier "XML signierung" ... Mal schauen ob's das auch in "einfach" gibt.

[l0wside]

Ob uns noch jemand folgen kann?

[QUOTE=tuxedo;428946]
Würde hier (GA und PA) gerne bei den Properties bleiben. Dann brauche ich im mittlerweile doch recht knappen Arduino-Speicher nicht noch einen Mechanismus.
OK, da habe ich den Vorteil von 32k Flash .

Wie bringst du dem Device initial bei, welche PA es hat? Oder schreibst du die Property "PA" in die 15.15.255 und schickst einen Reset hinterher?

Für die GA bietet sich GENERIC03 an: 8 bit KO und 16 bit GA. So hatte ich es mal vor längerer Zeit implementiert (ist wieder rausgeflogen). Unbenutzte werden einfach genullt.

Access Levels:
Ist das nicht nur eine Schein-Sicherheit? Wer die Werte "testweise" ändert, der kann auch dein Zugriffslevel testweise ändern und so die Konfiguration verbasteln. Oder wie würdest du diese Manipulation sicherstellen?
Nö, wer die Werte testweise ändert, kommt gar nicht mehr aufs Device. Die Keys stehen in der XML und müssen vor Property Write und Read mittels AuthRequest an das Device geschickt werden, das dann prüft, ob sie passen. Entspricht dem Parameter -k von mpropread/mpropwrite. Auch die ETS setzt das ein.
Wirklich interessant ist es aber im Grunde nur für den Factory Mode, das stimmt. Bei DIY ist es überflüssig.

Zur Wertebegrenzung:
Das habe ich auch schon gesehen. Wenn ich das aber richtig verstanden habe wird nur die Range des Typs kontrolliert. Das hab ich schon umgesetzt.
Da bist du weiter als ich...
Die Konnex hat die Doku übrigens veröffentlicht. Was wir gesucht hatten, sieht dort so aus:

<TypeNumber SizeInBit="8" Type="unsignedInt" minInclusive="0" maxInclusive="64" />

Ich muss mal schauen, wie ich das bei mit vermostet bekomme.

RegEx ist (auch wenn ich gerne damit arbeite) hier völlig overdone. Dann lieber die Dropdowns implementieren, das sollte erträglicher Aufwand sein.

Um das Thema "nur eine File" etwas abzumildern, hätte ich noch folgende Idee:
Die initielle vom Hersteller zu erstellende Datei hat irgendwo in einem Tag einen "Schlüssel", einen Fingerabdruck, eine Signierung.
Mir ist der Anwendungszweck nicht ganz klar, wer prüft den Schlüssel, und was fängt er mit dem Ergebnis an?
Die Applikation sollte ohnehin stabil genug sein, um auch mit Unfug in den Konfig-Daten zurechtzukommen. Ansonsten: im DIY-Bereich ist die Erkennung von Manipulationen m.E. überflüssig, die ETS hat ihre eigene Lösung, und in meinem Graubereich dazwischen trenne ich ohnehin zwischen Deklaration und Definition und brauche deswegen m.E. die Signatur nicht - muss aber noch mal drüber schlafen.

Max

[Bernator]

na da tut sich ja was
Ich für meinen Teil finden den Ansatz mit Qt recht gut, Java ist nicht so mein Ding....
Hab auf der Basis von Max auch mal bissl was gemacht in Richtung verschachtelter Konfiguration. Sprich bestimmte Properties werden nur zugänglich wenn übergeordnete entsprechend gesetzt sind.





Dabei stellt sich mir die Frage wohin mit diesen Properties? Der Ursprüngliche Gedanke zu den entsprechenden KO's lässt sich da nicht wirklich verfolgen da eine unterschiedliche Konfiguration die KO's unterschiedlich verwendet.
Habs daher einfach mal unter die Common Properties mit eigenem Objekt gepackt...die Menüstruktur wird auch im xml abgebildet wobei jedes Propertie mehrere Optionen (Werte des Propertie) enthalten kann oder eine freie Eingabe ist. Bestimmte Optionen können dann wieder untergeordnetet Properties "freischalten" (xml anbei damit man sich was vorstellen kann)
Soweit funktioniert das bei mir auch schon, was ich noch machen will ist das auch nur jene KO's angezeigt werden die konfiguriert wurden und nicht alle und das nur geänderte Properties "programmiert" werden.

Generell will ich die Bedienung in Richtung ETS bringen und auch ganze Projekte damit abbilden inkl. GA Struktur um mit der lite version kommerzielle KNX Produkte zu konfigurieren und als "Dummy" dann hier einzubauen.
GA Baum und drag and drop der KO's hab ich auch schon grob hinbekommen...


Leider fehlt mir neben dem Bau halt auch die Zeit daher ist jetzt auch schon wieder länger nix passiert aber ich verfolge das hier mit Interesse.

Qt ist auch Neuland für mich aber man kommt recht schnell zu einem Ergebnis und es lässt sich scheinbar auch für andere Plattformen kompillieren somit bräucht man nur den backendtreiber anpassen, falcon is ja nur windowns oder?
Würde es zumindes begrüßen wenn wir die Ressourcen bündeln und nicht jeder sein eigenes Ding macht

[tuxedo]

Ob uns noch jemand folgen kann?

Gute Frage ;-)

OK, da habe ich den Vorteil von 32k Flash .

Mein Arduino Leonardo bzw. Micro hat auch 32k. Nur gehen ca. 4K für den Arduino Bootloader drauf. Und dann noch einiges für den KNX Stack. Hab glaub rdun 15k für die eigentliche Anwendung. Mal schauen ob ich den KNX Stack auch noch etwas reduzieren kann.

Wie bringst du dem Device initial bei, welche PA es hat? Oder schreibst du die Property "PA" in die 15.15.255 und schickst einen Reset hinterher?

Plan ist es das auch über das Tool zu machen --> writeAddress() ...

Für die GA bietet sich GENERIC03 an: 8 bit KO und 16 bit GA. So hatte ich es mal vor längerer Zeit implementiert (ist wieder rausgeflogen). Unbenutzte werden einfach genullt.

Wieso 3 byte, bzw. wieso noch die KO-Nummer mitschicken? Es ist doch vordefiniert an welcher Stelle/Object/Property welches KO seine GA erwartet... Mir reichen hier 2 byte.

Nö, wer die Werte testweise ändert, kommt gar nicht mehr aufs Device. Die Keys stehen in der XML und müssen vor Property Write und Read mittels AuthRequest an das Device geschickt werden, das dann prüft, ob sie passen. Entspricht dem Parameter -k von mpropread/mpropwrite. Auch die ETS setzt das ein.
Wirklich interessant ist es aber im Grunde nur für den Factory Mode, das stimmt. Bei DIY ist es überflüssig.

Ach so, du machst das über AuthRequest... hab ich von gelesen. Aber ich glaub das kann ich mir sparen.

Was wir gesucht hatten, sieht dort so aus:

<TypeNumber SizeInBit="8" Type="unsignedInt" minInclusive="0" maxInclusive="64" />

Ich muss mal schauen, wie ich das bei mit vermostet bekomme.

Nach meinen letzten Überlegungen ist das nicht wirklich nötig. Mit dem regex Ansatz (der das etwas overpowered ist, aber quasi null-aufwand bedeuter) reicht es die Auswahl auf ein paar Elemente einzuschränken (abbildung der DropDown Indizes). beim rest ist mir noch nicht eingefallen warum ich unbedingt ein z.B. uint16 einschränken muss. Hier ist es ggf. einfacher die Anwendung so anzupassen dass sie mit dem vollen uint16 zurecht kommt.

RegEx ist (auch wenn ich gerne damit arbeite) hier völlig overdone. Dann lieber die Dropdowns implementieren, das sollte erträglicher Aufwand sein.

KISS ... Theoretisch könnte man RegEx auch weglassen und eine Art CommaSeparatedValue einsetzen um die DropDown abzubilden. Mal schauen. Mit RegEx ist es bis dato halt schneller gelöst/implementiert.

Mir ist der Anwendungszweck nicht ganz klar, wer prüft den Schlüssel, und was fängt er mit dem Ergebnis an?

Es ging mir hier nur da drum in der Anwendung anzeigen zu können "Diese File ist eine unveränderte herstellerfile" vs. "Diese File ist eine Benutzerkonfiguration mit eigenen Werten (Ga, ...)".
Ist ggf. im 1-file-Ansatz hilfreich. In deinem 2-File Ansatz wohl nicht wirklich nötig.

Die Applikation sollte ohnehin stabil genug sein, um auch mit Unfug in den Konfig-Daten zurechtzukommen.

Die Konfig-Applikation, oder die "Firmware" im Device?

[tuxedo]

na da tut sich ja was
Ich für meinen Teil finden den Ansatz mit Qt recht gut, Java ist nicht so mein Ding....

Entwickle seit nunmehr 11 Jahren mit Java. Hab die Erfahrung gemacht dass wenn jemand Java abschreckend findet, meist die Anwendung grottig implementiert wurde. Und meist wird dann Java als Ursache genannt (und nicht der unfähige Entwickler).

Kannst davon ausgehen dass das fertige Java-Tool "out-of-the-box" laufen wird, ohne dass man was einrichten oder Java extra installieren muss.

Ist schon spät, der Tag war lang, die Baustelle trotz Sonntag anstrengend. Zu deinem restlichen Post komme ich dann morgen im laufe des Tages...

Gut's nächtle ...

- Alex

[Bernator]

Entwickle seit nunmehr 11 Jahren mit Java. Hab die Erfahrung gemacht dass wenn jemand Java abschreckend findet, meist die Anwendung grottig implementiert wurde. Und meist wird dann Java als Ursache genannt (und nicht der unfähige Entwickler).

Das glaube ich dir sofort, daher ist es für jemanden mit wenig Erfahrung darin gefärhlich und praktisch vorprogrammiert das es grottig wird

[tuxedo]

Das glaube ich dir sofort, daher ist es für jemanden mit wenig Erfahrung darin gefärhlich und praktisch vorprogrammiert das es grottig wird

Ach so, du meinst aus deiner Entwickler-Sicht... Okay. Dachte aus Anwendersicht.

[tuxedo]

na da tut sich ja was

Hab auf der Basis von Max auch mal bissl was gemacht in Richtung verschachtelter Konfiguration. Sprich bestimmte Properties werden nur zugänglich wenn übergeordnete entsprechend gesetzt sind.

Über sowas hab ich auch schon mal nachgedacht. Die Frage ist nur: Lohnt sich der Aufwand? Die KNX DIY "Szene" ist relativ klein und überschaubar. Muss es da gleich zu Anfang die Eierlegende Wollmilchsau geben? Und sind die ersten DIY-Geräte dann auch so umfangreich dass man das braucht?

Würde lieber "schnell, klein, aber funktionierend" anfangen/releasen, als eine gefühlte Ewigkeit das Tool auszubauen und zu verbessern ...
Wenn die erste Version funktioniert und anklang findet, kann man ja immer noch die Sache ausbauen und erweitern.

Ein weiterer Punkt ist die Zielgruppe... Muss es wirklich ein recht aufwendiges XML-Format sein das sich bald nur noch mit einem grafischen Tool beherrschen lässt?

Qt ist auch Neuland für mich aber man kommt recht schnell zu einem Ergebnis und es lässt sich scheinbar auch für andere Plattformen kompillieren somit bräucht man nur den backendtreiber anpassen, falcon is ja nur windowns oder?

AFAIK .. Ja, nur Windows. Einer der Gründe warum es die ETS nicht für Linux gibt. Kenne, außer Calimero (java....) keinen anderen umfangreichen KNX "Backendtreiber". Ob man das an Qt anflanschen kann um damit die Linux-Welt abzudecken?! Keine Ahnung.

Würde es zumindes begrüßen wenn wir die Ressourcen bündeln und nicht jeder sein eigenes Ding macht

Es wäre ein Anfang wenn wir auf ein gemeinsames, kompatibles XML-Format kommen. Wenn es dann mehrere Tools gibt die damit umgehen können: Wieso nicht. Aber aktuell verfolgen wir teils unterschiedliche Ziele :-(

[JuMi2006]

Wieso 3 byte, bzw. wieso noch die KO-Nummer mitschicken? Es ist doch vordefiniert an welcher Stelle/Object/Property welches KO seine GA erwartet... Mir reichen hier 2 byte.

Mitreden kann ich hier schon lange nicht mehr, hab aber zumindest auf Hardwareseite noch 1-2 Arduino-Projekte in der Schublade.
Sofern ich mich recht erinnere hat Max keine fest definierten Speicherblöcke für das ganze Property-Zeugs sondern schreibt die ganze Tabelle frei von vorne weg, das würde zumindest das 3. Byte erklären.

Gruß

[Bernator]

Würde lieber "schnell, klein, aber funktionierend" anfangen/releasen, als eine gefühlte Ewigkeit das Tool auszubauen und zu verbessern ...

Naja genau das hat Max mit seinem Config Tool ja bereits am laufen, also warum nochmal neu erfinden? Nur wegen Linux?
Ich für meinen Teil will eben auch Digitale Eingänge konfigurieren und da wirds schnell unübersichtlich da viele properties benötigt werden. Ist zwar am Anfang wenn man in der Materie drinnen ist nicht unbedingt das Problem aber sobalt man später weider drauf schaut ist es eine Qual. Daher darf aus meiner Sicht das xml schon etwas "komplexer" sein, da steck ich einmal mein Hirnschmalz rein und später muss ich mich nicht mehr darum kümmern....

Es wäre ein Anfang wenn wir auf ein gemeinsames, kompatibles XML-Format kommen. Wenn es dann mehrere Tools gibt die damit umgehen können: Wieso nicht. Aber aktuell verfolgen wir teils unterschiedliche Ziele :-(

Sehe ich auch so, zur Not werten die jeweiligen Tools halt bestimmte Teile des anderen gar nicht aus....
Schöner wär trotzdem EIN Tool