Seite 1 von 2

Logik zum Verändern des HAVC-Modus

Verfasst: So Nov 03, 2019 10:47 am
von Jürgen
Hallo zusammen,

ich versuche derzeit, eine Logik im Timberwolf zu installieren, die folgendes machen soll:
Wenn eine Türe oder ein Fenster geöffnet wird, soll diese den Heizkörper (über den RTR) darunter in den Frostschutz-Modus versetzen (DPT:20.102).
Wenn die Türe oder das Fenster wieder geschlossen wird, soll der Modus wieder auf den Wert davor verändert werden.

Ich habe es bisher auch schon geschafft, dass eine Logik auf diesen Ausgang den Wert von "3" über das Mapping sendet.
Die war eine einfache Logik (And) mit entsprechendem Mapping.
Bild

Woran ich scheitere ist, den Heizkörper beim schließen der Türe wieder in den Modus zu schalten, der vor dem Öffnen angelegen ist.
Derzeit konnte ich es nur so festlegen, dass ich immer in den Komfort-Modus schalte.
Gibt es dafür einen Tipp??
Ich vermute, dass ich dafür eine Custom-Logik benötige, aber darin habe ich bisher noch nicht viel Erfahrung.

Richtig testen konnte ich diese Logik bisher nur im "Doktor-Modus", da ich den Wert nicht mit dem DPT 20.102 nicht an den KNX-Bus senden kann. Dies liegt daran, dass es diesen DPT in der Applikation für den Timberwolf nicht gibt.
Bild

Weiterhin würde ich gerne diese beiden Logiken zusammenfassen, da diese beide (fast) das gleiche machen:
Beide Logiken greifen den Kontakt ab. Die eine sorgt dafür, dass der Rollladen geöffnet wird (Aktiviert den Aktor entsprechend, da dieser den Zustand vorher über ein Sicherheitsobjekt speichert), die andere soll den Heizkörper entsprechend regeln.

Bild

Gibt es eine Möglichkeit, in eine Logik 2 Ausgänge entsprechend einzubauen?

Kann mir hierzu jemand eine Hilfe geben?

Viele Grüße
Jürgen

Re: Logik zum Verändern des HAVC-Modus

Verfasst: So Nov 03, 2019 11:13 am
von Robert_Mini
Kann sich der letzte Modus in der Zeit auch ändern oder ist es fix der Modus vor dem Öffnen des Fensters?
=> Soll die Logik auch im Hintergrund auf den ein Objekt hören oder sich nur den Eingang merken?

lg
Robert

Re: Logik zum Verändern des HAVC-Modus

Verfasst: So Nov 03, 2019 12:06 pm
von gbglace
Welchen RTR benutzt Du denn? Bei einigen braucht es nur ein binäres Signal als Alarm, das könnte direkt der Reed hinterm BE sein.

Re: Logik zum Verändern des HAVC-Modus

Verfasst: So Nov 03, 2019 12:52 pm
von Jürgen
Hallo Robert,

der letzte Modus könnte sich in der Zeit auch ändern, aber mir wäre dabei schon geholfen, wenn die Logik den letzten vor dem Wechsel verwenden würde.
So häufig verändern sich die Modi bei mir nicht.

RTR ist in diesem Fall von Busch-Jäger, habe aber auch andere im Einsatz. Daher ändere ich die Modi auch über die Visu immer mit dem HVAC-Onjekt.

Grüße
Jürgen

Re: Logik zum Verändern des HAVC-Modus

Verfasst: Mo Nov 04, 2019 8:43 am
von Elrom
Jürgen hat geschrieben: So Nov 03, 2019 12:52 pm RTR ist in diesem Fall von Busch-Jäger, habe aber auch andere im Einsatz. Daher ändere ich die Modi auch über die Visu immer mit dem HVAC-Onjekt.
Nur um noch mal sicher zu gehen, dass du es dir nicht schwerer machst als nötig: Hast du bei den verwendeten RTR kein Objekt für den Frostschutz, was Göran mit seinem Hinweis wohl auch meint? Die Umschaltung des Betriebsmodus in der Visu kannst du ja weiterhin über das entsprechende Objekt machen.
Meine RTR bekommen bei aktivem Frostschutz eine Änderung der Betriebsart im Hintergrund mit und kennen diese dann nach Deaktivierung des Frostschutzes (schließen des Fensters) auch.

VG
Erik

Re: Logik zum Verändern des HAVC-Modus

Verfasst: Mo Nov 04, 2019 8:48 am
von Robosoc
Hallo Jürgen,

mir fällt es ein wenig schwer Dir zu helfen, weil ich noch nicht ganz verstanden habe, was genau Du machen willst und was Dir Probleme bereitet. Sorry.

Mich verwirrt zum Beispiel folgendes
Jürgen hat geschrieben: So Nov 03, 2019 10:47 am Ich habe es bisher auch schon geschafft, dass eine Logik auf diesen Ausgang den Wert von "3" über das Mapping sendet.
Die war eine einfache Logik (And) mit entsprechendem Mapping.
Bild
Du machst ja ein Mapping auf die Werte 4 und 1. D.h. der Baustein soll beim Ergebnis nicht true sondern eine 4 senden und bei false eine 1 statt des boolschen false. Aber Du schreibst, dass Du schon eine 3 ( = Eco oder NAcht) geschafft hast. Ich vermute Du meintest einfach allgemein, dass Dir klar ist, dass Du über Mapping einen belibigen Wert in Abhängigkeit vom Logikergebnis senden kannst. Korrekt? ...

Zwei oder mehr Ausgänge (die sich auch unterschiedlich verhalten können) geht, aber nur über Custom Logiken. Um zwei Objekte mit nur einer Logik zu schalten, kannst Du dem Ausgang auch einfach mehrerer Objekte zuweisen. Das geht aber natürlich nur, wenn das Verhalten der Ausgänge und der Typ (bool oder numerisch) der gleiche ist. Somit brauchst Du in Deinem Fall zwei Ausgänge, weil das eine ja eine numerischer Wert ist (HVAC Mode) und das andere ein bool (K-196 Rolladen). Aber es wird gehen alles in einem zu machen.

Für das temporäre Zwischenspeichern könnte man A) eine weitere GA anlegen oder B) vielleicht einen zusätzlichen Ausgang und einen zusätzlichen Eingang schaffen. Das finde ich eine spannende Idee. Keine Ahnung ob es geht, finde ich aber gut. Ich probier da gleich mal was und Schreibe Dir dann eine Lösung.

Solange 20.102 nicht im TWS verfügbar ist könntest Du Dir behelfen, in dem Du das Objekt auf einen anderen 1-Byte Wert legst. Z.B. 5.005.

Erik war mit seiner Antwort schneller, beantworte am Besten erstmal seine Frage.

Re: Logik zum Verändern des HAVC-Modus

Verfasst: Mo Nov 04, 2019 8:50 am
von ThomasD
Hallo,

also ich mache das bei meinen Berker B.IQ mit RTR auch über das Frostschutz Objekt....

Gruß
Thomas

Re: Logik zum Verändern des HAVC-Modus

Verfasst: Mo Nov 04, 2019 8:18 pm
von Jürgen
Hallo zusammen,

diese Lösung habe ich in der Zwischenzeit geprüft. Das entsprechende Objekt ist bei den Busch-Jäger RTRs vorhanden und ich werde es auch nutzen, bis der andere DPT vom Timberwolf unterstützt wird.
Ich hätte zwar gerne die andere Lösung bevorzugt, da ich es dann einheitlich gehabt hätte.

Die Lösung mit der Änderung im Hintergrund werde ich dann auch prüfen. Vielleicht ist damit ja mein Problem schon gelöst.

@ Sven:
zunächst danke für die ausführliche Antwort. Ich habe hier zunächst den Text geschrieben und danach die Screenshots angefertigt.Da ich in der Zwischenzeit die Doku eines RTRs gelesen habe, musste ich feststellen, dass die "4" für den Frostschutz steht und nicht die "3".
Dann habe ich auch sofort die Logik geändert, aber leider den Text nicht mehr.

Das mit dem Mapping habe ich verstanden uns so auch bereits im Einsatz.

Das mit der Custom-Logik werde ich versuchen, sollte in dem Fall relativ einfach sein. Damit spare ich mir eine Logik, dies sollte das ganze übersichtlicher machen.
Ich habe mich bisher nur an den Modulen versucht, die im Standard vorhanden sind...
Ich werde mich in den nächsten Tagen an der Programmierung versuchen, kann ja nicht so schwer sein...

Viele Grüße
Jürgen

Re: Logik zum Verändern des HAVC-Modus

Verfasst: Mo Nov 04, 2019 8:59 pm
von gbglace
Nichts gegen den TWS und dem LE, aber alles was nativ im KNX erledigt werden kann erledige ich im KNX. Darunter zähle ich dann auch sowas wie nen Reedkontakt direkt auf ein Alarmeingang zu legen. Egal welcher das ist.

Re: Logik zum Verändern des HAVC-Modus

Verfasst: Mo Nov 04, 2019 10:02 pm
von Robosoc
Ich glaube der folgende Code macht was Du willst.

Du kannst über das + in der Logikzelle (nicht im Code) mehrere Tür- oder Fensterkontakte einbinden, diese werden mit ODER behandelt.

Schau Dir die Lösung mal an und versuche jeden Parameter nachzuvollziehen. Ich habe beispielsweise bewusst eine "u" für den ersten Eingang gewählt. Aber den Grund versuch mal selber rauszufinden. Das übt denke ich. Eventuell auch mit den Kapiteln 4.6.6 und 4.6.7 der Knowledge Base.

Die Logik würde ich im Persistenz-Modus laufen lassen (Button oben rechts in der Zellenansicht), da Sie mit zwei internen Merkern arbeitet. Sonst könntest mal nach einem Neustart des TWS oder nur des Dienstes ein unerwünschtes Verhalten haben.

Code: Alles auswählen

/**
 *  HVAC Mode Frostschaltung
*/
{
  "Level":[
    ["$HVAC_In","integer",0],
    ["$HVAC_Out","integer",0],
    ["$mHVAC","integer",0],
    ["$VAR<In!>","bool",false],
    ["$constTrue","bool",true],
    ["$const3","integer",3],
    ["$Ausloeser","bool",false],
    ["$Rolladen","bool",false]
  ],
  "Module":[
    ["Or" , ["$VAR<In!>"], "$Ausloeser"],
      // Logik für HVAC 
    ["Latch","$HVAC_In","$mHVAC","$Ausloeser",1],
    ["Latch","$const3","$HVAC_Out","$Ausloeser",1],
    ["Latch","$mHVAC","$HVAC_Out","$Ausloeser",2],
      // Logik für Rolladen
    ["Latch","$constTrue","$Rolladen","$Ausloeser",1],
    ["Latch",0,"$Rolladen","$Ausloeser",2]
  ],
  "Input":[
    ["HVAC Mode Aktuell","Wert des aktuellen HVAC Mode","$HVAC_In","u"],
    ["Kontakt","binäre Eingang von Tür- oder Fensterkontakten","$VAR<In!>","c"]
  ],
  "Output":[
    ["HVAC Mode","Wert des HVAC Mode, ggf. durch diese Logik modifziert","$HVAC_Out","c"],
    ["Rolladen","binärer Ausgang für Rolladensteuerung","$Rolladen","c"]
  ]
}
Und aus folgendem Grund würde ich allen anderen Recht geben und den Frostschutz in den Aktoren lösen!
Diese Logik übersteuert den HVAC Mode dauerhaft mit dem Wert 3, solange bis irgendein anderes Gerät einen anderen Wert definiert.
Wenn Du das nicht willst und Du ein dauerhaftes Übersteuern mit 3 erreichen willst, dann kannst Du es
A) durch Änderung eines einzigen Parameters (welches ist eine Übungsaufgabe zum Lernen der Logik :D :-), aber wenn Du es wissen willst, frage einfach) in der Logik "quasi dreckig" ändern, denn das hat dann zur Folge, dass auf der GA vom HVAC-Mode dann erst einmal der andere Wert gesendet wird und dann anschließend durch diese Logik wieder eine 3. Das wäre für Visualisierungen denke ich sehr unschön. Eventuell belastet das auch Schaltaktoren unnötig.

oder B) durch anlegen einer weiteren GA (quasi "HVAC Soll" oder so ) lösen.