ElabNET Technik Forum

gbglace hat geschrieben: ↑Fr Aug 19, 2022 3:59 pm Insofern muss man sich gedanklich zweierlei Sorten KO denken. Jene KO die man nutzen will um einfach ganz genau wie im Buslog alle Telegramme mit einer GA separat auszuwerten und wegzuschreiben. Versus jene KO die man benutzt um Logikfunktionen oder andere Funktionen im TWS zu erzeugen, also den TWS als "Aktor" zu verstehen. An KO von Aktoren nutzt man ja auch gern um Telegrammlast zu reduzieren die Verbindung mehrerer GA lesend an einem KO.

Also reagiert hier der TWS wie jedes andere KNX-Gerät. Vielen Dank für die Verdeutlichung! Damit ist klar, dass man beim Protokollieren von Sensordaten am TWS keine KOs sparen kann, aber selbstverständlich bei Verwendung des TWS als Aktor.

petertau hat geschrieben: ↑Fr Aug 19, 2022 2:17 pmwunderbar, dass der TWS GAs nicht bloß aggregiert auf die jeweilige KO verarbeitet, sondern weiterhin jede zugeordnete GA einzeln sieht.

Das habe ich nicht gesagt.

Gemäß dem KNX Standard werden - in ALLEN KNX Geräten - Listen geführt, welche GAs eingehend auf welche KOs geführt sind (ausgehend ist es immer nur eine GA).

Es wird weder irgendeine Aggregation wie Mittelwertbildung durchgeführt, noch sonst etwas anderes gemacht, als das Mapping der GA auf die KO.

Stellt Dir das wie in einer Wohneinheit vor die von mehreren Personen (Familie) bewohnt wird, die aber alle zusammen nur eine Anschrift und zumeist auch nur einen Briefkasten benutzen. Es gibt da viele Personen (= GA) aber nur ein Briefkasten (= KO). Die gesamte Post (= Telegramme) für alle dort lebenden Personen (= assoziierte GAs) landet dort.

petertau hat geschrieben: ↑Fr Aug 19, 2022 2:17 pmIch habe hier eine Einschränkung des TWS vermutet, die gar nicht besteht.

Wenn Du das als Einschränkung empfindest, dann gilt das für den gesamten KNX Standard und die Art und Weise wie ALLE KNX Geräte, also jeder Aktor, jeder Glastaster usw. arbeiten. GAs sind nur Adressen für (gruppierte) Funktionen. Das ist die Aufgabe und diese ist auf diese Weise zu implementieren.

Das behandeln der einzelnen GA, wie es viele andere Server machen, ist fachlich falsch und unterläuft die Architektur des KNX die darauf angelegt ist, Telegramme zu sparen, indem Funktionen gruppiert werden.

Ich wünsche viel Erfolg mit Deinem Projekt

Stefan

gbglace hat geschrieben: ↑Fr Aug 19, 2022 3:59 pm Insofern muss man sich gedanklich zweierlei Sorten KO denken. Jene KO die man nutzen will um einfach ganz genau wie im Buslog alle Telegramme mit einer GA separat auszuwerten und wegzuschreiben. Versus jene KO die man benutzt um Logikfunktionen oder andere Funktionen im TWS zu erzeugen, also den TWS als "Aktor" zu verstehen. An KO von Aktoren nutzt man ja auch gern um Telegrammlast zu reduzieren die Verbindung mehrerer GA lesend an einem KO.

Also reagiert hier der TWS wie jedes andere KNX-Gerät. Vielen Dank für die Verdeutlichung! Damit ist klar, dass man beim Protokollieren von Sensordaten am TWS keine KOs sparen kann, aber selbstverständlich bei Verwendung des TWS als Aktor.

StefanW hat geschrieben: ↑Fr Aug 19, 2022 4:15 pm Gemäß dem KNX Standard werden - in ALLEN KNX Geräten - Listen geführt, welche GAs eingehend auf welche KOs geführt sind (ausgehend ist es immer nur eine GA).

Passt schon, ist klar. Ich wollte mit meiner Frage lediglich klären, wie sich der TWS verhält. Auch wenn der TWS an die Eigenschaften des KNX-Standards gebunden ist, ist damit noch lange nicht gesagt, was genau im Inneren des TWS (oder auch jedes anderen KNX-Geräts) abläuft. Aber nun haben wir das Thema GAs und deren Zuordnung zu KOs des TWS in der ETS detailliert behandelt! Vielen Dank für die Geduld...

Hi,

petertau hat geschrieben: ↑Fr Aug 19, 2022 4:26 pmAuch wenn der TWS an die Eigenschaften des KNX-Standards gebunden ist, ist damit noch lange nicht gesagt, was genau im Inneren des TWS (oder auch jedes anderen KNX-Geräts) abläuft.

Eigentlich schon, weil das tatsächlich genau vorgegeben ist, soweit es GA und KO betrifft. Das wird auch geprüft.

Das was "frei" ist, das ist, was hinter dem KO ist, weil das kann ein Relais sein beim Aktor und ein Temperatursensor beim Glastaster, das ist Sache des Herstellers.

Beim Timberwolf Server sind es Universal-Objekte, weil die Belegung im Server ist frei, was ihn zu dem multidirektionalen Gateway von allem auf alles macht.

Viel Erfolg

Stefan