| | Zeit:
23.11.2022 12:19:42 |
Weil einiges im Nachbarthread untergegangen ist, soll es hier speziell um die Steuerung der Jeisha mit Heishamon und Rules gehen. Bitte Fragen zu iobroker und anderen Systemen weiterhin in diesem Thread diskutieren. Danke!
|
| Zeit:
23.11.2022 12:20:17 |
Hier mal der letzte Beitrag aus dem Nachbarthread... Zitat von McMagellan58  Zitat von Jockel_Bln  Viel hatte ich nicht drin, nur eine Berechnung dar AT über 12h ohne weitere Auswertung und meine Regel zum Umschalten des 3-Wege-Ventils. Es lief einmal gut 1 1/2 Tage und einmal gerade 6-7h Habs mir mal angeschaut und konnte es nicht lassen meine Idee dazu mal als Vorschlag umzusetzen. Konnte es aber nicht ausprobiert weil meine Rules grad im Langzeittest laufen. Ich würde die Datenbasis als Schieberegister ausführen weil du dann immer chronologisch auf die letzten Werte zurücksehen kannst und die Einschreibroutine einfacher ist. Deine Version hat mir zu viele Klammern. Ich meinte mal gelesen zu haben das nicht mehr als 4 Verschachtelungen (if-end) binnen eines Timers gehen. Ich verwende anstelle TAB 3xLeerzeichen. Einschreiben Loop auf >3 geändert anstelle >4. Du schläfst wohl nie ;-) Von den maximalen Verschachtelungen habe ich noch nichts gelesen. Ist aber auch kein Wunder, da sich mein Englisch in Grenzen hält und deutsche Dokus habe ich noch nicht gefunden. Überhaupt sind das für mich alles noch "Böhmische Dörfer". Schieberegister, warum ist mir das nicht eingefallen. sowas hatte ich mir schonmal in Blockly gebastelt. Ich habe das mal nachgebaut und ein paar Sachen (Tippfehler?) geändert. Habe es gerade erst in Heishamon gestartet und denke aber, dass es funktionieren wird. Ähnlich läuft es doch auch in deinem Projekt, nur mit 4 statt 12 Messungen, oder? Ich lasse es erst mal eine Weile mitlaufen, dann schau wir mal.
|
| Zeit:
23.11.2022 20:35:04 |
Zitat von Jockel_Bln  Ähnlich läuft es doch auch in deinem Projekt, nur mit 4 statt 12 Messungen, oder? So ist es. Danke für die Einrichtung dieses Extra- Threads. Hier mal der nächste Schritt (von AT zu VLT) als Vorschlag so wie es bei mir läuft. Das kannst du ja mal gleich mittesten wenn du magst, währe aber auch an deiner Lösung mal interressiert. Ansonsten läuft mein Programm mit den 3 Modulen jetzt seit 2 Tagen durch und besonders die Kontrolle der VLT- Hysterese gefällt mir gut. Den Betriebszustand VL erhöhen muss ich nochmal überarbeiten. [img] [/img]
|
| Zeit:
23.11.2022 21:16:18 |
Ich werde wohl so schnell nicht auf Rules umsteigen. Die Analyse- und Testmöglichkeiten sind mir einfach zu beschränkt. Wenn ich die berechneten Werte nicht in Grafana bekomme damit ich diese visualisiert bekomme oder man einfach mal Tests machen kann ohne direkt steuern zu müssen nimmt mir das die Lust. In iobroker ist das mit JavaScript jedenfalls auf ne Stunde erledigt und man kann alles besser nachvollziehen. Ich möchte euch das nicht vorenthalten, vielleicht hilft es ja dennoch bei der Adaption. Der EMA über einen Tag ist bei mir ausreichend, mein Haus reagiert relativ zügig aus AT-Schwankungen. Seit ich das Script laufen habe, hat sich aber die VL Temperatur nicht verändert. Die Temperatur schwankte zwischen 0-5°C und der EMA dämpft alles weg. Danke für eure Idee, so läuft sie schön ruhig. iobroker_ema.jsEine Sache bei Rules, warum habt ihr für jede Messung eine Variable? Gibt es eine Beschränkung, dass ihr nicht einfach mit dem letzten EMA Wert weiterrechnen könnt?
|
| Zeit:
24.11.2022 11:05:04 |
Zitat von hacki11  Ich werde wohl so schnell nicht auf Rules umsteigen. Die Analyse- und Testmöglichkeiten sind mir einfach zu beschränkt.
Eine Sache bei Rules, warum habt ihr für jede Messung eine Variable? Gibt es eine Beschränkung, dass ihr nicht einfach mit dem letzten EMA Wert weiterrechnen könnt? Schön das du mit nur einer Formel klar kommst. Mir ist es lieber wenn ich einen Blick auf den historischen Temperaturverlauf habe was nur geht mit den vielen Variablen. Ich habe es gerne so simpel wie möglich. Für Java und MQQT- Kram reicht mein Horizont altersbedingt leider nicht mehr. Daher ist Rules für mich grade noch so zu stemmen. Du hast aber vollkommen recht mit den beschränkten Test und Analysemöglichkeiten. Bisher kam ich aber klar damit. Da Rules sehr Systemnah angebunden ist erhoffe ich mir diverse Programmkorrekturen damit realisieren zu können. Wie Stabil das läuft wird die Zeit zeigen. Zum Beispiel habe ich vor wiefolgt auf die VLT- Hysterese Einfluss zu nehmen: Wenn die VLT die VLTsoll um 2° für 3 Minuten übersteigt schaltet der Kompressor ab. Diese Marke wird oft durch zu hoher Startwärme und auch durch zu unruhige AT- Vorgabe erreicht weswegen es zu unerwünschten Takten kommt. Rules soll nun diese anstehende Abschaltung erkennen und einfach die VLTsoll um 1° erhöhen damit es nicht zur Abschaltung kommt. Dieses " BonusGrad" wird dann nach Taktende wieder aus der VLsoll entfernt. Im Grunde wird dadurch der obere Hysteresepunkt verschoben sodass die WP das 2. Grad über VLsoll nicht nur 3 Minuten antestet sonder dieses voll durcharbeitet. Dadurch werden die Takte verlängert und die Pausen danach ebenfalls. Diese Aufgabe löst Rules zu meiner vollen Zufriedenheit. Währe sowas auch in deiner Programmumgebung möglich? Einen weiteren Eingriff in die Steuerung habe ich in der Taktpause realisiert. Wenn die VLT die VLTsoll um mehr als 3° unterschreitet erfolgt ein Startanreiz. Das setzt einen klar definierten unteren Hysteresepunkt und ein "Endlosschnüffeln" gibt es nicht mehr. Die Hysterese ist somit klar definiert mit: Abschalten bei VL Überschreitung der VLTsoll von 2°. Wiedereinschalten bei Unterschreitung der VLsoll von 3°. In der Grafik sieht es sehr gut und harmonisch aus. Jetzt bleibt zu hoffen das Rules das dauehaft und zuverlässig leistet. Uns das ganz ohne Wlan- Umgebung.
|
| Zeit:
24.11.2022 11:25:24 |
Hier mal eine Grafik dazu. Schön zu sehen das bei VL-Überschreitung der Vorgabe um 2 Grad die blaue Linie der Sollvorgabe nachzieht und dadurch eine anstehende Abschaltung verhindert. Der Takt wird dadurch künstlich um die Zeit die die blaue Linie angestiegen ist verlängert. Hier sind das ca 50% Laufzeitverlängerung, also weit entfernt vom Kurzzeittakten. [img] [/img]
|
| Zeit:
24.11.2022 11:47:00 |
Zitat von McMagellan58  ...währe aber auch an deiner Lösung mal interressiert. Moin, wenn ich sehe, was du da schon so zusammen geklöppelt hast, wird mir ganz schwindelig. Ich bekomme das alles nur schwer in den Kopf und ein zusammenklicken mit Blockly wäre mir fast lieber. aber wir wollen ja unabhängig vom WLAN und eventuellen Ausfällen/ Wartungsarbeiten eines zusätzlichen Systems sein. Ich wollte es eigentlich viel simpler machen, ganz ohne Berechnung einer Heizkurve. Momentan fahre ich mit interner waagerechter HK 26/-15, 26/15 und versuche herauszufinden, bei welcher Durchschnittstemperatur ich eine SWV machen muss. Wenn ich die Werte zusammen habe, würde ich gern einmal (vielleicht auch 2x) am Tag eine Funktion aufrufen, die dann die entsprechende SWV ausrechnet. Diese SWV soll dann der Wert für @SetZ1HeatRequestTemperature sein. Eventuell mache ich das auch mit fester VLT, aber der Spielraum +/-5K sollte mir auch reichen. Um die benötigte SWV zu bestimmen habe ich mir sowas hier gedacht, aber noch nicht getestet. Wie gesagt, das ist nur ein Beispiel und ich habe eigentlich gar keine Ahnung von dem was ich hier mache ;-) Anstatt der fest definierten Werte in der Funktion könnte man auch Variablen nehmen, die dann bei Systemstart festgelegt werden, dann kann man schneller mal etwas ändern und muss nicht erst suchen. Wenn das einfacher geht bin ich für jeden Tipp offen. Ja so richtig schnell komme ich nicht voran. Irgendwie raucht mir gerade schon der Kopf und meine Frau kommt auch andauernd mit "tollen Aufgaben" für mich :-(
|
| Zeit:
24.11.2022 12:01:47 |
Zitat von McMagellan58  Hysterese ist somit klar definiert mit: Abschalten bei VL Überschreitung der VLTsoll von 2°. Wiedereinschalten bei Unterschreitung der VLsoll von 3°. Dazu mal eine Frage. In dem Bild dazu im anderen Thread hast du die Zeilen @Quiet_Mode_Schedule == 0 then mit Sperre gekennzeichnet, was meinst du damit? Kannst du dann im Schnellmenü durch Aktivierung des Flüstertimers die Rule deaktivieren?
|
| Zeit:
24.11.2022 12:41:09 |
Zitat von Jockel_Bln  Dazu mal eine Frage. In dem Bild dazu im anderen Thread hast du die Zeilen @Quiet_Mode_Schedule == 0 then mit Sperre gekennzeichnet, was meinst du damit? Kannst du dann im Schnellmenü durch Aktivierung des Flüstertimers die Rule deaktivieren? Ja so soll es sein. Dadurch habe ich die Möglichkeit den Rules- Eingriff in die lfd Steuerung wahlweise von der Kabelfernbedienung abzuschalten. Das erste Modul was ich realisiert habe ist ja die Startwärmebremse durch automatisch gezieltes Zuschalten des Flüstertimers nach Taktstart. Da diese Funktion in Konkurrenz zu dem evtl gesetzten Flüstertimer steht habe ich mir das so gedacht das mein Rules- Eingriff eben nicht stattfindet wenn der Timer aktiviert ist. Quasi ein Schalter. Das habe ich dann für das 2. Modul der VLsoll Berechnung und das 3.Modul der Hysterese-Control auch so programmiert. Die Aktivierung des Flüstertimers erfordert allerdings mindestens einen Eintrag. Ich habe dann einfach Level 0 zu einer belibigen Zeit eingetragen und es geht, hat aber im lfd Betrieb keine Auswirkungen.
|
| Zeit:
24.11.2022 13:19:23 |
Aha, danke für die Bestätigung 👍
|
| Zeit:
24.11.2022 21:06:21 |
Zitat von McMagellan58  Zitat von hacki11  [...] Schön das du mit nur einer Formel klar kommst. Mir ist es lieber wenn ich einen Blick auf den historischen Temperaturverlauf habe was nur geht mit den vielen Variablen. Ich habe es gerne so simpel wie möglich. Für Java und MQQT- Kram reicht mein Horizont altersbedingt leider nicht mehr.[...] Sehr sehr cool! Ja ich kann das Robustheitsargument der Integrierten Lösung sehr gut nachvollziehen und freut mich, dass es klappt. Das ist auch das tolle an solchen Internet-Community-Maschinen. Es sind soviel Leute da, die Dinge vorwärts bringen damit man mehr aus dem Produkt rausholen kann. Im Gegensatz zu anderen Produkten die nicht mal eine Schnittstelle anbieten. Mit MQTT sollten eigentlich dieselben Variablen lesbar und schreibbar sein wie per rules. Eine solche dynamische VL Anpassung ist gar kein Problem. Brauch ich aktuell nicht, da meine J9 schon durchläuft. Wenn die Zeit des Takten kommt werd ich wohl sowas machen wie du
|
| Zeit:
24.11.2022 21:28:36 |
Ich bin auch von dem Dauerschnüffeln betroffen, und hab versucht das Temperaturintegral der Nibe Wärmepumpen mit Heishamon zu emulieren: Wenn eine Schwelle von Grad*Minuten (Variable #dtiMax) unterschritten wird, dann wird ein Startimpuls per Sollwertverschiebung generiert. Weiß jemand, wie man in diesem Forum Code formatieren kann? on System#Boot then #dtiMax = 576; setTimer(1,60); #dti = 0; end on timer=1 then $TVL = @Main_Outlet_Temp; $TVLT = @Z1_Water_Target_Temp; if $TVL < $TVLT then #dti = #dti + $TVLT - $TVL; else #dti = 0; end if #dti > #dtiMax then setTimer(2,10); #dti=0; @SetZ1HeatRequestTemperature = @Z1_Heat_Request_Temp + 3; end setTimer(1,60); end on timer=2 then @SetZ1HeatRequestTemperature = @Z1_Heat_Request_Temp - 3; end
|
| Zeit:
24.11.2022 23:05:48 |
Zitat von Rebirama  Ich bin auch von dem Dauerschnüffeln betroffen, und hab versucht das Temperaturintegral der Nibe Wärmepumpen mit Heishamon zu emulieren: Wenn eine Schwelle von Grad*Minuten (Variable #dtiMax) unterschritten wird, dann wird ein Startimpuls per Sollwertverschiebung generiert. Weiß jemand, wie man in diesem Forum Code formatieren kann? Hallo Rebirama, schön zu sehen das sich noch jemand mit Rules beschäftigt :-) Du schreibst von einer Nibe WP an der du Heishamon betreibst welches eigentlich an der Heisha, und Jeisha funktioniert? Währe demnach die Nibe WP eigentlich eine Panasonic? Dein Code ist clever gemacht. Ich bin nicht betroffen von dem Dauerschnüffeln deshalb schau ich nur mit einem Auge drauf falls ich es doch mal brauch. Die Pumpe läuft m.M.n. auch nach einer Art Hysterese die aber nichts mit dem Kompressor zu tun hat. In meiner Grafik von oben kann man das schön sehen, das die Pumpe nach einer Zeit des Maxbetrieb langsam heruntermoduliert auf min Leistung von ca 10L/min. Dann schaltet der Kompressor ab und die Pumpe geht in den Schnüffelmodus der auch den 10L/min entspricht. Bei mir wird der Schnüffelmodus abrupt beendet wenn der Rücklauf um mehr als 2° unter die VLsoll fällt (gut in der Grafik grüne Linie RL, Volumenstrom hellblau zu sehen). Das währe dann der untere Hysteresepunkt der bei mir aber immer in die Taktpause fällt lange vor dem nächsten Start. Dann Kickst du den SWV gleich mit 3° für 1 Minute. Ist das nicht ein bisschen viel? Die Formatierung mit führenden Leerzeichen oder Tabs geht hier im Thread leider verloren. Daher mach ich meistens ein Bild vom Ausdruck. Dann kann man auch entsprechende Kommentare dazu schreiben um es besser zu verstehen. Hier mal meine Kicks als Wiederstartanreiz allerdings genau definiert wenn die VLT um mehr als 3° die VLsoll unterschreitet. [img] [/img]
|
| Zeit:
25.11.2022 09:37:59 |
Ein kleiner Tipp, da vielleicht noch nicht bekannt. Normalerweise ist es ja so, dass im Betriebsmodus Heizen + DHW die WP nach dem DHW-Betrieb den Heizbetrieb nicht startet, wenn die eingestellte Vorlauftemperatur nicht mehr als 3K über der Rücklauftemperatur liegt. Im Betriebsmodus (nur) DHW tritt dieser Effekt nicht auf und die WP startet, wenn im Wochentimer der Heizbetrieb nach dem DHW gesetzt wurde, ohne Probleme mit der Heizung. In der Vergangenheit hatte ich im Wochentimer den DHW-Betrieb und 2,5 Stunden später den Heizbetrieb gesetzt. Leider mit dem Nachteil, dass wenn die WP schneller mit dem DHW-Betrieb fertig war, diese längere Zeit nicht auf Heizen ging oder wenn die DHW-Phase länger dauern würde, diese vom Wochentimer abgebrochen wurde. Mit der Rule von Jockel_Bln für das 3-Wege-Ventil gibt es nun aber eine super Lösung, einfach zur gewünschten Uhrzeit im Wochentimer den DHW-Betrieb setzen (somit wird der Heizbetrieb unterbrochen) und nach Beendigung schaltet die WP durch die Rule von Jockel_Bln mit gleicher Vorlauftemperatur in den Heizbetrieb ohne die Startschwierigkeit des DHW+Heizen Betriebs. Ich werde zwar den Code von Jockel_Bln noch anpassen, damit im Sommer auch der Kühlbetrieb läuft, aber fürn Winterbetrieb passt es vorerst einmal.
|
| Zeit:
25.11.2022 09:54:50 |
Ergänzend noch ein Diagramm dazu, Vorlauf vor DHW 26°C und nach DHW 25°C, Vorlauf Request 25°C und Rücklauf 24°C. |
| Zeit:
25.11.2022 17:16:59 |
Zitat von Jockel_Bln  Ich wollte es eigentlich viel simpler machen, ganz ohne Berechnung einer Heizkurve. Momentan fahre ich mit interner waagerechter HK 26/-15, 26/15 und versuche herauszufinden, bei welcher Durchschnittstemperatur ich eine SWV machen muss. Wenn ich die Werte zusammen habe, würde ich gern einmal (vielleicht auch 2x) am Tag eine Funktion aufrufen, die dann die entsprechende SWV ausrechnet. Diese SWV soll dann der Wert für @SetZ1HeatRequestTemperature sein. Eventuell mache ich das auch mit fester VLT, aber der Spielraum +/-5K sollte mir auch reichen. Hier mal skizziert wie ich die durch Rules ermittelte VLTsoll in die Steuerung bekomme. Das ist derzeit ein Provisorium weil ich doch noch versuche die volle Funktionalität des Wochentimers zu erhalten. Dazu müsste ich das Rules Ergebniss gleichgeschaltet in die Parameter TOP29 und TOP30 eintragen. Für MQTT gibt es diesen Befehl aber in Rules nicht. Er müsste idealerweise @SetZ1HeatCurves(32,32); lauten. [img] [/img]
|
| Zeit:
25.11.2022 18:12:31 |
Es gibt SetCurves mit denen du die Heizkurve definieren kannst. Würde der für dein Vorhaben helfen?
|
| Zeit:
25.11.2022 18:56:54 |
Zitat von Rebirama  Wenn eine Schwelle von Grad*Minuten (Variable #dtiMax) unterschritten wird, dann wird ein Startimpuls per Sollwertverschiebung generiert. Weiß jemand, wie man in diesem Forum Code formatieren kann? Die Variante ist auch eine Überlegung wert. Da ich in der Übergangszeit gern mit 25° VL fahren will, ist es mit der Einschaltschwelle von soll VL - 3K so eine Sache. Mitunter kann das eine halbe Ewigkeit dauern, da würde sie nach Grad*Minuten sicher eher wieder zu Potte kommen. Gerade wenn es wieder mal einen Startabbruch gab. Code lässt sich hier leider nicht formatieren :-( Zitat von McMagellan58  Bei mir wird der Schnüffelmodus abrupt beendet wenn der Rücklauf um mehr als 2° unter die VLsoll fällt (gut in der Grafik grüne Linie RL, Volumenstrom hellblau zu sehen). Das währe dann der untere Hysteresepunkt der bei mir aber immer in die Taktpause fällt lange vor dem nächsten Start. Da beneide ich dich um deine interne Steuerung. Meine dreht generell frühestens mit dem Start des Kompressors hoch, meist aber viel später. Anfang Oktober war ich im Urlaub und habe die Jeisha einfach mal machen lassen. An einem Tag ist weder die UWP noch der Kompressor aus dem Schlaf erwacht, obwohl VL und RL schon 5K unter Soll waren. Zuvor war auch kein Startabbruch, sondern ein ganz normaler Takt. Auch moduliert die UWP während des Taktes nie runter, sondern geht mit Taktende abrupt in den Schnüffelmodus. Zitat von berhan  Ein kleiner Tipp, da vielleicht noch nicht bekannt. Normalerweise ist es ja so, dass im Betriebsmodus Heizen + DHW die WP nach dem DHW-Betrieb den Heizbetrieb nicht startet, wenn die eingestellte Vorlauftemperatur nicht mehr als 3K über der Rücklauftemperatur liegt. ... Ich werde zwar den Code von Jockel_Bln noch anpassen, damit im Sommer auch der Kühlbetrieb läuft, aber fürn Winterbetrieb passt es vorerst einmal. Inzwischen habe ich auch nur noch einen Timer pro Tag, der WW einschaltet. Das Ausschalten übernimmt dann die Rule. Die Bedingung habe ich auf @Operating_Mode_State != 0 angepasst, damit greift sie immer, egal ob DHW oder DHW + HEAT. Für den Sommer will ich mir auch noch etwas überlegen, damit sie nach dem WW komplett ausschaltet. Zitat von McMagellan58  Zitat von Jockel_Bln  [...] Hier mal skizziert wie ich die durch Rules ermittelte VLTsoll in die Steuerung bekomme. Das ist derzeit ein Provisorium weil ich doch noch versuche die volle Funktionalität des Wochentimers zu erhalten. Dazu müsste ich das Rules Ergebniss gleichgeschaltet in die Parameter TOP29 und TOP30[...] Das grenzt ja schon an Raketentechnik :-) Falls du der englischen Sprache mächtig bist, kannst du doch mal auf github oder im Slack von Igor nachfragen, ob sie noch einen Command Topic hinzu fügen können. Ich habe mal gelesen, dass wohl mehr möglich ist. Es wurde nur nicht umgesetzt, da niemand es benötigt hat. Zitat von hacki11  Es gibt SetCurves mit denen du die Heizkurve definieren kannst. Würde der für dein Vorhaben helfen? Da muss man aber ein JSON Dokument senden, Rules kann wohl nur Zahlen.
|
| Zeit:
25.11.2022 20:14:02 |
Zitat von Jockel_Bln  Falls du der englischen Sprache mächtig bist, kannst du doch mal auf github oder im Slack von Igor nachfragen, ob sie noch einen Command Topic hinzu fügen können. Ich habe mal gelesen, dass wohl mehr möglich ist. Es wurde nur nicht umgesetzt, da niemand es benötigt hat.. Das ist für mich das Problem mit github und englisch. Ich könnte mir vorstellen, das es nur ein kleiner Aufwand ist diese hierfür benötigte "@SetZ1HeatCurves-Kommando" zu realisieren weil es ja als Json File über Heishamon schon supportet wird. Hier mal die Skizze wie ich es mir im Idealfall vorstelle sodass die Wochentimer-Funktion voll erhalten bleibt und Tagesprofile wie Nachtabsenkung oder PV Bonusgrade über die Fernbedienung ermöglicht. [img] [/img] Hier weden aber Parameter von Heishamon überschrieben die vermutlich im EEProm stehen der möglicherweise einen limitierten Schreibzugriff hat. Wie muss das bewertet werden? Kann jemand dazu was sagen. Eigentlich müsste jede Betriebsstunde und jeder Takt zu Schreibzugriffen führen weil diese Zähler auch nichtflüchtig sind. Was machen dann die vielleicht 4 weiteren Schreibzugriffe pro Tag zur gedämpften VLTsoll noch aus.
|
| Zeit:
25.11.2022 21:52:56 |
"Z1_Heat_Curve_Target_High_Temp", //TOP29 "Z1_Heat_Curve_Target_Low_Temp", //TOP30 "Z1_Heat_Curve_Outside_High_Temp", //TOP31 "Z1_Heat_Curve_Outside_Low_Temp", //TOP32
Kann man in Rules einfach diese Variablen setzen?
edit: ich seh gerade, dass du das eh machst. Ok, dann hab ich nicht verstanden was du noch benötigst.
|
| Zeit:
26.11.2022 00:02:02 |
Zitat von hacki11  "Z1_Heat_Curve_Target_High_Temp", //TOP29 "Z1_Heat_Curve_Target_Low_Temp", //TOP30 "Z1_Heat_Curve_Outside_High_Temp", //TOP31 "Z1_Heat_Curve_Outside_Low_Temp", //TOP32
Kann man in Rules einfach diese Variablen setzen?
edit: ich seh gerade, dass du das eh machst. Ok, dann hab ich nicht verstanden was du noch benötigst. Du hast genau das erfasst wie ich es machen will. Leider sind diese Befehle nicht in der Bibliotheke der Rules zur Verfügung stehenden Befehle enthalten. Stattdessen gibt es einen Hinweis auf einen Befehl SetCurves anzuwenden mit einem JSON- File (mit Beispiel angegeben). Ich kann aber aus Rules keinen JSON-File absetzen. Es bleibt die Hoffnung das Rules um diese, vielleicht vereinfachten Befehl, z.B. @SetZ1HeatCurvesTarget(Maxwert,Minwert) oder eben getrennt als @SetZ1HeatCurveTargetHighTemperature = 32 --> setzt TOP29 und @SetZ1HeatCurveTargetLowTemperature = 32 --> setzt TOP30 implementiert wird kann doch Heishamon das schon machen nur nicht über Rules. Jetzt brauchen wir noch jemand der das mal dem Entwickler vorschlägt
|
| Zeit:
26.11.2022 00:22:09 |
https://github.com/Egyras/HeishaMon/issues/291 Habe meinen englischenText mal eben durch den Google-Übersetzer gejagt, um ihn hier zu posten. Hoffe ich habe das Kernproblem getroffen, falls nicht bitte mal hier kurz schreiben ;) Wir haben einige Leute in unserer deutschen Heishamon-Community, die nur die Heishamon-Regeln und kein zusätzliches Zeug von Drittanbietern (MQTT-Broker usw.) verwenden möchten, um es einfach zu halten und mehr Betriebssicherheit zu haben (weniger Ausrüstung - weniger Fehler- / Ausfallmöglichkeiten). ). Nach unserem Verständnis können die folgenden Befehle nur über eine JSON-Datei verwendet werden: "Z1_Heat_Curve_Target_High_Temp", //TOP29 "Z1_Heat_Curve_Target_Low_Temp", //TOP30 "Z1_Heat_Curve_Outside_High_Temp", //TOP31 "Z1_Heat_Curve_Outside_Low_Temp", //TOP32 Gibt es eine Möglichkeit, die Heizkurveneinstellungen direkt über die Heishamon-Regeln anzupassen oder diese Funktion hinzuzufügen? Brgds
|
| Zeit:
26.11.2022 08:42:27 |
|
| Zeit:
26.11.2022 08:47:28 |
Vielleicht hätte man noch erwähnen können das das der einzige Weg ist bei externer Übernahme der VLTsoll- Berechnung bei dem der Wochentimer weiterhin voll nutzbar ist.
|
| Zeit:
26.11.2022 11:11:27 |
Kann ich gleich noch dazu schreiben, aber für mich zum Verständnis: Wenn du die Jeisha anstatt nach Heizkurve nach Festwert fährst könntest du ihr doch auch die VLsoll vorgeben. Problem ist dann aber, dass man keine SWV mehr über den Timer hat oder warum kommt das nicht in Frage? Oder geht das mit den Rules gar nicht erst?
|