Aktiver Gruppenmonitor verändert Busverhalten?

[BadSmiley]

Wenn er im X1 verwendet wird, hat der X1 eine Applikation, mit der man die GA verbinden kann. Evtl. erzieht man die Leute mal endlich zu etwas mehr Sorgfalt?

[vento66]

Ich gehe mal davon aus, das es so gemacht ist, sonst würde der Staus ja nicht verknüpft werden können, oder irre ich mich da?

[BadSmiley]

Ich gehe mal davon aus, das es so gemacht ist, sonst würde der Staus ja nicht verknüpft werden können, oder irre ich mich da?

Ich wette ein Corona, dass nicht.

[Gast1961]

Ich gehe mal davon aus, das es so gemacht ist, sonst würde der Staus ja nicht verknüpft werden können, oder irre ich mich da?

X1 und L1 erlauben ja beide Varianten
- GA nur im GPA verknüpft ohne Beteiligung der ETS (im X1 unter "Gruppenaddress-Datenpunkte")
oder
- GA in der ETS mit dem X1 verknüpft (im X1 unter "Geräte-Datenpunkte")

[vento66]

Und in beiden Varianten müsste der X1 den Empfang bestätigen.....

[vento66]

Selbst wenn ich die GA mit DIP Schaltern einstellen muss, und das Gerät gar nicht in der ETS auftaucht, muss das Gerät ein ACK senden. Würden sich alle Geräte daran halten, einen Status nur zu verarbeiten, wenn ein anderes Gerät den Empfang bestätigt, würde kein Gerät am Bus die Bestätigung senden. (keiner will ja in dem Fall der erste sein). Ich seh da immer noch einen Fehler bei Gira. Oder darf ich dann immer einen LK einbauen, der einfach alles stumpf bestätigt? Oder braucht eine reine X1 Visu dann einen von der Sorte? https://www.my-knx-shop.net/b-b-E001...ledge-Baustein

[jb1]

In den Gira IP-Geräten haben wir das Konzept von Datenpunkten in einem Objektmodell. Jeder Datenpunkt hat einen bestimmten Typ (z.B. Binärwert, vorzeichenlose Zahl oder Text).

Jeder Datenpunkt kann ein Eingang und/oder Ausgang für einen Wert sein.

Diese Datenpunkte unterscheiden sich in verschiedene Arten:
- Gerätedatenpunkte: diese gibt es immer und sind teilweise mit einem KO in der ETS verknüpft
- Gruppenadress-Datenpunkte: benutzerdefiniert anlegbar, kommuniziert über Gruppenadressen über KNX, hier wird der Datentyp noch weiter nach dem KNX-Standard unterteilt, z.B. 8-bit Zahl oder 14-Byte Text
- Variablen-Datenpunkte: auch benutzerdefiniert anlegbar, nur für Visu oder Logik verwendbar



Wenn bei den Gruppenadress-Datenpunkten eine schreibende Gruppenadresse angegeben wird, dann sendet jedes Schreiben auf den Datenpunkt ein GroupValueWrite auf den KNX-Bus an die angegebene Schreib-Adresse. Falls niemand ein ACK auf dieses Telegramm sendet, gilt dies für den X1 als Fehler und der Datenpunkt wird auf einen leeren Wert zurückgesetzt. Denn warum sollte man einen KNX-GA-Datenpunkt verwenden, wenn dieser gar nicht über KNX kommunizieren soll...

Wenn du jetzt nur einen Datenpunkt in der Logik oder in der Visu benutzen möchtest, dann nimm doch einen frei definierbaren Variablen-Dantepunkt.
Mit diesen hast du auch nicht die Einschränkungen der KNX Datenpunkttypen, es werden keine unnötigen Telegramme auf den Bus versendet.

Edit: Gruppenadress-Datenpunkt Typ umbenannt zu dem, wie er im GPA steht; Bemerkung wegen Performance entfernt, da dies irrelevant ist.

[vento66]

Grenzgenial! Jetzt darf ich mir schon wegen ein paar GA Gedanken zur Resourcenauslastung machen! Ah nein eher nicht, weil das Zeugs kommt mir ja nicht mehr auf die Baustellen...

[gbglace]

Ha und da meckere mal noch einer über den TWS der eben konsequent, wenn man mit KNX-GA arbeiten möchte auch ein KNX-KO in der ETS hat und entsprechend dem Standard die Kommunikation herstellt. Will man ohne KNX-GA arbeiten gibt es auch Objekte für den TWS internen Gebrauch, die nennen sich aber zum Glück nicht GA oder KNX im Namen, weil man dann auch nicht so ein Durcheinander als User bauen kann.

- Gerätedatenpunkte: diese gibt es immer und sind teilweise mit einem KO in der ETS verknüpft

Das doch schonmal inkonsequent und von der Wirkung nicht mehr Transparent für den User.

KNX-GA-Datenpunkte: benutzerdefiniert anlegbar, kommuniziert über Gruppenadressen über KNX, hier wird der Datentyp noch weiter nach dem KNX-Standard unterteilt, z.B. 8-bit Zahl oder 14-Byte Text

Das doch noch verwirrender, wenn so ein GA-Datenpunkt womöglich auch noch ohne echtes KO in ETS generiert werden kann.

Oder war jetzt deine Erklärung unglücklich und Gerätedatenpunkte ist alles und davon gibt es zwei Typen, A) KNX-Datenpunkte inkl. ETS KO und anderer Seits B) die variablen Datenpunkte quasi ohne direkten KNX-Anschluss?

[Gast1961]

Ha und da meckere mal noch einer über den TWS

Huh?

Beim X1 hast du alle drei Möglichkeiten, man muß sich halt nur entscheiden was wann passt. Und diese Besonderheit einer Variante im Blick behalten, wenn man den Wert von der Logik nicht nur versenden sondern auch in der Visu anzeigen will.

Das doch noch verwirrender

Die Verwirrung schaffst du gerade, weil du die Begrifflichkeiten durcheinanderwirfst. Die Erklärung von jb1 war sehr klar.

Als GPA-Nutzer muß man nur schauen wo man den Datenpunkt anlegt.

gpa_dp.png

[jb1]

"- Gerätedatenpunkte: diese gibt es immer und sind teilweise mit einem KO in der ETS verknüpft"
Das doch schonmal inkonsequent und von der Wirkung nicht mehr Transparent für den User.

Aus der anderen Richtung ist es vielleicht einfacher: Alle KOs in der ETS sind mit Gerätedatenpunkten verknüpft, also nur diese können über ETS mit Gruppenadressen verknüpft werden.

"Gruppenadress-Datenpunkte: benutzerdefiniert anlegbar, kommuniziert über Gruppenadressen über KNX, hier wird der Datentyp noch weiter nach dem KNX-Standard unterteilt, z.B. 8-bit Zahl oder 14-Byte Text"
Das doch noch verwirrender, wenn so ein GA-Datenpunkt womöglich auch noch ohne echtes KO in ETS generiert werden kann

Diese Datenpunkte haben kein KO, es können nur die Gruppenadressen im GPA angegeben werden. Es muss ein DPT aus dem KNX Standard ausgewählt werden und es wird ganz normal über KNX mit anderen Geräten kommuniziert.

[gbglace]

Wenn der X1 schon die Visu intern hat, also mit seinem Objektmodell direkt bedient werden kann, warum dann für KNX basiertes zwei Wege?

Entweder ein reines internes Objekt für nur Logik <> Visu oder eben ein KNX-Objekt für die Buskommunikation mit Logik und/oder Visu. Warum aber für KNX zwei verschiedene Objekttypen verwendet werden erschließt sich mir nicht, ich finde das nicht intuitiv.

[voglerc]

Na da hab ich was losgetreten

Ich denke mein Problem war wie von BadSmiley beschrieben.

Wenn er im X1 verwendet wird, hat der X1 eine Applikation, mit der man die GA verbinden kann. Evtl. erzieht man die Leute mal endlich zu etwas mehr Sorgfalt?

Ich habe jetzt die beiden GA mit Gira X1 Binärvariablen verknüpft. Ob das richtig/falsch/unsauber/egal ist könnt ihr mir sicher besser beantworten - es funktioniert mal

[Gast1961]

Wenn der X1 schon die Visu intern hat, also mit seinem Objektmodell direkt bedient werden kann, warum dann für KNX basiertes zwei Wege?

Ich finde es sehr positiv.

Der Nutzer kann selbst entscheiden, ob er den schnellen Weg gehen möchte mit Verknüpfung der GA im GPA - oder den Weg über Verknüpfung in der ETS, was dann für Filtertabellen in Kopplern usw. Vorteile hat.

Die Verknüpfung im GPA - ohne ETS - hat erkennbar Vorteile auch für Endanwender die gar keine ETS haben (weil Elektriker/SI sich um KNX gekümmert hat) aber die als Bewohner trotzdem den vollen Funktionsumfang eines X1 nutzen wollen und können.

[vento66]

Und wo geht dann die GA hin, die sich der User im GPA ausgedacht hat? Kann er den Aktor dann auch mit dem GPA bespaßen?