Eigene ETS Produktdatenbanken erzeugen

[l0wside]

Warum um alles in der Welt ist alles, was mit Java zu tun hat, erst mal mit hunderten Megabytes an Krempel verbunden? Die Maven-Installation hat mit unter Ubuntu 95 MB auf die Platte gespült.
Egal: gibt es so etwas wie eine Anleitung dazu? Muss ja nicht schön sein. mvn install scheitert bei mir mit
"Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on project sbtools-products-editor: There are test failures."
Ich bin durchaus daran interessiert, mich an dem zu beteiligen, was ihr da macht - ich habe selbst etwas Ähnliches geschrieben, siehe http://maxgauger.de:5081/knxcfg/doxygen/ (wenn der Server grade mal läuft, der ist ein ziemliches Bastelprojekt). Dort wird aus einer XML-Datei zum einen C-Code für den µC, zum anderen eine Definitionsdatei für mein Qt-basiertes Konfigurationstool erstellt.

Max

[tuxedo]

Egal: gibt es so etwas wie eine Anleitung dazu?

Java instalieren, Maven installieren, auschecken, "mvn install". Fertig. Das ist so der generelle Weg wenn der entsprechende Entwickler alles richtig gemacht hat. Hab mit aber das entsprechende Projekt noch nicht angeschaut.

[jolt]

Hallo Zusammen,

ich habe gerade einen Pull Request für den ersten Wurf des XML2ProductDB Converters erzeugt. Ziel war es aus einer (einfachen) XML Struktur eine gültige ProductDB zu erzeugen. Parameter, Kommunikationsobjekte und alle sichtbaren Namen und Werte kann man konfigurieren. Die Beispiel XML demonstriert das alles.

Was fehlt ist die ganze Anbindung an das Hardware Device. Hier muss ich noch forschen was genau dann auf dem Bus passiert und wie man das am besten löst.

Weiterhin sind im Moment die Typen der Parameter bzw. Kommunikations Objekte im Konverter hardgecoded. Muss man entweder im XML hinterher anpassen oder es findet sich jemand der das im Konverter implementiert. Ist kein Rocket Science. Fragen dazu beantworte ich gerne.

Grüße,
Florian

[jolt]

Habe gerade alles gepusht und einen weiteren Pull Request aufgemacht. Der Converter ist soweit (aus User Sicht) Feature complete. Kommunikations Objekte und Parameter kann man jetzt per XML konfigurieren.

Als nächstes würde ich mich um die Anbindung der Devices kümmern. Hier muss ich erst einmal forschen wie ETS die Parameter und Kommunikations Objekte über den Bus schickt. Falls jemand hier Infos oder Source hat, lasst es mich wissen. Gibt es im selfbus Projekt Erkenntnisse, die mich hier weiter bringen? Soweit ich das verstehe habt ihr ja eine VD die komplett an die Hardware angebunden ist oder?

Grüße,
Florian

[olterion]

Hallo Florian,

ich hole das Thema noch einmal nach oben, da ich mich in letzter Zeit sehr viel mit unterschiedlichen DIY KNX Lösungen beschäftige und einige Geräte mit der Selfbus Bussankopplung und Library erstellt habe.
Nun las ich mit Spannung von "Konnekting" und deren separaten Konfigurations-Tool.
Bisher habe ich darauf gesetzt, VD Dateien zu übernehmen bzw. neu zu erstellen und damit die ETS zur Konfiguration nutzen zu können. Mit den bereits entwickelten Geräten funktioniert das Ganze auch wunderbar.

Allerdings ist die Grenze der VD bearbeitung recht schnell erreicht und ich habe nun diesen "alten" Thread gefunden.

So wie ich dem Ganzen entnehme, wurde bereits einiges getan um die Signierung der knxprod Dateien zu erneuern. Das war bislang die Hürde, warum ich mich nicht mit der Veränderung dieser Dateien beschäftigt habe.

Es wäre doch für alle DIY Projekte ein riesiger Schritt, wenn knxprod Dateien selber erzeugt/verändert werden können, sodass das DIY Gerät dann per ETS konfiguriert werden kann, oder?!

Ich sehe nun hier, dass ein entsprechender Editor (oder Konverter) bereits existiert.
Mir schwebt ein grafisches Tool vor, mit dem ich die KOs mit entsprechenden Datentypen, Herstellercode, Application usw. verändern bzw. komplett neu erstellen kann. Anschließend wird signiertund ich kann die knxprod in die ETS einlesen und damit mein Gerät konfigurieren.

Hoffentlich sind die entsprechenden Leute noch hier aktiv und können ein wenig Licht ins Dunkel bringen?

Wie gesagt, ich bin bereits mit der Entwicklung von Hard- und Software der Selfbus Komponenten (ARM1115 Prozessor) und der Erstellung von VD Dateien vertraut und würde auch hier das Ganze mit weiter entwickeln, falls nötig.

Grüße,
Olli

[mfd]

Es wäre doch für alle DIY Projekte ein riesiger Schritt, wenn knxprod Dateien selber erzeugt/verändert werden können, sodass das DIY Gerät dann per ETS konfiguriert werden kann, oder?!

Dem stimme ich zu 100% zu.

Es gab aber, soweit ich mich erinnere, damals Bedenken wegen rechtlicher Aspekte, da wohl ein Bestandteil zum Signieren der eigenen Produktdatenbanken aus der ETS "abgezweigt" war...

[olterion]

Hallo,

im Verlauf dieses Threads ist ja bereits die Lösung zur Signierung bekannt gemacht worden.
Das Signieren kann man ja von der eigentlichen Erstellung bzw. der Veränderung der knxprod Datei abkoppeln, falls es rechtlich zu gefährlich ist.
Somit hätte man aber eine gute Chance zumindest einen Viewer für die knxprod Dateien zu bauen, mit dem man sich die Daten komfortabel ansehen kann.
Dadurch ist es dann möglich, Applikationen für z.B. Selfbus Geräte an bereits vorhandene knxprod Dateien (und somit bereits bestehende Geräte) anzupassen.
Wenn dann noch eine Möglichkeit zur Veränderung der knxprod Daten in den "Viewer" eingebaut wird, ok.
Die Signierung kann dann jeder vornehmen, so wie er es für richtig hält.

Grüße,
Olli

[jolt]

Hallo,

also wir haben ein Tool zum Signieren und ein Tool um aus einer einfachen XML Sprache eine Product DB zu machen, die sich in ETS laden lässt. Der nächste Schritt wäre jetzt entsprechender Code auf den Hardware Geräten, um das Mapping was durch die ETS geladen wird, zu verstehen. Da bin ich leider noch nicht wirklich viel weiter gekommen. Ich habe angefangen einen KNX Stack zu schreiben, der die Infrastruktur bietet, das sauber umzusetzen. Aus Zeitgründen bin ich da aber nicht fertig geworden.

[olterion]

Hallo.

Diese Umsetzung der Applikation auf dem Gerät ist recht einfach mit der sblib von selfbus für den LPC1115 möglich. Bei dem Prozessor ist auch ein sehr gutes und einfaches Debugging möglich.

Dort ist ein kompletter KNX Stack implementiert, der die Werte der KOs einfach in einen festgelegten Adressenreich schreibt. Wenn man dann die Zuordnung der knxprod zu den Adressen hat, geht das Erstellen eines Applikationsprogramms sehr gut.

Kann ich diese Tools irgendwo gekommen, oder werden die nur persönlich weitergegeben?

Grüße,
Olli

[jolt]

Die Tools findest du hier: https://github.com/KARDUINO/SignKnxProd

Auf Device Seite ist das alles andere als Trivial. Die ETS macht da eine ganze Menge Magic beim Upload, bevor die Werte dann über KO ins Device transportiert werden. Diese Magic muss korrekt umgesetzt werden, sonst klappt der Upload nicht und du weisst nicht, auf welche KO du überhaupt hören musst.

Deswegen habe ich damals einen Stack getrennt nach Layern aufgebaut, sonst bekommt man das nicht auf die Doku gemappt und hat keine Chance zu verstehen, was gerade passiert.

[tuxedo]

Ich melde mich als "damaliger Skeptiker" zu Wort..

An meiner Skepsis hat sich nach wie vor nichts geändert.

Um eine .knxprod zu erzeugen, muss man aus der ETS den privaten Schlüssel zum signieren extrahieren. Das ist quasi eine Art "Reverse Engineering" die

a) die Konnex sicher nicht gerne sieht
b) vermutlich durch eine Art EULA und Co. dem Nutzer entsprechend untersagt wurde. In wieweit so eine Lizenzvereinbarung rechtlich angreifbar ist: Kein Plan.

Fakt ist jedoch: Es ist für ein Projekt wie KONNEKTING nicht vertretbar der Community ein fertiges Tool an die Hand zu geben, mit dem man "ganz einfach" mit aus der ETS mutwillig extrahierten Daten eine .knxprod erstellt, die mit einem Schlüssel erstellt ist, der einem nicht gehört. Da steht die Konnex sicher schneller auf der matte als man schauen kann.
Rechtlich sicherer für uns wäre es, wenn wir das jemand anderem überlassen, oder ggf. nur eine theoretische Anleitung liefern wie man das macht und dann die "grauzone" dem Nutzer selbst überlassen. Aber wir möchten natürlich auch nicht zu solchen Grauzonen-Aktionen anstiften.

Fakt ist auch: Hätte die Konnex es vorgesehen dass jeder seine eigene knxprod signieren kann, hätten sie den Schlüssel nicht "versteckt". Denn normalerweise bekommt man den nur, wenn man entsprechender KNX Member ist und Zugriff auf diverse KNX Manufacturer Tools hat.

Was wir schon realisiert haben, ist ein Parser für .knxproj Dateien, die einem später (beta5...) das Leben in der KONNEKTING Suite einfacher machen (mit all den Gruppenadressen aus der ETS etc..)

Ich denke mit unserer Suite fahren wir aktuell recht gut. Und wir sind ja nicht das einzige Projekt das auf ETS unabhängige Tools setzt. Auch tatsächliche Firmen machen das hier und da so.

[tuxedo]

Die Tools findest du hier: https://github.com/KARDUINO/SignKnxProd

Auf Device Seite ist das alles andere als Trivial. Die ETS macht da eine ganze Menge Magic beim Upload, bevor die Werte dann über KO ins Device transportiert werden. Diese Magic muss korrekt umgesetzt werden, sonst klappt der Upload nicht und du weisst nicht, auf welche KO du überhaupt hören musst.

Deswegen habe ich damals einen Stack getrennt nach Layern aufgebaut, sonst bekommt man das nicht auf die Doku gemappt und hat keine Chance zu verstehen, was gerade passiert.

Man muss auch bedenken: So ein "richtiges" KNX Device, das man komplett und umfänglich mit der ETS nutzen kann, ist bei weitem komplexer als sowas wie unser bisheriges KONNEKTING Projekt. Und da gab und gibt es Stimmen die sagen: Bereits das ist viel zu komplex.

Am besten schaut man sich mal das Webinar zu den Manufacturer-Tools der Konnex an: https://www.youtube.com/watch?v=kUXmZ8q9A7g
Das alles "technisch" nachzubauen... have some fun.

KONNEKTING bemüht sich das ganze noch recht einfach zu halten (und das ist echt nicht leucht). Es nützt niemandem wenn der User alles bequem mit der ETS einstellen kann, es aber niemanden gibt der die ganze komplexität dahinter in ein DIY KNX Device baut.

Selbst wenn ich die KNX Manufacturer Tools hätte, offiziellen Zugang zum signierprozess hätte etc... Ich glaube ich würde das alles nicht tun wollen. Da steckt zu viel "kram" drin um das als kleines Projekt zu stemmen.

[jolt]

Mein Plan war gewesen ein Tool zu bauen, dass auf der einen Seite eine Product DB ausspuckt und auf der anderen Seite eine C++ include Datei, die entsprechende Kommunikations-Endpoints im Device bereitstellt. Den Rest kann man dann komplett in einer Library verstecken. Upload und Zuordnung Endpoint zu Gruppen Adresse passiert in der ETS und wird auf das Device geladen.

Nur der Weg zu so einer Library ist leider sehr steinig, alleine die Bus Adresse sauber gemäß den Specvorgaben programmieren zu können ist schon ein kleiner Staatsakt, der eine Menge Infrastruktur benötigt. Das habe ich bereits implementiert. Aufgehört habe ich dann irgendwo bei den Mapping Tabellen.

[tuxedo]

Mapping Tabellen sind ja nur der Anfang. Schau dir das Webinar an. Der Aufwand eine korrekte knxprod zu erzeugen mit dem ganzen memory mapping ist nicht ohne.

Nach wie vor: für Hobby Projekte finde ich den Aufwand zu hoch, bzw die Lernkurve zu lang und zu steil. Die KONNEKTING Lernkurve ist ja schon für viele eine zu große Hürde, und wir haben noch lange nicht die Komplexität einer knxprod.

Aber ich will niemand bekehren. Ist nur meine Meinung.

[olterion]

Hallo,

ich verstehe, dass die Hürde für Konnekting Nutzer so niedrig wie möglich gehalten werden sollte.
Meine Idee oder Befürchtung ist, dass man mit mehreren Werkzeugen seine Geräte parametrisieren muss, also auch die Gruppen- und Geräteadressen in mehreren Tools konsistent halten muss.
Da ich sehr viel auf DIY Geräte setzen werde, wäre das in meinem Fall ein recht großer Aufwand, denke ich.
Daher die Idee, eine ETS kompatible Datei zu erzeugen.

@jolt:
Danke für den Link!

Der komplette Stack für die eigentliche Buskommunikation ist in der sblib enthalten und frei zugänglich:
https://github.com/selfbus/software-...e/master/sblib

Da kann man sich sicherlich das ein oder andere ansehen.
Allerdings habe ich die sblib nicht geschrieben und bin daher mit den Mechanismen der Buskommunikation nicht so vertraut.

Grüße,
Olli