Wie sind die "Dynamic" blöcke in den XML Deskriptoren zu lesen?

[thewhobox]

Hallo Waldemar,

Meiner Auffassung nach wird das when default nur angezeigt wenn alle anderen whens nicht aktiv sind.
Somit würde bei deinem Beispiel X nie angezeigt werden, da der when Zweig mit > immer aktiviert ist.

So hab eich es bei mir implementiert und bisher noch keine Fehler zumindest bei der Anzeige gemerkt.

Hatte das glaube ich mal mit einer Test Produktdatei sogar getestet wann was angezeigt wird und da kam genau das raus.

Wenn ich später Zeit habe, erstelle ich mal kurz eine und Teste es und geb euch bescheid.


Gruß Mike

[mumpf]

Achso, also wie ein case default: in c++? Ok, das macht auch Sinn, dann verstehe ich es.

Danke, das würde Sinn machen. Musst Du auch nicht testen. Ich werde das ausprobieren, wenn ich das nächste mal was mache, da ich jetzt weiß, wie ich es einsetzen müsste.

Danke und Gruß, Waldemar

[cdutz]

Hi,

Da ich also kein Hersteller bin und auch für keinen arbeite, habe ich dieses Manufacturer-Tool nicht. Wenn ich es richtig gesehen habe muss man hierfür eine Lizenz erwerben wie für's ETS. Ich vermute mal dass dies auch nur registrierte Unternehmen bei der KNX Foundation erwerben können. Zwar sind wir bei der Apache Software Foundation als "Associated Partner" gelistet, allerdings erlaubt uns das wohl nicht Zugriff auf das Manufacturer Tool. Zumindest habe ich noch nirgends finden können wo man es Download, kaufen oder nähere Informationen dazu finden kann.

Auch schon mal vielen dank für die vielen Gedanken, die du dir gemacht hast. Vielleicht sollte ich auch mal erklären, was ich gerade genau mache:
Ich habe im Apache PLC4X Projekt die Auto-Discovery für KNX implementiert. Hiermit kann ich nun alle meine KNX Geräte entdecken, identifizieren und auch auslesen welche Gruppenadressen an welche ComObjekte gekoppelt sind und wie diese konfiguriert sind (Lesen, Schreiben, Übermittlung und welcher genereller Datentyp verwendet wird)

Leider ist das nur die halbe Miete. Nun weiß ich zwar dass ComObject X einen bestimmten Wert hat und einen bestimmten typ, allerdings nicht was dieser Wert in der aktuellen Konfiguration genau bedeutet und welcher Datentyp das genau ist (Also nicht nur "16 bit", sondern z.B.: "Temperatur in °C" und was der Wertebereich ist.

Hier kommt nun das in's Spiel, an dem ich gerade herumwerkle. Ich will herausfinden welche Parameter ich auslesen muss, um diese interpretation machen zu können. Nicht alle parameter haben eine Auswirkung auf die generelle Konfiguration der ComObjekte. Ich nenne die Parameter, die eine Auswirkung haben mal "Discriminator-Parameter". Generell sollten das vermutlich alle Parameter sein, die als input zu einer der Choose Blöcke verwendet werden. Allerdings nur, wenn die Konfiguration des ComObjects nicht immer die gleiche ist, egal welcher wert der Diskriminator hat (Habe da auch schon choose Blöcke gesehen, bei denen bei allen varianten einige ComObjects immer die gleiche Konfiguration haben. In diesem fall wäre der Parameter des Choose elements für mich kein Discriminator-Parameter.
Ich will die minimale menge an Parametern bestimmen, die die Funktion eindeutig beschreiben, damit ich genau diese Parameter auslesen kann.

Ich habe die Schemata für die Deskriptoren in version 11, 12, 13, 14 und 20 (Mehr gibt es wohl nicht) allerdings arbeite ich jetzt erst an der 11, weil die meisten Geräte in meinem haus dieses Schema benutzen (Auch sind die meisten von Gira) ... in den Deskriptoren der anderen Hersteller habe ich das nicht so oft gesehen.
Hier scheint es aber ein Design-Pattern zu sein, dass ein ParameterRefRef deklariert wird, direkt darauf ein choose kommt, welches diesen Parameter referenziert und dann enthält das choose nur ein when mit "default='true'". Ich vermute das kann eigentlich keinen funktionalen Grund haben, sondern dient nur der Strukturierung oder ist das Resultat eines Code-Generators.

Jetzt mache ich mir erstmal eine XSLT, die einfach den ganzen Dynamic Block so ausgibt, dass keine RefIds benutzt werden, sondern alles schön in Klartext ausgegeben wird. Ja das XML wird dadurch noch gigantischer als es vorher schon ist, aber ich denke mit sprechenden Namen kann ich die Struktur viel einfacher begreifen als mit diesen monströsen ID Konstrukten ;-)

Ich hoffe sehr, dass mir das dann beim verstehen hilft.

Gruß,
Chris

[mumpf]

Hi,

danke für die Erklärung, ist ja spannend, was Du so machst. Geht ein bisschen in die gleiche Richtung wie der der Ansatz von Mike thewhobox, der ein eigenes Parametrisierungswerkzeug baut. Eben auch mit Erkennung der Geräte und mit einer Art Rekonstruktionsansatz.

Ich mach das als Hobby, um meine DIY-Geräte mit der ETS parametrieren zu können. Deswegen erzeuge ich die knxprod, auch ohne das Manufacturer Tool.

Ich will die minimale menge an Parametern bestimmen, die die Funktion eindeutig beschreiben, damit ich genau diese Parameter auslesen kann.

Du willst zu jedem KO auch dem DPT feststellen, habe ich das richtig verstanden? Durch eine Art Rückwärtssuche, indem Du alle Parameter und deren Werte rausfindest, die das KO beeinflussen? Sozusagen die schwächste Vorbedingung für ein bestimmtes KO?

Spannend... Warum dann nicht gleich alle Parameter und eine komplette Rekonstruktion? Wobei das schwierig ist, da ja verschiedene Parameter den gleichen Speicher im Memory-Block belegen können und somit man erstmal feststellen muss, welcher Parameter gerade den aktuellen Wert belegt. Aber das müsste vom Algorithmus her genau so sein, wie die Parameter für ein KO zu bestimmen.

Aber ich schweife ab... Du kannst ja vielleicht mal vorstellen, was daraus geworden ist, wenn Du so weit bist.

Gruß, Waldemar

[thewhobox]

mumpf Ich habe es gerade mal auf die schnelle getestet mit:

<ChannelIndependentBlock Name="Unbenannt" Text="">
<ParameterBlock Name="Unbenannt" Text="Allgemein">
<ParameterRefRef RefId="M-00FA_A-0001-10-0000_P-1_R-1" />
<choose ParamRefId="M-00FA_A-0001-10-0000_P-1_R-1">
<when test="&gt;=1">
<ParameterRefRef RefId="M-00FA_A-0001-10-0000_P-2_R-2" />
</when>
<when test="&gt;=2">
<ParameterRefRef RefId="M-00FA_A-0001-10-0000_P-3_R-3" />
</when>
<when default="true">
<ParameterRefRef RefId="M-00FA_A-0001-10-0000_P-4_R-4" />
</when>
</choose>
</ParameterBlock>
</ChannelIndependentBlock>

Der Parameter ist ein Enum mit 0, 1 und 2.
Hier wird der Default nur angezeigt, wenn der Parameter 0 ist.

Wie stellst du eig deine Produktdatenbanken her? Per hand oder mit dem CreatKNXProd?


cdutz Um das zu rekonstruieren musst du den kompletten Speicher auslesen und von oben nach unten rechnen, welcher ComObjectRef sichtbar ist, da wie du schon erkannt hast, ein ComObject auch mehrere Datentypen haben kann, je nach Einstellung in den Parametern.
Das ganze Spiel ist besonders lustig, wenn es um Parameter in chooses geht, die nicht im Speicher gespeichert werden xD

[wknx]

• Wenn der ParamRefRef aktiviert wird und der User noch nichts gemacht hat, dann steht da ja eine 3 drin (default), dann sollte X, Y und Z aktiv sein (also interpretiert werden).
• Wenn der User den ParamRefRef auf 4 stellt, dann sind nur noch Y und W aktiv.
• Wenn der User wieder auf 3 geht, was hab ich dann: Y und Z oder X, Y und Z? Die Frage ist hier, ob "default" meint, dass der Parameter noch nicht vom User verstellt wurde oder ob es besagt, dass der Wert des Parameters gleich dem Wert des Defaultwertes (value) ist.
• Und falls Y und Z in 4 rauskommen: Was passiert, wenn der ParamRefRef zwischendurch inaktiv (z.B. durch einen anderen choose) und dann wieder aktiv wird, mit der drin stehenden 3: Hab ich dann wieder Y, Z oder doch ein X, Y und Z?

Ist bei mir nun auch schon wieder eine weile her, dass ich mich intensiver damit beschäftigt hatte: Nach meinem Verständnis wird bei Choose-When maximal ein When-Zweig ausgewählt. Entweder der erste der matched, ansonsten ein ggf. vorhandener default-Eintrag.

[thewhobox]

wknx Es werden alle angezeigt deren Test-Bedingung erfüllt ist.
Das default nur, wenn alle anderen whens nicht erfüllt sind.

[mumpf]

Hi,

Nach meinem Verständnis wird bei Choose-When maximal ein When-Zweig ausgewählt.

das ist definitiv nicht so. Ich hab ein einigen Stellen ein when test=">0" und ein when test="3", und beide werden durchlaufen, wenn der Parameter 3 ist. Mit "default" hab ich keine Erfahrung, aber es klappt bestimmt wie beschrieben.

Wie stellst du eig deine Produktdatenbanken her? Per hand oder mit dem CreatKNXProd?

Ich hab ein eigenes Tool geschrieben, findest Du hier: https://github.com/mumpf/multiply-channels. Das ist nicht perfekt, aber es läuft soweit. Ist eine reine Kommandozeilen-Version.

Gruß, Waldemar

[thewhobox]

mumpf Cool, probiere ich die Tage mal aus.
Ich bin eher Fan von Klicki Bunti Guis xD
Und hab mir auch was kleines geschrieben:

https://github.com/thewhobox/Kaenx.Creator

[mumpf]

Ja, UI ist nett, aber überflüssig .

Nee, bei mir ist das Erzeugen der knxprod eigentlich nur Nebensache. Ich nutze das Tool, um mit Includes zu arbeiten und Teile zu vervielfältigen, damit ich so Spielereien machen kann wie 80 Logikkanäle und 30 1-Wire-Kanäle usw. Das alles inclusive renumbering der IDs und einigen sanity checks, um meine ganzen Tippfehler schon frühzeitig rauszufinden. Aber "einfache" Files kann es auch verarbeiten .

Gruß, Waldemar

[cdutz]

Hi,

also ich hatte gedacht ich lese so wenig wie möglich aus um so wenig wie möglich last auf dem KNX bus zu erzeugen. Weil generell muss ich für den von mir geplanten einsatzzweck diese Einstellungen für jedes Device auslesen. Zwar theoretisch nur bei der Auto-Discovery, aber halt dennoch für alle Geräte. Ich bin einfach mal davon ausgegangen, dass nur ein kleiner Anteil der Parameter einen direkten Einfluss auf die interpretation des Com-Object Datentyps haben.

Ich habe mir auf jeden Fall jetzt mal eine XSLT gebaut, die mir den dynamic block so ausgibt dass die referenzierten Elemente inline eingebettet sind und ich damit direkt sehen kann was Sache ist. Das hilft schon mal sehr viel.

Ich hatte auch erst erwartet, dass ein "default" block ähnlich einem switch statement in den meisten Hochsprachen ist. Hier würde der default nur genommen werden, wenn keiner der cases gematcht hat. Wenn hier allerdings mehrere cases matchen können, dann ist das eine sehr wichtige info, davon wäre ich nämlich jetzt nicht ausgegangen.

Momentan tesste ich noch mit den descriptoren der Devices, die ich in meinem Haus verbaut habe, weil ich mir damit am einfachsten mit dem ETS5 anschauen kann, was Sache ist. Allerdings habe ich hier in einem Ordner noch ca. 12GB an XML daten rum liegen, auf die ich meine SW dann anwenden muss. Ich bin mir sicher, dass da der eine oder andere Hersteller noch üble Dämonen in seinen Deskriptoren versteckt hat (Ich meine ... wer sich mit Unicode Whitespace Sonderzeichen im Firmennamen in die KNX Datenbank einträgt, von dem erwarte ich, dass die Deskriptoren dem Endgegner im Mario-Land ähnelt.

Ach ja ... falls sich jemand dafür interessiert. Meine Auto-Discovery habe ich im Apache PLC4X repo drin (https://github.com/apache/plc4x/blob...x_discovery.go) Ich habe das bisher nur mit meinen eigenen Geräten getestet und denen im Haus eines Freundes ... wäre für feedback sehr dankbar :-)


VIele Grüße,
Chris

[mumpf]

Hi ihr beiden,

ich wollte euch mal einen Fall präsentieren, der mich gestern die ganze Nacht beschäftigt hat und bei dem ich dachte, dass ich es wohl nicht hin bekomme, es dann aber nach viel Try&Error geschafft habe. Für euch beide, die die xml-Files ja parsen wollen, ist das sicherlich interessant.

Szenario: Ich will die Auswahl von Sensoren erlauben. Dabei kann jeder Sensor unterschiedliche Messwerte erfassen, das will ich visualisieren.
BME280.jpg
Hier wird gezeigt, dass der BME280 sowohl als Temperatur-, Luftfeuchte- und Luftdrucksensor genutzt wird.
Es gibt auch noch Sensorkombinationen, die man in der Dropdown auswählen kann, um alle Messwerte zu bekommen.
SHT3x-IAQCore.jpg
Ich denke, das Bild erklärt sich von selbst. Somit kann man über die Dropdown bestimmte (getestete und bevorzugte) Kombinationen auswählen. Das funktioniert problemlos. Dann gibt es aber noch den User-Modus "Einzelauswahl", wo ich für jeden Messwert den Sensor einzeln bestimmen kann:
Einzelauswahl.jpg
Beim Umschalten von der letzten ausgewählten Kombi auf Einzelauswahl wollte ich natürlich, dass die Sensoren der letzten ausgewählten Kombi der Ausgangspunkt für die Einzelauswahl sind. Leider stand immer in allen unteren Dropdowns "Kein Sensor", sobald ich die "Einzelauswahl" gewählt habe. Ich habe es nur hinbekommen, indem ich 3 Sachen gemacht habe, die eigentlich sinnlos sind bzw. bei denen äquivalente Sachen nicht gingen.

Folgendes hab ich gemacht:
Die Dropdown "Sensor" hat folgenden Datentyp mit Werten 0-12:

              <ParameterType Id="M-00FA_A-0001-01-0000_PT-SensorDevices" Name="SensorDevices">
                <TypeRestriction Base="Value" SizeInBit="6">
                  <Enumeration Text="Kein Sensor" Value="0" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-0" />
                  <Enumeration Text="SHT3x" Value="1" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-1" />
                  <Enumeration Text="SHT3x+IAQCore" Value="10" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-10" />
                  <Enumeration Text="BME280" Value="2" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-2" />
                  <Enumeration Text="BME280+SCD30" Value="3" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-3" />
                  <Enumeration Text="BME280+IAQCore" Value="11" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-11" />
                  <Enumeration Text="BME680" Value="4" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-4" />
                  <Enumeration Text="BME680+SCD30" Value="5" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-5" />
                  <Enumeration Text="SCD30" Value="6" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-6" />
                  <Enumeration Text="SCD30+BME280" Value="7" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-7" />
                  <Enumeration Text="SCD30+BME680" Value="8" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-8" />
                  <Enumeration Text="IAQCore" Value="9" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-9" />
                  <Enumeration Text="Einzelauswahl" Value="[MARKIEREN]12[/MARKIEREN]" Id="M-00FA_A-0001-01-0000_PT-SensorDevices_EN-12" />
                </TypeRestriction>
              </ParameterType>

(die 12 wird noch wichtig). Die anderen Dropdowns sind ähnlich definiert, für das Problem aber nicht wichtig. Ich habe für die anderen Dropdowns natürlich Parameter definiert und pro Parameter immer 2 ParameterRef, einer mit Access="Read", der andere eingebbar:

              <ParameterRef Id="M-00FA_A-0001-01-0000_UP-200_R-2001" RefId="M-00FA_A-0001-01-0000_UP-200" />
              <ParameterRef Id="M-00FA_A-0001-01-0000_UP-200_R-2002" RefId="M-00FA_A-0001-01-0000_UP-200" Access="Read" />
              <ParameterRef Id="M-00FA_A-0001-01-0000_UP-201_R-2011" RefId="M-00FA_A-0001-01-0000_UP-201" />
              <ParameterRef Id="M-00FA_A-0001-01-0000_UP-201_R-2012" RefId="M-00FA_A-0001-01-0000_UP-201" Access="Read" />

(das sind jetzt nur 2 der 5). Jetzt wird es länglich, aber ich markiere mal die wichtigen Stellen gelb und kürze alles auf nur 2 Dropdowns statt 5:

                <!-- Old sensor selection -->
                <ParameterRefRef RefId="M-00FA_A-0001-01-0000_UP-160_R-1601" />
                <!-- Try to keep compatibility: We convert old dropdown setting to new parameters -->
                <choose ParamRefId="M-00FA_A-0001-01-0000_UP-160_R-1601">
                  <when test="[MARKIEREN]12[/MARKIEREN]">
                    <!-- this looks senseless, but is necessary keep values in dropdown -->
[MARKIEREN]                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" SourceParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" />
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" SourceParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" />
[/MARKIEREN]                    <!-- Assing target dropdown values -->
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2001" SourceParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" />
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2011" SourceParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" />
                  </when>
                  <when test="0">
                    <!-- No sensors -->
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" Value="0" />
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" Value="0" />
                  </when>
                  <when test="1">
                    <!-- SHT3x: Temp, Hum -->
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" Value="1" />
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" Value="1" />
                  </when>
                  <when test="2">
                    <!-- BME280: Temp, Hum, Pre -->
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" Value="2" />
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" Value="2" />
                  </when>
                  <when test="3">
                       [B]... usw bis ...[/B]
                  <when test="11">
                    <!-- BME280+IAQCore: Temp, Hum, Pre, Voc, Co2-Calc -->
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-200_R-2002" Value="2" />
                    <Assign TargetParamRefRef="M-00FA_A-0001-01-0000_UP-201_R-2012" Value="2" />
                  </when>
                </choose>
                [MARKIEREN]<!-- New sensor selection -->[/MARKIEREN]
                <choose ParamRefId="M-00FA_A-0001-01-0000_UP-160_R-1601">
                  <when test="[MARKIEREN]12[/MARKIEREN]"> 
                    <ParameterRefRef RefId="M-00FA_A-0001-01-0000_UP-200_R-2001" />
                    <ParameterRefRef RefId="M-00FA_A-0001-01-0000_UP-201_R-2011" />
                  </when>
                  <when test="&lt;12">                  
                    <ParameterRefRef RefId="M-00FA_A-0001-01-0000_UP-200_R-2002" />
                    <ParameterRefRef RefId="M-00FA_A-0001-01-0000_UP-201_R-2012" />
                  </when>
                </choose>

3 Sachen, die ich nicht verstehe:

1. Wenn ich statt when test="12" ein when default="true" nehme, was ja der else-Fall ist, weil alle anderen Werte 0-11 in anderen when-Klauseln abgehandelt werden, bekomme ich "Kein Sensor" (also value=0) für alle dropdowns.
2. Wenn ich bei when test="12" die gelben Assigns nicht mache (achtet darauf, das ist eine Zuweisung A=A, erst die darunter ist die eigentlich gewünschte B=A), dann bekomme ich "Kein Sensor" für alle dropdowns.
3. Wenn ich das choose nach dem gelben "New sensor selection" vor den choose direkt davor mache (die ParamRefId ist bei beiden choose die gleiche), dann (rate mal) bekomme ich "Kein Sensor" in allen dropdowns.

Fall 1 sollte beides erlauben, denn beides ist (bei einer dropdown mit 0-12 und when von 0-11) identisch.
Fall 2 macht gar keinen Sinn (und ich weiß nicht, in welchem Stand meines übernächtigten Deliriums ich darauf kam, so was zu testen, aber das war der Durchbruch): Warum muss ich A=A zuweisen, damit ich dann B=A machen kann? Warum ist ohne A=A ein B=A => B=0 aber mit A=A ein B=A => B=A?
Fall 3 hatte ich andersrum, weil ich normalerweise immer erst die ParamRefRef aktiviere (also darstelle), bevor sie Werte zugewiesen bekommen. Und meiner Meinung nach sollte das auch keinen Unterschied machen.

Aber nachdem das jetzt klappt, stelle ich mir die Frage: Soll das gehen oder nutze ich einen Bug der ETS aus, der mit irgendeiner zukünftigen Version "bereinigt" wird und dann geht mein UI nicht mehr? Immerhin habe ich min. 10 verschiedene Kombinationen ausprobiert, die nicht gingen und nur diese eine geht!

Falls ihr Ideen/Anregungen zu dem Thema habt, nur her damit...

Gruß, Waldemar

[thewhobox]

Hallo Waldemar,

ich glaub das hat was mit der "sichtbarkeit"/"aktive" Parameter zu tun.
Aber bei Fall 1 solltest du eigentlich recht haben, dass das keinen Unterschied machen sollte.
Mit dem Assign hab ich bisher auch nur wenig erfahrung. Hab den nur mal in einer Applikation von MDT gesehen.
Ich denke aber mal einfach laut: Mit dem A=A machst du den Parameter quasi "sichtbar"/"aktiv", da du unten ja nur _R-2001 einbindest.
Ich kann mir vorstellen, dass wenn der Parameter nicht sichtbar ist eben der DefaultWert genommen wird (was ja 0 ist).

Ist aber auch eher geraten als gewusst.


Gruß Mike

[cdutz]

Auch wenn ich auf einen Alten Thread von mir antworte ... ich glaube ich habe das jetzt so verstanden, dass der default=true block nur dann aktiviert ist, wenn kein anderer block aktiviert ist. In dem sinne, wäre das nicht ganz, wie du es beschreibst ... test=">0" kann neben anderen cases ausgeführt werden default=true nur wenn wirklich sonst nichts anderes aktiv ist.

Habe ich das richtig verstanden?

[cdutz]

Sorry .. hatte nicht gesehen, dass eine 2. Seite war und das alles schon beantwortet war ... ergänze gerade neue Einsichten von diesem Thread in meiner Doku ...
https://github.com/apache/plc4x/blob...-profiles.adoc