Gegenüberstellung 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äteprojekt aufgebaut ist.

Zu allererst sei gesagt, dass KONNEKTING darauf ausgerichtet ist, ein KNX „Gerät“ zu entwerfen, das sich – wie andere KNX Geräte auch – über den KNX Bus programmieren/einstellen lässt.

KONNEKTING versucht, sich so nahe wie möglich an bekannten Dingen und Abläufen aus der KNX Welt zu orientieren. Aber fangen wir von vorne an:

Wenn man in der KNX Welt ein neues KNX Gerät installieren möchte, dann muss man sich vom Hersteller des Gerätes eine Produktdatenbank in Form einer (seit ETS4) .knxprod Datei besorgen. Das Gerät selbst schließt man an die Bus-Leitung an, startet auf seinem Computer die ETS Software und fügt das Gerät mittels der Produktdatenbank-Datei hinzu. Danach stellt man in der ETS die physikalische Adresse des Gerätes ein, stellt die Parameter des Geräts auf die eigenen Bedürfnisse ein und verbindet die Kommunikationsobjekte mit einer Gruppenadresse. Dann drückt man am Gerät den Programmierknopf und in der ETS startet man dann die Programmierung. Fertig.

Mit KONNEKTING funktioniert das ähnlich. Die „Produktdatenbank“ ist hier jedoch keine .knxprod Datei, sondern eine Datei mit der Endung „.kdevice.xml“. Man verbindet das KONNEKTING Gerät mit der Bus-Leitung, startet die Programmiersoftware „KONNEKTING Suite„, fügt das neue Gerät mittels der .kdevice.xml Datei hinzu, setzt die Parameter gemäß den eigenen Bedürfnissen, verbindet die Kommunikationsobjekte mit einer Gruppenadresse. Dann drückt man am Gerät den Programmierknopf und in der Suite startet man dann die Programmierung. Fertig.

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.

Soweit so gut. Ein KONNEKTING Gerät benötigt also eine Produktdatenbank. Für den KONNEKTING Benutzer reicht das an Information. Wer aber KONNEKTING Geräte entwickeln möchte, der muss sich zwangsweise ein wenig mit dem Format der Produktdatenbank .kdevice.xml beschäftigen. Doch keine Sorge, das ist keine Raketenwissenschaft.

Die Sache mit den IDs

Wie bei der ETS gibt es auch bei KONNEKTING „Hersteller von Geräten“. Man kann eine Produktdatenbank von Hersteller A nicht auf Geräte von Hersteller B anwenden. Damit das sichergestellt ist, weiß ein Gerät und auch die Produktdatenbank von/für welchen Hersteller es/sie ist. Kurzum: Es muss irgendwo eine ID hinterlegt sein. So auch bei KONNEKTING.

Jedes Gerät ist einem Hersteller zugeordnet. Und jedes Gerät hat auch noch eine „Geräte ID“, sowie eine „Revision“. Das ist notwendig, damit man Produktdatenbank X von Hersteller A nicht auf ein Gerät Y von Hersteller A anwenden kann. Und wenn das Gerät X in einer neuen, verbesserten Version (die z.B. eine Hardware-Änderung notwendig gemacht hat) erscheint, dann muss auch hier sichergestellt sein, dass Gerät X Version 1 nicht mit einer Produktdatenbank für Gerät X Version 2 verwendet werden kann.

Ein Gerät wird also eindeutig beschrieben durch:

• Hersteller ID
• Geräte ID
• Revision

Und dieses 3-Tupel muss im Gerät und in der Produktdatenbank bekannt sein.

Prinzipiell kann sich jeder Entwickler eigene IDs überlegen. Doch wenn Geräte dann in Open Source/Open Hardware -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äte am selben Bus hängen. 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.

Die Registrierung ist selbstverständlich optional und keine Pflicht. Aber sie ist kostenlos und hilft Konflikte zu vermeiden, weswegen wir sie nachdrücklich empfehlen.

Wenn du selbst Geräte entwickeln willst, registrierst du Dir am besten JETZT GLEICH eine Hersteller-ID. Wie das geht und welche IDs es schon gibt, steht hier.

Das .kdevice.xml Format

Bisher hierhin wissen wir also, dass sich KONNEKTING ähnlich wie KNX/ETS verhält, und ähnliche Informationen zur korrekten Identifikation benötigt.

Das ETS Produktdatenbankformat .knxprod ist mehr oder weniger eine getarnte ZIP-Datei, welche eine Vielzahl an recht aufwendigen XML-Dateien enthält, die das Gerät beschreiben.

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öglichst einfach gehalten. Der Benutzer verwendet sie einfach, der Entwickler muss sie für sein Gerät aber erst einmal erstellen (und dann den Benutzern seines Geräts zur Verfügung stellen). Idealerweise tut er das bevor er die Firmware bzw. den Sketch für sein Gerät entwickelt.

Eine ausführliche .kdevice.xml Dokumentation mit Beispiel-Elementen findet man hier.

Aber nehmen wir uns für den Anfang mal ein einfaches Beispiel her. Wir wollen ein Gerät entwickeln, das eine Temperatur misst, und diese in regelmäßigen Abständen auf den Bus sendet. Was benötigen wir hierzu?

1. Ein Parameter der den Sende-Intervall angibt. Der spätere Benutzer soll einstellen können wie oft er den Temperaturwert auf dem Bus sehen will.
2. Ein Kommunikationsobjekt, welches der Benutzer mit einer Gruppenadresse versehen kann, und das zum Senden des Temperaturwertes genutzt wird.

Punkt 1 ist recht einfach. Man muss sich überlegen welchen Datentyp man dafür benötigt. Wir nehmen als Beispiel hier mal den Datentyp „uint32“. Also „unsigned integer 32bit“. Oder vereinfacht gesagt: Ein ganzzahliger, positiver Zahlenwert mit 32bit Länge. Das heißt, ein Zahlentyp der die Werte 0 bis 4294967295 ermöglicht. 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.

Hinweis: Der Datentyp ist dann auch der, den man später im Arduino-Code verwendet.

Wer mit uint32, uint16, … nichts anfangen kann, der liest sich am besten hier ein: Arduino – UnsignedInt

Punkt 2 ist ein wenig komplizierter. Schließlich 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

• K-Flag (Kommunikation)
• L-Flag (Lesen)
• S-Flag (Schreiben)
• Ü-Flag (Übertragen)
• A-Flag (Aktualisieren)

Je nachdem wie diese Flags gesetzt sind, verhält sich das KO anders. Im großen und ganzen gibt es für den Einstieg nur zwei wichtige Konstellationen:

• Sensor Profil -> K+L+Ü
• Aktor Profil -> K+S+A

Also entweder das KO sendet bei einer Wert-Änderung Daten auf den Bus (Sensorprofil), oder das KO wartet auf ein Telegramm vom Bus, damit das Gerät irgend etwas damit macht, z.B. einen Ausgang schaltet (Aktor-Profil). Für unser Beispiel hier ist das Sensor-Profil relevant.

Und zuguter letzt muss man sich noch überlegen, welchen Datentyp bzw. DPT das KO hat. KNX Telegramme können ja die unterschiedlichsten Informationen transportieren. DPT1 z.B. für Schaltvorgänge, DPT9 für soetwas wie eine Temperatur, …
Hier kann man sich am besten am den orientieren was ähnliche/vergleichbare Geräte in der KNX Welt für DPTs nutzen. Die Infos hierzu finden sich in den jeweiligen Handbüchern der Geräte, sowie in der Produktdatenbank.

So, aber nun zur XML. Die folgende XML deckt unser exemplarisches Beispiel ab:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<KonnektingDevice xmlns="http://konnekting.de/xml/KonnektingDevice/v0">
    <Device ManufacturerId="57005" DeviceId="3" Revision="0" SystemType="1">
        <ManufacturerName>KONNEKTING</ManufacturerName>
        <DeviceName>SimpleSensor</DeviceName>

        <Parameters>
            <ParameterGroup Name="Temperatur" Id="0">
                <Parameter Id="0" IdName="tempPollingTime">
                    <Description>Cycle [s]</Description>
                    <Value Type="uint32" Default="0000001E" Options="" Min="00000000" Max="000FFFFF"/>
                </Parameter>
            </ParameterGroup>
        </Parameters>

        <CommObjects>
            <CommObject Id="0" IdName="tempValue">
                <Name>Temperature</Name>
                <Function>Value</Function>
                <DataPointType>9.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
        </CommObjects>
    </Device>
</KonnektingDevice>

Tipp: Unter Windows ist das kostenlose Programm Notepad++ ganz hilfreich zum erstellen oder bearbeiten von XML Dateien.

Die ersten beiden Zeilen sind quasi Standard. Daran ändert sich eigentlich nichts, die kann man einfach so in jede .kdevice.xml übernehmen.

Die Zeile mit dem Element „Device“ (Element nennt man die Teile in der XML die mit einem <> eingefasst sind) enthält Attribute für die Hersteller-ID, Geräte-ID und Revision des Geräts. Attribute werden mit AttributName=“AttributWert“ innerhalb des Elements definiert.

Optional kann man noch einen Hersteller- und Gerätenamen mittels weiteren Elementen wie gezeigt setzen. Muss man nicht, gehört aber zum guten Ton.

Parameter sind immer einer Gruppe zugeordnet. Das hilft bei vielen Parametern. Wir haben hier nur einen Parameter. Die zugehörige Gruppe nennen wir mal „Temperature“. Für „interne“ Zwecke gibt es an vielen Elementen auch ein „Id“ Attribut. Genaueres dazu entnimmst Du bitte der detailierten Doku.

Innerhalb der Parametergruppe folgt dann der Parameter. „Description“ ist die Beschreibung des Parameters wie er später in der KONNEKTING Suite aufgeführt wird.

Etwas kniffliger ist das Element „Value“. Hier muss man den Parametertypen (in unserem Fall „uint32“ angeben. Damit die Suite einen vernünftigen Default-Wert für den Benutzer anbietet, sollte man mit „Default=“ angeben, was der Standard sein soll. Die Angabe erfolgt in Hexadezimaler Schreibweise!

Ähnlich 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änge bis 4294967295 nicht voll ausreizen will. Die Suite erlaubt dann keine Werte die sich außerhalb von Min/Max bewegen. Das Attribut „Options=“ ist hier in diesem Beispiel nicht nötig und bleibt leer (mehr Details dazu findest du natürlich in der Doku…).

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ßt und welche Funktion es hat. „DataPointType“ gibt den DPT des KOs an. Hier im Beispiel „9.001“ für unseren Temperaturwert. Und zuguter letzt noch das Element „Flags“. Das ist im Detail ein bisschen knifflig. Aber da wir hier primär nur zwei „Profile“ haben, trägt man hier entweder 52 für ein Sensor-KO oder 42 für ein Aktor-KO ein. Details wie man zu diesen Zahlen kommt findet man, du errätst es sicherlich schon, in der Doku.

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ängigkeit von anderen Parametern einschränken kann. Aber das ist für ein solch kleines Anfänger-Beispiel erst einmal nicht relevant und kann weggelassen werden.

Und was gibt es noch?

Aus der .kdevice.xml kann man über ein in der Suite enthaltenes Tool eine Header-Datei generieren lassen, die einem den notwendigen Code-Abschnitt im Arduino-Sketch für die Parameter und KOs abnimmt. Aber das kommt dann in der nächsten Lektion, wo es dann darum geht, den Arduino-Sketch für das Gerät zu schreiben.

Ausblick

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ügt oder eins entfernen/streichen möchte, ist das von Hand zwar möglich, aber zeitraubend, und vor allem fehleranfällig.

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ührt von Menüs/Wizards. Damit wird das Erstellen der XML deutlich einfacher und fehlerfreier. Bis dahin führt aber kein Weg an der händischen Erstellung der XML vorbei.

<– Lektion 2: Was steckt in der Siemens BCU?Lektion 4: Es geht in die Praxis –>