Rethink how to support heating units

[andig]

Der logische nächste Schritt wäre ja jetzt auch die Begriffe SoC und die Einheit % konfigurierbar zu machen ;) Für Wärmepumpen oder Heizgeräte wären das dann eben Temperatur und °C.

Denkbar wäre auch, die Steuerung über Leistung statt Strom zu machen. Diese Diskussion soll dazu dienen, den Lösungsraum besser zu verstehen.

Originally posted by @andig in #5200 (comment)

[VolkerK62]

Was mich stört, dass bei einem Grad Temperaturunterschied, sofort wieder eingeschaltet wird. Hier würde ich mir eine größere Toleranz wünschen.

[andig]

ich tendiere auch immer mehr dazu evcc uc sind bevs.

was meinst du?

[premultiply]

Naja, evcc basiert halt rein auf den Momentandaten und ist auf Überschussladen mit idealerweise regelbaren Verbrauchern (Fahrzeuge, andere Batteriespeicher) ausgelegt.

Für alles was mit heizen (Wärmepumpe, usw.) oder programmbasierten Geräten (Waschmaschine, Gerschirrspüler usw.) zu tun hat ist aber ein prognosebasiertes Planungsmodell (a la SMA Sunny Home Manager) eigentlich deutlich besser geeignet weil man eben einerseits vorausschauend planen kann und andererseits auch den Ablauf bzw. die Energiezuvor nicht jederzeit einfach unterbrechen darf und auch wenn einmal gestartet nicht drosseln kann.
Dieses Modell eignet sich andererseits NICHT für das Ad hoc-Überschussladen. :)

[batmanvane]

ich tendiere auch immer mehr dazu evcc uc sind bevs.

was meinst du?

der usecase von evcc ist klar eauto mit überschussladen zu optimieren. rest wie @premultiply schon schreibt. was natürlich speicher als zeitnah regelbare last einschließt. für warmwasser, heizung hat man ohnehin die nebenbedingung "comfort" also es muss i.a. pro tag eine mindestzeit laufen, und diese mindestzeit kann ich auch nur um einige stunden vor oder zurückschieben (sonst schafft es zb die wp nicht den speicher auf 45c zum duschen). da bist du wieder bei a) planer, aber selbst der hat geringen freiheitsgrad oder eben b) statistischem ansatz. also feste zeiten für verbraucher und die optimal setzen (was man ja nachführen kann mit bayeschem ansatz oder buzzword KI konstrukten zum demand side management) bei autos hat man i.a. noch die nacht. von daher ideal für überschussladen.

fazit für mich soweit: frage ist zu beantworten: evcc fokussiert halten oder usecases erweitern. ich tendiere zu erstem.

edit: evcc könnte auch in die richtung weiterentwickelt werden: pv überschuss u/o günstiger/grüner strom aus dem netz. so könnten auch eFahrer profitieren, die kein pv haben. die prinzipielle funktionalität ist ja schon gegeben via plugins und apis zu awatta & co. man könnte aber auch das tracking von evcc oder anderen lokaleren (netzebene) quellen nutzen. ich weiss, der thread dreht sich um heat. sorry für das ot, den gedanken wollte ich nur noch schnell teilen.

[andig]

evcc könnte auch in die richtung weiterentwickelt werden: pv überschuss u/o günstiger/grüner strom aus dem netz.

Das ist ja heute schon so bzw. wir es sein sobald #2211 umgesetzt ist.

Naja, evcc basiert halt rein auf den Momentandaten und ist auf Überschussladen mit idealerweise regelbaren Verbrauchern (Fahrzeuge, andere Batteriespeicher) ausgelegt.

Ich würde (im Moment) auch nicht versuchen, daran etwas zu ändern. Ich glaube dennoch, dass wir mit kleinen Tweaks einige Use Cases der Wärmenutzung etwas verbessern könnten. Aber wenn wir zu dem Schluss kommen dass das nicht der Fall ist dann ists auch gut :)

[MarkusGH]

Nur als Hinweis: Mit dem JavaScript Plugin kann man auch komplexere Regel- und Anzeigelogiken implementieren. Ich habe mir z. B. eine Wärmepumpenanbindung gebaut, die die Fahrzeuge "Heizen", "Kühlen" und "Warmwasser" unterscheidet und z.B. bei Wechsel des Fahrzeugs eine Ladeunterbrechung simuliert um die Fahrzeugerkennung zu triggern. Die eigentliche Leistungsregelung ist dabei in einer externen Software, man könnte die aber auch genauso gut weitgehend in JavaScript implementieren.