Öffentliches Forum
  - Wärmepumpen

Nein, eben nicht. Dafür muss der User programmieren können. Damit ist er aber nicht mehr deine Zielgruppe, wer das kann machts einfach gleich selbst oder nutzt von Anfang an deinen Code als Basis. Du willst dich ja gezielt an diejenigen richten, die es simpel wollen. Also solltest du denen min. mal die Möglichkeit geben den Key im WebUI auszutauschen oder auf die freie, non-kommerzielle Variante zu wechseln. Einfach, simpel und klar im Handbuch & UI beschrieben in welchen Fällen das passieren sollte.


Das ist eben nicht failsafe. Failsafe wäre ein Fallback auf den physischen NTC vor Ort. Deine Lösung hingegen führt ggf. zu Problemen mit der Abtauung, führt ggf. zu kalter Bude wegen zu niedriger Vorlauftemperatur, und führt sicher zu Effizienzverlusten ggü. einem Einsatz ohne dein Tool. Führt auch dazu das plötzlich im Hochsommer die Heizung das Heizen anfängt.
Und wie bekommt der Nutzer das alles am Ende mit? Eben, nur durch Zufall weil er merkt das die Heizung kompletten Bockmist macht und er sich mal auf das Portal einlogged. Und der Hinweis da ist auch überschaubar, nichts zur Ursache oder möglichen Fehlerbehebung nur "Sicherheits-Modus, keine Daten, simuliere 5°C". Hilft das Opi weiter bei der Problemlösung? Da sollte min. unterschieden werden ob das Teil gar nicht ins Internet kommt (z.B. Referenzcheck gegen den verwendeten NTP-Server), oder die API keine, oder falsche Rückmeldungen gibt. Schön wäre es natürlich wenn Fehler mit dem API-Key gleich erkannt würden.


ich hoffe halt für dich, dass die User wirklich alle stumpf das Netzteil verwenden, den Isolator nicht übersehen, etc. Ein USB-C-Stecker verleitet ja wie schon weiter vorne geschrieben auch schnell dazu sich die Spannung wo anders her zu holen, erstrecht wenn gerade keine Steckdose da ist, die Anlage aber so einen schönen USB-A-ähnlichen Port bietet. Was passiert denn wenn deine Schaltung da dann mit 12 oder 24V versorgt wird, vor allem mit dem Widerstandsausgang, an dem die Anlage hängt?
Hier also auch min. fette Warnung vor sowas anbringen, besser: festes Netzteil oder zumindest kein Standard-Stecker, und den Isolator direkt onboard


was ist denn simpel und robust, wenn du die Gleichung dann eh implementieren musst, somit Hard- und Software also damit klarkommen müssen? Jetzt hast du 2 parallele Implementierungen, die du beide testen und pflegen musst. Erhöht die Fehlerquellen und den Pflegeaufwand. Entweder keine freie Eingabe von NTC-Werten zulassen, und nur die Tabellenwerte verwenden, oder lediglich die Kennwerte für die Gleichung ablegen und immer berechnen.


nur wenn er sich auch an einem geeigneten Ort befindet. Caldio1 soll ja innen montiert werden, er müsste also per Kabel abgesetzt werden, bräuchte dann ein eigenes Gehäuse, aber wieder mit genug Luftwechsel. Und auch in er Außeneinheit wäre der Ort wohl nicht gut, da dort die Werte zu leicht von der Anlage beeinflusst werden. Das ganze muss dann natürlich auch noch den ganzen EMV- und CE-Richtlinien entsprechen, trotz der langen Leitung gegen alle möglichen Fremdeinstrahlungen resistent sein etc. Wird die Kosten für ihn also schon ggf. deutlich erhöhen, und den Aufwand für den Kunden.
Den vorhandenen NTC auslesen wäre da schon einfacher, liefert aber natürlich keine Feuchte-Infos. Und ist schwerer an verschiedene NTC-Werte anzupassen, kombiniert mit dem wahrscheinlich nicht so prickelnden AD-Wandler von den ESPs... auch nix dolles. Dazu muss es natürlich auch erstmal einen vorhandenen NTC geben. Die LG Therma nutzt in der Billigvariante einen Fühler im Außengerät, den man auch besser nicht verändern sollte, da er für mehr als die Heizkurve da ist. Es gibt einen Anschluss für einen Außentempfühler im Innengerät, der ist aber eben optional, und wenn sich der Heizungsbauer Kohle sparen will... bleibt der offen. Der Kunde müsste also neben Caldio1 noch den Außentempfühler kaufen und montieren. Nochmal: Zielgruppe = ich will mich nicht um die Heizung kümmern und es muss alles popeleinfach sein

Zur Abtauproblematik an sich: hängt ja leider auch extrem von der Anlage, und ihren Einstellungen ab. Die Therma z.B. hat teils auch bei 0-1°C noch wenig mit Abtauung zu tun, auch bei höherer Luftfeuchte, solange man nicht auf den Trichter kommt sie auf Silent zu stellen. Da gehts dann hingegen schon bei 4°C unter ansonsten identischen Bedingungen mit dem Abtauen los. Nur Caldio weiß halt von all dem nix. Wieviel Ärger das in der Praxis machen wird, wird Dario ggf. dann erfahren, hoffentlich nicht all zu schmerzlich. Bei der besagten Therma ist es vermutlich nicht das Problem, solange man eben nicht auf den Trichter kommt den Temperatursensor der Außeneinheit zu ersetzen. Wenn doch dürfte es aber auch abseits Abtauwetter ggf. zu diversen Problemen kommen.

Ich sag es mal so freundlich wie es mir möglich ist:
Wenn ich mir das Repo so ansehe, ist da viel von der KI gemacht worden. Vor allem die Generierung des HTTP für die Web-UI. Seine Antworten sind ebenfalls von der KI generiert/glattgebügelt. Der Algorithmus ist ein schlechter Witz, da gibts jede Menge "richtige" Beispiele als HA-Integrationen.

Ganz ehrlich, ich erlebe in meinem Job mittlerweile ebenfalls jede Menge Leute die sich mit KI was zusammenkloppen und meinen sie sind jetzt Softwareentwickler - ich sehe hier eine gewisse Ähnlichkeit...

Das wird man an der CE-Konformitätsbescheinigung sehen können, ob alle anzuwendenden Regelwerke berücksichtigt sind.

Ich mache schon lange Hardwaredesign, die fehlende Failsafe auf den originalen NTC verstehe ich nach wie vor nicht. Das sind <30 Cent Kosten, um das umzusetzen. Auch könnte man da einfach mit kurzem Check des originalen NTC die reale Aussentemperatur gegenüber der API verifizieren. Das überlegt man sich aber vorher.
Die gängigen digitalen Potis sind auch nur für 5V auf der Widerstandsbank geeignet, hat da eine WP eine höhere Abfragespannung des NTC, ist das schon off-spec-Betrieb.

ESP32 wäre jetzt auch nicht meine erste Wahl für einen Prozessor, wenn es um Haltbarkeit und Zuverlässigkeit angeht.

Für mich hört sich das alles nach Arduino-Bastelbude an (wo andere kostenlos Code und Libs zur Verfügung stellen und Hirnschmalz investiert haben) und jemand versucht da mit begrenztem Design-Know-How, zwei selbst geschriebenen Codezeilen und Forenhilfe, damit jetzt irgendwie Geld zu verdienen.

Ich finde es erstaunlich, wie weit das Projekt technisch fortgeschritten ist.

Nur sehe ich dafür überhaupt keinen Markt.

Bis auf ein paar Tuner, wird das Interesse wahrscheinlich gegen Null gehen.

Bei 79€ Selbstkosten und 149€ Verkaufskosten sind das mal ganz grob gerechnet 70€ Gewinn.

Wieviel Stück Du bei den 70€ verkaufen musst, dass sich das lohnt kannst ja schnell ausrechnen.

Ich gratuliere Dir, wenn Du mehr als 200Stk verkaufst.

Wie gesagt, super Lösung aber leider realitätsfern.

Kommt mir auch bekannt vor. In den Antworten kommt mir etwas zu oft der Halbgeviertstrich vor. Da wüssten die meisten (mich eingeschlossen) vermutlich nicht einmal wie man diesen eingibt.

Zur Software: Es gibt dort einen Button für ein Systemupdate, dieser führt aber ins Leere oder übersehe ich da was?

Hallo zusammen,

hier ein kurzes Update. Ich habe damals für den Caldio One V1 ordentlich (und größtenteils zu Recht!) Prügel bezogen. Ich wollte mich kurz zurückmelden, denn ich habe die Zeit genutzt und euer Feedback – so schmerzhaft es teils war – fast zu 100% in die neue Hardware-Generation V2 einfließen lassen.

Hier ist das Update für die Skeptiker von damals:

Galvanische Trennung (Onboard): V2 nutzt jetzt einen isolierten DC/DC-Wandler (B0505S). Die Steuerelektronik ist nun physisch komplett vom Fühlerkreis der Wärmepumpe getrennt. Keine Ground-Loops, kein Rauschen, volle Sicherheit für die WP-Platine.

Hardware-Bypass (Echte Sicherheit): Ich habe die Kritik am 'Festwert bei Ausfall' gehört. Die V2 hat nun einen echten mechanischen Bypass. Bei Stromausfall oder Hardware-Defekt wird der originale NTC-Fühler 1:1 durchgeschleift. Das System ist somit 'fail-safe'.

Industrie-Hardware: Statt Breadboard-Look gibt es jetzt ein sauberes PCB-Design mit dem ESP32-S3 Chip (mehr Leistung für die KI-Modelle) und integriertem Schutz gegen Spannungsspitzen.

Software: Der Algorithmus ist gereift. Die Defrost-Protection ist jetzt Standard: Bei kritischen Wetterlagen (Feuchte/Temp) schaltet das System die Manipulation ab, um die Abtauung nicht zu stören. Zudem ist ein Optokoppler-Eingang für SG-Ready/PV-Überschuss dazugekommen.

Mir ist klar, dass viele hier HomeAssistant oder Heishamon nutzen. Caldio bleibt die Lösung für diejenigen, die genau das nicht können oder wollen (die 'Plug & Play' Fraktion).

Ich wollte mich einfach für den 'Realitätsschock' im Januar bedanken – ohne eure harten Kommentare wäre die V2 heute nicht auf diesem technischen Niveau. Wer die neue Hardware-Doku sehen will: caldio.de ist aktualisiert.

Beste Grüße, Dario

Warum soll es keinen Markt dafür geben?

Es gibt enduaer die bereit sind für vermeintlich smarte Heizkörper Thermostate Unsummen auszugehen... Die genau null Einfluss auf Verbrauch haben..

Ich finde schon, dass es einen Markt dafür gibt.
Hatte selber schon mal die Idee, sowas zu basteln, meine Kenntnisse waren dafür aber nicht ausreichend, ich habe das dann über Node Red realisiert und gebe den VL meiner Wärmepumpe über Modbus dann weiter. Hat den Vorteil dass die Ist-Temperatur nicht verfälscht wird wegen Abtauungen etc.
Meine LG Wärmepumpe ist absolut dämlich, die kann nicht einmal einen gedämpfte Außentemperatur sondern sticht das 1:1 an die Regelung weiter. Mein Haus ist sehr massiv und mit der Fußbodenheizung merkt man es deutlich in der Übergangszeit, wenn es nachts frostig ist und tagsüber warm wird. Meine Regelung verhindert, dass morgens der Estrich voll geballert wird und ab Mittag das Haus viel zu warm wird. Und mittags geht dann ein bisschen mehr Energie in den Estrich als Vorbereitung auf eine kalte Nacht.

Generell würde mich die Frage interessieren, wie man am besten Näherungsweise an die korrekte Temperaturvorgabe hinkommt. Ich habe z.B.. 60% den 24h-Schnitt der Vergangenheit und 40% die Prognose in 4h.
Passt meist bei meinen Bedingungen ganz gut, aber schwierig wirds wenn es neblig ist, und die Wetterprognose den Nebel nicht erkennt. So bleibts dann oft bei frostigen Temperaturen und die Prognose gibt aber super-Sonnenwetter vor. Habe mehrere Wetter-APIs verwendet und alle sind in der Nebel-Prognose schlecht.

Hi Dario, finde ich super dass da jemand etwas in die Richtung macht. Die alte Heizkurve ist überholt und nicht ideal für Wärmepumpentechnologie!

Ich grüble noch an meiner eigenen Lösung für das Problem - ohne Wetterprognose, aber einer Regelung so stumpf und einfach wie die Heizkurve - meiner Meinung nach ist die Wetterprognose überbewertet. Wir reden ja von einem "Handelsrisiko" von wenigen Euro an einem wolkigen Tag, wenn überhaupt.

VLT vorgeben ist auf jeden Fall die sauberere Variante. Bzw. noch besser wäre es der WP nur einen Offset vorzugeben, ähnlich wie das ein Raumeinfluss macht. Wenn die Logik dann streikt kann die WP anhand der Kennlinie weiterarbeiten. Ggf. hat die WP dann noch 2 Grad Offset, aber damit wirds nicht unerträglich warm oder ganz kalt. Wenn deine Regelung bei 0°C AT und 40°C VLT-Vorgabe aussteigt und es hat tags drauf +10°C AT wirds deutlich zu warm werden.

Optimale Gewichtung der Faktoren kann man pauschal nicht sagen.
24h Vergangenheit und 4h Zukunft hört sich aber nicht optimal an. Du willst das Haus ja nicht heute wärmer weil es gestern zu kühl war. Die alten Werte interessieren direkt eigentlich nur noch um zu kalte / zu warme Wände auszugleichen.

Die Werte aus der Vergangenheit würde ich eher verwenden um ne konstante Abweichung zwischen Prognose und Fühler zu kompensieren. Oder für ne Anpassung des Hubs (in dichter Bebauung ist der niedriger als am Ortsrand).

Vermutlich würde es reichen ne (ggf. jahreszeitlich verzerrte) Sinuskurve mit so +- 5-7 Grad Hub auf die aktuelle Tagesmitteltemperatur zu modulieren. Ganz ohne Wetterprognose. Das ist die erwartete aktuelle Temperatur.
Nach diesen Werten wird dann primär die VLT eingestellt. Bzw. unter Berücksichtigung der Glättung in der WP-Steuerung besser als Offset (nach Kennlinie umgerechnet) der WP vorgegeben. z.B. nachts bei niedriger AT eher wenig heizen, tagsüber bei hoher AT mehr.

Für Wetterumschwünge oder abweichenden Temperaturhub ne Mitteltemperatur über die letzten 1-2 Stunden. Die Differenz zur erwarteten Temperatur kommt dann für die VL-Vorgabe (nach Kennlinie umgerechnet) obendrauf.
Ne in Summe verbleibende abweichende Heizleistung kann man dann auf 2-3 Stunden sofort nachholen (auch nach Kennlinie umgerechnet).

Wettervorhersage brauchts dafür keine. Nebel ist auch kein großes Problem. Wenn der Hub größer ist als angenommen wird nachts etwas mehr geheizt (sieht nach "Kälteeinbruch" aus) und tagsüber weniger als optimal. Aber ne Wettervorhersage ist auch nur ein Schätzwert. Bei Nebel ists halt morgens kühler als erwartet, wird aber durch die Kurzzeitdifferenz ausgeglichen.
Und ne statische Kurve kann weder ausfallen noch die API ändern.

Bei der ganzen Sache muss man auch aufpassen wie die Heizflächen zeitlich genutzt werden. Bzw. wie bei FBH der Wärmeübergang Rohr>Estrich aussieht.
Nützt wenig wenn die VLT nachts deutlich niedriger ist als tagsüber, dann sind die Flächen schlecht genutzt. Aber ne FBH die nachts reinbollert und sich tagsüber langweilt ist natürlich Käse.
Im Ergebnis sollte - vom Gesamtwärmebedarf und für beste Effizienz - der VL tagsüber etwas höher sein als nachts. Ich schätze so 5-7 Grad Differenz dürften das Optimum sein. So es die WP von der Leistung erlaubt und die Räume/Estrich nicht zu sehr auskühlen.

da muss ich dir schon vehement widersprechen.
Es kommt sehr auf die Bauweise an, wie die Prognose und die Vergangenheit zusammengesetzt werden soll
Ich hab z.b ziemlich viel Masse, 36er Ziegel + Massivklinker, dazu noch einen alten Heizestrich aus Anfang der 80er. Wetterumschwünge schlagen bei mir erst voll nach 2 Tagen durch, und das gilt es zu kompensieren.
Ich habe auch eine Nachtabsenkung, wenn es wärmer als 5° ist, morgens würde ohne Prognose der ausgekühlte Estrich sehr viel Wärme aufnehmen und der COP gleichzeitig schlecht sein weil draußen nocht kalt.

Ich sehe da keinen Widerspruch. Aber mein Vorschlag war auch nicht als Universallösung gedacht.

Wetterumschwung und Nachtabsenkung mal ganz außen vor hast ohne Glättung/Dämpfung der AT schon Nachts evtl. erhebliche Probleme.
Da kann die Außenwand noch ne ganze Weile warm sein. Die kühlt zunächst außen ab. Innen hast noch über Stunden die Wandtemperatur vom warmen Tag, also kaum Wärmeverluste. Die FBH heizt aber hoch und dann wirds in der frühen Nacht zu warm. Wenn die Außenwände gut isolieren und viel Speichern bis in den Vormittag.
Wenn die Fußbodenbeläge eher gut isolieren (Parkett, Vinyl plus evtl. Teppiche) ist der Estrich und die RT morgens sicher zu warm und es zieht sich bis in die Mittagszeit
(Vormittags ist die Wand außen zwar ausgekühlt, innen aber evtl. noch relativ warm und die FBH ist aufgeladen). Nachmittags ist die Innenwand dann eher kühler als normal, die FBH liefert aber weniger nach.

Das ganze ist ein System mit ca. 5 Energiespeichern (Estrich, Raum+Möbel, Außenwand in 3 Schichten) und Wärmeübergangswiderständen, die sich je nach Gebäude erheblich unterscheiden können.

Evtl. kann man das auf ne Summenformel bringen, aber durchschaubarer wäre es die Temperaturen der Energiespeicher und Wärmeflüsse als "Beobachter" zu modellieren und davon ausgehend die Wärmezufuhr zu steuern.

Für nen Wetterumschwung kann man ne Prognose einarbeiten. Aber 4h bringen da nicht viel, wenn es 48h dauert bis die Temperaturen wieder passen. Da hilft dann aber ggf. der Vergleich mit dem Erwartungswert um schnell zu reagieren.

Lange Nachtabsenkung mit Sprung ist auch nicht gut. Da geht die WP dann ggf. auf 100% hoch. Besser wäre ne gedämpft ansteigende Heizkurve, die die WP auch problemlos schafft.
Oder auch Nachtabsenkung aufteilen, dass der Estrich nicht ganz auskühlt.

Bei 5°C AT darf man den Effekt auch nicht überbewerten. Da ist der Wärmebedarf eh schon niedrig und der COP eher hoch. Entscheidend für den Stromverbrauch ist da eher der Bereich von -5 bis 0 °C AT.
Wenn du bei -3°C AT und Heizgrenze von 16°C 137kWh Wärme pro Tag brauchst sind das mit COP 3,5 39kWh Strom pro Tag.
Bei 5°C AT und Heizgrenze von 16°C sinds dann nur 79kWh Wärme pro Tag brauchst sind das mit höherem COP von 4,5 nur 18kWh Strom pro Tag.

Aber zurück zu deinem Szenario mit der dummen WP:

Lass die WP auf dem 24h-Mittelwert der AT laufen und du hast morgens keinen aufgeladenen Estrich. Konkret wäre es morgens/vormittags wohl leicht zu kühl (Wand etwas ausgekühlt) und Abends etwas zu warm (Wand noch warm).
Reagiert dann allerdings schlecht auf Wetterumschwünge.

Nimm meine Idee eines pauschalen Temperaturverlaufs im Tagesablauf und du kannst die aktuelle AT dazu in Relation setzen. Ob die AT dann wegen Nebel niedriger ist als erwartet oder weils klar ist höher als erwartet oder ob es sich um einen Wetterumschwung handelt ist unklar. Liefert die 4h-Prognose aber auch nicht besser.
Kann man aber natürlich mit gemessener Luftfeuchtigkeit, 4h-Prognose, 12h-Prognose etc. verheiraten.
Die Kurzzeitdaten (1-2h-Mittel) gehen dann verstärkt in die Steuerung ein. Also wenns z.B. wegen Nebel vormittags 3 Grad kühler ist als erwartet kommt direkt 1 Grad (1/3) auf den Temperaturmittelwert drauf. Der Rest dann ggf. über ein Energieintegral (aber auch nicht alles, denn weils gestern zu kalt war brauch ichs heute nicht wärmer).
Und bei nem Wetterumschwung das gleiche.

Ungeglättete AT-Führung lässt sich aber kaum mit nem Offset vereinbaren.

Wieviel du dann Nachts absenkst und tagsüber den Estrich zusätzlich aufheizt ich auch ziemlich individuell nach Nutzung und Haus.