Frage zu Dummy-Geräten; Flags; Anzahl verknüpfte GA je KO

[TabSel]

Ich eruiere gerade die Unterschiede der verschiedenen Dummy-Geräte im Katalog.
technisch mag es da keine, aber "optisch" schon, hinsichtlich der Texte (z.B. der Name, oder die "Objektfunktion"), die dann überall im Projekt auftauchen. Daher guck ich grad mit welchem Dummy-Gerät ich am besten "klar komme".

1) Jetzt fällt mir auf dass die verschiedenen Dummy-Geräte meist KO's mit unterschiedlichen Default-Flags aufweisen. Da stellt sich mir die Frage ob die Flags vielleicht "intern" für die ETS und die Filtertabellen oder auch anderes eine Bedeutung haben. Ich will einfach keine zwei oder mehrere KO's mit "L"-Flag mit ner GA verknüpfen. Ein Dummy kann eh nicht auf ein ValueReadRequest reagieren, also was soll das dass KO's von Dummy-Geräten das "L"-Flag gesetzt haben?

2) Gibt es eine Begrenzung der Anzahl GA's mit denen ein KO verknüpft sein kann? Ich möchte vermeiden unzählige Dummies im Projekt zu haben, zwecks Übersicht

Danke
Tab

[Beleuchtfix]

Ein Dummy ist dum und existiert in der realen Welt nicht, egal wie die Flags eingestellt sind nehmen sie keine Befehle entgegen und antworten auch nicht. Du kann ziemlich viele GAs mit einem Dummy KO verbinden, irgendwo gibt es wohl innerhalb der ETS oder der einzelnen Applikationen eine Begrenzung, dann nimmst du ein weiteres Dummy. Egal wie die Bezeichnungen jetzt sind, du benötigst nur für jeden DTP Grundtypen (1 Bit, 1 Byte, 2 Byte …) ein eigenes KO, der Rest ist egal.

Gruß Florian

[gbglace]

Ggf nochmal den Grund für den Dummy überdenken und auf passende KNX Geräte setzen.

Baust Du eine SP? Sodass alles was ein Sensor macht eine GA als Sensorwerte ist und dann eine Logik daraus einen Befehl rechnet und dann für jedes Aktor-KO auch noch genau eine GA existiert? Mit einem solchen Konstrukt hast natürlich sehr sehr viele GA und sicher auch den Bedarf an mehrere Dummys.

Dummys sind nur eine Sortierhilfe für die ETS um die Einträge der Filtertabellen zu ermitteln.

Auf dem Bus selbst existiert davon nichts und es passiert da auch nichts.

Bei realen KO gehen glaube meist bis zu 16 Assoziationen je KO. Am Dummy könnte es auch mehr sein, weil ja nichts in einen Gerätespeicher muss.

[tobiasr]

Natürlich existiert der Dummy so auf dem Bus. z.B. hinter einer IP Schnittstelle oder in einem Konnekting Gerät. Von Weinzierl gibt es einen Dummy, der per CSV Datei recht bequem gefüttert werden kann.

[meti]

Aber die Einstellungen der Dummy Flags haben trotzdem nix mit dem Gerät/Software das dahinter evtl läuft zu tun.
Zb wenn das so eingestellt ist das es auf ein GroupValueRead antwortet kannst du das am Dummy nicht verändern.
So gesehen wird ich auch sagen das der Dummy am Bus nicht existiert.

[gbglace]

Natürlich existiert der Dummy so auf dem Bus.

Nee nee nee
Da existiert irgendwas, was der Dummy, für den Bus bzw. nur die ETS, repräsentieren soll.

Weil das was man da irgendwo eingebaut hat eben keiner KNX-Zertifizierung unterliegt und keine ETS-Applikation hat.

[mumpf]

Man kann einen Dummy in unterschiedlichen Rollen nutzen, für welche Rolle man sich entscheidet, muss jeder selber wissen:

1. Rein technisch für die Filtertabellen: In jeder Linie, in der ein KNX-Teilnehmer ohne ETS-Applikation steckt, packt man einen Dummy und verbindet alle GA, die von den KNX-Teilnehmern ohne Applikation genutzt werden, mit diesem einen Dummy. Das sorgt rein technisch für korrekte Filtertabellen, mehr kann man aus so einer Konstellation nicht erkennen.
2. Gerätebezogene Dummies: Man packt für jeden KNX-Teilnehmer ohne ETS-Applikation (z.B. für jeden Shelly) einen Dummy auf die entsprechende Linie. Hier verknüpft man aber immer noch alle gleichen DPT mit nur einem KO. Dann sieht man in der ETS zumindest, welches Gerät diese GA verwendet.
3. Dummies mit Semantik: Wie 2, nur macht man sich die Mühe, die Schnittstelle des Gerätes im Dummy abzubilden. Man benennt jedes KO passend, macht die Verknüpfungen passend zu verschiedenen KO (auch wenn sie gleiche DPT haben) und setzt die Flags passend. Dadurch kann man in der ETS auch nach 2 Jahren noch nachvollziehen, was das Gerät macht und wie es kommuniziert. Dieser Ansatz hat natürlich (bis auf Filtertabellen) nur einen dokumentierenden und keinen funktionalen Charakter.

Ich mache eine Mischung aus 2 und 3, meine Logikengine hört auf meine Hauptlinie (da brauche ich keinen Dummy für die meisten GA, sondern nur für die GA der Außenlinie - und auch da nur für die, die sonst nirgendwo verbunden sind). Für alle Geräte, die Einzelfunktionen erfüllen (1-Wire-Sensoren) habe ich einzelne Dummies, die passend benannte KO besitzen und entsprechenden Räumen und Gewerken zugeordnet sind.

Gruß, Waldemar