Öffentliches Forum
  - Wärmepumpen

Warum eigentlich nicht einfach mit Abtauen=1 FM aktivieren und wenn Abtauen auf 0 geht timer starten, der FM nach kurzer zeit runter setzt?

Die letzten Tage waren ideal zum Testen rund ums Abtauen. Hier mal 3 Mitschnitte verschiedenen Abtauungen.
Bei der Linken ist die Flüsterrule abgschaltet und der Heizstab wird benutzt. Die Detailanalyse ergab, das der Heizstab zeitgleich mit dem Abtaustatus eingeschaltet wird und zeitgleich nach 12 Minuten mit dem Abtaustatus wieder ausgeschaltet wird. Der Kompressor lief dann die letzten 4 Minuten schon wieder parallel mit.
Fazit: Der Heizstab sorgt hier für ein Überschwingen des Vorlaufs.

Bei der mittleren Grafik war die Flüsterrule 3->1->0 aktiv und der Heizstab deaktiviert. Hier bricht die Kompressorfrequenz und die Lüfterdrehzahl nach der Startminute zu sehr ein weswegen ich die Flüsterrule auf 2->1->0 geändert habe wie dann in der rechten Grafik zu sehen. Hier auch noch der Fehler mit nicht erwünschtem FL1 Timer vom 1. Takt.

In der rechten Grafik läuft die Lüfterfrequenz nahe zu e-Funktional und die Kompressorfrequenz wird nicht zu sehr eingebremst. Der Verlauf der VLT ist m.M.n ideal und ich werde bei der Rule Start->FL2 für 5 Min -> FL1 für 5 Minuten -> FL0 vorerst bleiben.
[img][/img]

Was Rules angeht:
Beide Starts finden unter dem Abtaustatus statt und sind daher nicht separierbar. Beim ersten ist keine korrektur erwünscht, wohl aber beim zweiten. Ich meine das während des Abtauens die Flüsterkorrektur keine Anwendung findet und auch die Lüfterdrehzahl keine Rolle spielt weswegen ich es einfach so laufen lasse.

Meine Lösung zur stornierung des Timer4 wenn er nach dem ersten Start noch läuft mit settimer(4,0) hat nicht funktioniert. daher habe ich es jetzt so gelöst, das wenn der Timer3 ausgeführt werden soll eine Abfrage stattfindet ob Abtaubetrieb aktiv ist. Wenn ja dann ruf Timer 3 erneut auf nach 3 Minuten, wenn nein ruf Timer 4 auf. Dadurch wird verhindert das Timer 4 vom ersten Start aus augerufen wird.


on timer=3 then
if @Defrosting_State == 0 then
@SetQuietMode = 1;
settimer(4,300);
else
settimer(3,180);
end
end

Wenn das wirklich so ist, dann ist es ja ok.
Hier mal der Verlauf mit meiner Anpassung von oben.

Das sieht doch gut aus. Auch schön zu sehen wie der VL sich nach dem 2. Start wieder entwickelt. Da würde ich nichts mehr dran ändern.

Hast du den Heizstab deaktiviert? Auch hier zu sehen wie Grafana die Werte frisiert. Es gibt 2 Zustände in denen der Kompressor auf 0 Hz geht. Aber nicht in deinen Grafik.

Dein Vorlauf geht auf 21° runter. Bei mir sind es 16° weswegen anschliessend ein kraftvoller Start angesagt ist.

Dieser starke Einbruch ist meiner Glykol- Systemtrennung geschuldet. Die Wärmetauscher könnten das zwar voll umsetzen wenn die sekundärseitige Pumpe ihren Volumenstrom in diesem Falle auch von 12 auf 28 L/min steigern könnte. Tiefer runter kann es nicht gehen weil der Heizkreis im Rücklauf stabile 27°geliefert hat. Bleibt trotzdem die Frage ab wann die Jeisha auf Störung geht bei abgeschaltetem Heizstab.

Als Vorteil kann man aber verbuchen, das der zum Abtauen erhöhte Volumenstrom der Jeisha nicht die Heizkörper zum Rauschen bringt.

Hallo Mo75,
ich antworte mal hier auf deinen Beitrag im anderenThread (der ohne Rules).

Prima wenn es so läuft wie du es dir vorstellst. Ich habe es nicht so mit Matheformeln und bleibe vorerst bei meiner Kurzzeitlösung. Ausserdem habe ich das Modul z. Zt deaktiviert und fahre mit der internen Heizkurve mit meinen Korrekturen in der SWV.
Es macht für mich erst Sinn weiterzumachen wenn die Möglichkeit besteht Daten aus Rules heraus in TOP29 und TOP30 zu senden. Bei Github gibts keine Reaktion darauf.

Du antwortetest auf meine Frage wie oft du eingreifen willst mit "So wenig wie nötig" oder so. Das hast du aber noch nicht umgesetzt. Daher möchte ich dir folgendes vorschlagen:

Wenn ich es richtig gesehen habe wird bei externer Veränderung der SWV TOP27 im Modus Festwert dieser Wert intern gesichert in TOP29. D.h. die Jeisha schreibt diesen Wert in ihre dann nicht benötigte Heizkurvenvorgabe als VLTmax ein. Zu sehen auf der Console kurz nach der Änderung von TOP27) Die Heizkurvenvorgabe steht aber sehr wahrscheinlich im nichtflüchtigen EEPROM von dem wir nicht wissen wieviele Schreibzyklen er verträgt.

In deinen Rules wird der TOP27 alle 15 Minuten aktualisiert -> 96x pro Tag.

Da du nun die Sollvorgabe so stabil wie möglich halten willst ist die Frage wieviele Korrekturen in 24h überhaupt nötig sind.

Also könnte man doch bevor du Einschreibst einfach die Notwendigkeit prüfen ob der neue Wert anders ist als der alte z.B. durch vorherigen Abfragevergleich des TOP27 um dann nur noch einzuschreiben bei Bedarf. Ich lasse bei mir einen Zähler mitlaufen der die Einschreibvorgänge erfasst.

Noch so eine Idee: Dann wissen wir auch nicht wie hoch eine Gazzahl in Rules werden darf. Wenn du Temperaturen mit 1000 multiplizierst könnte man (theoretisch ) bei 35°C über die 32K- Grenze kommen.

Ja den habe ich deaktiviert.
Grafana rundet im "Normalzustand" immer wieder. Das kann man erheblich verbessern, wenn man Aggregations auf distinct stellt, ist standardmäßig auf mean.
Sollte ich mir vielleicht mal angewöhnen ;-)

Ja leider. Ich gucke auch immer mal wieder bei git nach, aber scheinbar scheint das Interesse an der Möglichkeit eher gering zu sein :-(
Vielleicht kommt da noch mal was. Bis dahin versuche ich auch erstmal überhaupt eine passende Heizkurve zu finden.

Bist 'n Fuchs! Ist mir so noch gar nicht aufgefallen, sieht man aber auch im iobroker, der die TOPs ja via MQTT entgegen nimmt und sie anschließend in der Datenbank ablegt, sofern der Wert via MQTT übertragen wurde, was er ja nicht tut, wenn er nach außen unverändert bleibt. Auch TOP56 bekommt diesen Wert. Nun wissen wir ja leider nicht, ob der Speicher tatsächlich jedes mal neu überschrieben wird, es ist aber zumindest nicht unwahrscheinlich. Die Sinnhaftigkeit, warum der Wert nicht einfach nur in TOP42 (Z1_Water_Target_Temp) geschrieben wird, lohnt sich leider kaum zu hinterfragen. Ebenso ist unklar, ob der Speicher das aushält oder nicht. Von daher macht eine Abfrage, ob sich der Wert geändert hat, absolut Sinn.

Allerdings habe ich mich ja bewusst für die Methode entschieden den festen VL zu setzen, um eben dieses Problem mit der Anzahl der Schreibzyklen zu umgehen. Nun könnte man also genauso immer eine gerade Heizkurve setzen und man hätte dazu noch den Vorteil, die SWV (zB per Timer) nutzen zu können. Das geht aber leider nicht per Rule, wie ja festgestellt wurde (TOP29 und TOP30).

In der Simulation hat sich über 74 Tage (16.9.22 bis 29.11.22) der Wert 86x geändert. Das sind 0,86 Änderungen pro Tag. Extremwerte sind von 6 Tage ohne Änderung bis zu 4x/ Tag.

Ich werde die Abfrage noch in den Code einbinden. Danke für den Hinweis.

Ich habe jetzt den Code am Ende so abgeändert:


Das sollte dafür sorgen, dass nur geschrieben wird, wenn sich ein neuer Wert ergeben hat.


Nicht nur theoretisch, das ist auch beim mir praktisch bereits der Fall, wie die Konsole zeigt:

Also erstmal Entwarnung diesbezüglich?

Ich würde es wiefolgt umsetzen:

if @Z1_Heat_Request_Temp != #SetZ1HRTneu then
@SetZ1HeatRequestTemperature = #SetZ1HRTneu;
end

Brauchst keine neue Variable wenn man am Original maßnehmen kann.


Habe mal skizziert wie die Temperaturvorgabe in den TOP abgebildet ist (ohne Kühlmodi). Demnach ist TOP7 der zentrale Übergabepunkt für die Kompressorsteuerung.
[img][/img]

Mir ist aufgefallen, wenn ich ein Reboot anstoße und dann die Seite schließe bevor Reboot abgeschlossen ist und sie sich wieder aufgebaut hat, werden die Rules nicht gestartet. Beim späteren Öffnen des WebIF sind auf der Console keine Variablen zu sehen.
Ist das wieder so ein komisches Ding nur bei mir, oder kann das jemand nachstellen?

War nur n Test ;-)
Danke für den Tip, ist schon geändert!

Das Schema versuche ich morgen zu durchblicken :)

Genau das hatte ich auch schon mal hier erwähnt das vermutlich nach einem Reboot die Bootsequenz von Rules nicht aufgerufen wird. Wie es nach einem Start nach Stromabschalten aussieht habe ich nicht probiert. Kann es jetzt nicht testen weil Heishamon mit meinen Rulesmodulen läuft. Hatte mir aber schon überlegt Boot auszulagern in eine Funktion die dann ggf aus einem Ereignis heraus nachgestartet wird wenn Boot nicht gegeriffen hat.

Schlimmer ist m.M.n das manchmal eine Variable mit gleichem Namen 2x in der Console auftaucht wobei eine davon den Wert "NULL" ausweist. Welche wird verwendet? Siehe Variable Stat. Ansonsten funktioniert Rules gut.
[img][/img]

Du meinst, dass on System#Boot then nicht aufgerufen wird?
Das kann durchaus sein. Bei mir sah es aber so aus, als wenn die ganze Rules engine nicht geladen wird. Sonst hätte ja wenigstens meine 3-Wege-Ventil Rule laufen müssen, die läuft unabhängig von System#Boot und meldet sich regelmäßig alle 5 Minuten in der Console mit
==== DHW_Energy_Consumption ====
>>> rule 12 nrbytes: 247
>>> global stack nrbytes: 52
>>> local variables

>>> global variables
...

Aber bei mir erscheint gar nichts mehr in der Art.
Normal habe ich bei einem Reboot nie Probleme gehabt. Nur bei früheren ominösen Reboots, die ich nicht veranlasst hatte, oder wenn ich während eines manuellen Reboots die Webseite schließe. Sehr seltsam...

Doppelte Variablen konnte ich bisher bei mir noch nicht sehen.

Ja, ich hatte gestern auch einen solchen Zustand, wo in der Konsole keine Rückmeldung der Rule kam, so als wäre gar keine vorhanden. Ob sie im Hintergrund lief, kann ich nicht sagen.

TOP27 scheint ja auch der Wert zu sein, den man an der FB im Modus "feste VLT" vorgibt. So weit, so schlüssig auch diesen per Rule zu schreiben.
Fraglich, ob die Entwickler die Möglichkeit hätten, TOP42 zu schreiben und was das für Auswirkungen hätte.

Da ich heute Vormittag wieder einen (selbstständigen) Reboot hatte und die Uptime plötzlich wieder nur einige Minuten anzeigte (Rules liefen natürlich auch wieder nicht), habe ich mal einen Stromausfall simuliert und den Stecker gezogen.
Nach dem erneuten Start lief alles wie gewohnt, das sollte also kein Problem darstellen.

Übrigens der "Softstart" über FM läuft nun wie er soll, wenn Rules denn läuft.
Guckst du...

Link ist plötzlich verschwunden, hier noch einmal.

Sieht doch gut aus. Und deine Daten sehen auch nicht mehr korrupt aus.

Eine Sache könntest du noch mal versuchen zu verbessern. Beim ersten Start ist zu sehen, das die Pumpenleistung nach dem Start immer noch mit ca 10L/min nahe am Schnüffeln bleibt und das dadurch mangels Kühlung die VLT trotz Flüstermodus 3 zu schnell hochgeht.

Wie kann man nun die Pumpe mit Rules dazu bringen Fahrt aufzunehmen? Im Grunde hast du nur eine Möglichkeit einzugreifen ohne in Konflikt mit der Pumpensteuerung zu geraten und das ist die SWV über TOP27.

Ich würde die Starterkennung, die du ja sowieso schon hast, erweitern um eine Abfrage ob zu diesem Zeitpunkt der Pump Flow kleiner als 12 Liter/Min ist. Wenn das so sein sollte muss die Pumpenhysterese über den Tiefpunkt gehoben werden. Vielleicht klappt das indem man 2 Timer anstößt. Der erste liest TOP27 aus, haut 2° drauf und schreibt wieder ein. Der zweite macht das ca 10 Sekunden (Reaktionszeit muss man ausprobieren) später wieder rückgängig. Die WP bekommt praktisch für Sekunden eine zu niedrige Ist- Situation ihres Vorlaufs aufgedrückt und sollte dann aus den Puschen kommen.
Ist nur so ein Lösungsansatz von mir, ich habe dieses Problem nicht.

Wenn das funktionieren sollte brauchst du auch nicht mehr die volle Einbremsung durch Flüsterlevel3 nach dem Start. Ich würde das dann mal auf Level2 ändern. Die Abtauungen zeigen einen Vorlaufeinbruch nach der Startminute. Der könnte so noch ausgebügelt werden.

Also kam diese Meldung gar nicht im Fehlerfall?
Oder kam sie nur ohne Variablen Information?

Ihr seid jetzt hier an einem Punkt, wo bei jedem Start ziemlich tief eingegriffen wird, sowohl nach dem Abtauen als auch im Taktbetrieb in der Übergangszeit. Ich sehe das mittlerweile etwas kritisch, vor allem, weil jetzt jedes mal TSoll auch noch geändert wird. Das ggf auch noch beim "Kickstart". Das wollen wir zu Gunsten der Schreibzyklen ja eigentlich vermeiden.
Ich frag mal ganz unverblümt: Wozu das alles?
In der Übergangszeit bei hohen AT (zB >12-14° oder so) reicht es doch, dauerhaft den FM zu aktivieren, darunter bleibt er aus.
Habt ihr Probleme mit Abbrüchen nach dem Abtauen? Bei McM könnte ich mir das wegen der Problematik mit zwei Kreisen und WT noch ggf vorstellen. Hier wäre eine Möglichkeit den Heizstab zu deaktivieren, was oft sowieso erwünscht ist. Aber sonst? Wo liegt das Problem der höheren Startleistung?

Was anderes:
Für Jockels extrem flache Heizkurve kommt mir gerade die Idee, den Heizbedarf in Abhängigkeit der gemittelten AT über die Zeit zu bestimmen. Dann einen Heiztimer morgens (Heizung an) setzen und eine Funktion ähnlich der Heizkurve anstatt der VLT eine "An-Zeit" über Timerkaskaden zu realisieren. Wenn kalt genug -> Dauerbetrieb oder sogar VLT entsprechend der HK erhöhen.

Gar nicht denke ich. So war es zumindest bei mir auch mal, als sich Heishamon selbstständig resetet hat.

Könnte man über eine Art HK realisieren, die am Punkt "Dauerbetrieb mit 26°" eine 1 ausgibt. Alles größer 1 wird mit 26 multipliziert und enthält als Ergebnis den VL-Soll. Alles kleiner 1 wird mit 24h multipliziert und enthält als Ergebnis die Betriebsstunden ab Timer "Heizung an".

Das habe ich auch schon (manuell) getestet, aber die UWP macht was sie will. Bei einem "Warmstart" nach dem WW oder Abtauen legt sie sofort los. Nach längerer Taktpause schnüffelt sie erst mal eine Weile weiter.
Ab 26° SollVL ist das auch kein so großes Problem mehr, aber in der Übergangszeit will ich eigentlich mit 25° fahren, da gibt es schon gern mal einen Startabbruch.
Einzige Möglichkeit, die bisher gegriffen hat, ist das Fahren nach fester Pumpendrehzahl. Da verbraucht sie aber unnötig Strom in den Taktpausen. Lösen lässt sich das dann zwar mit Rules und Max_Pump_Duty, aber ich weiß nicht, wo dieser Wert gespeichert wird und ob man den so oft schreiben sollte.
Den Befehl SetPump bei Taktstart habe ich auch schon getestet, aber den ignoriert die WP leider.

Richtig. Wie @Mo75 schon geschrieben hat, kam da gar nichts mehr von den Rules.
Ich habe es auch mal eine Weile weiter laufen lassen, die Rules haben auch nicht mehr eingegriffen. Scheinbar stürzt da irgend ein Modul in der FW ab, ich habe keine Ahnung.

Das läuft doch bisher alles über die SWV, damit sollte es eigentlich keine Probleme geben, denn die werden sicher in den flüchtigen Speicher geschrieben.

Ob die flache HK so bleiben kann, wird der Winter noch zeigen ;-)
Morgens an und am Abend aus geht auch, wenn es noch etwas wärmer ist. Dann muss ich sie aber auch mit mindestens 26° fahren, da sie sonst auch am Tage taktet und dann nicht genug für die Nacht "einlagert". Irgendwie hatte ich aber das Gefühl, dass sie dann etwas mehr verbraucht, als wenn ich sie einfach auf niedrigem VL durchlaufen/Takten lasse.
Gucke ich mir im Frühjahr noch einem an.
Jetzt wäre ich erst einmal froh, wenn mein HeishMon verlässlich läuft und ich mich auf die Rules verlassen kann. Ich habe das Modul jetzt an das Kabel des TAW1 gesteckt und gucke ob es eventuell daran liegt.

Ah, ok. Das mit der SWV hatte ich verdrängt, da ich ja im anderen Modus unterwegs bin. Das ist allerdings eigentlich noch kein Grund da ständig einzugreifen. Wenn du mit 25° fahren willst, muss es genauso mit dauerhaft aktiviertem FM klappen. Wenn nicht, hilft die Umschalterei ja auch nicht, weil sich die Mindestleistung nicht weiter verringert.

Ob sich die ganzen Verrenkungen lohnen, um 1K rauszukitzeln... Ich weiß nicht... Besonders weil du in der Hauptzeit ja sowieso schon mit sehr nieder. VLT gesegnet bist. Eigentlich wären für dich dann eher 22° VLT erstrebenswert ;-)
Ich hielte es für praktikabler das ganze über künstliche Takte (1x/Tag, wie erwähnt) zu realisieren, dann kann sie auch schön die hohen AT nutzen.

Bin auch gespannt, ob der Reset bei mir wiederholt auftritt oder ob das am Gefummel lag ;-)