KNX/EIB MDT Schaltaktor logische Verknüpfung erstellen

[Knaller52]

Hallo liebe Experten. Ich bin ein KNX Neuling und habe leider nur wissen über Logiken bei eine SPS.
Dachte mir das es sicher leit sein könnte mit einem KNX Schaltaktor 4 Ausgänge Einer Wetterstation Sutracer bei einer Bestimmen Zeit und nur oberhalb von einer Temperatur einen Ausgang zu schalten.... Hoffe mir kann jemand weiter helfen. Bin auch neu in diesem Forum. Vielleicht kann mir jemand sagen wo ich logikbeispiele finde. l.g.

[GLT]

Logik wäre eine UND-Verknüpfung (kann man im Aktor z.B. machen); Temperatur wäre der Schwellwert in der Suntrace u. für Zeit brauchst du halt eine Zeitschaltuhr.

[knxPaul]

Herzlich Willkommen im Forum!
Die Logiken bei einer SPS sind standardisiert, das Wissen von einer SPS funktioniert recht gut auch auf einer anderen SPS.

Nicht so bei KNX Logik Komponenten. Jedes Gerät ist anders. Nur: Logik läuft nicht über Schaltaktoren, die man sich als Leistungsschalter vorstellen muss. Als erstes schaut man das technische Handbuch der Wetterstation an, wie dort die gewünschte logische Verknüpfung erstellt werden kann. Um welchen Typ geht es?
Die Suntracer KNX sl basic von Elsner hat 'UND' sowie 'ODER' Elemente und einen Vergleicher für die Temperatur. Die Zeitschaltuhr fehlt, so dass dafür ein anderes Gerät benötigt wird.
Die Verbindung zwischen mehreren KOs von Temperaturvergleich und Zeitschaltuhr zum 'UND' erfolgt mit GAs wie es bei KNX gängig ist.

[Knaller52]

Hallo und danke für die Antworten. Der Begriff KOs oder GAs sind mir leider nicht bekannt. Denke GAs heisst gruppenadressen. Dachte bei dem Suntracer Aktor gibt es ja eine Wochenzeitschaltuhr. Dort habe ich 2 Zeiten parametriert . Dachte diese lege ich in eine Gruppe Ein oder Ausschalten. Dann habe ich noch einen Temperaturgrenzwert parametriert und diesn in die Freigabe Gruppe Kannal A gelegt. Mein Schalaktor hat auch eine Logikfunktion wo ich dann das und Ausgewählt habe. Diese Logik 1 habe ich dann auch in die Gruppe Freigabe Kannal A gelegt. Leider funktioniert das noch immer nicht. Was habe ich da nur vergessen??

[Knaller52]

Ach ja den Schaltkannal A von Schaltaktor habe ich natürlich auch in die Gruppe ein oder Ausschalten gelegt.

[knxPaul]

GA heisst gruppenadresse, stimmt.

Der Begriff KO

ist ebenso wichtig: KO = KommunikationsObjekt

Was habe ich da nur vergessen??

Schwer zu sagen, alles scheint vernünftig.
Gibt es einen Schalter in der Gruppe "ein oder Ausschalten" ?

Nun kommt ein mächtiges Werkzeug ins Spiel: In der ETS gibt es den Gruppenmonitor; damit können Telegramme auf dem KNX-Bus beobachtet und gesendet werden. Damit kann man seine Logik "debuggen". Es gibt sogar youtube Videos zur Bedienung des Gruppenmonitors.

[Gast1961]

Zeig doch mal ein paar Screenshots, dort sieht man besser was du versucht hast.

[gbglace]

Hier braucht es eher Grundlagen der Buskommunikation zum Verständnis.

Im KNX geht alles über Datentelegramme. Die Datentelegramme haben soweit zwei wesentliche Informationen, die GA und den Wert an sich (Messwert oder binär 0/1). Alle Funktionstelegramme sind quasi Multicast auf dem Bus, kommen also prinzipiell an allen Geräten an.

Sender und Empfänger von Telegrammen sind die KO. Welche Rollen ein KO einnimmt bestimmen die Flags die man daran festlegen kann (das aber für den Einstieg zu viel Information).

Will man eine Informationsverbindung für eine Funktion herstellen dann verbindet man eine GA mit mindestens zwei KO.
Sollen mehrere Geräte die gleiche Funktion erfüllen dann wird diese GA eben noch an weitere KO verbunden.
Was grundsätzlich nicht geht wäre in diesem Gedanken, für jeden Aktorkanal eine GA als AN/AUS Funktion zu definieren und dem einen Lichtschalter alle diese GA am KO zu verbinden, um sie gemeinsam AN/AUS zu schalten. Ein KO kann immer nur Telegramme mit einer GA als Inhalt senden, kann aber auf viele GA reagieren.

Also zurück zum generischen Ansatz. Die Definition auf was ein Gerät / KO reagieren soll definiert sich dadurch welche GA da dran verbunden sind. Geräte haben meist verschiedenste KO, da an einem KO immer nur Daten zu einem Datentyp verarbeitet werden können. Also ein 1Bit 0/1, ist was anderes als 1Byte gespeicherte Temperaturmesswert. Durch diese klare Definition ist eine Datentypangabe im Telegramm selbst nicht erforderlich. Die Datentypen sind in der ETS am KO und der GA definiert.

Zu Deinem Projekt:

Du benötigst also die Information Helligkeit, und daraus abgeleitet unter/über Schwellwert ja/nein. Wetterstationen bieten meist beides den reinen Messwert aber meist auch intern Schwellwertauswertungslogiken und dann ein KO für Output binäres 0/1. Das binäre 0/1 wird via einem KO mit einer GA auf den Bus gesendet. Will man für mehrere Zwecke unterschiedliche Schwellwerte haben, dann muss man meist die Helligkeiten senden und dann an anderer Stelle die Schwellwerte auswerten da meist nur ein Schwellwertobjekt an der Wetterstation existiert (Tag/Nacht).

Wenn die Wetterstation noch eine Zeitschaltuhr besitzt, dann halt dort Zeitfenster definieren, sodass da am Ende auch ein 0/1 per einem KO mit einer GA auf den Bus gesendet wird.

Beide Telegramme gehen in einen Logikbaustein (zwei Eingangs-KO an den je eine der beiden GA verbunden wird), der hier ein UND zur Verfügung stellt und das Ergebnis dann per KO mit einer dritten GA ausgibt. Und jene GA ist dann letztendlich an einen Aktor verbunden, damit der das Licht schaltet.

Je nachdem ob man sehr viele unterschiedliche Helligkeitsschwellen in Seinem Projekt nutzt kann man schauen ob denn ggf. auch ein Aktor den Helligkeitswert selbst gegen einen Schwellwert vergleichen kann (MDT und ABB können das wohl). Und einige Aktoren bieten dann auch das passende UND-Logikgatter. Offensichtlich kann auch die Wetterstation ein solches UND. Hier wäre dann in der Applikation zu sehen das man die beiden 0/1 intern da rein bekommt ohne das erst auf den Bus zusenden. Dann käme einzig und allein der direkte Schaltbefehl als Telegramm aus die Wetterstation auf den Bus. Das hinzubasteln bedarf aber wohl das Studium der ETS-Applikationsbeschreibung. Und hier mal die Versuche Die du schon gemacht hast, wie Volker meinte in Form von Screenshots.


Insgesamt gilt im KNX, wo die einzelnen Stufen der Informationsverarbeitung stattfinden ist recht flexibel im KNX, da jedes Gerät eine gewisse Intelligenz mitbringt. Das Zusammenspiel macht es interessant. Manch einer macht es auch eher SPS-typisch sehr zentral in Logikengine und lässt sich einfach nur Sensorwerte usw. senden und generiert daraus die Schaltbefehle und sendet die an die Aktoren.

[Knaller52]

So habe heute wieder einmal versucht meine Probleme zu lösen bezüglich Logik und ETS. Schaltaktor 4 Ausgänge für die Ansteuerung des Lüfters.pdf
Leider ohne Erfol.

Habe jetzt mal sceenshots gemacht vielleicht fällt jemenden etwas auf.

[knxPaul]

Super ausführlich. Was ich erkenne:

• Die Telegramme der Zeitschaltuhr werden auf die GA = 16/0/0 gesendet.
• Das Ergegebnis des Temperaturvergleichs wird auf die GA = 16/1/0 gesendet.
• Die GA = 16/0/0 ist mit dem Schalteingang des Aktors verbunden
• die GA = 16/1/0 ist mit dem Logikeingang des Aktors verbunden.
• Logik ist UND von Schaltobjekt und Logikobjekt.

Ich hätte es nicht anders gemacht.

Zur Analyse ist der Gruppenmonitor in der ETS sehr hilfreich:

1. Gruppenmonitor Starten
2. Die Uhrzeit der Wetterstation auf eine passende GA senden lassen & beobachten
3. GA = 16/0/0 'Lesen'
4. GA = 16/0/1 'Lesen'
5. Wert '1' nacheinander auf beide GAs 'Schreiben'
6. Nun muss der Aktor schalten; gegebenenfalls mit einer neuen GA am KO-7 "Kanal A Status" beobachten

[gbglace]

Was bringt es eigentlich immer diese Screenshots so extrem minimal zu machen das man immer erst ewig suchen muss von welchen Geräten ist das wieder so ein Schnipsel?

Wie sind denn die Einstellungen der UND Logik, gab es schonmal Telegramme auf beiden Eingangs-GA? Manch eine Logik arbeitet erst richtig wenn beide GA quasi initialisiert sind. Und wenn man die Schaltzeiten der ZSU sieht gibt es da ja kaum Änderungen, da die nur um 22 Uhr, um 0 Uhr, um 1Uhr und um 5 Uhr eine Aktion macht. Da wird halt die 16/0/0 kaum bedient. Mit der Einschränkung der Logik auf nicht initialisierte Eingänge bleibt es am Aktor halt dunkel.

[Knaller52]

Entschuldige die Schnipsel. Dachte mir das es so einfacher ist als wenn ich immer den ganzen Bildschirm screene.

Was meist du "Mit der Einschränkung der Logik auf nicht initialisierte Eingänge"?

Das Heist das wenn ich den bei dem Schaltaktor das Applikationsprogramm lade er nicht den Status der Uhr und der Temperatur sich mal holt??

[knxPaul]

Das Heist das wenn ich den bei dem Schaltaktor das Applikationsprogramm lade er nicht den Status der Uhr und der Temperatur sich mal holt?

ja, genau so ist es. Der Aktor bleibt passiv und holt nichts. Stell Dir vor, Du programmierst das erste Mal das komplette Projekt und gleich das erste Device fängt an, sich Daten aktiv zu holen

Daher - mach es anders herum:

• Wenn im laufenden System der Aktor neu programmiert wurde, im Gruppenmonitor alle GAs nacheinander lesen, die mit Eingängen vom Aktor verbunden sind. Dann kennt der Aktor alle alten Zustände, seine Eingänge sind initialisiert. Das ist Handarbeit.

[Gast1961]

Das Heist das wenn ich den bei dem Schaltaktor das Applikationsprogramm lade er nicht den Status der Uhr und der Temperatur sich mal holt??

Normalerweise nicht, es hängt vom Gerät ab.

Bei manchen Geräten kann man eine solche "aktive" Abfrage einstellen, bei manchen Geräten gibt es einen wählbaren Initialwert, und wieder andere Geräte warten bis ein gültiger Wert von Bus kommt. Das ist wirklich unterschiedlich.

[Beleuchtfix]

Auch ein nicht vorhandener Wert an einem Oder Eingang kann den Ausgang blockieren, auch wenn ein True an einem anderen Eingang eigentlich reichen würde.
Viel Erfolg
Florian