Logik für eine Ein/Aus Sequenz - und Diskussion zu Sinn und Nutzen von Objekten

[ELehmann]

Hallo Zusammen,

ich habe ein Problem, ich möchte mittels Logikengine folgende einfache Sequenz für mein Automatisches Dachfenster in der Dusche programmieren. Komme aber nicht weiter...

Mit einem Knopfdruck soll das Dachfenster aufgehen (KNX MDT GlasSchalter2 schickt Wert an KNX UP Schaltaktor der löst Schaltimpuls auf RotoFenstersteuerung) und 45min später wieder schliessen. Während der Zeit soll ein LED am Glastaster blau leuchten umzuzeigen dass diese Sequenzlogik aktiv ist. Ich habe noch einen 1-Wire Fenster-Öffnungskontakt verbaut.

Welchen LogikBaustein nehme ich für die 45min Sequenz?

Meine Idee war bisher. Ich öffne das Fenster normal/klassisch via Taster an die entspr. KNX GA und starte damit zusätzlich eine Timer3-Logik mit fixen Zeitparameter. Brauche dann aber 2 Ausgänge - einen für das LED (Timer Läuft) und später für das Signal Fenster-zu.

Nur wie genau mache ich das und brauche ich mehrere Logiken bzw was passiert wenn das Fenster zwischendurch händisch/direkt (per KNX) geschlossen wird?

Könnt ihr mich auf den richtigen Weg bringen. Bisher habe ich in LE ein paar einfache und Verknüpfungen erstellt.

Vielen Dank

PS: Zusätzlich kurze Sicherheitsfrage zu meinem Vertändnis - Es können nur KNX Universal Objekte in der LE verwendet werden, die in der ETS für den Timberwolf erstellt wurden, richtig. Andere KNX Objekte können nicht direkt genutzt / integriert werden.

[blaubaerli]

Hallo @ELehmann,

sorry, habe gerade fälschlicherweise auf den "Bedanken"-Button geklickt, hätte der Zitat-Button sein sollen, also nicht wundern.

Zu deiner Logikfrage bin ich noch nicht wirklich fitt genug um sicher zu beraten. Dazu brauche ich noch was mehr an Erfahrung.

Aber zu dem Teil hier:

PS: Zusätzlich kurze Sicherheitsfrage zu meinem Vertändnis - Es können nur KNX Universal Objekte in der LE verwendet werden, die in der ETS für den Timberwolf erstellt wurden, richtig. Andere KNX Objekte können nicht direkt genutzt / integriert werden.

Das hast du korrekt erkannt, du kannst nur die KNX-Objekte im LE nutzen, die du via ETS für den TWS auch explizit freigeschaltet hast. Also freischalten, GA's zuordnen und dann kannst du die KNX-Objektnummer im LE nutzen. Viel Erfolg beim Experementieren.

Beste Grüße
Jens

[StefanW]

Danke Jens.

...du kannst nur die KNX-Objekte im LE nutzen, die du via ETS für den TWS auch explizit freigeschaltet hast.

Richtig.

Nur um das noch hinzuzufügen, weil es offenbar nicht auf den erste Blick klar ist, warum das so ist:

1. Der Timberwolf Server ist ein KNX zertifiziertes Produkt.
2. Die technischen Regeln im KNX schreiben vor, dass alle Objekte, die von einem KNX Device genutzt werden, mit einer Verwaltungssoftware anzulegen und mit den GAs zu verknüpfen sind, hier die ETS, da als einzige verfügbar.
3. Nur damit bekommt letztlich die Ordnung und Wiederprogrammierbarkeit von KNX mit einem einzigen Tool hin, wofür sich KNX auch so besonders auszeichnet.
4. Es ist die besondere Stärke von KNX, das gut 8000 Produkte von 400 Herstellern sich mit nur einer Software managen lassen, die es nun auch schon über 20 Jahre gibt und die stetig verbessert wird. Das ist - auch wenn einzelne Versionen sehr kritische Fehler hatten - ein sehr gutes Konzept, in dem sich nun auch der Timberwolf Server einordnet.
5. Wer sehr viele Objekte hat, die er im Timberwolf Server freischalten will, kann sich die Definitionen auch in Excel oder ähnlichem bauen, daraus eine CSV-Datei schreiben und diese dann über die ETS-APP "Timberwolf Importer" anlegen lassen. Dann nur noch Programmieren, das Projektfile einlesen und fertig (wobei das Einlesen des Projektfiles dient nur dazu, die Informationen daraus herauszuziehen, die der Server bei der Programmierung nicht bekommt, also insbesondere die ganzen Bezeichnungen von Geräten, Haupt- und Mittelgruppen, DPT usw auch der "fremden" GAs für eine bestmögliche Anzeige. Es gibt eine Anleitung und Berichte hier im Forum über den Nutzen des "Timberwolf Importers" für das Anlegen von vielen Objekten.

lg

Stefan

[ELehmann]

Jens / Stefan

Vielen Dank für die Erklärung. Letztlich bedeutet es aber das Logiken für nicht Timberwolf KNX Elemente immer einen Umweg über zusätzlich für den TWS definierte Objekte gehen müssen. Das ist unpraktisch in meinem einfachen Beispiel oben bedeutet das 3 weitere KNX Objekte plus Kommunikation ... Nehme mit das kann man auch nicht ändern, wg der Anforderung zur Programmierbarkeit via ETS. Na gut ... die Importer App habe ich im Einsatz.

Hat jemand einen Vorschlag für die beschriebene Logikanfrage /Sequenz:

Einschalten /Fenster öffnen
45 min warten & Status senden
Ausschalten /Fenster schließen

Alles mit einem Knopfdruck ausgelöst? Wie kann ich das in der LE darstellen?

Vielen Dank für jeglichen Denkanstoß (bin gestern abermals gescheitert)

Gruß Erik

[S. Kolbinger]

Hi Erik,

Vielen Dank für jeglichen Denkanstoß (bin gestern abermals gescheitert)

damit sollte es funktionieren:

[StefanW]

Hallo Erik,

Vielen Dank für die Erklärung. Letztlich bedeutet es aber das Logiken für nicht Timberwolf KNX Elemente immer einen Umweg über zusätzlich für den TWS definierte Objekte gehen müssen.

Ich darf hier nochmal darauf hinweisen, dass dies für ALLE offiziellen KNX-Logik-Server gilt, also z.B. auch für die kaufbaren Logikmodule auf Hutschiene.

Alle anderen Logiken, die nur auf der Ebene GAs arbeiten, mögen schneller definiert sein, aber werden in Verbindung mit mehreren Linien bei größerem Datenverkehr schnell zu einem Problem. Weil da die ETS in diesen Fällen nicht mehr weiß, welches Gerät nun welche Infos bekommen soll (also dessen Objekte mit GAs verknüpft sind) kann die ETS auch keine Filtertabellen berechnen. Daher muss man / frau dann seine LK / BK / IP-Router auf vollen Durchzug schalten, damit alle GAs auch überall hingesendet werden. Das kann schnell zu Durchsatzproblemen führen.

U.a. deshalb gibt es ja diesen Zwang in der ETS, den Objekten die GAs zuzuordnen. Zum einen damit das Gerät weiß, welche Telegramme es in den Stack hochreichen soll und zweitens, damit die ETS auf Basis der Topologieinformationen die Filtertabellen für Linienkoppler / Bereichskoppler und Router berechnen kann, weil sonst die Linien mit ihren 35 Telegrammen pro Sekunde schnell überfahren werden, wenn alles und jedes gebroadcastet werden muss.

Ansich ist es also höchst sinnhaft, wenn man in der ETS die Objekte und die GAs verbindet. Bei den "normalen" Devices muss man das ohnehin tun und beim voll zum Standard kompatiblen Timberwolf Server eben auch. Es bedeutet auch mehr Ordnung und Klarheit, weil man dann in EINEM Tool sehen kann, wer eigentlich wo was wie auf den Bus schreibt. Mit den nicht zertifizierten, nur auf GA basierten Systemen sieht man das nicht mehr so klar.

Ich bitte daher diese klare und damit auch gut dokumentierte Verfahrensweise nicht als "Umweg" zu sehen, sondern als den einzig richtigen Weg für eine saubere Konfiguration. Ja, das kostet mehr Zeit, tut ordentliche IT immer.

Das ist unpraktisch in meinem einfachen Beispiel oben bedeutet das 3 weitere KNX Objekte plus Kommunikation ...

Bitte was ist mit Kommunikation gemeint? Nur weil eine GA mit mehreren Objekten mehrerer Geräte verbunden ist, wird das Telegram nur einmal gesendet, weil KNX ist immer ein (optimalerweise gefilterter) Broadcast. Also ein mehr ein Kommunikation gibt es deshalb nicht. Nur die Objekte muss man halt anlegen und verbinden. Es ist übrigens nicht immer erforderlich, auch das Projekt im TWS einzulesen. Programmieren genügt.

Vielleicht stimmt Dich auch unser Service, mit fertig vorgeschlagenen Logik-Konfigurationen passend zu Deiner Anfrage wieder positiv. Weil das gibt es in dieser Intensität und Reaktionsgeschwindigkeit von keinem anderen Hersteller.

lg

Stefan

[Robert_Mini]

Ein paar Kommentare nach längerer Nutzung.

Ja am Anfang erscheint dies als Umweg, wenngleich der sauere Weg wie Stefan beschreibt.
Das hat aber eben Vorteile (wie oben beschrieben mit LKs, größeren Anlagen etc.), aber da gibt es noch mehr!
Der TWS antwortet sauber mit ack und viel wichtiger, kann bei gesetzten Lesen-Flag auch auf ein Lesen-Diagramm (zB bei Starten der Visu) antworten.

Gerade bei Werten, die in der Logik erzeugt werden, ist das praktisch, da eben auch der Status vom KNX Stack gelesen werden kann.

Zum Handling: Ich habe mir angewohnt, neben den bestehenden GA (die ich absehbar brauche) auch ein paar Reserve GA's mit den wichtigsten DPT (1,5,9) anzulegen und mit Objekten zu verknüpfen.
So kann ich jederzeit diese Objekte nützen, ohne ETS Programmierung und Import - einziger Nachteil, die Texte werden am TWS vorerst falsch angezeigt.
Spätestens mit dem nächsten Import (auch ohne Neuprogrammierung des TWS) kann ich die aktualisierten Bezeichnungen auch sehen. Ich habe aber auch schön strukturierte Objektnummern aufgegeben (wozu? die Suche am TWS liefert ja schnell das Objekt, die Objektnummer merkt sich eh keiner). Einzige ein paar grobe Bereiche: 1-wire: 1-200, Technik (HKL) 201-400, Technik im Garten 401-500...

So kann ich die Vorteile der sauberen KNX Objekte und die "Nachteile" des Mehraufwandes leicht verkraften.

lg
Robert

[StefanW]

Hallo Robert,

danke, ich denke dass man diese Best Practises in der KB unterbringen sollte und auch das Wie und Warum, weil nicht jedem ist das alles immer klar und wir wollen ja auch insbesondere den frisch Smarthome-Interessierten die Hürden kleiner machen...

Stefan

[gbglace]

Kleine Ergänzung zum Thema, gerade User mit mehreren Linien in der Anlage suchen wg EDOMI und Co auch immer nach Dummy-Applikationen im KNX-UF um eben eine saubere definierte Kommunikation im Gruppenmonitor der ETS zu haben, denen fehlt halt ne ordentliche Simulationsmöglichkeit. Das denen aber immernoch AcK fehlen und so mit auch nur an die Visu gesendete GA unnötig Traffic durch Wiederholung erzeugen wird da auch schnell ausgeblendet.

Die Frage war gut und genau wie Robert, am Anfang fand ich es auch ein wenig zu umständlich aber mit der konsequenten Nutzung erkennt man dann auch die Vorteile.

[gurumeditation]

An alle, die sich über den "Umweg", neue KNX-Objekte anlegen zu müssen, ärgern:

Seid froh, dass ihr diese Objekte anlegen dürft!
Auch andere "herkömmliche" KNX-Geräte wie Taster, PM oder Logikmodule müssen diese Objekte anlegen. Dies geschieht bei variablen Objekten in der Regel über die Applikation (Parameter), z.B. ob ein PM sein Objekt "Präsenz" auf den Bus senden soll oder nicht. Standardmäßig deaktiviert muss dieses Objekt in der Applikation freigeschaltet werden.

Die Unterschiede zwischen diesen "herkömmlichen" KNX-Geräten und dem TWS sind:

• Die schiere Anzahl der möglichen Objekte
• Die Freiheit, die Funktion / Verarbeitung hinter den Objekten festzulegen
• Die Freiheit, Datentypen frei zu wählen

Von daher würde ich sagen, dass diese Freiheit ein sehr großer Vorteil und kein Nachteil ist!

Und was saubere Parametrierung / Dokumentation angeht:
Als ehemaliger IT-Qualitätsmanager ist meine Meinung dazu, dass Qualität nichts kostet, sondern im Gegenteil Kosten senkt. Natürlich habe ich zunächst zusätzlichen Aufwand, der durch Pfusch oder Schlamperei (Chaos im Design, fehlende Dokumentation) vermeintlich eingespart werden kann. Meist fällt einem dies eher früher als später auf die Füße und man braucht ein vielfaches der "gesparten" Zeit für die Rekonstruktion.