Nachdem wir uns in Lektion 1<\/a> mit dem prinzipiellen Hardwareaufbau und und Lektion 2<\/a> mit dem KNX Transceiver-Chip befasst haben, geht es in Lektion 3 nun darum, wie ein KONNEKTING Ger\u00e4teprojekt aufgebaut ist.<\/p>\n\n\n\n Zu allererst sei gesagt, dass KONNEKTING darauf ausgerichtet ist, ein KNX “Ger\u00e4t” zu entwerfen, das sich – wie andere KNX Ger\u00e4te auch – \u00fcber den KNX Bus programmieren\/einstellen l\u00e4sst.<\/p>\n\n\n\n KONNEKTING versucht, sich so nahe wie m\u00f6glich an bekannten Dingen und Abl\u00e4ufen aus der KNX Welt zu orientieren. Aber fangen wir von vorne an:<\/p>\n\n\n\n Wenn man in der KNX Welt ein neues KNX Ger\u00e4t installieren m\u00f6chte, dann muss man sich vom Hersteller des Ger\u00e4tes eine Produktdatenbank in Form einer (seit ETS4) .knxprod Datei besorgen. Das Ger\u00e4t selbst schlie\u00dft man an die Bus-Leitung an, startet auf seinem Computer die ETS Software und f\u00fcgt das Ger\u00e4t mittels der Produktdatenbank-Datei hinzu. Danach stellt man in der ETS die physikalische Adresse des Ger\u00e4tes ein, stellt die Parameter des Ger\u00e4ts auf die eigenen Bed\u00fcrfnisse ein und verbindet die Kommunikationsobjekte mit einer Gruppenadresse. Dann dr\u00fcckt man am Ger\u00e4t den Programmierknopf und in der ETS startet man dann die Programmierung. Fertig.<\/p>\n\n\n\n Mit KONNEKTING funktioniert das \u00e4hnlich. Die “Produktdatenbank” ist hier jedoch keine .knxprod Datei, sondern eine Datei mit der Endung “.kdevice.xml”. Man verbindet das KONNEKTING Ger\u00e4t mit der Bus-Leitung, startet die Programmiersoftware “KONNEKTING Suite<\/a>“, f\u00fcgt das neue Ger\u00e4t mittels der .kdevice.xml Datei hinzu, setzt die Parameter gem\u00e4\u00df den eigenen Bed\u00fcrfnissen, verbindet die Kommunikationsobjekte mit einer Gruppenadresse. Dann dr\u00fcckt man am Ger\u00e4t den Programmierknopf und in der Suite startet man dann die Programmierung. Fertig.<\/p>\n\n\n\n Ist Dir etwas aufgefallen? Das funktioniert genau so wie in der ETS. Nur hat die Produktdatenbank eine andere Endung, und die Suite bedient sich ein klein wenig anders als die ETS.<\/p>\n\n\n\n Soweit so gut. Ein KONNEKTING Ger\u00e4t ben\u00f6tigt also eine Produktdatenbank. F\u00fcr den KONNEKTING Benutzer<\/em> reicht das an Information. Wer aber KONNEKTING Ger\u00e4te entwickeln<\/em> m\u00f6chte, der muss sich zwangsweise ein wenig mit dem Format der Produktdatenbank .kdevice.xml besch\u00e4ftigen. Doch keine Sorge, das ist keine Raketenwissenschaft.<\/p>\n\n\n\n Wie bei der ETS gibt es auch bei KONNEKTING “Hersteller von Ger\u00e4ten”. Man kann eine Produktdatenbank von Hersteller A nicht auf Ger\u00e4te von Hersteller B anwenden. Damit das sichergestellt ist, wei\u00df ein Ger\u00e4t und auch die Produktdatenbank von\/f\u00fcr welchen Hersteller es\/sie ist. Kurzum: Es muss irgendwo eine ID hinterlegt sein. So auch bei KONNEKTING.<\/p>\n\n\n\n Jedes Ger\u00e4t ist einem Hersteller zugeordnet. Und jedes Ger\u00e4t hat auch noch eine “Ger\u00e4te ID”, sowie eine “Revision”. Das ist notwendig, damit man Produktdatenbank X von Hersteller A nicht auf ein Ger\u00e4t Y von Hersteller A anwenden kann. Und wenn das Ger\u00e4t X in einer neuen, verbesserten Version (die z.B. eine Hardware-\u00c4nderung notwendig gemacht hat) erscheint, dann muss auch hier sichergestellt sein, dass Ger\u00e4t X Version 1 nicht mit einer Produktdatenbank f\u00fcr Ger\u00e4t X Version 2 verwendet werden kann.<\/p>\n\n\n\n Ein Ger\u00e4t wird also eindeutig beschrieben durch:<\/p>\n\n\n\n Und dieses 3-Tupel<\/a> muss im Ger\u00e4t und in der Produktdatenbank bekannt sein.<\/p>\n\n\n\n Prinzipiell kann sich jeder Entwickler eigene IDs \u00fcberlegen. Doch wenn Ger\u00e4te dann in Open Source\/Open Hardware<\/em> -Manier im Netz “geteilt” werden, kann es schnell zu ID-Konflikten kommen. Das passiert dann, wenn Entwickler A die gleiche Hersteller ID wie Entwickler B verwendet, und beide Ger\u00e4te am selben Bus h\u00e4ngen. Es gilt also ID-Konflikte zu vermeiden. Aus diesem Grund kann man sich bei uns eine kostenlose ID registrieren, die wir dann in einer offiziellen Liste pflegen und die jeder einsehen kann.<\/p>\n\n\n\n Die Registrierung ist selbstverst\u00e4ndlich optional und keine Pflicht. Aber sie ist kostenlos und hilft Konflikte zu vermeiden, weswegen wir sie nachdr\u00fccklich empfehlen.<\/strong><\/p>\n\n\n\n Wenn du selbst Ger\u00e4te entwickeln willst, registrierst du Dir am besten JETZT GLEICH eine Hersteller-ID. Wie das geht und welche IDs es schon gibt, steht hier<\/a>.<\/p><\/blockquote>\n\n\n\n Bisher hierhin wissen wir also, dass sich KONNEKTING \u00e4hnlich wie KNX\/ETS verh\u00e4lt, und \u00e4hnliche Informationen zur korrekten Identifikation ben\u00f6tigt.<\/p>\n\n\n\n Das ETS Produktdatenbankformat .knxprod ist mehr oder weniger eine getarnte ZIP-Datei, welche eine Vielzahl an recht aufwendigen XML<\/a>-Dateien enth\u00e4lt, die das Ger\u00e4t beschreiben.<\/p>\n\n\n\n Bei KONNEKTING ist das ein wenig einfacher. Die Produktdatenbank .kdevice.xml ist direkt eine “lesbare” XML-Datei. Lesbar im Sinne von “nicht als ZIP getarnt”, und auch m\u00f6glichst einfach gehalten. Der Benutzer verwendet sie einfach, der Entwickler muss sie f\u00fcr sein Ger\u00e4t aber erst einmal erstellen (und dann den Benutzern seines Ger\u00e4ts zur Verf\u00fcgung stellen). Idealerweise tut er das bevor er die Firmware bzw. den Sketch f\u00fcr sein Ger\u00e4t entwickelt.<\/p>\n\n\n\n Eine ausf\u00fchrliche .kdevice.xml Dokumentation mit Beispiel-Elementen findet man hier<\/a>.<\/p><\/blockquote>\n\n\n\n Aber nehmen wir uns f\u00fcr den Anfang mal ein einfaches Beispiel her. Wir wollen ein Ger\u00e4t entwickeln, das eine Temperatur misst, und diese in regelm\u00e4\u00dfigen Abst\u00e4nden auf den Bus sendet. Was ben\u00f6tigen wir hierzu?<\/p>\n\n\n\n Punkt 1 ist recht einfach. Man muss sich \u00fcberlegen welchen Datentyp man daf\u00fcr ben\u00f6tigt. Wir nehmen als Beispiel hier mal den Datentyp “uint32”. Also “unsigned integer 32bit”. Oder vereinfacht gesagt: Ein ganzzahliger, positiver Zahlenwert mit 32bit L\u00e4nge. Das hei\u00dft, ein Zahlentyp der die Werte 0 bis 4294967295 erm\u00f6glicht. Das sollte ausreichend sein um die Anzahl Sekunden Wartezeit zwischen zwei Temperaturwerten zu speichern. Wem das zu viel ist, der nimmt eben uint16 oder uint8.<\/p>\n\n\n\n Hinweis:<\/em> Der Datentyp ist dann auch der, den man sp\u00e4ter im Arduino-Code verwendet.<\/p>\n\n\n\n Wer mit uint32, uint16, … nichts anfangen kann, der liest sich am besten hier ein: Arduino – UnsignedInt<\/a><\/p><\/blockquote>\n\n\n\n Punkt 2 ist ein wenig komplizierter. Schlie\u00dflich geht es hier um ein Kommunikationsobjekt (kurz KO). Vielleicht kennt man es schon aus der ETS dass man einem KO “Flags” setzen kann. So etwas wie<\/p>\n\n\n\n Je nachdem wie diese Flags gesetzt sind, verh\u00e4lt sich das KO anders. Im gro\u00dfen und ganzen gibt es f\u00fcr den Einstieg nur zwei wichtige Konstellationen:<\/p>\n\n\n\n Also entweder das KO sendet bei einer Wert-\u00c4nderung Daten auf den Bus (Sensorprofil), oder das KO wartet auf ein Telegramm vom Bus, damit das Ger\u00e4t irgend etwas damit macht, z.B. einen Ausgang schaltet (Aktor-Profil). F\u00fcr unser Beispiel hier ist das Sensor-Profil relevant.<\/p>\n\n\n\n Und zuguter letzt muss man sich noch \u00fcberlegen, welchen Datentyp bzw. DPT das KO hat. KNX Telegramme k\u00f6nnen ja die unterschiedlichsten Informationen transportieren. DPT1 z.B. f\u00fcr Schaltvorg\u00e4nge, DPT9 f\u00fcr soetwas wie eine Temperatur, … So, aber nun zur XML. Die folgende XML deckt unser exemplarisches Beispiel ab:<\/p>\n\n\n Tipp: Unter Windows ist das kostenlose Programm Notepad++<\/a> ganz hilfreich zum erstellen oder bearbeiten von XML Dateien.<\/p><\/blockquote>\n\n\n\n Die ersten beiden Zeilen sind quasi Standard. Daran \u00e4ndert sich eigentlich nichts, die kann man einfach so in jede .kdevice.xml \u00fcbernehmen.<\/p>\n\n\n\n Die Zeile mit dem Element “Device” (Element nennt man die Teile in der XML die mit einem <> eingefasst sind) enth\u00e4lt Attribute f\u00fcr die Hersteller-ID, Ger\u00e4te-ID und Revision des Ger\u00e4ts. Attribute werden mit AttributName=”AttributWert”<\/em> innerhalb des Elements definiert.<\/p>\n\n\n\n Optional kann man noch einen Hersteller- und Ger\u00e4tenamen mittels weiteren Elementen wie gezeigt setzen. Muss man nicht, geh\u00f6rt aber zum guten Ton.<\/p>\n\n\n\n Parameter sind immer einer Gruppe zugeordnet. Das hilft bei vielen Parametern. Wir haben hier nur einen Parameter. Die zugeh\u00f6rige Gruppe nennen wir mal “Temperature”. F\u00fcr “interne” Zwecke gibt es an vielen Elementen auch ein “Id” Attribut. Genaueres dazu entnimmst Du bitte der detailierten Doku<\/a>.<\/p>\n\n\n\n Innerhalb der Parametergruppe folgt dann der Parameter. “Description” ist die Beschreibung des Parameters wie er sp\u00e4ter in der KONNEKTING Suite<\/a> aufgef\u00fchrt wird.<\/p>\n\n\n\n Etwas kniffliger ist das Element “Value”. Hier muss man den Parametertypen (in unserem Fall “uint32” angeben. Damit die Suite einen vern\u00fcnftigen Default-Wert f\u00fcr den Benutzer anbietet, sollte man mit “Default=” angeben, was der Standard sein soll. Die Angabe erfolgt in Hexadezimaler Schreibweise!<\/p>\n\n\n\n \u00c4hnlich dazu der Minimal-Wert (“Min=”) und Maximalwert (“Max=”) den man in der Suite eintragen kann. Das ist ganz hilfreich wenn man z.B. den uint32 Datentyp von seiner L\u00e4nge bis 4294967295 nicht voll ausreizen will. Die Suite erlaubt dann keine Werte die sich au\u00dferhalb von Min\/Max bewegen. Das Attribut “Options=” ist hier in diesem Beispiel nicht n\u00f6tig und bleibt leer (mehr Details dazu findest du nat\u00fcrlich in der Doku<\/a>…).<\/p>\n\n\n\n KOs werden im Element “CommObjects” gelistet. Jedes KO sitzt dabei in einem eigenen Element “CommObject”. Die Kind-Elemente “Name” und “Function” sind quasi Freitext-Elemente. Hier kann man textuell angeben wie das KO hei\u00dft und welche Funktion es hat. “DataPointType” gibt den DPT des KOs an. Hier im Beispiel “9.001” f\u00fcr unseren Temperaturwert. Und zuguter letzt noch das Element “Flags”. Das ist im Detail ein bisschen knifflig. Aber da wir hier prim\u00e4r nur zwei “Profile” haben, tr\u00e4gt man hier entweder 52 f\u00fcr ein Sensor-KO oder 42 f\u00fcr ein Aktor-KO ein. Details wie man zu diesen Zahlen kommt findet man, du err\u00e4tst es sicherlich schon, in der Doku<\/a>.<\/p>\n\n\n\n Und das war es dann auch schon mit der XML. Es gibt zwar noch einige weitere Elemente mit denen man die Sichtbarkeit von KOs und Parametern in Abh\u00e4ngigkeit von anderen Parametern einschr\u00e4nken kann. Aber das ist f\u00fcr ein solch kleines Anf\u00e4nger-Beispiel erst einmal nicht relevant und kann weggelassen werden.<\/p>\n\n\n\n Aus der .kdevice.xml kann man \u00fcber ein in der Suite enthaltenes Tool eine Header-Datei generieren lassen, die einem den notwendigen Code-Abschnitt im Arduino-Sketch f\u00fcr die Parameter und KOs abnimmt. Aber das kommt dann in der n\u00e4chsten Lektion, wo es dann darum geht, den Arduino-Sketch f\u00fcr das Ger\u00e4t zu schreiben.<\/p>\n\n\n\n Das Erstellen der .kdevice.xml ist nicht unbedingt trivial. Speziell wenn man mitten in der Entwicklung ist und hier und da ein KO noch hinzuf\u00fcgt oder eins entfernen\/streichen m\u00f6chte, ist das von Hand zwar m\u00f6glich, aber zeitraubend, und vor allem fehleranf\u00e4llig.<\/p>\n\n\n\n Sobald die Definition des XML-Formats einen stabilen Zustand erreicht hat (KONNEKTING ist ja noch in der Beta-Phase), werden wir uns dran setzen ein Programm zu entwickeln, mit dessen Hilfe man die XML Datei “zusammenklicken” kann, gef\u00fchrt von Men\u00fcs\/Wizards. Damit wird das Erstellen der XML deutlich einfacher und fehlerfreier. Bis dahin f\u00fchrt aber kein Weg an der h\u00e4ndischen Erstellung der XML vorbei.<\/p>\n\n\n <– Lektion 2: Was steckt in der Siemens BCU?<\/a>Lektion 4: Es geht in die Praxis –><\/a><\/p>","protected":false},"excerpt":{"rendered":" Gegen\u00fcberstellung KONNEKTING KNX Nachdem wir uns in Lektion 1 mit dem prinzipiellen Hardwareaufbau und und Lektion 2 mit dem KNX Transceiver-Chip befasst haben, geht es in Lektion 3 nun darum, wie ein KONNEKTING Ger\u00e4teprojekt aufgebaut ist. Zu allererst sei gesagt, dass KONNEKTING darauf ausgerichtet ist, ein KNX “Ger\u00e4t” zu entwerfen, das sich – wie andere … Continue reading “Lektion 3: Aufbau von KONNEKTING”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":163,"menu_order":3,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-310","page","type-page","status-publish","hentry"],"translation":{"provider":"WPGlobus","version":"3.0.2","language":"en","enabled_languages":["de","en"],"languages":{"de":{"title":true,"content":true,"excerpt":false},"en":{"title":false,"content":false,"excerpt":false}}},"_links":{"self":[{"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/pages\/310","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/comments?post=310"}],"version-history":[{"count":26,"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/pages\/310\/revisions"}],"predecessor-version":[{"id":716,"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/pages\/310\/revisions\/716"}],"up":[{"embeddable":true,"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/pages\/163"}],"wp:attachment":[{"href":"https:\/\/www.konnekting.de\/en\/wp-json\/wp\/v2\/media?parent=310"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Die Sache mit den IDs<\/h1>\n\n\n\n
Das .kdevice.xml Format<\/h1>\n\n\n\n
Hier kann man sich am besten am den orientieren was \u00e4hnliche\/vergleichbare Ger\u00e4te in der KNX Welt f\u00fcr DPTs nutzen. Die Infos hierzu finden sich in den jeweiligen Handb\u00fcchern der Ger\u00e4te, sowie in der Produktdatenbank.<\/p>\n\n\n\n\n<?xml version="1.0" encoding="UTF-8" standalone="yes"?>\n<KonnektingDevice xmlns="http:\/\/konnekting.de\/xml\/KonnektingDevice\/v0">\n <Device ManufacturerId="57005" DeviceId="3" Revision="0" SystemType="1">\n <ManufacturerName>KONNEKTING<\/ManufacturerName>\n <DeviceName>SimpleSensor<\/DeviceName>\n\n <Parameters>\n <ParameterGroup Name="Temperatur" Id="0">\n <Parameter Id="0" IdName="tempPollingTime">\n <Description>Cycle [s]<\/Description>\n <Value Type="uint32" Default="0000001E" Options="" Min="00000000" Max="000FFFFF"\/>\n <\/Parameter>\n <\/ParameterGroup>\n <\/Parameters>\n\n <CommObjects>\n <CommObject Id="0" IdName="tempValue">\n <Name>Temperature<\/Name>\n <Function>Value<\/Function>\n <DataPointType>9.001<\/DataPointType>\n <Flags>52<\/Flags>\n <\/CommObject>\n <\/CommObjects>\n <\/Device>\n<\/KonnektingDevice>\n\n<\/pre><\/div>\n\n\n
Und was gibt es noch?<\/h1>\n\n\n\n
Ausblick<\/h1>\n\n\n\n