[Gelöst] Bekomme Logik zum "Übersteuern" einer Automatik nicht hin

[Dragonos2000]

Ich versuche schon seit geraumer Zeit eine Custom-Logik im TWS zu bauen, die ich über KNX-Logikmodule schon länger implementiert habe. Ich krieg's aber auf dem TWS nicht hin. Entweder hab' ich "nen Knoten im Hirn", weil ich zu sehr an der Implementierung via nativer KNX-Logik klebe und das Umdenken nicht schaffe, oder es geht tatsächlich nicht:

Was ich vereinfacht gesagt möchte ist, eine Automatik übersteuern, bis der Wert der Automatik dem Wert der manuellen Übersteuerung gleicht. Ab da soll wieder die Automatik greifen. Und das ein einem einzelnen Custom-Logikbaustein. Klingt einfach, aber...

So, nun ein konkretes Beispiel (hab' aber auch noch andere Anwendungsfälle):
Die Wetterstation sendet Tag/Nacht zyklisch alle paar Minuten (Bool, also True/False). Per Taster möchte ich das toggeln, also auf "Tag" (True) umschalten, obwohl die Wetterstation noch "Nacht" (False) zyklisch sendet. Sobald die Wetterstation ebenfalls auf "Tag" umgeschaltet hat, sollen deren Telegramme wieder "führend" sein. Das Ganze soll dann natürlich ebenso funktionien, wenn ich manuell auf "Nacht" umschalte, obwohl die Wetterstation noch "Tag" sendet.

Auf nativer KNX-Logik habe ich das mit Telegrammfiltern und Toren und deren Sperren gelöst. Beides habe ich auf dem TWS nicht zur Verfügung. Ob es ein echtes Tor auf dem TWS innerhalb von Custom Logiken geben kann bezweifle ich zudem (kann es mir konzeptionell gerade wirklich nicht vorstellen).

Hat da jemand eine Idee...?

[StefanW]

Hallo Jochen,

magst Du das mit den TORen etwas erläutern, bei uns ist das nicht so ein Begriff.

Merci

Stefan

[Dragonos2000]

@StefanW Klar doch!
In den KNX nativen Logikbausteinen gibt es meistens eine Funktion "Tor" mit folgenden Eigenschaften (je nach Hersteller auch "Multiplexer" oder "Trennwand" bezeichnet):
Kommunikationsobjekte:

• Dateneingang
• Datenausgang
• optional: Steuereingang
• Sperre

Du legst beim Tor die Datenflussrichtung fest (Eingang zu Ausgang oder Umgekehrt oder Bidirektional), der Datentyp kann festgelegt werden. Manche Hersteller versehen das auch mit einem binären Steuereingang, bei dem Du je nach Wert des Steuereingangs die Datenflussrichtung festlegen kannst.
Bei der Sperre ist das "Tor zu", d.h. es werden keine Daten weitergeleitet.

Ein wesentlicher Punkt beim Tor (so wie ich es kenne) ist, dass bei Freigabe oder Umschaltung kein voriger Eingangswert irgendwie wiederholt oder gesendet wird (wobei ich mir das per Steuereingang auch schon manchmal gewünscht habe). Es wird also lediglich für neue Telegramme auf Durchzug geschaltet oder eben gesperrt. Dazu gibt es die Möglichkeit bestimmte Telegramme zu filtern (also bspw. nur "True" durchzulassen).

[Robosoc]

Moin Jochen, hatte schon in deinem ersten Nachricht gedacht, dass das nach einem Binarmultiplexer klingt... Und dann hast Du es ja sogar selber noch geschrieben... Ausführlich kann ich erst später oder morgen antworten... Aber die Lösung ist meiner Meinung nach die Eingänge über einen Binarmultiplexer einzusammeln und dann danach mit einem Multiplexern oder schwellwertschwltern jeweils eine eine Reaktion folgen zu lassen. Aber genau hier kann es, wenn du mehrere Folgen hast schwierig werden mit nur einer Logik. Dafur ist fehlt sowas wie Goto oder ein Einkapseln von mehreren Zeilen, die nur bei einer Bedingung ausgeführt werden. Habe ich mir vor einigen Tagen schon mal gewünscht

Brauchst du noch weitere Hinweise später oder morgen oder reicht der Verweis auf den binärmultiplexer schon?

[Robosoc]

Aber denke ruhig mal drüber nach, ob es nicht doch sinnvoll ist die Folgen (mit schwellwert oder multiplexer im Eingang ) in eigenen logikbausteinen zu machen. Wenn du denen dann allen ein gleiches Tag gibst wird es richtig übersichtlich und sehr flexibel für spätere ausbauten... Das ist das eigentlich Konzept der TWS Logik... Denke ich immer mehr.

Und dann hast du eventuell nicht mal custom logiken im Einsatz.

[Dragonos2000]

Hi Sven@Robosoc ,

danke für den Hinweis. Auf Multiplexern und Latches hab' ich schon einige Stunden rumgedacht, ein funktionierender Baustein wollte daraus aber nicht entstehen. Ich glaube ich hänge gedanklich einfach zu sehr in der nativen KNX Welt fest. Mal mit ner Flasche Wein probieren (erase brain) und nochmal dransetzen

[Matze76]

Hallo Jochen,

Was ich vereinfacht gesagt möchte ist, eine Automatik übersteuern, bis der Wert der Automatik dem Wert der manuellen Übersteuerung gleicht. Ab da soll wieder die Automatik greifen.

Hmm, heißt das denn aber nicht, dass die manuelle (Über-)steuerung für sich alleine schon reichen würde? Bei Abweichung wird der manuelle Wert gesendet, bei Gleichheit der Wert der Automatik, der dann ja auch wieder dem manuellen Wert entspricht. Es wird also in jedem Fall der manuelle Wert gesendet

Lösen könnte man das so wie unten dargestellt - aber wie gesagt ist es im Endeffekt immer der manuelle Wert, der durchgereicht wird. Mit einem "A" (Always) auf dem Wetterstations-Eingang hätte man zumindest das Senden im Zyklus der Wetterstation.

Code: Alles auswählen

{
  "Level": [
    [
      "$In1_",
      "bool",
      false
    ],
    [
      "$In2_",
      "bool",
      false
    ],
    [
      "$InStat",
      "int",
      0
    ],
    [
      "$Out",
      "bool",
      false
    ],
    [
      "$OutTrue",
      "bool",
      true
    ],
    [
      "$OutFalse",
      "bool",
      false
    ],
    [
      "$VAR<Inhibit?>",
      "bool",
      false
    ]
  ],
  "Input": [
    [
      "Wetterstation",
      "Tag=1, Nacht=0",
      "$In1_",
      "c"
    ],
    [
      "Manuell",
      "Tag=1, Nacht=0",
      "$In2_",
      "c"
    ]
  ],
  "Module": [
    [
      "Break",
      [
        "$VAR<Inhibit?>"
      ]
    ],
    [
      "BinaryMultiplexer",
      [
        "$In1_",
        "$In2_"
      ],
      "$InStat"
    ],
    [
      "Multiplexer",
      [
        "$OutFalse",
        "$OutFalse",
        "$OutTrue",
        "$OutTrue"
      ],
      "$Out",
      "$InStat"
    ]
  ],
  "Output": [
    [
      "Tag/Nacht",
      "1=Tag,0=Nacht",
      "$Out",
      "c"
    ]
  ]
}

Gruß
Matthias

[Dragonos2000]

@Matze76 Danke für das Beispiel. Problem hier ist, dass "Manuell" immer Vorrang hat. Sobald die Automatik aber wieder den gleichen Wert annimmt, soll Automatik wieder Vorrang haben.
Beispiel:
Automatik sendet False (Nacht)
Manuell sende ich True (Tag), dann sendet der Ausgang auch True (Tag)
Passt soweit.
Nun schaltet auch die Automatik auf True (Tag) und der Ausgang bleibt auf True (Tag)
Passt auch noch.
Nun wird es wieder Nacht und die Automatik schaltet auf False.
Nun passt es nicht mehr: Der Ausgang bleibt auf True, weil manuell True vorgegeben ist.

[Robosoc]

Moin Jochen, ich wollte Dir gerade mal einen Lösung basteln und als Screenshots schicken, aber dann habe ich gemerkt, dass mir die Aufgabe doch noch nicht ganz klar ist. Ich störe mich an Folgendem:

Per Taster möchte ich das toggeln, also auf "Tag" (True) umschalten, obwohl die Wetterstation noch "Nacht" (False) zyklisch sendet. Sobald die Wetterstation ebenfalls auf "Tag" umgeschaltet hat, sollen deren Telegramme wieder "führend" sein. Das Ganze soll dann natürlich ebenso funktionien, wenn ich manuell auf "Nacht" umschalte, obwohl die Wetterstation noch "Tag" sendet.

Interpretiere ich es korrekt:
Jede Betätigung des Tasters toggled den aktuellen Hauszustand (Tag=1 oder Nacht=2) und macht daraus quasi einen manuellen Zustand.
Wenn die Wetterstation zyklisch den gleichen Tag oder Nacht-Wert sendet, ändert dies den Status nicht.
Wenn die Wetterstation den Wert jedoch ändert (also bei steigender oder fallender Flanke), soll der Hauszustand in den von der Wetterstation vorgegebenen Zustand annehmen...der Hauszustand springt also quasi in den Automatikmodus.

Ist das korrekt?

[Robosoc]

Wenn meine Interpretation korrekt ist, dann würde ich es glaube ich mit zwei Standardlogiken lösen (und in einer Custom fällt mir die Lösung im Moment nicht leicht, lasse Sie daher weg):

1. Logik AND
nur ein Eingang: Wettestation-Status, Trigger= C (also nur bei Änderung)
Ausgang: Haus-Status: Trigger = C (Wird also auch nur bei Änderung geschrieben, hier geht aber auch A, weil die Logik ja auch nur bei Änderung getriggert wird)

2. Logik AND
nur ein Eingang: Haus-Status, Trigger= U (Update, but never trigger), nach dem Eingang negieren.
Trigger 1: Taster, Trigger= A (also bei jeder Ausführung).
Ausgang: Ausgang: Haus-Status: Trigger = C (Wird also nur bei Änderung geschrieben, hier geht aber auch A, weil die Logik ja bei jedem Triggern eine Änderung macht)

Ich habe das jetzt nicht getestet und einfach mal nieder geschrieben. Müsste meines Erachtens aber richtig sein. Gebe gerne mal ein Feedback.