Öffentliches Forum
  - Wärmepumpen

Über Festwert fahren und VLsoll mit Heishamon vorgeben geht auch, aber es geht @McM um die Timer zur SWV. Die kann man mit fester Startzeit eben nur an der WP und nicht in Heishamon einrichten.

Ich glaube das weiß keiner so genau, wo diese Daten abgelegt werden.
Wenn man mal die Fühler kalibriert sind hinterher alle Timer weg. Und stellt man die Heizung zwischen Steuerung nach Festwert und Heizkurve hin und her, stehen da auch plötzlich wieder Standardwerte.
Nach längerer Zeit ohne Strom soll sich wohl auch einiges zurück setzen.
Bleibt die Frage, was wirklich im EEProm festgehalten wird...

Alles klar, dann war ich ja auf dem richtigen Weg. Ich habe es mal dazu geschrieben.

Ist auch der Grund warum ich im Moment nicht mit dem Node-Red Addon fahre (Link). Das funktioniert auch über Festwert und dann kann man die SWV nicht mehr nutzen.

Ich sehe schon, du durchblickst das Parameterkonstrukt.
Prinzipiell gibt es nur den SWV- Parameter TOP27 den man im Bezug auf die VLT-Sollvergabe ändern kann.

Bei Festwert steht in diesem der absolute Wert. Im Wochentimer stehen auch absolute Werte die dann bei Erreichen des Zeitpunkts den TOP27 überschreiben. Man kann jetzt diesen Parameter überschreiben doch bei der nächsten Timerzeit wird er wieder überschrieben werden.

Im Wochentimer kann ich pro Tag Absenkzeiten oder Boosterzeiten definieren die aber als Offset zur "Basis-Soll Temp" arbeiten sollten. Im Grunde kann ich über einen Parameter keine 2 Funktionen fahren.

In der Betriebsart "Heizkurve" sind "Basis Soll- Temp" und Offset (-5 bis +5) getrennt und unabhängig. Die Basis Soll Temp hat keinen TOP und ist das Ergebniss der internen Heizkurvenberechnung die aus extern nicht verändert werden kann.

Doch! Mit einem Trick geht es. Wenn ich nun die Vorgabedaten der internen Heizkurvenberechnung frisiere geht die Rechnung wieder auf. Wenn nun die VL-Temperatureckwerte gleichgeschaltet werden und mit Rules auf den gewünschten Wert gebracht werden (TOP29 und TOP30) liefert die interne HK-Berechnung egal bei welcher AT immer den Wert den ich voreingestellt habe. Und auf den setzt dann der Timer sein Offset und das Ergebniss steht in TOP42 als Vorgabe für HK1 im Heizbetrieb. Das sehe ich als beste Lösung an das Zappeln der internen Vorgabe zu
zähmen.

Warum nun Rules den Befehl für TOP29 und TOP30 nicht kennt JSON aber schon erschliesst sich mir nicht. Vielleicht hat auch bisher keiner an die oben beschriebene Variante gedacht. Ideal währe ein Universal-Rules Befehl wie z.B. @SetTOPXXon = YYY; mit dem man jeden TOP setzen könnte. Dann bräuchte man uns den nur sagen.

Vielleicht kann man das ja nachträglich erklären wenn der Entwickler nach der Sinnhaftigkeit nachfragt.

Genau so ähnlich habe ich das mit meinen bescheidenen Englischkenntnissen mal bei einer Anfrage zu einem neuen Befehl gelesen. Sinngemäß: "Bisher hat das noch niemand gebraucht/nachgefragt."
So ein Universalbefehl wäre natürlich genial.

Habt ihr schon ein
@SetCurves = {"zone1":{"heat":{"outside": {"low": -15}}}};
probiert?

Passt vielleicht nicht ganz zum Thema, aber ich glaube ich habe die Viertelgrad-Werte für Vor- und Rücklauftemperatur gefunden. Hilft zukünftig vielleicht bei der Regelung.

Byte 118 decrypt:
Inlet Water Temperature [°C]
1st, 2nd & 3rd bit
.00 b001
.25 b010
.50 b011
.75 b100

Outlet Water Temperature [°C]
4th, 5th & 6th bit
.00 b001
.25 b010
.50 b011
.75 b100

Issues #293

Danke!
Bin gespannt, was die Entwickler dazu sagen.

Bei mir läuft grade der Langzeittest meiner Rules weswegen ich es nicht probieren kann. Vom Sysnax her dürfte es hier nicht funktionieren.

Ansonsten bin ich mit dem Ergebniss meiner Rules bisher sehr zufrieden.

Wurde schon implementiert, und es läuft ;)

Wow, das sind ja mal tolle Nachrichten! Respekt für deine Analyse! Endlich vernünftige Werte.
Bin seit einigen Tagen nun auch endlich soweit, Heishamon und raspi mit iobroker und influxdb laufen jetzt. Hat doch einiges an Zeit gekostet sich in die Themen komplett rein zu arbeiten und einige Stolpersteine weg zu räumen. Heute Abend dann mal die neue Firmware flashen. Wie schaffe ich das beim update eine checksum mitzugeben, was ja zur Sicherheit empfohlen wird, um keine ggf beschädigte .bin aufzuspielen?

Die erste Rule (danke nochmal Jockel!) läuft und endlich reicht es einen Timer für WW zu setzen ohne unnötige Heizungsparameter mitgeben zu müssen. Sie braucht dann noch die kleine Erweiterung, dass sich vor dem Aktivwerden des Timers der vorherige Operating_Mode_State gemerkt wird, auf den dann zurückgesetzt wird, dann klappt das auch im Sommer. Sicher lässt sich dann auch eine bessere Sommerabschaltung über die selbst berechneten AT-Mittelwerte realisieren.
Werde mich in den nächsten Tagen an dem Code versuchen vernünftige EMA's in der Rule hin zu bekommen.

Die Jungs sind ja echt fix!
Danke auch dir nochmal für die Arbeit.

Wenn du die neue Alpha Version meinst, das trägt sich die von alleine mit ein, ableitend aus dem Dateinamen.

Ja, die meinte ich. Danke für den Hinweis, werde es heute Abend hoffentlich probieren können.

Hast du sie schon drauf und hast in Grafana die Zwischenwerte?

Die TP-gefilterten Werte, die du hier mit drin hast, sind aber von anderen Sensoren, oder?

Klappt einwandfrei.

Ja, sind zwei ADT7422. Diese sind sehr genau, (+- 0,1°C absolute Genauigkeit), da diese jedoch außen am Kupferrohr angebracht sind, leider auch ein bisschen träge.

Ich habe mich bei diesem Chart ein bisschen mit dem Volumenstrom gespielt, damit ich den Vorlauf anpassen kann, Rücklauf geht auch ein bisschen damit, aber nur ganz leicht. Ist halt eine BKA ;)

Ja das sieht jetzt aus wie in der Cloud.

Prima. Hab's jetzt auch drauf, sieht gut aus.

Darf ich fragen, was du mit der absoluten Genauigkeit bezweckst?

Eine dT Messung zur Berechnung der Heizleistung und nachdem ich mit einer Spreitzung von 1,5-3 K arbeite, sollten die Sensoren sehr genau sein. Die Temperatursensoren könnte man zwar auch auskalibrieren (habe ich auch getan, die Sensoren liegen um ca. 0,015°C auseinander) aber das ganze soll ja auch über einen größeren Temperaturbereich funktionieren. Die Teile kosten aber auch nur ein paar Euro, wobei ich nach dem Winter auf PT1000 mit Tauchhülse aufgrund der kürzeren Reaktionszeit umsteigen wollte, naja vielleicht brauch ich es ja jetzt nicht mehr.

Dass die Genauigkeit einigermaßen hoch sein sollte, verstehe ich ja. Nutze ja selbst einiges an billigen DS18B20 die per Regression zueinander kalibriert sind.

Aber warum dir eine hohe zeitliche Auflösung so wichtig ist, verstehe ich noch nicht so ganz.

WW, durch die Trägheit wird bei schnellen Temperaturänderungen die Messung ungenau.

Verstanden habe ich es noch nicht so ganz.
Bedeutet es, das Heishamon jetzt die VLT in TOP6 und die RLT in TOP5 nicht mehr nur als Ganzzahl sondern in einer Auflösung von 0,25°- Schritten anzeigt.
Wenn es so währe könnte ich das auch in Rules nutzen. Um das Schnüffeln zu begrenzen setze ich einen Kick in TOP27 wenn die VLT um mehr als 3K unter die VLTsoll fällt. Bei 4K dauert es mir zu lange, bei 3K ist es ein wenig zu kurz. Daher könnte man dann als Referenzwert 3,5K nehmen.

Kannst du mal in der Console schauen ob dort die bessere Auflösung zu sehen ist?

Ja die Auflösung ist definitiv besser.
Mal springt es um 0,5 und mal auch 0,25 was wohl den Sensoren geschuldet ist.

Gibt es die Version mit der feineren Auflösung als binary im Download oder kompiliert ihr selber?

Gruß,
Lars

Danke, sieht brauchbar aus.
Wie kommt man an diese neue Version und wie geht die Übertragung in Heishamon. Habe mit updaten keine Erfahrung und währe froh über eine kurze Anleitung.