[sanya]

Hallo zusammen,

ich hab nun einige Zeit an der Taupunktüberwachung der Buderus WP gebastelt und ich kann endlich die erste Lösung präsentieren
Voraussetzung sind die Modelle Buderus WLW 196i AR / IR. Mit dem Vorgänger WPL funktioniert es meines Wissens nicht, neuere Modelle gibt es noch nicht. Man sollte aber schauen, dass der Gekko auf aktuellem Stand ist, da mit einem der letzten Updates die Integration der Buderus tiefer erfolgt ist (Danke noch mal, hrhr)

Bei diesem Tutorial hab ich jetzt nicht mehr im Detail erklärt, wie man wo was anklicken muss. Wenn da Bedarf besteht, einfach kurz melden. Aber wer sich schon die Sonnenschutzlogik von Santos oder die EMS-Steuerung von mir gebastelt hat, sollte hiermit auch zurechtkommen

Die Herausforderung war, wie man den Taupunkt in den Gekko bekommt, da sich dieser in Abhängigkeit von Feuchte und Raumtemp dynamisch verhält. Hierzu habe ich anhand Angaben aus dem Internet eine kleine Tabelle erstellt, ausgehend von einer Vorlauftemperatur von 18 Grad (die WP muss hierauf begrenzt werden, der darf nicht darunter sinken!!!). Je nach Raumtemperatur variiert entsprechend auch die maximale Feuchte, bei der dann der Taupunkt erreicht ist. Je niedriger der Vorlaufwert, desto niedriger auch der mögliche Feuchtewert, bei dem der Taupunkt überschritten wird.
   
Die Tabelle war relativ schnell erstellt, aber das Problem war das dynamische Verhalten. Letztlich hab ich einfach die beiden Raumtemperaturen 20 Grad und 28 Grad als lineare Gleichung gleichgesetzt und kam auf einen Wert von 4,375:
20 x 4,375 + 85 = 28 x 4,375 + 50
Diese Gerade hab ich für alle Raumtemps erstellt und bin so auf den unteren Teil der Tabelle gekommen. Der zeigt nun recht schön, dass der Wert zum Taupunkt um die 172 rumpendelt. Somit konnte im Gekko nun diese Formel angelegt werden mit einer Vorgabe, dass bei Überschreiten dieses rechnerischen Wertes ein Alarm rausgehen soll. Dat kommt nun

So sieht das Logikchen erst mal aus:
   

Position 1: Fragt ab, ob das Ergebnis aus Gatter B größer als 165 ist. 165 deswegen, damit hier noch ein minimaler Puffer drin ist. Ich muss das diesen Sommer im laufenden Betrieb beobachten, evtl. setz ich sogar runter auf 160. Kann man sich ja selbst ausrechnen, welcher Feuchte das entspricht, bei der dann der Alarm auslöst.

Position 2: Hier hab ich aus meiner Sonnenschutzlogik einen Merker (M26) reingeholt. Der fragt ab, ob der aktuelle Monat zwischen März und Oktober liegt und ob die Außentemperatur größer 22 Grad. Die KüFu ist in unserer Buderus ab einer Außentemp von 24 Grad aktiviert, darunter ist sie entweder im Leerlauf oder im Heizmodus. Ich möchte nicht, dass die zugehörige Aktion dann wahllos ausgelöst wird, sondern halt auch nur, wenn die Heizung sich im Kühlmodus befindet. Die 2 Grad Differenz zwischen meiner Abfrage und der tatsächlichen Einstellungen bleiben jetzt mal vernachlässigt

Position 3: Hier ist ein zentraler Temperaturfühler definiert. In unserem Fall sitzt der im EG an der Treppe neben dem Slide. Ich muss allerdings mal tief in mich gehen, ob nicht evtl. einer ausem OG sinnvoller wäre, weil warme Luft ja nach oben steigt. Schauen wir mal, für den Moment bleibt es so.

Position 4: Hier habe ich einen Enocean Feuchtefühler (NodOn für etwa 60 Euro, der Gerät hier: https://smile.amazon.de/Nod-STPH-2-1-05-...01N6KXYS1/)  mit einer Batterie versehen und einfach nur in meinen HKV im EG geworfen. Politisch korrekt wäre, wenn der zweite HKV auch einen kriegt und man ne Abfrage zwischen den beiden macht, aber auch das schauen wir erst mal im laufenden Betrieb, ob es optimiert werden muss oder unnötig ist. Wichtig ist jedenfalls, nicht die Raumfeuchte zu nehmen, sondern eben die HKV-Feuchte. Praktisch: der Nodon misst auch die Temperatur und die kann man beim zugehörigen Raum auch gleich als Bodentemperatur anlegen.

Position 5: Hier wird der Wert von Gatter A (also Feuchteformel überschritten und die Monats-Außentemp-Bedingung) genommen und wenn beide zutreffen, dann wird ein Raising Trigger ausgelöst mit 3 Sekunden. Der soll einen Taster für die zugehörige Aktion simulieren und ist als Merker M25 definiert.

Position 6: leer

Wichtig, unten rechts muss das kleine Alarmkästchen angeklickt werden.

Hier nun die I/O dazu:
   

Und ganz im Detail am Bsp. des Feuchtefühlers:
   
Im Fall von dem Enocean-Feuchtefühlers muss man in der IO zusätzlich den Wert auf 100 begrenzen, sonst steht der iwo bei 10xxx. Danke an Strabbit für den Hinweis, ich kam hier alleine nicht weiter

Jetzt haben wir also einen funktionierenden Alarm (einfach mal den Feuchtewert auf 120 setzen die Monatsabfrage auf 0 setzen. Dann ploppt direkt das rote Alarmoverlay auf =)



Ich will ja aber auch ne Aktion dazu, die die KüFu abschaltet. Das hab ich nun erst mal so gelöst, evtl. müssen auch hier im laufenden Betrieb die zeitlichen Werte korrigiert werden:

   

Diese sieht so aus, dass bei Starten der Aktion der Heizkreis anstelle vom Modus "Automatik" nun auf den Modus "Sommer aus" umgestellt wird, also nicht mehr kühlt, sondern aktiv in den Leerlauf gesetzt wird. Nach einer Wartezeit von 4h (On-Stop-Funktion) wird sie wieder in den Automatikmodus gesetzt und entscheidet wieder selbstständig, was sie treibt.
   
   

Die I/O ist recht simpel belegt. M25 kommt als Taster rein, um die Aktion zu starten. Als Startbedingung hab ich noch mal M26 hinterlegt (also Monat und Außentemp). Das ist grundlegend unnötig, weil die Sperre nun doppelt gemopelt ist, einmal in der Logik und einmal in der Aktion. Ich finds aber praktisch, wenn bei der Aktion mittels rotem Balken angezeigt wird, dass es sperrt, daher brauch ich hier die Bedingung. Da ich aber auch nicht will, dass die Logik "ständig" die Aktion triggert und die Aktion durch die Sperrbedingung nicht loslegt, ist die Bedingung auch in der Logik hinterlegt. Ist eine Geschmackssache, ob man das so mag, ich finds gut
   

Und das wars eigentlich auch schon

Viel Spaß beim Nachbauen und bei Fragen einfach fragen.