Hallo Markus,
der Timberwolf Server ist außerordentlich vielfältig umd flexibel einsetzbar. Deas macht es notwendig, ein wenig mehr einzustellen, als man sich das am Anfang womöglich vorgestellt hat. Ich will das kurz erklären.
Insbesondere ist der Timberwolf Server ein "Multidirektionales Multi-Schnittstellen Gateway zwischen gleichberechtigten Subsystemen". Das bedeutet:
1. Die zentrale Komponente im Timberwolf Server ist der Dispatcher ("Verteiler").
2. Der Dispatcher enthält eine Liste von Objekten und deren Verknüpfung miteinander. Es gibt praktisch keine Einschränkung, man kann N Objekte mit M Objekten verbinden. Es ist also durchaus möglich, EIN (1) ankommendes Objekt auf tausend (1000) andere Objekte schreiben zu lassen.
3. Der Datenaustausch mit den jeweiligen Bussystemen / Protokollen geschieht über soganannte "Sub-Systeme". Subsysteme sind Instanzen einer Technologie. Mehrere Technologien können zu einer Technologiegruppe gehören.
Beispiel:
Technologruppe: KNX
Technologie: KNX-TP
Subsystem: KNX-TP auf z.B. der Linie 1.1
Interface: KNX-TP (im System enthalten)
Diese Struktur gestattet es, dass man eines Tages (wenn das komplett vom TWS unterstützt wird) auch mehrere Interfaces mit einer KNX Applikation betreiben kann, insbesondere auch andere KNX Technologien anbinden könnte wie z.B. enen KNXnet/IP Stack oder KNX RF.
Man wird das in einigen Monaten sehen, wenn es in der Technologiegruppe "Modbus" mehrere verschiedene Technologien aussuchen und als Subsystem mehrere Interfaces zuordnen kann.
4. Jedes Subsystem hat seine eigene Menge an Objekten. Ein KNX TP Subsystem hat KNX-Objekte, ein 1-Wire Subsystem dann eben 1-Wire Objekte und das Zeitserien-Subsystem bildet wieder Objekte aus.
Wie die jeweiligen Objekte erzeugt werden, hängt von der Technologie des Subsystems ab.
- Bei KNX muss hierfür die ETS verwendet werden. Der KNX Standard sieht vor, dass durch Programmierung die Objekte des betreffenden KNX Gerätes aktiviert werden, Optionen gesetzt und ein oder mehrere Gruppenadressen mit diesen Objekten zu verbinden sind. Die einzige für die Programmierung verwendbare Programmiersoftware ist die ETS, daher ist die ETS zu verwenden, um im TWS die KNX Objekte im verbundenen Subsystem anzulegen, dabei den DPT zuzuweisen und ein oder mehrere GAs diesen Objekten zuzuordnen.
- Bei 1-Wire werden die 1-Wire Sensoren angeschlossen und anschließend sind Regeln anzulegen. In diesen Regeln wird spezifiziert welches der Fähigkeite eines 1-Wire Gerätes in welchem Zyklus abzufragen ist, ob Berechnungen damit angestellt werden und unter welchen Umständen die Werte an das interne Objektsystem zu senden sind.
- Bei den meisten anderen neueren Technologien wie ekey und bald auch Modbus legt man ebenfalls solche Regeln an. Der Freiheitsgrad dieser Regeln ist sehr groß.
Gleichberechtigt bedeutet hier, dass KEINE Technologie irgendwie "bestimmend" ist. Es ist also nicht wie bei anderen KNX-zu-irgendwas Gateways, dass sich alles nach KNX richten muss und es nur die Richtung KNX <-> irgendwas gibt, sonder alle zu allen. Insofern ist KNX nur ein Subsystem im TWS und auch 1-Wire ist nur ein solches und bei allen anderen ist es auch so.
Daher ist der Timberwolf Server auch kein "Wiregate 2.0" das nur die Aufgabe KNX <-> 1-Wire kennt (und manches dann auch einfacher wäre). Es ist ein Alles zu Alles gateway mit Logik, Visu und Aufzeichnung und deshalb muss man da einfach etwas mehr einstellen.
KNXMane hat geschrieben: ↑Sa Aug 22, 2020 4:22 pmUnd wo stell ich das ganze ein? In der ETS oder in der TW Oberfläche? Ich will einfach nur meine Fensterkontakte wieder auf dem Bus haben!!! In der ETS am TW sehe ich meine ganzen alten GA der Fensterkontakte. Aber was muss ich noch tun, damit das Ding sendet?
Wenn man eine Migration vom WireGate Server auf den Timberwolf Server in der richtigen Reihenfolge vornimmt, dann wird alles richtig vom Wiregate Server übernommen und fertig eingerichtet. Wichtigste Voraussetzung dafür ist, dass man die 1-Wire Sensoren erst ganz am Ende anschließen darf, wenn die Daten alle übernommen wurden vom WireGate Server. Schließt man die Sensoren zuvor an, dann greift ein anderer Automatismus und dann ist diese halbautomatische Übernahme der Konfiguration vom Wiregate Server nicht mehr möglich.
Die manuelle Reihenfolge um einen Sensorwertes eines 1-Wire Sensors auf KNX zu bringen ist so:
1. Feststellen, welche Werte von 1-Wire Sensoren / Aktoren man nutzen möchte im KNX
2. ETS starten und in der TWS Applikation die entsprechenden Objekte mit dem richtigen DPT anlegen.
3. Diese Objekte in der ETS mit den GAs verbinden
4. Den TWS durch die ETS programmieren.
5. Wir empfehlen anschließend das ETS Projekt auch zu importieren. Das ist nicht zwingend notwendig, aber nur so weiß der TWS von allen angegeben Bezeichnungen, kenne alle im Projekt angelegten GAs, kennt die PAs und Geräte und kann daher dann deutlich mehr anzeigen
6. Im 1-Wire Geräteeditor nun eine bestehende Regel anpassen oder eine neue Regel anlegen. Hierbei die Applikation des 1-Wire Gerätes auswählen (z.B.) die Temperatur, ein Pollintervall angeben (also alle wieviele Sekunden / Minuten ist ein Sensorwert zu lesen), ggfls. einen Offset, dann ist anzugeben wann der Wert weiterzugeben ist (Empfehlung: Bei Wertänderung und alle x Minuten, letzeres muss ein vielfaches des Pollwertes sein) und schließlich gibt man das Ziel an. Also hier das zuvor mit der ETS angelegt KNX Objekt und aktiviert die Regel durch Speichern. Sofern die Regel nicht rot hinterlegt wird, sollte nun alles funktionieren.
Fertig. Jetzt nur noch warten, bis der Polling-Intervall einmal durchgelaufen ist und man sollte einen Wert auf den KNX bekommen. Der Wert wird auf der GA gesendet, die als "schreibende GA" zu dem Objekt in der ETS hinterlegt wurde.
Gleichzeitig kann man den selben Wert auch auf jedes andere Objekt im Timberwolf Server legen, also auf eine Zeitserie schreiben, auf andere KNX Objekte senden usw.
Es ist also ganz anders als am WireGate Server.
1. Der Server ist ein KNX Gerät und arbeitet intern auf der Basis von Objekten und hinsichtlich KNX mit KNX-Objekten, welche zunächst durch die ETS anzulegen ist. Das gibt der KNX Standard so vor. Welche GAs diesen KNX Objekten zugeordnet sind, wird mit der ETS angelegt. Im Server wählt man dann das entsprechend KNX Objekt aus. Allerdings kann man im Suchfeld dazu auch eine GA angeben und dann wird angezeigt, welche Objekte dieser GA zugeordnet sind.
2. Im Timberwolf Server kann man bei 1-Wire durchaus auch MEHRERE Regeln für den selben Wert anlegen.
3. Jede der Regelm hat einen eigenen Fahrplan ("Poll-Intervall"), man kann also eine Temperatur sowohl alle 5 Minuten als auch einmal stündlich abrufen, diese verschieden berechnen lassen, jeweils andere Sendefilter einrichten und an einen anderen Satz von Objekten weiterleiten.
4. Man kann im Timberwolf Server einen Wert auf mehrere Objekte gleichzeitig senden, das können mehrere KNX Objekte, oder aber auch Zeitserien
sein.
Es gibt also eine sehr große Freiheit beim Timberwolf Server. Man kann mehr damit einrichten aber man muss muss auch deutlich mehr einstellen dafür, daher gibt es eine kleine Lernkurve zu nehmen.
KNXMane hat geschrieben: ↑Sa Aug 22, 2020 4:22 pmZum Thema echtes KNX Geräte. Bei einem echten KXX Geräte erstelle ich die GA, verknüpfe sie, flash, fertig.
Das ist auch hier so, allerdings werden im Timberwolf Server sogenannte "Universalobjekte" verwendet, deren Funktion vom Nutzer zugewiesen wird.
Nehmen wir als Beispiel ein einfaches KNX Gerät wie einen Taster der ein Lämpchen enthält. In der einfachsten Ausführung hätte dieses KNX Gerät zwei Objekte zur Verfügung. Das eine ist ein (sendendes) Objekt für den Taster und ein empfangendes Objekt für das Lämpchen. In der ETS würde man also diese beiden Objekte sehen und ordnet in der ETS diesen dann die GAs zu auf denen bei Tastendruck gesendet (eine "Sending GA") werden soll bzw. die GAs auf die das Lämpchen reagieren soll.
Hier hast Du völlig recht, GAs erstellen, mit den beiden Objekten verknüpfen, programmieren und fertig. Das ist hier so, weil die Funktion dieser Objekte vom Hersteller dieses Gerätes fest zugeordnet wurde und intern sind diese Objekte fest verdrahtet mit dem Taster und dem Lämpchen-
Der Timberwolf Server ist dagegen ein "multidirektionaler Server mit Gateway zu multiplen Schnittstellen unterschiedlicher Technologien". Das wird am Ende in jeder Installation anders aussehen. Der eine Nutzer mag drei DMX Interfaces, fünf Mobus und eine 1-Wire-Subsystem betreiben und mit KNX verbinden, ein anderer zwei MQTT, vier DMX, zwei ekey und fünf Rest-API Schnittstellen, aber keinen 1-Wire.
Wie wollten wir bei der großen Vielfalt an möglichen Installationen eine feste KNX Applikation vorgeben. Hätten wit Objekte für 100 Temperatursensoren, 100 Luftfeuchte und 200 IOs fest vorgeben sollen? Was macht der Kunde mit 101 Temperatursensoren dann, einen neuen Server kaufen? Es machte eben keinen Sinn, irgendwelche Objekte in einer KNX Applikation vorzugeben, zumal die interne Verknüpfung nicht vorhersehbar ist für uns, weil der Nutzer fast unendliche Freiheitsgrade hat.
Daher haben wir uns entschieden, dass der TWS in der KNX Applikation Universalobjekte bekommt und diese daher im Inneren des Servers dann selbst durch Verknüpfen belegen muss.
Daher muss man beim Timberwolf Server anschließend nach dem Programmieren mit der ETS die angelegten Objekte mit anderen Objekten verknüpfen, damit etwas sinnvolles geschieht.
Das ist dann auch der einzige Unterschied zwischen den zumeist üblichen KNX Geräten und dem KNX Gerät Timberwolf Server: Bei den einen ist fest vorgegeben, was man mit den Objekten machen kann (weil zumeist mit einer HW-Funktion oder eine fixen Gateway-Fuktion verbunden) und beim Timberwolf Server ist man als Nutzer völlig frei, was man damit machen kann, muss es aber dann auch bestimmen.
Für die meisten Benutzer ist der Timberwolf Server das erste KNX Gerät, bei dem man BEIDE Seiten sieht. Die Seite zum KNX-Bus hin sind die GAs, die andere - interne - Seite sind die Objekte, die mit den GAs verbunden sind. Tatsache ist, dass ALLE KNX Geräte intern mit KNX Objekten arbeiten, nur sieht man das dort eben nicht, weil es keine Benutzeroberfläche gibt, Beim TWS sieht man es schon, weil man sich drauf einloggen kann.
Ich wünsche viel Erfolg mit dem Projekt.
lg
Stefan
