Open-Source Mitstreiter vor allem mit KNX-Wissen gesucht ...

[cdutz]

Hallo Mike,

vielen Dank für dein Input ... bin auch gerade noch dabei den Input von meinem über einem Jahr alten Thread einzupflegen, in dem du ja auch fleißig mitgeholfen hast :-)

Ich muss gestehen, dass ich momentan einfach das aufgeschrieben habe, was ich gesehen habe. Die ModuleDeines habe ich noch nie gesehen.

Und generell ... ja ... da ist sicher einiges "Schwammig" aber es ist nunmal mein erster versuch das alles aufzuschreiben und sicher sind bei mir da noch viele Fragezeihen.

Habe mal einige Änderungen einfließen lassen und das Dokument aktualisiert.

Gruß,
Chris

[cdutz]

Vielleicht noch eine Frage zum Thema: "wie interpretiere ich die Daten?"

Also wir haben ein ParameterRefRef, welches ein ParameterRef referenziert und ein ParameterRef, welches ein Parameter referenziert ... dann ein Parameter, das einen ParameterType referenziert und bei den ComObjects ist das ähnlich.

Weil jetzt z.B. ein ComObject einen type hat und in einer ComObjectRef überschrieben werden kann ... verstehe ich es richtig, dass ich semantisch beim Parameter anfange und dessen attribute, wenn ein Attribut im ParameterRef erneut vorkommt, überschreibt es das gleichnamige Attribut aus Parameter? (Und ähnlich bei den ComObjects?)

[thewhobox]

Genau. Der Ref überschreibt bestimmte Eigenschaften des Parameters/KOs

ParameterTypes -> Parameter -> ParameterRef
ComObjects -> ComObjectsRef

Die RefRef sind nur zum anzeigen da, können also nix überschreiben oder so.

[cdutz]

Hi thewhobox,

danke für die Bestätigung ... das, was ich hier sehe, wenn ich das so in eine XSLT implementiere wirkt auch sehr viel übersichtlicher. Für computer ist dieses Id-referenziere vielleicht pillepalle ... für mein Hirn allerdings eine Folter ;-)

Kommt gleich noch in meine Doku :-)

Gruß,
Chris

[mumpf]

Hi Chris,

ich weiß nicht, ob Dich das schon jemand gefragt hat: Die frei zugängliche KNX-Spec von der KNXA hast Du schon, oder? Ich meine die Version 2.1 von Oktober 2013

Gruß, Waldemar

[mumpf]

Hi cdutz und thewhobox,

ich bin heute über was gestolpert, dass mir nochmal den Unterschied zwischen when ... "default" und when ... "<fester Wert>" gezeigt hat. Folgendes Konstrukt (vereinfacht):

                <choose ParamRefId="R_84">
                  <when test="0">
                    <ParameterRefRef RefId="R_77" Cell="2,2" />
                  </when>
                  <when test="1">
                    <ParameterRefRef RefId="R_64" Cell="2,2" />
                  </when>
                </choose>
...
                <choose ParamRefId="R_64">
                  <when test="0">
                    <ParameterRefRef RefId="R_65_1" Cell="2,3" />
                  </when>
                  <when test="1">
                    <ParameterRefRef RefId="R_65_2" Cell="2,3" />
                  </when>
                  <when default="true">
                    <ParameterRefRef RefId="R_65_3" Cell="2,3" />
                  </when>
                </choose>

Zur Erklärung:
R_64 und R_84 sind eigentlich boolean und so hab ich auch gedacht. Und R_84 ist auch immer Sichtbar, somit ist es auch aktiv. Der choose R_84 ist komplett, weil nur 0 oder 1 vorkommen kann. Hier würde ein default nie wirksam werden. Und wenn R_84 = 1, dann wird R_64 sichtbar und kann auch nur true/false werden und somit nur R_65_1 oder R_65_2 aktivieren.
Und hier der Fall, an den ich immer nicht denke: Wenn R_84 = 0, dann wird R_64 nie aktiviert und ist dann WEDER 0 NOCH 1! Dann greift der default und R_65_3 wird aktiviert!

Ich wollte das nur der Vollständigkeit mal schreiben, weil wir letztens darüber diskutiert haben, falls ihr das schon wisst, dann vergesst einfach meinen Post.

Gruß, Waldemar

[thewhobox]

Hey Waldemar,

vielen Dank für die Info.
Das war mir nicht bekannt. Ich dachte immer, dass dann der zweite choose einfach komplett ignoriert wird.
Dann darf ich jetzt wohl wieder meinen Anzeigealgorithmus neu schreiben^^

Gruß Mike

[mumpf]

Hi Mike,

bevor Du das komplett neu machst, probiere es nochmal aus. Ich mach das auch nochmal, ich hab das Beispiel hier vereinfacht (bei mir sind noch mehr Indirektionen drin), nicht das ist das fehlinterpretiert habe. Mir erschien das schlüssig, aber ich gestehe, dass ich in der Vergangenheit auch Deiner Meinung war:

Ich dachte immer, dass dann der zweite choose einfach komplett ignoriert wird.

Ich gebe nochmal Feedback...

Gruß, Waldemar

[mumpf]

Hi Mike,

Kommando zurück. Du hast Recht, ich habe Unrecht. Ist eine Tabellenzelle, und ich habe an einer anderen Stelle nochmal in einem choose in der gleichen Zelle was dargestellt, deswegen hab ich das Missinterpretiert. Das "when default" kommt gar nicht zum Zuge. Du hast Recht, das ganze choose wird ignoriert. Hab ich extra nochmal ausprobiert!

Sorry für die Verwirrung!

Gruß, Waldemar

[thewhobox]

Kein Problem
Jetzt haben wir wenigstens Gewissheit!

Gruß Mike

[cdutz]

Hallo allerseits ;-) und danke für die info ... und habe auch gesehen, dass du das mit der KNX Spec erwähnt hast ... ich meine die offizielle Spec 2.1 von der KNX Foundation zu haben.

Und wegen der interpretation: Ich habe das mal bei mir so gemacht, dass ein "ParamRefRef" einen ParamRef in eine Map steckt mit der id der RefRef ... ein choose ist wie ein "if(es ist eine refref mit dieser Id in der map)" dann habe ich für jedes choose eine boolean variable, die in jedem when block von false auf true gesetzt wird. Das chose default=true checkt dann ob diese variable false ist. Sollte das von der logik her an den echten case ran kommen?

Gruß,
Chris

[thewhobox]

Sollte das von der logik her an den echten case ran kommen?

Von der Logik her sollte es passen.

Ich hab von der Logik her mich von dem XML gelöst.
Das ist zwar schön und gut um die Daten zu speichern und visuell zu machen, aber für mich in der Handhabung her nachher zu unhandlich.
Deswegen hat jeder Parameter im Dynamic einfach eine Liste mit allen "Bedingungen", damit er angezeigt wird. (vom ParameterRefRef Element zum Dynamic Element durchschleifen)
Bei einem default, hab ich dann die Bedingung der anderen whens negiert, damit er angezeigt wird.

So kann ich ganz unkompliziert mit der Liste arbeiten ohne unzählig verschachtelte chooses in der Datenstruktur zu haben.
Und noch ein Pluspunkt: Wenn ich die SourceId habe (also den Parameter im choose), kann ich mir gezielt die Parameter rausholen und nur die berechnen.

Gruß Mike

[cdutz]

Habe mir eine XSLT geschrieben, die den dynamic block auflöst indem es bei den Ref anfängt und attribute vom Element nur dann übernimmt, wenn sie im Ref nicht überschreiben wurden. Habe dann nochmal eine XSLT, die unbenutzte parameter (Also parameter, die nirgends in einem choose benutzt werden) ausfiltert (In meinem fall interessieren die nicht) ... werde als letzten schritt nun einen SAX listener bauen, der mir dann bei gegebenen config-memory ausgibt welches com-object, welchen typ hat.

[thewhobox]

Stimmt, du musst die Parameter dann ja nicht anzeigen.
Dann klingt das echt besser. Aber mit XSLT kenne ich mich nicht aus.