Aber 65 ist doch auch unter dem, was die Pumpe überhaupt minimal liefern soll. Der Wert müsste doch mindestens 88 sein.

Die 65 sind dezimal. Habs jetzt getestet, von 64-80 hat die UWP 1500 u/min, bei 81 geht sie hoch auf 1550 u/min. Vielleicht sind die Mindestvolumenströme der jeweiligen WP unterschiedlich (meine wäre eine Jeisha Split mit 7 kW).

Ok, das setzen des @SetMaxPumpDuty zeitgleich mit anderen Befehlen dürfte Probleme verursachen, ich habe nun einmal einen zusätzlichen Timer mit einer Verzögerung von 20 Sekunden für @SetMaxPumpDuty erstellt.

In Einzelfällen ist das so. Das hängt mit dem Protokoll Heishamon -> Jeisha zusammen bei dem jeweils ein Befehl gesendet wird und auf die Quittung gewartet wird bevor der nächste gesendet werden kann. In dieser Zeit werden weitere anstehende Befehle in einem Buffer zwischengespeichert. Dabei kann es vorkommen das Befehle verloren gehen. Ich habe so einen Vorgang (korrigiere SWV im TOP27) mal dokumentiert und in Github gepostet.
Siehe diesen Link hier

Zu sehen ist hier das der von Rule abgesetzte Befehl zwischengepuffert wird, dieser dann wegen eines Timeouts offensichtlisch nicht weitergegeben wird weil es keine Antwort darauf von der Jeisha gibt.

Die Antwort war sinngemäß "Wenn du sicher sein willst ob ein Befehl durchgelaufen ist sende ihn erneut".

Ich kann aber sagen das das sehr selten vorkommt.

Ist bei meiner 5er auch nicht anders, alles unter 80 interessiert sie nicht.

Ich hatte heute einen kurzen Stromausfall von ca 10 Minuten. Da alles stromlos war kam es wieder zu dem Zustand den ich schon einmal hatte. Heishamon startet wieder auf aber die Fritzbox hat noch keine DSL- Verbindung. Das führt zu einer Default- Uhrzeit in Heishamon und in den Rules.

Währe nicht der Beachtung wert wenn Heishamon in angemessenem Abstand ein weiteres mal einen Syschronisierungsversuch machen würde was nicht mehr passiert. Nach einem Reboot über den Browser stimmt das Datum wieder.

Stromausfall ca 20:45, Zeit nach Neustart 1.Januar 1970 1:22 Uhr.




Das währe wieder ein Fall für Blockly zum Senden eines reboot- Befehls im Fehlerfall.

Bei mir war ja die Fritzbox online und nicht vom Strom getrennt. Die Zeit und Datum in der Console haben ja auch gepasst...
Und zufälliger weiße hatte ich heute morgen wieder dieses Phänomen nachdem tagelang alles gut war... 6.30 Uhr hat die WW-Bereitung gestartet ohne erkennbaren Grund und wieder bei 44°C. Up Time von Heishamon waren bei 4 Tagen, also kein plötzlicher unerwarteter reboot von Heishamon, auch die Rule ist so durchgelaufen wie es sein sollte, also auch hier keine Auffälligkeit.
Was mir aber am Code aufgefallen ist, waren einige unnötige Leerzeilen nach nicht mit ";" oder "end" abgeschlossenen Zeilen. Hat sowas Einfluß auf den Ablauf des Codes?
Als weitere Lösung und Sicherheit habe ich mir gedacht den @Main_Schedule_State zusätzlich im Zeitfenster 10-18 Uhr mit @SetMainSchedule ein/aus zu schalten. da ich sonst keine weiteren Timer der Jeisha verwende wäre das bei mir kein Problem.
Und wenn alle Stricke reißen werde ich das ganze auf die Logik-Engine von meinem Edomi-Visu Server auslagern. Aber generell hätte ich das schon gerne direkt in Heishamon/Jeisha gelöst.

Hier mal ein Foto von gestern abend bis heute morgen das den WW-Temp Verlauf und Operation Mode in Echart zeigt.
Auch heute morgen wurde wieder um 6.30 Uhr die WW-Bereitung gestartet bei 46°C... was sehr interessant und auffällig ist was nach der WW-Bereitung um ca. 20 Uhr passiert, hier wird der Operation Mode plötzlich wieder auf 4 gesetzt ohne erkennbaren Grund und obwohl die WW-Temp über der WW-Soll Temp war.

Echart

Kannst du das nicht mal auf github ansprechen?
Vielleicht können die Entwickler da etwas einzubauen.

Timer länger als 990 Sekunden?
Ich habe irgendwo gelesen, dass die max Timereinstellung 999 Sekunden wäre.
Auch sollte man die Timer kaskadieren können um Zeiten größer 999 s zu erreichen.
Aber wie?
Ich habe es zum Beispiel so probiert was aber nicht funktioniert weil es nicht akzeptiert wird:

on timer=40 then
setTimer(41,120);
end

on timer=41 then
@SetQuietmode = 0;
end

Weiss jemand wie man es macht?

Timer 40 wird endlos minütlich durchlaufen und lässt eine Variable mitzählen.
Wenn die gewünsche Minutenanzahl erreicht ist (hier 120 Minuten) wird der Befehl abgesetzt.


on System#Boot then
..#Faktor1 = 0;
end


on timer=40 then
..if #Faktor1 < 120 then
....#Faktor1 = #Faktor1 + 1;
....setTimer(40,60);
..else

....@SetQuietmode = 0;
....#Faktor1 = 0;
..end
end

Abbrechen des Timers mit "settimer(40,0);"


Die Variable muß vorher mit eine Wert versorgt werden bevor der Timer aufgerufen wird. (in System#Boot)

Danke McMagellan58.
Werde ich mal probieren.
Der Hintergrund ist folgender:
Bei Temperaturen >7°C moduliert meine Jeisha auf 19Hz runter und geht dann nach ca. 1h aus. Dann nach 15 min macht sie weiter.
Ich möchte nun diese Pause auf mindestens 1h vergrößern. Dazu will ich dann die Sommerabschaltung für >= 45 min auf den kleinsten Wert setzen damit sie nicht wieder schon nach 15 min angeht.

Moin Moin... also für mich ist Rules erstmal Geschichte....
Irgendwie macht das Ding was es will und hält sich nicht wirklich an Anweisungen...
Selbst wenn ich den Main_Schedule_State auf 0 setzte wird fröhlich die WW-Bereitung gestartet und wieder bei 44°C eben so wird der Schalter den @McMagellan58 am Anfang eingebaut hat komplett ignoriert... Irgendwas läuft da mi der Kommunikation schief... Aus/Einschalten und stromlos hatte keinen erfolg.
Selbst einfacher Code zum testen wird mal ausgeführt und mal ignoriert...
Wünsch euch trotzdem besinnliche Feiertage

@Geisha2021:
Bist du bei deinem Vorhaben weiter gekommen?

Ich arbeite ja auch daran und nach etlichen Versuchen will ich nun einen neuen Versuch starten unter Berücksichtigung meiner vorhergehenden Erfahrungen. Mittlerweile habe ich konkrete Vorstellungen wie es arbeiten soll. Ich werde es in Rules umsetzen.

Hast du interresse an einer gemeinsamen Realisierung? Es soll aber ohne die Sommerabschaltgrenze zu verschieben realisiert werden.

Darf ich Fragen was der aktuellster Code zum Bonusgrad zur Laufzeitverlängerung ist?

Der Thread ist mittlerweile recht unübersichtlich geworden und wenn ihr nur den Bonusgradschnipsel zur Hand hättet wäre ich euch sehr dankbar. :)

Auf GitHub von Jockel ist nur das Bonusgrad zur Startabbruchverhinderung so wie ich das gesehen habe.

Richtig, Laufzeitverlängerung ist bei mir nicht nötig und ich habe mich nicht weiter damit befasst.

McM hat sich aber etwas zur Laufzeitverlängerung ausgedacht, er kann dir da sicher weiter helfen.

Hallo McMagellan, zunächst möchte ich dir ein Gutes Neues Jahr wünschen und vor allem Gesundheit.
Ich glaube du gehörst ja auch zu älteren Generation wie ich (bald 72) und da ist Gesundheit mit das Wichtigste.

Meine Rule zur Auszeit-Verlängerung:
Bei Temperaturen >7°C moduliert meine Jeisha auf 19Hz runter und geht dann nach ca. 1h aus. Dann nach 15 min macht sie weiter.
Ich möchte nun diese Pause auf mindestens 1h vergrößern. Mit der Sommerabschaltung geht das nicht da erst bei größer 8°C (5°C + 3K) abgeschaltet wird.
Deshalb schalte ich mit folgender Rule die WP aus und aktuell nach 30min (für Testzwecke) wieder ein. Die Zeitspanne zur Wiedereinschaltung kann man dann verlängern indem man die Schwelle für den #Faktor2 entsprechend hochsetzt.

Beschreibung:

Ab Zeile 8 wird geprüft ob der Heizmodus beendet ist. Bei "Ja" wird der Timer 2 gestartet.
Ab Zeile 16 wird geprüft ob der Heizmodus für mindestens 10 min aus ist und ob kein WW gemacht wird.
Bei "Ja" wird die Wärmepumpe ausgeschaltet.
Ab Zeile 31 wird geprüft ob die 'WP für mindestens 30 min ausgeschaltet ist.
Bei "Ja" wird die Wärmepumpe wieder eingeschaltet.

Hier die Rule:

on System#Boot then
#HeatWPoff = 240102;
#Version = 2;
#Faktor1 = 0;
#Faktor2 = 0;
end

on @Heat_Power_Production then
if @Heat_Power_Consumption == 0 then
settimer(2,20);
else
#Faktor1 = 0;
end
end

on timer=2 then
if @Heat_Power_Consumption == 0 then
if @DHW_Power_Consumption == 0 then
if #Faktor1 <= 10 then
#Faktor1 = #Faktor1 + 1;
settimer(2,60);
else
@SetHeatpump = 0;
settimer(3,10);
#Faktor1 = 0;
end
end
end
end

on timer=3 then
if @Heatpump_State == 0 then
if #Faktor2 <= 30 then
#Faktor2 = #Faktor2 + 1;
settimer(3,60);
else
@SetHeatpump = 1;
#Faktor2 = 0;
#Faktor1 = 0;
end
end
end

Nötig ists bei mir insofern auch nicht, weil ich 200qm FBH als Speicher habe, aber mit meiner sehr flachen Heizkurve (5°C Steigung zwischen -15 und 15) bzw. den allgemeinen Bedingungen passiert es aktuell 2x in der Woche dass Sie bei 7°C noch gerade so auf minimaler Leistung durchläuft und bei 8°C die Heizkurve 1 Grad runter springt und sie dann aus geht.

Nach 4-5 Stunden geht sie dann Abends/Nachts wieder an und gibt erstmal Gas.
Das Bonusgrad wäre bei mir ideal um sie bis ca. 11°C AT am laufen zu halten.
Das hab ich manuell schon getestet.

Die Heizkurve will ich eben nicht verändern, weil das ja alles ändert. Die Laufzeitverlängerung wäre quasi nur eine ganz flache "Stufe" und auch nur im Ausschalt-Verhalten.

Meine Rule zur Auszeitverlängerung:

Funktioniert manchmal nicht. In der Console steht dann:
Wed Jan 3 06:17:27 2024 (49577553): sent bytes: 111 including checksum value: 18
Wed Jan 3 06:17:28 2024 (49577874): set heatpump state to 1
Wed Jan 3 06:17:28 2024 (49577877): Already sending data. Buffering this send request
rule_function_set_timer_callback set timer #3 to 10 seconds

Der Befehl "set heatpump state to 1" wurde also nicht ausgeführt sondern gepuffert.

Deshalb wurde die "Verlängerung" nicht gestartet.
Wie könnte man das verhindern?

Das die Gesundheit das Wichtigste ist kann ich bestätigen. Ich bin jetzt seit 11 Jahren in der "Verlängerung" und hoffe für dieses Jahr das die Vergänglichkeit noch ein Jahr aussetzt.

Habe mir deine Rule mal angesehen. Für den Anfang ist das nicht schlecht. Es gibt aber ein paar Dinge die aus der Erfahrung mit Rules heraus entstehen die man besser anders lösen sollte. Daher habe ich mal einen Entwurf entwickelt wie ich die Aufgabenstellung lösen würde und dir auch als Tutorial vorschlage.

1) Sichere Erkennung einer Pause nach einem Heiztakt.
2) Führen eines Zeitstrahls beliebiger Länge während eines Heiztaktes (positv ansteigend)
3) Führen eines Zeitstrahls beliebiger Länge während der Heiztaktpause (negativ absteigend)
4) Vermeidung von Heishamon Triggerpunkten.

Dieses Gefüge lässt es auch zu z.B. den Flüsterlevel zeitgesteuert nach einem Heizstart einzusetzen.

Hier mal der kommentierte Entwurf. Ich habe ihn nicht testen können. Bei Bedarf kann ich dir die Textdatei zur Verfügung stellen.

Aber schau dir das erstmal in Ruhe an was hinter der Logik steckt.

.

Ich finde es cool, wieviel Boomer sich mit dem Thema WP befassen und es scheinbar besser in den Griff bekommen, als so mancher Heizungsbauer.
OK wir haben auch mehr Zeit ;-)

Ich kann hier keine Fehlfunktion erkennen. Man muss allerdings wissen wie Heishamon hier tickt.

1) Der Eintrag "set heatpump state to 1" ist eine Nachricht an den "Postausgang zur Jeisha" die von Rules ausgelöst wird mit dem Kommando "@SetHeatpump = 0;"

2) Das "Heatpump = 0" zu "heatpump state to 1" wird darf dich dabei nicht stören. Die WP wird ausgeschaltet.

3) Dafür wird "Heatpump = 1" zu "set heatpump state to 2" und schaltet die WP wieder ein.

4) "Already sending data. Buffering this send request" ist ein normale Vorgang. Der Postausgangsbevollmächte (PM1) kann immer nur einen Auftrag bearbeiten und wartet auch immer schön ab ob sein letzter Auftrag auch von der Jeisha bestätigt wurde : Received 203 bytes data bevor er einen weiteren Vorgang angeht. Zwischenzeitlich werden weitere Anfragen in einer Warteschlange (Buffer) zwischengeparkt.

5) In deinem Consolenauszug ist vorher zu sehen : sent bytes: 111 including checksum value: 18
Diese Zeile besagt, das der PM1 zuvor eine Anfrage bearbeitet hat und jetzt auf Antwort wartet. So eine Anfrage kann die zyklische Abfrage alle x Sekunden sein.

6) Deshalb wird der set- Befehl in die Warteschlange gestellt.
In der weiteren Folge des Konsolenmitschnitts gibt es dann die Meldung : Sending command from buffer. Hier hat der PM1 wieder sonst nichts zu tun, schaut auf die Warteschlange, stellt fest: Oups, da is ja noch eener und arbeitet diesen dann ab.

7) Ob der Befehl wirklich durchgelaufen ist kannst du sehen wenn die nächste oder übernächste Routinabfrage nach Zeit durchgelaufen ist. (: Requesting new panasonic data)
Mit der Antwort der Jeisha kommt ein kompletter Parameterdatensatz zurück. Diesen nimmt sich der Posteingangsbevollmächtigte (PM2) zur Brust und vergleicht erstmal alle neuen Parameter mit dem des vorherigen Zustands. Sollte sich was geändert haben wird dieser Parameter wiefolgt angezeigt wenn die WP ausgeschaltet wurde.
: received TOP0 Heatpump_State: 0 Sollte die WP schon eingeschaltet gewesen sein gibt es keine Rückmeldung da kein Unterschied zum vorhergehenden Zustand.

8) Da wir grade dabei sind: An dieser Stelle wird vom PM2 bei Parameteränderung ein Trigger in Heishamon ausgelöst (on @Heatpump_State then) den Rules sofort bearbeitet. Dumm ist nur das der zuletzt empfangene Wert zu diesem Zeitpunkt noch nicht in die Rules- Variable @Heatpump_State übertragen wurde und daher bei Abfrage noch der alte Wert gilt. PM2 ist halt nicht der schnellste.


P.S. Habe einen Fehler in meinem Entwurf entdeckt. In Zeile 101 muss es heissen:
@SetHeatpump = 1;
Typischer Copy & Past- Flüchtigkeitsfehler.

Hallo @McMagellan,
danke für deinen Vorschlag. Ich werde das mal probieren.
Meine Rule würde ja auch funktionieren wenn sie das machen würde was ich programmiert habe:

on @Heat_Power_Consumption then
if @Heat_Power_Production == 0 then
settimer(2,10);
else
#Faktor1 = 0;
end
end

"@Heat_Power_Production" war vorher schon "0"

Folgendes hat die Rule gemacht:

Thu Jan 4 12:03:57 2024 (15474001): received TOP16 Heat_Power_Consumption: 0
==== @Heat_Power_Consumption ====
>>> rule 2 nrbytes: 151
>>> global stack nrbytes: 36
rule #3 was executed in 2207 microseconds

>>> local variables

>>> global variables
4 #HeatWPoff = 240102
12 #Version = 4
20 #Faktor2 = 0
28 #Faktor1 = 0

settimer(2,10); wurde also nicht ausgeführt! Warum?

Ich habe mal so eine Takt- Ende Situation nachgestellt und analysiert.
Das ich kein Freund der TOP- Trigger bin hatte ich oben schon geschrieben. Schau dir mal diese Analyse an:

Das erste Bild zeigt alle TOP15- Meldungen an nach denen du Triggerst. Ein Trigger wird bei Änderung des Wertes ausgelöst und turnusmäßig alle 300 Sekunden wenn es nicht im Heishamon- Setup geändert wurde. Der gelb markierte Eintrag ist der Beginn der Konsolenanalyse auf dem zweiten Blatt.





Hier ist zu sehen, das der Trigger nah der TOP15- Meldung sofort ausgeführt wird. Ich habe hier aber eine Test-Rule laufen die in diesem Trigger den Wert von TOP15 in die Variable "#Production1" schreibt. Wie zu sehen ist steht in dieser Variable nicht der aktuell getriggerte Wert sondern der vorhergehende alte Wert weil er in Rules noch nicht aktualisiert wurde. Ich rufe einen Timer 3 Sekunden später auf und lese den selbe Datenpunkt TOP15 erneut eben zeitversetzt aus und schreibe ihn in die Variable "#Production2". Und jetzt stimmt der Wert weil er zwischenzeitlich aktualisiert wurde. Auch gibt es einen Zeitversatz von 10 Sekunden zwischen dem TOP15 und dem TOP16 die theoretsch gleichzeitig auf 0 gehen sollten.




Daher halte ich es für Sinnvoller einen 1- Minuten Endlostimer 1x pro Minute checken zu lassen ob der Heiztakt zu Ende ist.

Ausserdem kann es sein, das beim Start von Rules ohne das es vorher einen Heiztakt gegeben hat deine Rulestimer loslaufen wenn die WP am Schnüffeln ist.

Hallo @McMagellan58,
mein Kompliment für deine Analyse. Meine Version ist gestern prima durchgelaufen und heute habe ich deinen Ansatz mit dem Endlostimer mal simuliert.

Statt die WP immer ein oder auszuschalten habe ich dafür die Sommerabschaltung @Heating_Off_Outdoor_Temp mit verschiedenen Werten verwendet.
Funktionierte prima und habe es jetzt mit den @SetHeatpump Befehlen aktiv geschaltet.

Heute sind jedoch die Aussentemperaturen niedrig sodass die WP durchläuft.

Bei meinen Anfängen mit den TOP triggern hat mich gestört, dass standardmäßig alle 5 min immer alle Werte abgerufen werden und dann natürlich events ausgelöst werden.

Mit dem Endlostimer hat man das Problem nicht und die Rule ist viel eleganter.

Danke für deine Unterstützung.

Gruß Uli