76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Na da hast du was richtiges geleistet. 

Ich habe nochmal ein Update ins contrib geladen.
Der Consumer type=noSchedule ist als deprecated gekennzeichnet und soll nicht mehr verwendet werden.
Statt dessen gibt es schon lange den Ersatz mode=mustNot.
'noSchedule' ist ja eigentlich kein Typ eines Consumers, sondern eine Eigenschaft. Außerdem soll der Typ fest sein und sich nicht ändern. 'noSchedule' war ursprünglich für temporäre Ausplanungen gedacht und ist mit dem besser verwenbaren mode=mustNot jetzt obsolet.

[TheTrumpeter]

- der Consumertyp 'heatpump' ist nun für Planung und automatisches Schalten durch SF geöffnet.
  Es gelten also die üblichen Schlüssel und Funktionalitäten. Um eine Planung auszuschließen, setzt
  mode=mustNot explizit. Wie schon diskutiert, vermeidet parallele Steuerungen durch SF und den nativen
  WP-Controller.

Ich weiß schon, dass ich darum gebeten habe das freizugeben. Das war aber vor der Zusammenfassung aller möglichen WP-Betriebsmodi in einen Verbraucher. Mit der aktuellen Implementierung habe ich folgende Probleme/Fragen:

Es gibt nur 1 Verbraucher für mehrere völlig unabhängige Aufgaben. Entsprechend müsste es für jede dieser Aufgaben unabhängige Ein-/Aus-Kommandos sowie Ein-/Aus-Bedingungen geben.
Für die Warmwasser-Bereitung habe ich einen eigenen Einschaltbefehl definiert, die Bedingungen für die Planung sind abhängig von der Speichertemperatur.
Die Heizung hätte keine Einschaltbedingung, die nötige Laufzeit würde sich aus den gelernten Zusammenhängen mit der Außentemperatur ergeben.
Ähnliches gilt für die Kühlung, wobei da noch weitere Umweltbedingungen passen müssen, damit die Wärmepumpe den Kühlmodus überhaupt freigibt.

Ich glaube nicht, dass es sinnvoll ist das alles in dem Consumer abzubilden.
Wäre es stattdessen nicht übersichtlicher den Verbraucher "Wärmepumpe" nur für die Verbrauchserfassung und -prognose zu verwenden und jegliche Planungs-/Schaltvorgänge in weitere Verbraucher (ich nenn' sie mal "Dummies") auszulagern?
Damit kann heute schon jeder selbst entscheiden welche Teilfunktionen der Wärmepumpe von SF gesteuert werden sollen.
Dann bräuchte es "nur" noch irgendeinen intelligenten Mechanismus wie die echten Verbrauchsdaten in den Dummy-Verbrauchern für die Planung zur Verfügung stehen ohne den Rest durcheinanderzubringen.