Öffentliches Forum
  - Wärmepumpen

Um das letztgenannte Problem zu umschiffen vielleicht gar nicht erst den Sollwert vergleichen

on @DHW_Temp then
if @DHW_Energy_Consumption == 0 && @Operating_Mode_State == 3 then
@SetOperationMode = #OperationModeAlt;
end
end

Das Problem gibt es bei mir nicht wirklich, da kein Timer auf das WW folgt und es somit immer fertig wird.
Deshalb habe ich da noch nicht drüber nachgedacht ;-)

Das könnte in die Hose gehen, wenn die WP mal während des WW abtauen muss, dann macht sie danach nicht mehr weiter.

Stimmt, ist bei mir auch so: Ende offen. Ist ja auch einer der Vorteile.

Beim Abtauen hast du auch recht.

Wäre da noch die Geschichte mit selbstgebauter Sommerabschaltung die natürlich gegen den geglätteten TA-EMA vergleichen soll und nur dann greifen soll, wenn nicht vorher manuell abgeschaltet wurde. Naja, später vielleicht, sind ja noch ein paar Monate zeit dafür :-)

Mit Operating_Mode_State haben wir bisher aber nur die halbe Wahrheit abgedeckt. Wir müssen auch noch Heatpump_State auf vorigen Stand zurück setzen, oder liege ich da falsch?
Die Betriebsart ist ja unabhängig von An/Aus.

Ja genau. Das ist eigentlich auch das einzige, was ich benötige.
Außer heizen und WW mache ich ja nichts.
Muss mal gucken, ob mir da was schlaues einfällt, wenn meine bessere Hälfte mir mal Zeit gibt ;-)

Gute Idee mit dem Operations_Counter. Ich würde den Defrosting_State noch abfragen, denn im Abtauzyklus erhöht sich bei mir der Operations_Counter und gleichzeitig ist Heat_Energy_Consumption > 0. Das Script dürfte dann beim Abtauen immer den Silent-Mode aktivieren. Außer es ist Absicht :)

Ja. Blöd, dass sie beim Abtauen die Energie als Heizenergie zählt. Sollte eher als Kühlleistung aufgeführt werden. Hoffe nicht, dass sie das auch im Energiezähler an der FB macht...

Eine Erkenntnis zu meinen Abbrüchen des MQTT-Verbindung zum iobroker: Der WLan -Router war zumindest für stündliche Abbrüche schuld, weil da immer nach besseren WLan-Kanälen gesucht wurde. Habe das nun erstmal deaktiviert.

Trotzdem seltsam, dass ich über den Tag nur 1x/h einen Abbruch und Neuverbindung hatte, aber als ich gerade nach Hause kam und den PC mit Browser geöffnet habe, kam erstmal fast nichts mehr von HeishaMon. Abbrüche ohne Ende und in der Console auch mal Meldungen, die daruf hindeuteten, dass auch die Daten, die von der Jeisha kamen, nicht ok waren (Checksum usw...)
Nach Routerneustart ging es wieder. Danach Kanalsuche deaktiviert, jetzt mal abwarten...

Ich sehe es als unktitisch an, weil:
Nachdem eine Abtauung ausgelöst wurde endet der vorherige Takt -> Compressor = 0.
Wahrscheinlich will man das 4Wege Ventil nicht bei laufendem Kompressor schalten.
Dann folgt der "Abtautakt" bei dem der Flüstermodus auch aktiviert wird. Das hat nur keine Auswirkungen. Bei meiner 5KW-Jeisha zieht der Kompressor alle Register und macht dann bis 58 Hz. Nach dem Abtautakt beginnt ein neuer Heiztakt und die Flüster Rule wird neu gestartet und tut dann was sie soll. Da bei mir der VL dann so eingebrochen ist legt sie dann sogar mit bis zu 30Hz trotz Flüsterlevel 3 los. Das hat nur keine Überschwing- Wirkung weil zur Zt das Haus ca 4KW Wärme abnimmt und es daher nicht zu einem Stau durch Startwärmeüberschuss kommt.

Danke für den Riesen-Smily, hatte mich fast erschrocken. :-))

Habe mir mal Gedanken gemacht über die 3Wege- Ventil Problematik. Ich selbst habe die nicht weil ich WW mir der Therme mach. Vielleicht im Sommer dann mit PV- Überschuss. Daher ist das auch eine ungetestete Theorie.

Mein Ansatz sieht so aus einen WW- Takt zu erkennen, ihn zu begleiten und letztenendes zu prüfen ob nach dessen Ende und einer Karrenzzeit das 3Wege Ventil noch auf WW steht. Wenn dem so sein sollte setze ich die verwendete Betriebsart neu auf die gleiche als wenn sie ohne WW eingestellt währe (siehe Modus-Matrix) und erzwinge dann ein zurückstellen des Ventils (so der Plan). Um dann 10 Sekunden später diese ursprüngliche Betriebsart wieder voreinzustellen. Ich erhoffe mir das so die WP nicht weis das vorher ein WW- Takt war und das Ventil nicht ändert aber in dem Modus Betriebsbereit bleibt.

Reine Theorie, habs nicht testen können soll als möglicher Lösungsweg dienen.
[img][/img]

Klingt schlüssig, wenn das grundsätzlich so ist. Eine Abfrage, ob defrost != 1 ist, kostet aber auch nicht viel.
Wozu setzt du den (Karenz-) Timer 2? Hast du da Probleme gehabt, wenn man das direkt nacheinander machen lässt?

Ein interessanter Ansatz, der plausibel erscheint. Auch der Code scheint schlüssig. Wenn man die eingebaute Sommerabschaltung benutzen will, wäre das ein Weg. Gute Arbeit!

Mein Plan ist eher als Basis nicht die momentane AT als Bezug zu nutzen, sondern die Mittelwerte, wenn sie schon zur Verfügung stehen. Diese repräsentieren mMn eher den Heizbedarf und bestimmen somit auch eher den Punkt, wo die Heizung aus- bzw abgeschaltet werden soll (anstatt ein Tageshöchst- oder tiefstwert). Dann auch mit deutlich kleinerer Hysterese als die Vorgabe von 3K.
Aber das hängt natürlich von der Betrachtungsweise und den eigenen Präferenzen ab.

Hast du richtig vermutet.
Hier war es so, das zwar das Ereigniss "Operations_Counter" ausgelöst wird worauf du in Rules reagieren kann aber in diesem Moment der eigentliche Wert noch nicht aktualisiert vorliegt. D.h. das du anstelle der neuen Taktnummer noch die alte bekommst. Daher habe ich ein paar Sekunden über den Timer dazwischengelegt.

Heishamon funktioniert meiner Beobachtung nach wiefolgt:
Alle 5 Sekunden wird ein Datendump aus der WP- Steuerung gezogen mit
"Requesting new panasonic data"
und die TOPs die sich seit dem letzten Dump geändert haben werden sofort als Ereignis angezeigt. Es sind aber nicht alle dabei z.B. müsste ja dauernd eine VLT- Änderung so gemeldet werden was nicht so ist.

Darüber hinaus werden alle 5 Minuten die kompletten TOP- Parameter von 1 bis 106 nacheinander aufsteigend ebenfalls als Ereignis angezeigt. Beide Zeitraster sind in den Settings erwähnt. Eine gezielte TOP- Abfrage liefert den Wert aus dem letzten Dump zurück. SET- Commandos laufen über einen Puffer relativ zeitnah. Wieviel Zeitversatz drin ist kann man sehen wenn man z.B. ein Flüsterlevel setzt und wartet dann bis dieses als Ereignis wieder auftaucht.

Um mir jetzt an dieser Stelle keine Probleme einzuhandeln schalte ich lieber einen Timer zwischen. Auch um die Programmausführung aus der "Hauptverkehrszeit" aller 106 Ereignisse am Stück rauszuhalten. Bisher hat das mit diesem Hintergrund gut geklappt. Auch beim SWV-Kick setze ich 10 Sehunden dazwischen um sicher zu gehen das kein Befehl verloren geht. Lost in Translation.

Bei den Rules halte ich mich raus, aber ich habe heute mal verglichen:

Nach Abtauung mit FL3 und Leistungsbeschränkung
Nach Abtauung ohne FL aber mit Leistungsbeschränkung
0°C AT / 33°C VL

Zumindest bei der 9kW Variante gibt es da keinen Unterschied beim Start. In beiden Fällen geht sie auf 57Hz hoch und moduliert dann runter wenn der VList = VLsoll+2° ist.

Heißt man kann sich wohl zumindest bei der 9er das mit dem Flüstermodus beim Start sparen, wenn man einfach die Leistungsbegrenzung nutzt. Bei niedrigerem VL kann das natürlich auch anders aussehen.

Bei höheren ATs / niedrigeren VL ist sie im FL3 auch mal mit 42-45Hz gestartet. In dem Fall würde aber einfach eine AT gesteuerte De-/Aktivierung des Flüstermodus reichen.

Ich habe es mal mit zusätzlichem @Defrosting_State == 0 probiert. Bei einem normalten Takt greift das auch, aber nach dem Abtauen startet sie dann ohne Flüstermodus. Es sieht fast so aus als wenn der Operations_Counter bereits einen neuen Takt anzeigt, Defrosting_State aber erst kurz danach aktualisiert wird.

Hier mal die Grafik von 2 aufeinanderfolgenden Abtauungen heute zwischen denen ich den Flüstertimer gesetzt habe um das die zweite Abtauung ohne Rules- Eingriff stattfand.
[img][/img]
Schwarz markiert der Rules Eingriff bei der ersten Abtauung die z.Zt so eingestellt ist das nach einem Start 5 Minuten lang Level 3 gefolgt von 5 Minuten Level 1. Gestartet wird beim Ersten Start im Abtau- Modus. Dieses hat aber keine Auswirkungen siehe Kompressorfrequenz bis 58Hz. Beim 2. Start nach Abtaumodus beginnen die 5 Minuten Level3 erneut.

Der grüne Ring zeigt die Auswirkungen auf die Lüfterdrehzahl die im Level1 nur noch schwach sind.

Der blaue Ring zeigt die Kompressordrehzahl. Die erste Minute ist bei beiden gleich. Dann folgt bei A1 ein Einbremsen durch den Rules- Gesteuerten Flüstermodus während bei A2 ein Durchstarten bis 47Hz erfolgt bei dem es unter kleinerer Last leicht zum Überschwingen kommen kann.

Da eine Sonderbehandlung beim Abtauuen keine Auswirkungen haben würde sehe ich hier keinen Änderungsbedarf. Höchstens mit den Zeiten könnte man noch spielen. Aber auch da sehe ich kein Problem an den z.Zt 5 Minuten Level3 nach Neustart.

Gerade konnte ich ein Abtauung mit Rules beobachten, das lief so ab:
17:03 Abtauvorgang beginnt, FM3 aktiviert
17:08 2. Timer greift und FM1 aktiviert
17:09 Abtauen beendet, Heiztakt startet und aktiviert FM3
17:13 jetzt funkt der 3. Timer vom Beginn des Abtauens dazwischen und setzt FM0
17:14 2. Timer des Heiztaktes aktiviert wieder FM1
17:19 3. Timer setzt FM auf 0 zurück

Ein kleines Durcheinander gibt es da durchaus. Auf das Ergebnis hat sich das aber nicht ausgewirkt.
Nachdem der Heiztakt mit FM3 gestartet ist, blieb der Kompressor trotz zwischenzeitlichem FM0 auf 32 Hz.

Gut beobachtet das sich hier die erste Timerkette mit einer zweiten beißt.
Hatte ich so bei mit noch nicht gesehen. ist aber ganz einfach wiefolgt abzustellen:

--> Neuer Takt beginnt:
@SetQuietMode = 3;
settimer(3,300);
Settimer(4,0);
end

on timer=3 then
@SetQuietMode = 1;
settimer(4,300);
end

on timer=4 then
@SetQuietMode = 0;
end

Das bewirkt das ein evlt noch laufender Timer (hier Timer4) abgeschaltet bzw storniert wird.

Kleiner Bug, kleines Fix.

Da war ja schon wieder einer fleißig ;-)
Ist seltsam, dass Defrosting_State erst ca. 2 Min. nach Operations_Counter den Status wechselt, aber egal. Ich habe mir auch noch Gedanken hierzu gemacht und probiere gerade diese Variante. Gut ist nicht ganz so simpel ;-)

Da der VL nach dem Abtauen ja unter dem RL liegt, sollte es hoffentlich funktionieren.
Ich werde berichten, ist ja wieder "Abtauwetter" heute.

Nach außen hin ist der Operations_Counter wie erwartet. Seltsam, dass es intern so stark verzögert ist.

Hier der Abtauvorgang mit Operations_Counter
Abtauvorgang + Operations_Counter

Der Operations_Counter kommt ja nicht zeitversetzt. Bei mir ist es Defrosting_State der erst auf inaktiv geht, wenn der Heiztakt schon fast 2 Min. wieder läuft.
Meine Rule von oben war natürlich Blödsinn, das sollte so aussehen.

Ob es funktioniert, kann ich noch nicht sagen, wenn man auf das Abtauen wartet...

Habe mir mal das Consolen- Log während einer Abtauung angesehen. Demnach sind beide KompressorStarts während der DefrostingState =1 ist. DefrostingState schaltet erst 3 Minuten nach dem zweiten Kompressorstart wieder auf 0 und ist daher als Event für Rules ungeeignet.

Bei dieser Abtauung hatte ich den Heizstab testweise deaktiviert und die VLT nach WT sinkt hierbei von 33° auf 14° ab bzw bleibt für 3 Minuten unter 17°. Hierbei besteht die Gefahr, das die WP auf Störung geht und sich abschaltet. Dann doch lieber die 10ct für den Heizstabeinsatz ausgeben. Der Heizstab läuft übrigens die ersten 3 Minuten nach dem zweiten Kompressorstart noch mit und sorgt dann dafür das die VLT direkt über die VLTsoll geht (siehe letzte Grafik). Wenn mein Haus nicht grade 4KW Leistung abnehmen würde könnte das zur Abschaltung führen. Daher macht das Einbremsen mit Rules und dem Flüstermodus Sinn. Ich werde es mit der Stornierung des zweiten Timers lösen.
[img][/img]

Wenn das funktioniert, bleibe dabei.
Meine Versuche waren bisher für die Tonne, der FM wurde mitten im Abtauvorgang aktiviert.
Eine Idee habe ich noch, dann werde ich wohl auch bei deiner Lösung bleiben.

Da Defrosting_State alleine leider nicht genutzt werden kann, der Durchfluss aber schon vor Taktbeginn nach dem Abtauen wieder gesenkt wird, habe ich es jetzt folgendermaßen realisiert.

Bis jetzt sieht es gut aus, aber ich werde es weiter beobachten.
Ich denke aber, da kann ich einen Haken dran machen ;-)