Ein Sensorausgang - mehrere Funktionen - Das "Sendend" Problem

[motzer]

Er hat zwei Funktionen, die auf ein Ereignis reagieren. Er hat Funktion = GA gedacht, also zwei GAs angelegt. Hätte er GA = Ereignis gedacht, hätte er richtigerweise eine GA angelegt und mit beiden Funktionen verknüpft.

Exakt das trifft es. Ich gehe auch vom Aktor aus.

Das es es nur eine sendende Adresse gibt macht es bei dem Ansatz hinten raus dann eben nicht mehr so logisch. Aber ich hab es jetzt drin und werde bei Problemfällen jetzt sicher schneller meine Fehler finden =)

Btw: alleine das der Hersteller beim PM die Ausgänge schon Lichtkanal nennt, lässt schnell eine Assoziation zu Licht zu...

...sehe es jetzt aber auch eher generisch.

[mumpf]

Hi,

ich weiß jetzt nicht, welchen Hersteller Du hast. Dass der Hersteller seine Kanäle mit Semantik belegt, kann schon Sinn manchen. Meistens will er es dem User/Kunden leichter machen. Wenn die Kanäle unterschiedlich heißen, dann sind sie häufig auch nicht gleichwertig in ihrer Funktion. Es gibt durchaus auch PM mit mehreren gleichwertigen Kanälen.

Ein Lichtkanal ist normalerweise nicht nur präsenz- sonder auch helligkeitsabhängig. Ein HLK-Kanal häufig nur präsenzabhängig und unterstützt mehrere Erfassungsfenster. Ein Präsenzkanal reagiert nur auf die Präsenz. Und so weiter...

Gruß, Waldemar

[motzer]

Hi mumpf,

hab hier fast nur mdt verbaut. Und ja der PM hat verschiedene Kanäle für Licht HLK Alarm. Da dies meine ersten Erfahrungen mit irgendeinem Präsenzmelder sind, hatte ich gar nicht auf dem Schirm, dass der Sensor hier für mich schon so viel bereitstellt. Macht aber schon alles Sinn.

Für mich ist es nachvollziehbar, dass ein Sensor nur eine Gruppenadresse triggern kann, um die Buslast gering zu halten. Jedoch bindet man den Sensor an Funktionen und diese können eben sehr unterschiedlich sein. Und da ich immer aus Aktorsicht gedacht habe, bekommt man eben schnell einen Knoten im Kopf und es erscheint chaotisch.
Aber wenn ich jetzt aus Sensorsicht denke wird das schon alles werden.

Danke für Euren Input.

Gruß,
motzer

[gbglace]

Naja wenn man ohne großartige Logiken auskommt, ist man mit dem Gedanken an Funktionen und die entsprechende Ausrichtung der GAs schon sehr gut bedient und bekommt eine fertige Installation ohne 24/7 Logik.
Setzt man voll auf ein solches zentrales Gehirn, ist es sehr intuitiv voll auf die Sensorlogik zu setzten und zusätzlich aktororientierte GA zu haben. Denn die Verknüpfung der unterschiedlichsten Senorsignale zu bedingten Funktionen passiert in der Logik, mit der man am Ausgang meist auch direkt unterschiedlichste Aktionen antriggern kann, also auch mehrere Ausgangs KO und GA gleichzeitig bedienen. Das ist dann zwar nicht mehr ganz im Sinne des Ursprungs von KNX aber je mehr zentrale Logik um so eher kommt man da hin.

[autopool]

Hallo Forum
hoffe dass ich hier richtig bin mit meinem Problem- stelle heute zum ersten Mal eine Frage
ich habe einen Fensterkontakt zum aufschalten der BA Frostüberwachung mit dem entsprechenden KO des Heizungsaktors in einer hierfür angelegten GA verheiratet
Wie geht man vor wenn ich nun den Fensterkontakt auch an anderen Stellen verwenden möchte, vielleicht für eine Alarmanlage oder einfach zum visualisieren?
Gesendet wird ja nur die zuerst angelegte GA.
Hätte aber gerne eine separate GA in welcher der Fensterkontakt hinterlegt werden kann
Habe viel über Zentrallfunktionen und hörende Adressen gefunden, werde aber daraus nicht so richtig schlau. Darf ich immer nur mit der zuerst vergebenen Adresse arbeiten um weitere Aktionen zu starten oder gibt es eine andere Möglichkeit ?
Vorab vielen Dank für eure Hilfe

[gbglace]

Lege eine GA an und nenne sie "Fenster XY offen" und verbinde diese mit den KOs die diese Sensorinformation benötigen.
Wenn man alle GA streng nach den Aktoren ausrichtet dann hat man schon mal das Problem das man einzelne Sensorzustände mehrfach verwenden möchte aber eben ohne Vervielfältigungsinstanz nicht kann. Zustandsevents von Sensoren hingegen kann man, solange der DPT zum Ziel passt, so oft verwenden wie man will. Man muss eine GA nicht als Funktion begreifen.

Der Frostschutz kann ja auch aus anderen Events entstehen, in der ETS ist es dann schon ausreichend transparent wenn das KO am Aktor dann mit mehreren GA entsprechend verknüpft ist.

[autopool]

Danke für die schnelle Antwort
Als ich die Frage gerade eingestellt hatte bin ich auf das Zitat von mmutz gestossen

Zitat:
Er hat zwei Funktionen, die auf ein Ereignis reagieren. Er hat Funktion = GA gedacht, also zwei GAs angelegt. Hätte er GA = Ereignis gedacht, hätte er richtigerweise eine GA angelegt und mit beiden Funktionen verknüpft.

Das trifft es und Du unterstreichst es mit Deiner Antwort
... und ich habe es nun endlich verstanden...
Danke