Auslesen der code-blocks?

[cdutz]

Hallo allerseits,

Für denn Fall, dass diese frage in meiner allgemeineren Frage untergeht:

Ich versuche gerade die Speicherbereiche auszulesen, in denen die Konfiguration der KNX Geräte hinterlegt ist.
Wenn ich mir die XML Files so ansehe referenzieren die Parameter ja gelegentlich Code Blocks. Diese würde ich gerne auslesen um daraus die Konfiguration zurück zu rechnen und daraus wiederum zu wissen welche genauen Datentypen meine Com-Objects haben.

Als ich die Gruppen-Adressen etc. ausgelesen hatte, habe ich ja die zugehörigen Datenpunkte, die die jeweiligen Adressen enthalten via KNX direkt auslesen können. Nur bin ich für diese Informationen noch auf keinen Datenpunkt gestoßen, der mir hier helfen könnte.

Hier wäre ich sehr dankbar für Hinweise, wie ich das bewerkstelligen kann.

Und das ist zu 100% für das Open-Source Projekt Apache PLC4X, eure Hilfe hilft also allen, die PLC4X nutzen/nutzen wollen :-)

Viele Grüße,
Chris

[Klaus Gütter]

Hallo Chris,

das wird nicht funktionieren. Du kannst dir zwar die Speicheradressen der Parameter aus dem XML extrahieren und dann per MemoryRead aus dem Gerät lesen, aber dann? Parameter und ihre Semantik sind in keiner Weise standardisiert. Du bräuchtest also eine riesige Datenbank in der für jedes unterstützte Produkt abgelegt ist, wie man aus den Bits im Speicher auf Datenpunkttypen schließt.

Totzdem viel Erfolg
Klaus

[cdutz]

Hallo Klaus,

eigentlich hatte ich gehofft, dass ich die Start-Adresse ohne Xml auslesen könnte (Wie bei den Group-Addressen). Mein Ziel war es den dynamischen teil der Xml via Xslt so zu vereinfachen, dass ich daraus wieder code generieren kann.

Ich habe mir das so vorgestellt, dass ich dann für jedes Gerät eine kleine Klasse habe, der ich als Input ein Byte-Array gebe und als Output bekomme welche Com-Objekte welchen Datentyp haben.

Ich weiß, dass ist einiges an Arbeit ... aber ich wäre bereit sie zu tun.

Ich hatte allerdings schon versucht die Start-Adressen aus dem XML zu nehmen und dann die Blöcke zu laden, allerdings wollten die Gräte die Information nicht rausrücken oder es waren daten drin, die eindeutig nicht stimmen können. (Habe probehalber versucht einzelne datenpunkte per Hand zu dekodieren)
Daher wollte ich sichergehen, dass es überhaupt möglich ist diese Code-Blöcke auszulesen ... Ich hätte gedacht, diese wären einfach wie aneinander gereihte Bytes, oder haben diese dann noch einen Header und eine besondere Struktur?

Gruß,
Chris

[Klaus Gütter]

Hallo Chris,

dein Enthusiasmus in allen Ehren. Aber:

"für jedes Gerät eine kleine Klasse" - du weiß schon dass es einige 10.000 KNX-Geräte gibt?

"allerdings wollten die Geräte die Information nicht rausrücken oder es waren Daten drin, die eindeutig nicht stimmen können" - die choose/when-Konstrukte können tief verschachtelt sein und nicht jeder Parameter wird auch in das Gerät geladen. Das ist richtig viel Arbeit (ich weiß das, weil unsere ETS-App "Rekonstruktion" sich daran abarbeiten muss).

"haben diese dann noch einen Header und eine besondere Struktur" - nein, nur Bytes.

Gruß, Klaus

[cdutz]

Hallo Claus,

Ich würde diese Klassen sicher nicht per Hand schreiben. In PLC4X machen wir sehr großen Gebrauch von Code-Generierung ... Tatsächlich ist es in etwa genau so aufwändig ein Profil zu übersetzen, wie 1000000. Von daher mache ich mir da nicht so sehr die sorgen. Ich muss halt einiges an Hirnschmalz in die Konvertierung der dynamic Blöcke stecken.

Dass eure App das auch kann, macht mich zuversichtlicher, dass es wohl auch gehen muss ... viel Arbeit und Komplexität scheue ich nicht.

Kann ja berichten, wie mein Vorhaben voranschreitet.

Gruß,
Chris

[wknx]

In PLC4X machen wir sehr großen Gebrauch von Code-Generierung ... Tatsächlich ist es in etwa genau so aufwändig ein Profil zu übersetzen, wie 1000000.

Bei diesem Ansatz müsstest Du aber bei jedem verfügbaren Update einer Applikation eine neue Klasse generieren. Soll das dann automatisch beim User passieren wenn der eine knxprod ans System übergibt, oder muss der dann auf ein Update von Dir/Euch warten bis er das Gerät nutzen kann? (Ich bin da auch skeptisch ob dieser Ansatz in der Praxis zufriedenstellen wäre)

Welche Vorteile konkret versprichst Du Dir denn von der Code-Generierung?

[cdutz]

Naja ... die Idee ist es eigentlich einen soliden Grundstock zu haben und zusätzlich die Möglichkeit fehlende Profile zu importieren ... Klar geht dann der "Automagic" Effekt ein wenig flöten, aber es ist besser als warten müssen. Vielleicht sollte ich auch ein wenig erklären: Ich arbeite zum einen an PLC4X, weil das mein Baby ist, ich habe es initiiert und ich arbeite am KNX Treiber, weil mein Haus mit KNX gemacht ist. Aber ich kann während der Arbeitszeit daran arbeiten, weil mein Arbeitgeber das auch nutzt (https://mapped.com). Hier ist halt die Idee, dass wir die gleiche Datenbank in der aufbauen, wie im Open-Source Projekt. Schließt ein neuer Kunde sein Gebäude an die Mapped Cloud an, dann werden sehr viele Geräte automatisch erkannt. Die, die fehlen, werden wir die Deskriptoren nachinstallieren und ab dann sind sie in der DB und werden beim nächsten Mal erkannt.

Außerdem releasen wir das Open-Source Project momentan alle paar Monate. Insofern sollte das nicht ganz so ein großes Problem sein, außer man setzt immer die aller neusten Produkte ein. Wenn ich mein Haus so ansehe, dann habe ich auch erst etwa ein Jahr nach dem Einzug in mein Haus überhaupt dran denken können mich mal mit meinem Haus zu unterhalten ;-)

Und warum Code-Generieren? Generell könnte ich auch sicher eine Datenstruktur vorbereiten, die kompakter ist. Alle KNX Device-Profiles, die ich hier auf der Platte habe, sind in summe etwa 12,4GB ... ich glaube keiner will einen Treiber benutzen, der 12,4GB Groß ist. Dann dachte ich mir: Wenn ich schon komprimiere, dann kann ich auch einfach code generieren. Den muss ich einfach nur ausführen. Das kostet weniger Speicher und weniger CPU zeit, als eine Interpretation.

[thewhobox]

Also mal ganz vereinfacht gibt es ja zwei Arten von Speichern bei den KNX-Geräten.
Absoluter Speicher: Wird in der Produktdatenbank vorgegeben und ist immer an der selben stelle und hat immer die gleiche größe.
Relativer Speicher: Speicher ist oft an verschiedenen Adressen (wird beim programmieren allociert) und ist über Properties auslesbar. Die Größe ist hier auch dynamisch.

Was das Gerät unterstützt ist auch abhängig von der Verwendeten Maskenversion. (Kann auch per DeviceDescriptor ausgelesen werden)

Du musst halt für alle Geräte die Produktdatenbank haben, damit dein Code weiß, wo die Daten gespeichert sind.
Danach kannst du das CodeSegment komplett auslesen (wenn du eben die Startadresse und Länge hast).
Sobald du die rohen Bytes hast, lass ich alle ParameterRefs ihren Wert auslesen (wirklich alle) und gehe dann den Dynamic von oben nach unten durch und berechne die sichtbarkeit.


Generell muss ich sagen, ist das deutlich aufwendiger, als das KNX-Projekt einzulesen, indem schon alles drin ist.
Letztendlich muss der User immer iwas hochladen bzw ihr parsen, damit ihr mit den Geräten klar kommt.

[cdutz]

Hallo thewhobox,

ich weiß, dass das Aufwändig ist ... leider hatten wir allerdings schon einige Kunden, bei denen das knxproj File einfach nicht verfügbar war. Da gehört ein Bürogebäude einer Firma und wird beispielsweise von einer anderen Firma vermietet und eine dritte kümmert sich um den technischen Betrieb. Selbst wenn die Firma für den Technischen Betrieb unser Kunde wird, war bisher auch nicht zu 100% garantiert, dass die ein knxproj File für das Gebäude haben. Hier gibt's wohl auch den Fall, dass ein Service vertrag mit einer Firma gibt, die die KNX Programmierung übernimmt und diese behalten ganz gerne die knxproj Files, weil das echt gut für die Kundenbindung ist ;-)

Ich bin Anfangs auch sehr viel naiver an das Thema ran gegangen. Man kann auch sehen, dass der Java Treiber für KNX in PLC4X nur einen betrieb mit knxproj File unterstützt ... nur habe ich bei meiner Arbeit halt lernen müssen, dass nicht immer ein knxproj file verfügbar ist :-(

Aber sonst habe ich mir das genau so vorgestellt, wie du das beschrieben hast.

Weißt du zufällig, wie Objekt ID und Property ID bei den Geräten heißt, bei denen die Code Blöcke dynamisch sind? Das wäre wirklich eine ungeheuer große Hilfe.

[thewhobox]

Schau dir mal eine knx_master.xml an.
Da stehen alle Properties drin.

Objekt-ID

<InterfaceObjectType Id="OT-1" Number="1" Name="OT_ADDRESS_TABLE" Text="Addresstable Object" />
<InterfaceObjectType Id="OT-2" Number="2" Name="OT_ASSOCIATION_TABLE" Text="Associationtable Object" />
<InterfaceObjectType Id="OT-3" Number="3" Name="OT_APPLICATION_PROGRAM" Text="Applicationprogram Object" />
<InterfaceObjectType Id="OT-4" Number="4" Name="OT_INTERACE_PROGRAM" Text="Interfaceprogram Object" />

Property-ID müsste dann die 7 sein.

<InterfaceObjectProperty Id="PID-G-7" Number="7" Name="PID_TABLE_REFERENCE" Text="Table Reference" PDT="PDT-4 PDT-9" />

[cdutz]

Hallo thehobox,

in der tat lese ich diese schon aus ... address-table und association table, um die gruppenadressen und welche com-objekte zugeordnet sind zu bestimmen. Allerdings lese ich bisher application programm und interfaceprogram nur aus um die applicationId und version zu bestimmen ... stehen da dann auch in property 7 die addressen der dynamischen code blocks drin? Muss ich mal näher untersuchen.

Danke schon mal :-)

Gruß,
Chris

[thewhobox]

Hallo Chris,

ja, über die Property 3-7 bekommst dann auch die Speicheradresse des Applikationsprogramms.
Um die ApplicationId zu bestimmen, würde ich dir Empfehlen erst die Maskenversion auszulesen und danach die Ressource "ApplicationId". Das klappt dann auch für ältere Geräte, da die AppId je nach Maskenversion in einer Property oder direkt im Speicher liegt.

In der AppId ist ja auch die Version schon enthalten.

[cdutz]

Ich habe eben mal nachgeschaut, wie ich das bisher gemacht hatte ... hier hatte ich 3-13 und 4-13 ausgelesen .. wenn 3-13 geklappt hatte, habe ich das benutzt um applicationId & version zu lesen, wenn nicht habe ich es aus der 4-13 genommen ... ist der Ansatz generell nicht korrekt? Ich würde mal vermuten, dass die, bei denen ich es das der 3-13 nicht lesen konnte, dass diese die Geräte sind, die du gemeint hast, wo ich das aus dem Speicher lesen müsste, richtig?

[thewhobox]

Wahrscheinlich musst du bei den e wo 3-13 nicht klappt das im Speicher lesen.
Anstatt es aber auszuprobieren und auf Fehler zu reagieren, kann man auch vorher nachschauen, was das Gerät kann^^

Dafür sind die Maskenversionen ja festgelegt.
Die Ressourcen die in der Maskenversion hinterlegt sind, müssen (zumindest hatte ich noch keinen Fall, in dem es anders war) auch im Gerät implementiert sein.

Die Propertys hingegen müssen nicht alle implementiert werden.


BTW Application- und InterfaceObject sind nicht das gleiche.

[wknx]

[…] Datenbank […] aufbauen[…]. Schließt ein neuer Kunde sein Gebäude an die Mapped Cloud an, dann werden sehr viele Geräte automatisch erkannt. Die, die fehlen, werden wir die Deskriptoren nachinstallieren und ab dann sind sie in der DB und werden beim nächsten Mal erkannt.

Außerdem releasen wir das Open-Source Project momentan alle paar Monate. Insofern sollte das nicht ganz so ein großes Problem sein, außer man setzt immer die aller neusten Produkte ein. […]

Wenn ich das richtig verstanden habe, dann stehen neue Produkte erst einige Monate verzögert zur Verfügung, nachdem Sie erstmalig in einem Projekt in der Mapped Cloud genutzt wurden? Wobei ist da nicht nur die Produkte an sich sehe, sondern auch Updates der Geräte/Applikationen.

Und warum Code-Generieren? Generell könnte ich auch sicher eine Datenstruktur vorbereiten, die kompakter ist. Alle KNX Device-Profiles, die ich hier auf der Platte habe, sind in summe etwa 12,4GB ... ich glaube keiner will einen Treiber benutzen, der 12,4GB Groß ist. Dann dachte ich mir: Wenn ich schon komprimiere, dann kann ich auch einfach code generieren. Den muss ich einfach nur ausführen. Das kostet weniger Speicher und weniger CPU zeit, als eine Interpretation.

Beziehen sich die 12,4GB nun auf die knxprod-Dateien, oder deren entpackte Inhalte, oder etwas ganz anderes? Wenn es sich um Informationen handelt die in der knxprod stecken, dann hättest Du die auch bereits in einem vorhandenen Projekt-Export. D.h.: Die 12,4GB bräuchte es nur, wenn die fehlt. Was den Speicherbedarf angeht: Wenn Du die Klassen nach der Benutzung nicht entlädst (In Java passiert das nicht mal so eben von alleine) dann hast Du dauerhaft über die Laufzeit Speicher belegt, während eine entsprechende Datenstruktur vom GC entfernt wird wenn nicht mehr benötigt. Bei CPU-Zeit frage ich mich ob das so relevant ist, wenn Du den Code nur einmal (übersehe ich da etwas?) ausführen musst. Ich habe in jedem Fall den Eindruck, dass Du diese beiden Ziele mit einer mehrmonatigen Verzögerung sehr sehr teuer bezahlst (zumindest aus Nutzersicht).