Gruppenadressen zuordnen

[spassbird]

Hallo und guten Tag,

hab mich trocken (also ohne praktische Tests, da mir noch die 24V DC Hilfsspannung fehlt) durch das Handbuch bis auf Seite 45 vorgearbeitet.
Dabei stolpere ich andauernd über die Zuweisung von Gruppenadressen, die sich mir aus mein bisherigen Wissen einfach nicht erschliessen will.

Bei allen KNX Kursen die ich gemacht habe (Online und zertifizierter Grundkurs an der HWK) wurde einem gelehrt, dass man eine Gruppenadresse für ein
Event anlegt und es dann mit dem entsprechenden Kommunikationsobjekt von Sensor und Aktor verbinde.
Also jede Gruppenadresse hat mindestens zwei Verknüpfungen.

z.B. Flur Deckenlicht hat die GA 1/0/1.
Diese leg ich dann auf die Wippe 1 des Tasters 1 und auf den Schaltaktorkanal A.
Soweit so klar und funktional.

Beim eibPC Handbuch, wird aber scheinbar für jedes Kommunikationsobjekt eine andere GA verwendet.

z.B. Wippe 1 Taster 1 mit GA 1/0/1
Wippe 2 Taster 1 mit GA 1/0/2
Aktorkanal A mit GA 1/1/1

jetzt wird im Handbuch erklärt um das Licht einzuschalten soll folgender Befehl gesetzt werden.
if ('1/0/1'b01==EIN) then write ('1/1/1'b01,EIN) endif

Die Logik hinter dem Befehl versteh ich, aber nicht warum die Kommunikationsobjekte unterschiedliche GA bekommen?

Für Verknüpfungen und Logiken wäre es ja erklärlich, aber nicht um einfach Licht ein und auszuschalten.

Meckert die ETS nicht, wenn ich zwar nen Haufen Adressen anlege, die aber nicht mit mindestens zwei KO verbinde?

Mit meinem bisherigen Wissen von rein ETS basierten Projekten, müsste die Syntax so aussehen.

if ('1/0/1'b01==EIN) then write ('1/0/1'b01, EIN) endif

Dafür braucht es natürlich keinen eibPC, das machen die Komponenten schon direkt nach der Programmierung der Applikation.

Gibt es irgendwo eine Anleitung wie mit der GA Vergabe zu verfahren ist?
Vielleicht stell ich mir das auch zu romantisch vor, dass der eibPC der gleichen GA-Struktur folgt wie die ETS.

Oder ist es gar so, was ich fast vermute, dass derlei einfache Aufgaben nix für den eibPC sind und er eher für komplexere Aufgaben
konzipiert ist und im Handbuch eher die Möglichkeiten ausgestellt werden, dass man virtuos alles mit allem verknüpfen kann?
Über einen sachdienlichen Hinweis wäre ich sehr dankbar.

[GLT]

Diese leg ich dann auf die Wippe 1 des Tasters 1 und auf den Schaltaktorkanal A.
Soweit so klar und funktional.

Das ist ohne sonstige Logikengine, also ohne EIBPC

Meckert die ETS nicht, wenn ich zwar nen Haufen Adressen anlege, die aber nicht mit mindestens zwei KO verbinde?

Warum sollte sie?

Mit meinem bisherigen Wissen von rein ETS basierten Projekten, müsste die Syntax so aussehen.

if ('1/0/1'b01==EIN) then write ('1/0/1'b01, EIN) endif

Denken wir mal darüber nach - wenn das Licht eingeschalten ist, dann schalte ein - ist das wirklich sinnig?

Ander rum - wenn Taster EIN anfordert, dann schalte das Licht ein - wäre das nicht besser?
Dafür brauchts aber 2 verschiedene GAs

[enertegus]

z.B. Wippe 1 Taster 1 mit GA 1/0/1
Wippe 2 Taster 1 mit GA 1/0/2
Aktorkanal A mit GA 1/1/1
jetzt wird im Handbuch erklärt um das Licht einzuschalten soll folgender Befehl gesetzt werden.
if ('1/0/1'b01==EIN) then write ('1/1/1'b01,EIN) endif

Im Handbuch wird eine "2-Kanal-Bedienung" mit dem EibPC realisiert, das können mittlerweile auch Raumkontroller, aber es geht da mehr um die zarte Hinführung zum Komplexeren.

Meckert die ETS nicht, wenn ich zwar nen Haufen Adressen anlege, die aber nicht mit mindestens zwei KO verbinde?

Nein.

Oder ist es gar so, was ich fast vermute, dass derlei einfache Aufgaben nix für den eibPC sind und er eher für komplexere Aufgaben
konzipiert ist und im Handbuch eher die Möglichkeiten ausgestellt werden, dass man virtuos alles mit allem verknüpfen kann?
Über einen sachdienlichen Hinweis wäre ich sehr dankbar.

Nun man kann komplexere oder einfachere Aufgaben damit erledigen. Nicht jeder Raumkontroller kann 2 Kanal Bedienung und das ist eine einfache Aufgabe aus der Praxis - tauglich auch fürs Einsteigerverständnis. Das Beispiel wird dann ja noch weiterentwickelt mit Flurlichtsteuerung etc.

[Uwe!]

jetzt wird im Handbuch erklärt um das Licht einzuschalten soll folgender Befehl gesetzt werden.
if ('1/0/1'b01==EIN) then write ('1/1/1'b01,EIN) endif

Die Logik hinter dem Befehl versteh ich, aber nicht warum die Kommunikationsobjekte unterschiedliche GA bekommen?

das ist ein sehr einfaches Beispiel für den Anfang, dass SO noch nicht viel Sinn macht, da das (wie Du ja selber angemerkt hast) auch ohne EibPC wunderbar funktionieren würde. Dann muss aber natürlich bei Taster uns Aktor die gleiche GA verwendet werden.

Das ist ja aber nur zum Einstieg. Stell Dir vor, Du willst das das Licht nur geschaltete wird, wenn nicht schon ein anderes Licht eh an ist. Dann könnte das so ausssehen:

if ('1/0/1'b01==EIN) and anderes_licht == AUS then write ('1/1/1'b01,EIN) endif

Und DAS geht ohne EibPC (oder ähnliches) nicht mehr.

[GLT]

Und DAS geht ohne EibPC (oder ähnliches) nicht mehr.

Du unterschätzt die Applikationen mancher Aktoren

[spassbird]

Ich danke für die Antworten.
Lag ich also doch nicht so falsch, dass es im Handbuch weniger darum geht einfachste Schaltvorgänge über den eibPC zu erklären,
sondern darum, den Einstieg zu Höherem zu finden.

Nur, wenn ich Verküpfungen und Logiken mit dem eibPC erstelle, macht das bloße schalten ja kaum mehr Sinn.
z.B. Wie das Beispiel im Handbuch, mit dem zeitabhängigen Schalten verschiedener Helligkeiten.
Wie hier bemerkt, geht das nur über Verknüpfungen von Bedingungen (oder vielleicht mittlerweile auch über einige Raumcontroller oder Aktoren).
Nur kann man sich bei diesen Dingen von der direkten Verwendung von GA's verabschieden.
Man muss wohl genau wissen, wie man es steuern will und entsprechend die Adresse als KO-GA begreifen.

Ich werd mich mal weiter dem Selbststudium widmen und Dauemn drücken, dass das 24V DC REG Netzteil endlich beim Großhändler eintrifft.
Das scheint ja so exklusiv zu sein, dass es als Sonderbestellung behandelt wird.

Danke nochmals für eure Antworten

[EPIX]

nur so als "Leitfaden"...

GRUNDfunktionen sollten möglichst "hardwarenahe" sein - also ohne Logiken dazwischen....
wenn der eibpc neu startet (und das dauert ab einer gewissen Projektgröße "gefühlt" eine Ewikeit) und das Licht im Gang geht nicht - dann sinkt der WAF nicht nur, er stürzt ins Bodenlose

[spassbird]

nur so als "Leitfaden"...

....... und das Licht im Gang geht nicht - dann sinkt der WAF nicht nur, er stürzt ins Bodenlose

hihi
mein WAF ist auf meiner Seite und gönnt mir meine "Spielereien", sie sagte auch auf der L&B nimm den Gutschein für den eibPC,
bevor wir später mehr zahlen.

Mein Schatz ich danke Dir

Werde dann wohl für die "Grundfunktionen" sorgen.

[Uwe!]

Du unterschätzt die Applikationen mancher Aktoren

Nö! Ganz und gar nicht. "Ähnliches" = Logik. Das viele Schaltaktoren UND- und ODER-Gatter mit drin haben, ist bekannt.

[evolution]

nur so als "Leitfaden"...

GRUNDfunktionen sollten möglichst "hardwarenahe" sein - also ohne Logiken dazwischen....

Das entspricht zu 100% meiner Meinung!