Hallo zusammen,

Meine 5KW Panasonic Jeisha Monoblock im DIY habe ich mit der Zusatzplatine Heishamon als Internet- Schnittstelle erweitert. Neben der Betriebsdatenübertragung über MQTT an ein SmartHome System können auch Befehle als url- Kommandos an die WP gesendet werden.

Das bisherige Alleinstellungsmerkmal von Heishamon ist aber die Möglichkeit selbstgeschriebene individuelle Programme auf dieser Zusatzplatine systemnah ablaufen zu lassen auch ohne funktionierendes Wlan und nachgeschaltetem SmartHome.

Dafür wird die proprietäre Programmiersprache Rules verwendet und es ist nur ein Texteditor (vorzugsweise Notepad ++) notwendig. Im Prinzip wird dadurch die WP um eine frei programmierbare Fernbedienung erweitert.

So einfach Rules auch ist gibt es doch relativ wenig verwendbare Programmbeispiele die in Kombination oft nicht zusammen passen. Daher kam die Idee einen Basisrahmen zusammenzustellen in den dann verschiedene Aufgaben als kompatibele Szenarien eingestellt werden können und diesen ggf gleich um oft verwendete Funktionen auszustatten.

An die kleine Community gerichtet (es gibt bereits mehrere Threads zu Heishamon) möchte ich nach Vorschlägen fragen und Ideen sammeln einen solchen Basisrahmen zu realisieren.

Ich gebe mal ein Beispiel was ich meine mit der Lösung die ich derzeit verwende:

Adapterer zur Bereitstellung von Triggern die Anfang und Ende einer Betriebssituation abbilden.

................................................Start..............Ende
Betriebsart............................ Timer..............Timer
-----------------------------------------------------------
Heizbetrieb (#Mode 1)............... 11................ 10
WW- Betrieb (#Mode 2)............ 21................ 20
Ruhezustand (#Mode 0)


So wird einmalig Timer 11 aufgerufen wenn der Heiztakt startet oder Timer 10 aufgerufen wenn der Heiztakt endet.

Diese getriggerten Timer erleichtern das Programmieren enorm und stellen die Basis für eine sichere Struktur dar.

Beispiel:
Setzen des Flüstermodus für 5 Minuten nach dem Start als Szene in diese Struktur eingestellt.

1) Einfache Version:
Im Timer 11 wird....................@SetQuietMode = 3;..eingestellt
Im Timer 11 wird.................... settimer(12,300);..eingestellt

Timer 12 wird angelegt mit.... @SetQuietMode = 0;


2) Luxusversion:
Im Timer 11 wird eingestellt:
.....#FLBackup = @Quiet_Mode_Level;.. -> Sichere alten Werrt
.....settimer(12,300);................................-> Rufe Rückstelltimer auf

.....Setze Level nach AT- Vorgabe
.....if @Outside_Temp >= 8 then
.......@SetQuietMode = 3;
.....else
.......if @Outside_Temp >= 0 then
.........@SetQuietMode = 2;
.......else
.........@SetQuietMode = 1;
.......end
.....end

Im Timer 12 wird eingestellt:
.....@SetQuietMode = #FLBackup;...... -> Stelle alten Weret wieder her
.....#FLBackup = -1.............................. -> Flag das Rückstellen erfolgte

Im Timer 10 wird eingestellt:
.....if #FLBackup != -1 then
.......@SetQuietMode = #FLBackup;...... -> Stelle alten Wert wieder her
.......#FLBackup = -1.............................. -> Flag das Rückstellen erfolgte
.......settimer(12,0)................................. -> Storniere Timer 12
.....end
.

Was meint ihr dazu?

Und hier noch der Code dazu mit den zwei Betriebsarten. Der Code kann um weitere Modi wie z.B. der Kühlmodus oder auch was ich brauche eine Sperrzeit- Betriebsart erweitert werden. Das hier ist die einfache Version.

Tolle Idee. Wenn bei mir geeigneter Code vorliegt stelle ich ihn gerne rein. Kann allerdings noch länger dauern.

Wie gehen wir bei Fehler, nicht dokumentierten Funktionen oder Ungereimtheiten um?
Für mich wäre es auch interessant wenn Fehler und Programmtricks hier dokumentiert würden.

Gibt s nicht bei Github oder anderswo schon solch eine Codesammlung an die wir uns ranhängen können?

Rules Interpreter stürzt gelgentlich ab.
Wenn ich den Curser jedoch vor dem "Save" an eine andere Position setze läuft er sauber durch.

Github Gist bietet sich dafür an. Man könnte einen öffentlichen Account anlegen und nach Themen sortiert diesen zur Dokumentation nutzen. Ob es sowas besonders in Deutsch schon gibt weiss ich nicht.

Mit dem Cursorclick im Rulesfenster vor Save beobachte ich mal. Manchmal ist es wirklich ein Kampf eine neue Rule einzustellen. Eine Herausforderung besonderer Art die bis zum Stromlosmachen führen kann. Ich habe die Erfahrung gemacht das er gut läuft wenn er mal läuft.


Hier mal ein Beispiel in der Analyse wie eine Szene (Bonusgrad- Funktion) mit den Basistriggern gesteuert wird.

Hier meine Kernfunktion um die Heisha mit möglichst kleiner Leistung laufen zu lassen.
Der Grundgedanke ist:
Die Zieltemperatur soll knapp über der Vorlauftemperatur sein. Das ist dann ein Lastpunkt an dem sie mit geringer Leistung arbeitet.
Die Zieltemperatur wird dann solange angehoben bis die Maximaltemperatur erreicht ist.

on System#Boot then
#DeltaP = 0;
#Tmax =45;
settimer(1,5);
end

on timer=1 then
#Outtemp = @Main_Outlet_Temp;
#Elektrisch = @Heat_Energy_Consumption;

if #Elektrisch < 600 then
#DeltaP = 4;
else
if #Elektrisch < 800 then
#DeltaP = 2;
else
#DeltaP = 1;
if #Zieltemp > 45 then
#DeltaP = 3;
end
end
end

#Zieltemp = round(#Outtemp + #DeltaP);
if #Zieltemp > #Tmax then
#Zieltemp = #Tmax;
end

@SetZ1HeatRequestTemperature = #Zieltemp;

settimer(1,60);
end


#DeltaP sind Erfahrungswerte die ich über den Sommer/ Herbst hin identifiziert habe.

Vorteile:
Die Funktion erlaubt es die WP lange mit geringer Leistung laufen zu lassen. Damit kann die höchstmögliche PV geerntet und in Wärme umgewandelt werden.
Der Lüfter der WP läuft langsam und ist damit leise.
Der Kompressor muss nur einen geringen Druck aufbauen -> lange Lebensdauer
Der Kompressor hat wenig Starts -> lange Lebensdauer

Nachteile:
Der Code muss noch erweitert werden um alle Betriebspunkte abzudecken, wie;
Anlaufverhalten, höherer Leisungsbedarf, umschalten zwischen WW und Heizung

So ganz verstehe ich den Code nicht.

Du schriebst:
... um die Heisha mit möglichst kleiner Leistung laufen zu lassen.

Das mache ich auch. Der Regelkreis wird aber gesteuert durch Überprüfung ob der Abschaltpunkt kurz bevor steht. Dann erhöhe ich die VLsoll um 1 Grad weswegen die WP dann in niedrigster Modulation weiter läuft u.s.w. bis eine Obergrenze erreicht wird.

In deinem Code erzwings du unter anderem eine Vorgabenerhöhnug bei einer Leistungsaufnahme kleiner 600 Watt. Mein Code versucht die WP so lange wie möglich unter 600 Watt zu halten. Haben wir vielleicht doch andere Ziele?

Zu deinem Code:
1) Eine Zurücknahme der Sollvorgabe ist nicht vorgesehen. Wie kommt die Temperatur nach einer Erhöhungskaskade wieder runter?
2) Du schreibst jede Minute in die WP. Das sind 1440 Schreibzyklen pro Tag. Schätzungsweise sind davon vielleicht 30 nötig. Der Rest ist unnötiger Traffic.
3) Es steht im Raum und ist nicht bewiesen das das Eprom eine begrenzte Anzahl Schreibzyklen hat. Im Modus Festwert ist es so, das intern bei jeder Änderung dieser Wert in die Heizkurvenparameter gesichert wird was einem Schreibzyklus entspricht.

@McMagellan58,
mit den Timern zu arbeiten habe ich noch nicht drauf, liest dich aber sehr gut.
Bin noch gerne mit den Unterprogrammen unterwegs, also "on xxxx then".

Die Idee die "on xxx then" Funktion aktionsorientiert zu nutzen eröffnet jedoch mir bisher unbetrachtete Möglichkeiten. Werde es sicher das ein oder andere Mal nutzen.

Warum nutzt du nur 3 Bonusgrade? Hast du Angst dass es sonst zu warm wird?
Bei mir arbeitet die WP in einen gesplitteten Speicher (oben WW unten Heizung und hydraulische Weiche) der dann auch bis zu 50°C warm werden darf. Die Heiztemperatur regle ich dann mit einem Mischer herunter.
Prinzipiell ist das mit dem Mischer nicht das beste, jedoch kann ich da tagsüber Wärme bunkern.

Das Codeschnipsel kennt nur die Erhöhung und soll nur zeigen dass die VL Temperatur hochgezogen werden kann. Klar muss diese wieder neu gesetzt werden wenn die WP erneut anläuft.

Das mit dem hohen Trafik ist ein Problem. Für die Tests aber hilfreich.
Müsste sich der Trafik nicht reduzieren wenn ich auf "on xxx then" ereignisorientiert umstelle?

Dazu die Verständnisfrage:
Wird "on #Zieltemperatur then" nur dann aufgerufen wenn die #Zieltemperatur geändert wurde?
Bisher habe ich das bewusst vermieden denn ich war mir nie sicher ob der set-Befehl auch angenommen wird.

Ich heize doch direkt in den Heizkreis und den will ich nicht über +3° überheizen. Wenn meine Rule ferig ist folgt danach eine Integralbasierte Zwangspause sodass in Tagessume eine bestimmte Wärmemenge eingebracht wird mit möglichst wenig Takten und langer Laufzeit in min Modulation.

Der Traffic läst sich wiefolgt minimieren:

if @SetZ1HeatRequestTemperature != #Zieltemp then
. @SetZ1HeatRequestTemperature = #Zieltemp;
end

Indem man vorher prüft ob überhaupt die Notwendigkeit besteht was zu ändern.

Müsste sich der Trafik nicht reduzieren wenn ich auf "on xxx then" ereignisorientiert umstelle?

brauchst du nicht wenn du es die oben löst.

Den Trafik habe ich in meinem Produktivmodell wie du zeigt schon umgesetzt.

Da mein Heizsystem etwas komplexer ausgeführt ist und auch mit der WP die WW-Bereitung zu unterstützen macht es bei mir Sinn die gesamte PV zu nutzen und dann den Speicher (dient auch als Hydraulikweiche) bis auf WW-Temperatur anzuheben.
Die Heizkreise werden dann mit einem Mischer in der Temperatur angepasst.
Vieleicht ist das COP dann nicht optimal, jedoch wenn der Strom günstig kommt scheint es mir eine kostengünstige Lösung.

Das mit der integralen Regelung interessiert mich. Kannst du deinen Ansatz mal darlegen. Da gibt es aus der Regelungstechnik ja Gleichungen und dazugehörige Codes.
Vor 40 Jahren konnte ich bei einem professionellen Wärmeberechnungsprogramm mal die Diskussion über den besten Solver mitverfolgen. Die haben da mehrere Predictorverfahren gegeneinader laufen gelassen. (Geschwindigkeit, Genauigkeit, Einfachheit, Robusthheit). Es hat sich damals herausgestellt dass das Zeitschritt-Differenzenverfahren die Anforderungen am besten erfüllte. Seither nutzte ich immer Dieses und ggf. werden die Zeitschritte verkeinert um die Genauigkeit zu erhöhen.

Es geht ausschliesslich um den Betriebszustand der entsteht durch eine zu hohe Wärmeerzeugung der Jeisha weil sie nicht weiter runter modulieren kann. Das Ideal ist dabei die Anzahl entstehenden Takte weitgehend zu minimieren. Da du ja relativ grob in einen Puffer einspeist dürfte das Takten bei dir nicht das Thema sein.

Das Prinzip ist ja in einer Zeiteinheit soviel Wärme einzubringen wie in dieser Zeiteinheit gebraucht wird (z.B. in 4h). Es ergibt sich dadurch ein Tastverhältnis weil die WP zuviel Wärme produziert. Während des Taktes passiert eine gezielte Überheizung bei minimum Modulation durch Setzen von Bonusgraden. Diese Überheizung wird kompensiert durch eine folgende Taktpause. Es gibt allerdings kein fertige Lösung weswegen das individuell eingestellt werden muss.

Die Rule begleitet den Heiztakt und erfasst minütlich aufsummierend die Grade incl der gesetzten Bonusgrade die der VL über der VLsoll ist als Überheizungsintegral.
Ich nutze aber nur eine ganz kleine Funktion damit.

Aktuelles Beispiel im Test: 3 Bonusgrade erlaubt ohne Zeitbegrenzung
1) Es sollen nur 6 Heiztakte am Tag stattfinden.
2) Bei 1440 Tagminuten / 6 = 6 Zeiteinheiten zu 240 Minuten.
3) Der Integral Checkpoint soll bei 3/4 dieser Zeit liegen = 180 Minuten
4) Vom Integralwert wird die bisherige Taktlaufzeit abgezogen (1 Integralpunkt je Laufzeitminute abziehen = Durchschnitt 1° Überheizung erlaubt zur VLTsoll)
5) Wenn zum Integral Checkpoint der korrigierte Integralwert einen bestimmten Wert z.B.200 übersteigt wird die WP ausgeschaltet.
6) Das führt in diesem Fall zu einer Sperrzeit von 60 Minuten (durch die 3/4 Vorgabe) die die vorhergehende Überheizung kompensieren soll.
7) Diese Funktion soll eigentlich nur verhindern, das dauerhaft zuviele Bonusgrade verheizt werden weswegen die Takt- Zeiteinheit zwangsgekappt wird.

Tatsächlich ist es nur ein selten vorkommender Zwischenzustand.
Normalerweise wird ein Takt beendet wenn die VLsoll + alle verfügbaren Bonusgrade + 2° für 3 Minuten vorliegen wobei dann die WP von sich aus abschaltet. Die Rule schaltet dann die WP aus sodass es kein schnüffeln gibt und nach Ende der Zeiteinheit wieder ein.
Bei dem dann folgender Taktstart beginnt die nächste Zeiteinheit was idealerweise dann zu 6 Takten pro Tag führt.
Wenn die Zeiteinheiten bei höherer Wärmebelastung durchgängig durchfahren werden ist kein Eingreifen durch Sperrzeiten erforderlich.

Bekommst du durch diese Rule auch das ständige abtauen in den Griff? Wenn die Jeisha auf einer geringen Leistung läuft sollten doch die Abtauintervalle auch um einiges länger sein?

darf ich fragen, was du beruflich machst?
ich muss einschätzen, ob es sich lohnt, dich verstehen zu wollen
wenn du Nadelarbeit unterrichtest (hast) ... muss ich deine Ausführungen kritischer beäugen, ansonsten will ich mir das gerne antun ;-)

(nix für ungut, ist auf keinen Fall böse gemeint)

Ich sehe keine Möglichkeit die Abtauungen in irgendeiner Weise zu beeinflussen. Das ist ein echtes Naturprodukt.

Bin Rentner, Beruf war Gestern :-)

Ich habe vor knapp 50 Jahren mal Fernmelder gelernt zu einem Zeitpunkt an dem es ausschliesslich Wählscheibentelefone gab.
Bevor ich mit den anderen den ganzen Tag Bingo oder Schiffe versenken spiele nehme ich mir Rules als Puzzle ohne Vorlage vor. Es ist mit der DIY- WP sowas wie meine Hobby- Modelleisenbahn geworden. Weil mich Heishamon doch so fasziniert und ich mehr als nur einen 3-zeiler schreiben wollte hoffte ich mit diesem Thread auf einen Erfahrungsautausch.

Und hier noch die Tagesgrafik von Gestern mit den anvisierten 6 Starts die dann durch die WW- Bereitung 7 wurden. Hoffe das das 4h- Raster jedes Heizzyklus erkennbar ist. Sieht aus wie eine Pulsweitenmodulation, ist es auch.

So, dann will ich auch endlich mal meinen Senf dazugeben. Meine Basisstruktur sieht nur einen 30-Sek Timer vor, von dem aus je nach Betriebszustand verschiedene Events (Funktionen) aufgerufen werden, die dann noch entsprechend mit Leben zu füllen sind:


Die -CycleStarted / -CycleStopped Events werden am Anfang und am Ende eines Heiz- oder WW-Taktes aufgerufen und die -Main Events alle 30 Sek. während der Takte.
Standby wird entsprechend alle 30 Sek aufgerufen, wenn weder Heiz- noch WW-Betrieb ist. Evtl. muss ich da noch den Zustand beim Abtauen mit aufnehmen.

Mit dieser Basisstruktur habe ich jetzt eine Abschaltung bei unter 30 VL-Soll und eine Quiet-Mode-Level Kaskade am Heiztaktbeginn realisiert. Dabei erstelle ich weitere Events / Funktionen, die aus den Basisevents aufgerufen werden. Das macht die Sache für mich verständlicher, da man den Events sprechende Namen geben kann, z.B. SwitchHeatpumpStateBasedOnTargetTempThreshold, das aus Standby aufgerufen wird

Prima! Hier mein Senf zu deinem Senf.
Genau so hatte ich das auch bis ich festetellte das ich noch eine dritte Betriebsart brauchte auch mit einstellbaren Raktionszeiten. Deshalb habe ich es etwas aufwändiger ausgestaltet und ich kann auch meine um weitere Zustände erweitern.

Im Prinzip ist es das gleiche wie das was ich mit meiner Basisrule mache nur verwende ich Timer als Event- Ausgabe weil diese bei Bedarf in der Console optimal verfolgt werden können.

In so ein "Grundgerüst" werden jetzt verschiedenen "Szenen" als Codeschnipsel eingestellt.

Bei Timern die einen Takt zyklisch begleiten sollen beginnt diese "Szene" durch Timeraufruf im Starttimer weswegen ich CycleMain nicht brauche.

Ich dachte wenn die Jeisha mit deiner Rule mit kleiner Leistung dahin brümmelt, verschieben sich doch auch die Abtauintervalle? Oder liege ich da flasch?

Die Rule nimmt ja auf die Leistung der Jeisha keinen Einfluss. Alleine die Steuerung entscheidet mit welcher Leistung gefahren wird. Die Rule dreht praktisch nur an der Stellschraube VLsoll wenn die Steuerung bei minimalster Modulation sich kurz vor dem Abschalten wähnt weil sie nicht weniger Wärme produzieren kann. Ich sehe keine Möglichkeit auf das Abtauuen Einfluss zu nehmen. Von frisieren der Sensoren des Kältekreis rate ich ab.

Letzten Winter habe ich eine Rule geschrieben die den Abstand von 2 Abtauungen ermittelt. Sollte dieser kleiner 2h sein wird die bivalente Gastherme für 6h aktiviert. Diesen Winter habe ich vor ohne die Gastherme klar zu kommen. Mal sehn wie das dann läuft.

Die Abtaunotwendigkeit bleibt doch der Pumpe selber überlassen bzw. sie triggert das nach dem Schema/Kriterien, was im service manual zu finden ist, von alleine an.

Einziger positiver Einfluss von rules könnte sein, dass man ggf. einen Startüberschuss nach Abtauen einbremst und somit schnellerer Vereisung etwas entgegen wirkt.

Da ist erstmal die Frage zu stellen warum muss sie abtauen?
In der Luft ist eine Menge Wasser enthalten (Luftfeuchtigkeit). Ist es eine trockene Luft dann passiert nichts. Die Luft kann sich ohne weiteres unter den Gefrierpunkt von Wasser abkühlen.
Ist etwas Wasser in der Luft enthalten und die Radiatoroberfläche ist kälter als der Gefrierpunktes von Wasser dann gibt es eine Vereisung.
Der Extremfall macht es klar, bei 100% Wasser gefriert das unterhalb von 0°C. Dann haben wir einen Eisblock durch den fast keine Wärme mehr geleitet werden kann.
Diese Gefrierenergie des Wassers ist endlich. Wenn der Radiator voller Eis ist dann geht da keine Luft mehr durch und es muss aufgetaut werden. Die Energie die dem Wasser entzogen wurde muss wieder zugeführt werden.

Zurück zur Frage, Ja die Abtauintervalle müssen sich je nach Temperatur, Luftfeuchte, Luftdurchsatz und Leistungsanforderungen verschieben.
Hohe Temperatur lange Intervalle, evt. unendlich.
Hohe Luftfeuchte verkürtzen unter dem Gefrierpunkt am Radiator die Intervalle.
Hoher Luftdurchsatz verlängern die Intervalle.
Hohe Leistungsanforderung verringert die Radiatortemperatur und verkürzt damit die Intervalle.

Der energetisch optimalste Zustand ist, wenn Wasser kondensiert aber noch nicht gefriert. Dann wird der Luft und dem Wasser Energie entzogen. Das Wasser tropft nach unten weg.

Meine Jeisha taktet unnötig.
Wie baut ihr bei Rules Taktpausen ein?
Oder anders: mit welchem Rules-Code kann ich die WP überlisten z.B: 1,2,3 Std. in einem Zustand zu bleiben?
Über Codevorschläge bin ich dankbar.

Genau das kann man machen. Hier mal eine Abtauung von letzter Woche mit meiner Rule im Test. Zu sehen sind zwei Kompressorstarts. Beide Starts werden von der Rule sofort mit dem Flüsterlevel 3 belegt für 3 Minuten (dicke rote Linie unten). Nach dem ersten Start (im Umkehrmodus kühlen) dreht der Kompressor auf über 50Hz und der Flüsterlevel ist wirkungslos. Der zweite Start ist wieder im Heizbetrieb und wird vom Flüsterlevel 3 enorm eingebremst. Man sieht deutlich wie der Kompressor während FL3 nicht höher geht und dann nach Rücknahme FL wieder zulegt. Siehe auch Lüfterdrehzahl oben, Leistungsbezug (dicke schwarze Linie oben) und die Wärmeproduktion (dünne schwarze Linie oben).

Hieraus kann man ableiten das ein permanenter Einsatz des Flüsterlevels zu uneffizientem Betrieb führt. Man kann aber auch sehen. das man durchaus den kraftvollen Start nach Abtauuen durch gezieltes Setzen des Flüsterlevels einbremsen kann.