Öffentliches Forum
  - Wärmepumpen

Hier die BIN-Datei als ZIP-Datei runterladen (gelb markiert im Bild) und danach entpacken:


Dann bei Heishamon auf Firmware gehen:


BIN-Datei auswählen, Checksum Feld wird automatisch gefüllt, dann Update Firmware anklicken und warten bis es fertig ist:

Ups, da war einer schneller ;-)
Ich musste anschließend noch einmal manuell rebooten, da die Rules nach dem Update nicht mit gestartet waren.
Guck bitte mal vorher in der Console, ob das bei dir auch so ist.

Gibt es eigentlich irgendwo eine Art Auflistung welche Funktionen und Parameter mit Heishamon gesteuert werden können? Da mein KNX Modul nur die nötigsten Grundfunktionen steuert und anzeigt, was mir generell reichen würde, aber in den Anfängen eben zu "kastriert" ist... Bin ich am überlegen ob ich mir noch Heishamon integriere. Ich weiss parrallel geht nur lesend....

Klar doch:

https://github.com/Egyras/HeishaMon/blob/master/MQTT-Topics.md
https://github.com/Egyras/HeishaMon/blob/master/OptionalPCB.md

Ich habs geschafft dank guter Anleitung!!
Danke an mieschc und Jockel_Bln :-)

Ich habe jetzt auch in Rules diese Grad- Zwischenschritte zur Verfügung.
Da ich in der Jeisha 3 Dallas 1Wire Sensoren für VL, RL und AT die auch über Heishamon laufen verbaut habe, kann ich jetzt diese Sensorwerte direkt mit den TOP- Werten vergleichen. Hier mal eine tabellarische Gegenüberstellung der Sensoren mit Differenzen.

Schade das sich zum Thema Schreiben TOP29 und TOP30 aus Rules heraus nix tut.
[img]

@SetZ1HeatRequestTemperature interpretiert Werte zwischen -5 und 5 als Sollwertverschiebung, über 20 als absolute Temperatur. Darüber lässt sich die bestehende Heizkurve bequem adaptieren.

Alternativ ein JSON-String aufbauen und an @SetCurves übergeben.

Das finde ich auch sehr schade, vielleicht geht es aber auch nicht. Wäre nur schön, wenn jemand das kommunizieren würde.

Wie war es bei dir nach dem Aufspielen der FW und dem automatischen Neustart, waren deine Rules wieder aktiv, oder musstest du auch noch einmal manuell neu starten?
Bei mir liefen sie komischerweise nicht. Ähnliches Verhalten hatte ich schon 2-3 Mal, plötzlich war die Uptime im WebIF scheinbar zurück gesetzt und die Rules liefen nicht mehr.

Es geht hier ja um Steuerung mit Rules und da geht @SetCurves und JSON-String meines wissens nicht.

@McM möchte ja die SWV per Wochentimer weiter nutzen und die, mit Rules extern berechnete, VLT an TOP29 und TOP30 weitergeben.

Ich hab es nun hinbekommen, zwei kaskadierte EMA in eine Rule zu packen. Die Gesamtfilterlänge ist hier mal mit 48h vorgegeben (FilterStundenGesamt = 48, nur Ganzzahlen >=1). Messwerte wie gehabt alle 15min einer.
Als Starttemperaturwert einen vernünftigen Mittelwert der letzten 1-2Tage mit Faktor 1000 angeben (Hier: Starttemperaturwert1000 = 7100 für 7,1°)

Zum testen den Timer von 900 auf 5 Sekunden setzen und die Konsolenausgabe beobachten.

EMA2 liefert das Ergebnis als Dezimalzahl auf drei Nachkommastellen.

Vielleicht komme ich morgen dazu die Heizkurve dazu zu bauen, Beispiele gab es hier dazu ja schon.

Hier der Code, der auch ohne Formatierung 1:1 copy/paste gehen müsste.



Optisch simuliert mit Temperaturdaten von meteostat.net sieht das ganze so aus:


Seit ca 10 Tagen fahre ich die Kurve von Hand nach dieser Grafik an und es passt ziemlich gut, morgens gut 20° und abends ca 21°.
Bald dann hoffentlich automatisch per Rule.
Danach folgt noch eine Version mit automatischer Überkompensation als Alternative zur timergesteuerten Nachabsenkung/Taganhebung. Mal sehen, ob das zu gebrauchen sein wird.

Kommen die Variablen auch über das MQTT Debug Topic? Dann könnte man einen kleinen Parser schreiben damit die Variablen wieder zur InfluxDB und somit Grafana wandern könnten. Das wär denk ich relativ schnell gemacht und man könnte in die rules „reinsehen“

Das kann ich heute abend mal checken.
Das wäre natürlich gut zur längerfristigen Analyse.

Wenn man durch die HK aktiv Z1_Heat_Request_Temp schreibt, hat man ja auch eine Rückmeldung via MQTT in Grafana, aber natürlich "am offenen Herzen", was in dieser überschaubaren Anwendung zu verkraften wäre, wenn man erstmal in der Nähe bleibt ;-)

Was man auch machen kann um zu beobachten, ob der Filter planmäßig reagiert, ist, den Startwert auf 0 setzen und die Sprungantwort (also die nächten errechneten Werte) zu beurteilen. Dabei den Timer zum Test auf 5s. Zum Vergleich kann man sich eine Exceltabelle mit den gleichen Eingangswerten (1. Wert "0", danach alle zB "6") und der gleichen Funktion basteln. Bei Interesse kann ich mal eine solche Tabelle bereitstellen.

Das geht auch prima wenn einem die Bandbreite von 11° als Handlungsspielraum reicht. Was halt nicht mehr geht ist der Wochentimer weil ich dort bei jedem Eintrag eine Angabe machen muss die in Konflikt mit mit meiner Vorgabe steht. Damit kann ich nichtmal eine Sperrzeit realisieren. Als Krücke könnte man so noch einen Aus-Eintrag setzen und mit Heishamon sie wieder nach einer Laufzeit wieder anschalten.

Daher bin ich ja auf der Suche nach einer Alternative. Diese gibt es auch indem man die interne HK-Berechnung + Offset durch TOP27 so weterlaufen lässt. Einzig die Eckwerte der HK auf eine Basistemperatur setzt und gleichschaltet. Dadurch liefert die interne Berechnung egal bei welcher AT immer den gewünschten extern voreingestellten Wert. TOP29 und TOP30 extern Vorgeben. Und der Wochentimer funktioniert ohne Einschränkung.


Da ich versuche das alleine in Rules zu realisieren habe ich diese Möglichkeiten nicht.

Wenn doch ein JSON- String gesendet an Heishamon von Heishamon auf die WP-Parameter umgesetzt wird warum sollte es nicht möglich sein einen Heishamon Rules- Befehl von Heishamon auf die WP- Parameter umzusetzen.

Oder weiss jemand wie @SetCurves in Rules zu verwenden ist.

Nachdem es etwas klemmte, was aber im Nachhinein betrachtet am WLan gelegen haben könnte habe ich mich dazu entschlossen einen Factory Reset zu machen. Das überleben die Rules nicht. Ist aber kein Problem den Textfile einfach neu reinzukopieren. Gefühlte 250x gemacht in den letzten Tagen.


Arbeiten ohne Doku mit Rules ist ja z.Zt. weitgehen Try and Error. Oder kenn jemand das System was dahinter steckt mit entsprechender Doku?

Die letzten 4 Tage lief Rules problemlos durch. Was mir aufgefallen ist, das es einen Unterschied gibt ob Rules mit dem Save- Button gestartet wird --> (Boot- Ereignis wird ausgeführt) und einem Heishamon Reboot bei dem viele Variablen auf NULL stehen.
Wenn ich danach Rules neu Save stimmen die Vriablen auch wieder. Auch habe ich schon gehabt das es 2 Variableneinträge gleichen Namens gibt von denen einer auf NULL steht.

Theorie: Wenn das System nun einen Reset fährt und du nur einen Timer hast der ursprünglich durch Boot gestartet wurde läuft dieser nicht mehr und würde nur durch SaveRules neu gestartet.

Das ist mir auch aufgefallen. Ich vermute aber, es dauert nach dem Reboot einige Zeit, bis alle Werte aus der WP ausgelesen sind. Wenn nun on System#Boot then ausgeführt wird, sind sie noch nicht (alle) da und es wird NULL eingetragen.
Ich habe das für mich so gelöst:
on System#Boot then
setTimer(1,40);
end
Die Variablen werden dann erst mit dem Timer bzw. der dann ausgelösten Funktion befüllt.
Das klappt bisher bei jedem manuellen Reboot.

Habe das gerade mal getestet und in den Setting Debug log to MQTT topic from start aktiviert.
Im iobroker kommt dann die komplette Ausgabe der Console an, außer Timer und Variablen :-(

Wie empfindlich soll denn deine VLTsoll sein? Wie oft willst du den Wert in der WP aktualisieren?
Ich habe ja neben der FBH noch Radiatoren und ich merke grade das die bei diesen Temperaturen zu wenig Leistung bringen weswegen ich dynamischer reagieren muss.

Ich fahre anstelle einer Formel mit dem Schnitt aus 4 historischen Variablen die ich zu einstellbaren Zeiten aktualisiere bzw jeweils eins weiter schiebe um den chronologischen Temperaturverlauf zu sehen. Hier mal ein Screenshot.
[img][/img]
Derzeit aktualisiere ich alle 90 Minuten einen AT-Wert in T1 bis T4 wobei T1 der älteste Wert ist, bilde in T5 den Schnitt und errechne über die HK dann den gewünschten VLsoll in Vorlauf. Übertragen in TOP27 wird dieser dann alle 3h bei langen Takten oder langen Taktpausen oder wenn ein Takt endet um eine mögliche Wertänderung in die Taktpause zu legen.

Mein Code zur Ermittlung der zu verwendeten gemittelten AT sieht so aus. Da Mathe nicht so mein Ding ist halte ich es eher einfach.

on TimeEvent1 then
#Version = 5.411;
#T1 = #T2;
#T2 = #T3;
#T3 = #T4;
#T4 = @Outside_Temp;
#T5 = (#T1 + #T2 + #T3 + #T4) / 4;

if #T5 < #ATmin then
#T5 = #ATmin;
end

if #T5 > #ATmax then
#T5 = #ATmax;
end
end

Sie soll so oft wie nötig, so selten wie möglich und vom Zeitpunkt so günstig wie möglich geändert werden. Das Exceldiagramm zeigt ja eigentlich sehr gut was passiert (bzw per Rule passieren soll). Als erstrebenswert sehe ich an, dass eine kommende Sollwerterhöhung tendenziell am Vormittag und eine Verringerung am Nachmittag stattfinden soll, um die höheren Tagestemperaturen gut zu nutzen. Dazu ist eine Verschiebung der Extremwerte um ca. 12h nötig, was in der gefilterten AT mal mehr mal weniger gut hervor tritt.

Mit 4 Werten alle 90min ist deine Basis ein ungewichteter MA über die letzten 4,5h.
Ich kann nur von meinem Haus (40cm Ziegel + 10cm WDVS) sprechen, aber hier dauert es immer 1-2 Tage, bis ein Temperaturumschwung innen spürbar wird. Eine Verzögerung von so kurzer Zeit wäre hier zu wenig. Bei längerem ungewichtetem MA werden dann aber die alten Werte zu stark betont. Daher EMA.

Wenn deine Innentemperatur dauerhaft bei gleichbleibend niedriger AT zu niedrig ist, passt die HK nicht. Ist sie nur zu niedrig, wenn es draußen kälter (wärmer) wird, ist der Filter zu träge (flink). Zu flink dürfte der Standard für die interne Heizkurve im Massivbau sein.

Ein EMA ist vom Prinzip auch nicht komplizierter als ein MA, für den man aber viel mehr Werte zwischenspeichern muss. Einzig die Umrechnerei wegen Ganzzahlwerten lässt es hier komplizierter erscheinen, was im meinen Augen aber lohnt. Er rechnet ja eigentlich nur
wert = (neuer wert + (x+1) * alter wert) / x,
wobei x = 0,5 * Anzahl der Perioden ist, über die gefiltert werden soll (und mir gerade auffällt, dass ich in meinem Code wahrscheinlich noch hinzufügen muss, dass #FilterStundenGesamt noch durch 4 geteilt werden muss.)

Nee, die 4 hatte ich schon berücksichtigt. Da wir ja im Viertelstundenzyklus abfragen, hat sie sich rausgekürzt.

Also die 0,5 pro Filter stimmt, es sind aber zwei kaskadiert, die 4x pro Stunde abfragen. Womit sich die 4 wegkürzt.

Das nehme ich auch. :-)


Was letzte Woche noch gut gepasst hat passt Heute nach 3 "sonnenlosen" Tagen nicht mehr. Mein 40 Jahre alter "Altbau" ist aus 36,5 er Poroton mit 3fach Verglasung aber ohne sonstige Dämmung und man merkt förmlich wie sich die Kälte ins nur teilbeheizte OG schleicht.


So langsam erkenne ich, das das Vorhaben zur Findung der optimalen VLT- Vorgabe ein haschen nach dem Wind ist. Mal zurück zum Anfang. Für mich war der Hauptgrund die witterungsgeführte VLT-Regelung der Jeisha zu ändern das unruhige Zappeln was zu zusätzlichen Takten führte. Das zu verhindern und bei dieser Gelegenheit gleich die HK insgesamt zu glätten war dann das Ziel.

Heute überlege ich dieses Vorhaben fallen zu lassen. Ganz genau genomme sehe ich für mich das Problem darin, das die WP ihre VLTsoll zu schnell anfährt und erst zurückregelt wenn die VLTsoll schon überschritten ist. Dann ist es nur noch 1 weiteres Grad und 3 Minuten bis zur Abschaltung. Sie lässt sich einen zu engen Spielraum und stolpert dann über eine einfache 1-grätige Temperaturvorgabenänderung.

Ich habe in Rules ein weiteres Modul laufen bei dem ich die VLT- Hysterese kontrolliere. Darin erkenne ich das unmittelbar bevorstehende Abschalten (3 Minuten bei VLTsoll +2K) und setze einfach vorher die VLTsoll um 1K höher, so eine art Bonusgrad. Dann läuft sie weiter bis zum nächsten Abschaltpunkt 1K höher an dem ich sie aber dann abschalten lasse. Nach Taktende nehme ich das Bonusgrad wieder aus der VLT-vorgabe raus. Sollte zwischenzeitlich die VLT wieder unter die VLTsoll sinken nehme ich das Bonusgrad auch wieder zurück ohne Auswirkungen.

Diese temporären "Korrekturen" kann ich über TOP27 einfach einspielen durch:
Alt auslesen -> Korrektur drauf -> Neu überschreiben
selbst wenn der Wochentimer aktiv arbeitet. Ich verhindere damit ein Abschalten durch Zappeln nach unten in dem ich Gegenzappel. Ein Zappeln nach oben führt sowieso zu einer längeren Laufzeit und bedarf keiner korrektur.

Wenn diese Beruhigung zu einem akzeptabelem Taktverhalten führt mit der internen Heizkurve schenke ich mir die externe VLTsoll- Berechnung.

Und das passiert auch wenn die WP durch Änderung der AT den VLsoll absenkt, reagiert dann das Modul schnell genug und eine Abschaltung zu verhindern?
Dann müsste ich mir vielleicht auch mal was in der Richtung ausdenken. Meine Takte sind normal eh über 2h lang, momentan sogar bis zu 5h, da brauche ich eigentlich nichts zu verlängern. Mich stört nur wahnsinnig, dass sie sofort abgewürgt wird, wenn die AT sich ändert. Da hätte ich gern, dass sie den Takt noch zu den alten Bedingungen beendet.

Ob er das schafft wird die Zeit und die Aufzeichnungen zeigen. Ist ja alles noch im Beta mit mehr Theorie als Praxis. Schalte ab jetzt mal zurück auf die interne Heizkurve.
Habe hier mal die Grafik von Heute kommentiert. Musste die Formeln anpassen weil jetzt die VL / RL- Werte nicht mehr als Ganzzahl reinkommen.
[img][/img]

Stell doch mal eine Grafik von dir ein.

in welchem Objekt findet sich die Ausgabe dann?

Zeilenweise in mqtt.0.panasonic_heat_pump.log?

Vielleicht ja nicht mehr weit weg.

AT-geführte VLT kann natürlich mangels Rückkopplung niemals den echten Bedarf vorhersehen, sondern nur den empirisch gemittelten. Dazu würde man eine Raumaufschaltung benötigen.
Fremdwärme in Form von zB Sonne kann erheblich sein, auch eine ungedämmte Ziegelwand ist da anfälliger als eine mit Außendämmung. Konvektionsverluste durch Wind sind auch nicht zu verachten und verfälschen den Heizenergiebedarf in die andere Richtung.

Dass es mal passt und mal nicht, kann mit o.g. Faktoren zusammenhängen oder eben auch mit im Mittel sich ändernden AT im Zusammenhang mit der Trägheit des Gebäudes.

Schau dir mal auf meteostat.net für deinen Standort den kompletten November an, dann zeigt das Diagramm die Tagesdurchschnittstemperaturen (schwarze Linie). Dein VL-Soll sollte sich entsprechend deiner Heizkurve verhalten, im Idealfall verzögert. Also nur bei halbwegs konstanten AT kann man die passende VLT und damit einen Punkt auf der HK überhaupt erst einigermaßen verlässlich bestimmen. Um die Funktion der Gerade komplett bestimmen zu können, braucht es einen zweiten Punkt, der freilich in einer anderen Wetterlage bestimmt werden muss. Ich habe das zum Großteil über den Fußpunkt gemacht, da macht es schon einen großen Unterschied, ob man die 26° VLT bis 13 oder 15° AT fährt.
Das schöne an meteostat.net ist, dass man auch für die kommende Woche die Vorhersage mit einbeziehen kann und, dass bei Anzeige <13 Tagen die Stunden- statt Tageswerte angezeigt werden und auch einfach nach Excel exportiert werden können.

Ich hab mal auf Ubakus.de eine Porotonwand 35cm T18 +2*4cm Kalkputz gerechnet, der U-Wert liegt mit 0,463 W/m²K nicht so viel schlechter als meine mit 0,316. Auch die Phasenverschiebung (Reiter "Hitze") liegt massivwandtypisch bei mehr als einem halben Tag. Allerdings hat deine Mauer wg der geringeren Masse nur ca. die halbe Speicherfähigkeit, was insgesamt dafür spricht, dass dein dein Haus etwas schneller und auch etwas stärker auf Änderungen reagiert.
Aus dem Bauch würde ich den EMA2-Filter mit 24 oder 36h mal in die Rule einbauen. Aber vorher sollte sichergestellt sein, dass die HK passt.
Die kommenden Tage eigenen sich mit den stetig fallenden Temperaturen bei uns sehr gut um die Trägheit des Filters zu beurteilen.

Jetzt sind wie hier natürlich wieder OT, aber wollte noch kurz ergänzen, dass deine Porotonwand nicht nur die halbe Masse hat, sondern auch die Dämmfähigkeit nicht wie bei einer WDVS-Wand quasi nur außen sitzt, sondern über das gesamte Bauteil verteilt ist. Somit vermindert sich die Speicherfähigkeit nochmals deutlich. Siehe Reiter "Hitze" im Ubakus: die Wärmespeicherfähigkeit der inneren Schichten fällt auf ein Viertel. Also wirst du doch einen recht flinken Filter brauchen. Vielleicht wird das Verhalten so flink sein müssen, dass du tatsächlich zur kalten Tageszeit die größte Heizleistung erzeugen musst und eine 12h-Verschiebung nicht mehr komfortabel ist. Wahrscheinlich würde ich trotzdem mit einem Filter über 24h anfangen.