Einführung
Es ist die besondere Stärke des KNX Systems, dass die jeweiligen KNX Geräte völlig autark am KNX Bus agieren, es gibt keine zentrale Instanz, die etwas abfragt oder entscheidet. Jedes KNX Gerät kann Nachrichten auf den Bus senden und lesen.
KNX Geräte werden ab Werk ohne jede Konfiguration ausgeliefert. Deshalb muss jedes KNX Gerät, bevor es in einem KNX Bus Nachrichten senden oder auf empfangene Telegramme reagieren kann, entsprechend eingestellt werden. Die Gesamtfunktion einer KNX Anlage ergibt sich daraus, dass vom Errichter festgelegt wird, auf Basis welcher Nachrichten was auf einem Display angezeigt oder durch einen Aktor geschaltet wird.
Diese Konfigurationsaufgabe wird als “Parametrisieren” bezeichnet, weil die jeweiligen KNX Geräte im Rahmen der verfügbaren Optionen und Parameter eingerichtet werden. Hierbei werden die spezifischen Optionen, die genutzt werden sollen, ausgewählt und damit Objekte in den KNX Geräten aktiviert, die anschließend mit Gruppenadressen für die Kommunikation am Bus verknüpft werden.
Eine Software für alle KNX Geräte aller KNX Hersteller
Mehr als 500 KNX Hersteller bieten über 8.000 KNX Geräte am Markt an. Damit die vorzunehmenden Einstellungen nicht mit einer jeweils herstellerspezifischen Software vorzunehmen ist, wird von der Herstellervereinigung KNX Association eine Software mit der Bezeichnung “ETS” (“Engineering Tool Software”) angeboten, mit der sämtliche KNX Geräte am Markt (egal von welchem Hersteller) eingerichtet werden können. Für die Konfiguration Ihrer KNX Anlage und auch für die Einrichtung der KNX Funktionen des Timberwolf Servers, benötigen Sie die Software ETS ab der Version 5.7.4 (oder neuer)
Erst Parametrieren, dann Programmieren
Der Reihe nach werden beim Parametrieren die jeweiligen Optionen des Gerätes ausgewählt, die entsprechenden Objekte der KNX Geräte damit aktiviert und anschließend mit Gruppenadressen assoziiert (“verknüpft”). Diese Einstellungen sind zunächst nur in der ETS (im jeweiligen Projekt) gespeichert. Erst mit der anschließenden Programmierung werden diese Parameter durch die ETS in das jeweilige KNX Gerät übertragen und dann von diesem autark für die Zukunft ausgeführt.
Applikationsobjekte / Spezialobjekte
Bei den meisten KNX Geräten sind dessen Objekte intern mit vorgegebenen Funktionen verdrahtet - z.B. bei einem Aktor ist das Objekt für das Schalten eines Relais intern direkt mit dem entsprechenden Relais verbunden und das Objekt für das Rückmelden der Schaltposition mit dessen Meldekontakt (oder einer elektronischen Auswertung der Schaltstellung). Bei KNX Sensoren stellen die jeweiligen Sensoren ihre Messwerte ebenfalls über - vom jeweiligen Hersteller vorgegebene - Objekte zur Verfügung.
Beim Parametrisieren werden die Funktionen der jeweiligen Geräte ausgewählt und die damit in der Regel fest zugeordneten Hardwarefunktionen zusammen mit deren Objekten aktiviert. Diese - einer Funktion fest zugeordneten Objekte - wollen wir im weiteren Verlauf Applikationsobjekte nennen.
Auch der Timberwolf Server stellt solche Applikationsobjekte bereit, zum Beispiel für das Empfangen oder Senden der Zeitsynchronisierung über KNX (lesen Sie hierzu Zeitsynchronisierung mit KNX mit dem Timberwolf Server). In der KNX Applikation des Timberwolf Servers werden diese als “Spezialobjekte” bezeichnet.
Universalobjekte
Der Timberwolf Server erlaubt die Anbindung tausender Geräte über viele verschiedene Bussysteme gleichzeitig. Im Rahmen der Systemressourcen ist der Nutzer völlig frei, ob dies nun 500 Sensoren mit 1-Wire sind und / oder 100 Energiezähler mit Modbus und / oder 30 über MQTT angeschlossene Standorte mit deren Geräten und / oder jede andere Kombination aus Geräten und Systemen.
Die Art und Weise sowie der Umfang, wie ein Timberwolf Server in eine Automatisierung eingebunden wird, steht - im Rahmen der Ressourcen und technischen Möglichkeiten - im freien Belieben des Einrichters der Anlage. Mithin existiert - aus der Sicht von KNX - auch keine feste Verbindung von Objekten zu fertig vom Hersteller verdrahteten Funktionen. Der Timberwolf Server ist eben kein Aktor mit genau zwei, acht oder zwanzig Kanälen und auch kein Sensor mit drei anschließbaren Temperatursensoren.
Deshalb stellt der Timberwolf Server sogenannte Universalobjekte zur Verfügung. Diese sind nicht intern verknüpft, sondern können vom Errichter universell genutzt werden, in dem diese im Timberwolf Server beinahe beliebig mit den Objekten anderer Bussysteme und Protokolle (sowie Logiken und Zeitserien) verknüpft werden können.
ZUVOR müssen diese Universalobjekte in der Timberwolf Server Applikation in der ETS parametriert und der Timberwolf Server damit programmiert werden.
Programmierung mit der ETS vs. “nur Projektimport”
Viele “KNX Server” am Markt nutzen lediglich einen Projektimport aus der ETS und kommunizieren anschließend über die aus dem Import gelernten GAs mit dem KNX Bus und müssen nicht programmiert werden. Warum ist dies beim Timberwolf Server anders?
KNX Zertifizierung des Timberwolf Servers
Zertifizierte KNX Produkte MÜSSEN den KNX Standard einhalten. Dieser KNX Standard verlangt - unter anderem - dass ein KNX Gerät über Objekte verfügt, die mit Gruppenadressen zu verknüpfen sind und dieses durch die ETS zu programmieren ist.
Daher sind die KNX Objekte des Timberwolf Servers mit der ETS zu programmieren.
”KNX Server” die nur auf Basis von Projektimport / Gruppenadressen kommunizieren ohne vorherige Programmierung mit der ETS entsprechen NICHT dem KNX Standard, wurden nicht auf Einhaltung der Spezifikation geprüft und tragen auch KEIN KNX-Logo.
Berechnung von Filterlisten durch die ETS
KNX erlaubt die Errichtung sehr umfangreiche Anlagen mit über 60.000 KNX Geräten in einem System. Damit Kommunikation hier noch möglich ist, wird die Anlage in Segmente unterteilt, die als Linien bezeichnet werden. Solche Linien werden über Linienkoppler und Bereichskoppler (sowie IP Routern, die Bereichskoppler zwischen KNX-TP und KNXnet/IP sind) miteinander verbunden. Um nur die notwendigen Telegramme über mehrere Linien hinweg zu transportieren, berechnet die ETS entsprechende Filterlisten und lädt diese beim Programmieren der Anlage in die LK und BK.
Damit die ETS diese Filterlisten berechnen kann, muss die ETS die Topologie kennen, das bedeutet, welches KNX Gerät befindet sich in welcher Linie (ergibt sich aus der PA) und welche Gruppenadressen sind mit den Objekten des Gerätes assoziiert. Damit kann die ETS berechnen, welche Gruppenadressen gefiltert werden dürfen und welche nicht (wenn zwei Geräte in zwei verschiedenen Linien die gleiche GA benutzen, dann müssen die LK und BK zwischen diesen beiden Linien diese GA weiterleiten).
Durch die Einbindung der Applikation des Timberwolf Servers in die ETS, der Aktivierung der Objekte des Servers und dem Assoziieren mit Gruppenadressen kann die ETS die Berechnung der Filtertabellen auch für die vom Timberwolf Server genutzten Gruppenadressen korrekt vornehmen.
Für “KNX Server”, die NICHT über die ETS programmiert werden, sondern irgendwo am Bus angesteckt sind und irgendwelche Gruppenadressen benutzen, kann die ETS die Filtertabellen nicht berechnen (hier wäre der ETS nicht bekannt, WO in der Topologie der Server angeschlossen wäre und kennt auch nicht die von diesem Server genutzten Gruppenadressen).
Bei Projekten mit mehreren Linien müssen deshalb “Dummy-Applikation” in der ETS gepflegt werden, mit denen die Parametrisierung solcher nicht zertifizierten “KNX Server” vom Errichter in der ETS simuliert wird, wobei die nötige Sorgfalt einen hohen Aufwand erfordert. Bei Diskrepanzen zwischen den Parametern in einer solchen Dummy Applikation und den tatsächlichen Einstellungen solcher Server können schwer nachvollziehbare Probleme auftreten. Dies wird beim Timberwolf Server vermieden.
Wir sind der Meinung, dass ein KNX Server, der mit vielen tausenden Objekten ausgestattet ist und über mehrere tausend Gruppenadressen mit dem KNX Bus austauscht, vollständig in die ETS eingebettet sein muss, damit die KNX Projektdokumentation diesen Server auch auf korrekte Weise miteinbezieht und damit Filtertabellen korrekt berechnet werden können.
Deshalb ist der Timberwolf Server konform zum KNX Standard ausgelegt, verfügt über eine Applikation für die ETS und ist wie jedes andere konforme KNX Gerät zu parametrisieren.
Berücksichtigung der mit der ETS gesetzten Objekt Flags
Die Art und Weise, wie Objekte in KNX Geräten kommunizieren, wird über Flags der Objekte gesteuert. Diese Flags werden in der ETS angezeigt und verwaltet.
Bei den meisten KNX Geräten sind diese Flags für die jeweiligen Objekte fertig vorgegeben, beim Timberwolf Server sind diese für jedes Objekt einzeln einstellbar. Damit kann das Verhalten im Detail gesteuert und damit können wichtige Funktionen, z.B. für das Hochfahren einer Anlage (z.B. nach Stromausfall) granular gesteuert werden.
Dies ist nur möglich, weil der Timberwolf Server entsprechend dem KNX Standard mit KNX Objekten operiert, die mit der ETS parametriert werden.
Bei den “KNX Servern” die nur über GA kommunizieren, gibt es diese Funktionalität der Flags nicht, da diese zu Objekten zugehörig ist und nicht zu Gruppenadressen.
Wir wollten den Nutzern des Timberwolf Servers keine Kompromisse mit KNX zumuten, daher haben wir die Funktionalität entsprechend dem KNX Standard umgesetzt und deshalb sind die KNX Objekte mit der ETS zu parametrieren und der Server damit zu programmieren. Damit sind diese Objekte auch im Projekt dokumentiert, die Nutzung der Gruppenadressen ebenfalls, die ETS kann die Filtertabellen ordentlich berechnen und das Verhalten der Objekte kann granular über die Flags bestimmt werden.
Das Projekt können Sie trotzdem zusätzlich importieren, das dient dazu, dass der Timberwolf Server auch die Bezeichnungen kennt und die Datenpunkttypen aller Gruppenadressen im System (dies nutzt der Logger für die Dekodierung der Daten).
Die Aktivierung erfolgt in der ETS durch Angabe des DPT, anschließend sind die Objekte mit einer GA zu verbinden und der Timberwolf Server aus der ETS zu programmieren. Danach können im Timberwolf Server diese KNX Objekte über die Web-APP (Administrationsoberfläche) mit anderen Objekten, zum Beispiel einem 1-Wire Objekt, Modbus Objekt, MQTT Objekt, einer Logik oder einer Zeitserie verbunden werden.
Im Detail zeigen wir dies im nächsten Abschnitt.
Kommentar hinzufügen