76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Moin Peter,

Das Profil 'v1_heatpump_active_pv' klappt aber nur mit definiertem Wärmepumpen-Verbraucher und dieser benötigt eine Summenangabe der verbrauchten kWh - was meine Waterkotte nicht liefert bzw. ich nicht auslesen kann aktuell - einen Zwischenzähler habe ich nicht.

Als Workaround kannst du dafür ein userReading angeben welches immer '0' als Wert hat.
FANN braucht/betrachtet aktuell keine diskreten Verbraucherwerte sondern den Haushalt als Ganzes. Später habe ich vor dieses Feature noch zu ergänzen bzw. eine WP in der Legacy Verbrauchsprognose gesondert zu betrachten (Zuarbeit von Klaus).
Sobald ich das mache, müsstest du den WP-Consumer löschen und neu anlegen damit die falschen 0-Werte aus dem System verschwinden und nicht das Training verfälschen. Aber bis zu diesem Zeitpunkt kannst du den Workaround gern ausprobieren.

LG,
Heiko

[Parallix]

@Parallix, @all,

ConsumerXX->mode kann nun auch den Wert 'mustNot' erhalten. Dadurch kann ähnlich wie bei type 'noSchedule' die Planung verhindert werden.
...

Genial! Werde alles direkt nach den Karnevalstagen testen und dann berichten.

[Wolle02]

Bitte schaut euch die Liste an und gebt mir bitte Rückmeldung ob ich mit meiner Annahme (grün) richtig liege und welche Kennwerte der Liste auch noch geliefert werden können (als Reading oder userReading im Wallbox-Device):

Also die grün markierten kann meine openWB problemlos liefern.

- **Phasenanzahl:**  -> es gibt Wallboxen mit automatischer Phasenzuschaltung / Abschaltung -> Reading dafür?
  **Label:** `ev_phases` (1/3) 
  → beeinflusst typische Leistungsstufen.

Bei der openWB gibt es das Reading 'phases_in_use'

- **Fahrzeug-ID (pseudonymisiert):** 
  **Label:** `ev_id` 
  → um Muster pro Fahrzeug zu lernen.

Die openWB liefert die Readings vehicle_id und vehicle_name
Darüber hinaus habe ich bei mir noch einen RFID Leser an der WB mit dem ich ein Ladeprofil und ein Fahrzeugprofil aktivieren kann. Die RFID Kennung wird ebenfalls als Reading bereit gestellt.

Gruß
Wolle

[grappa24]

Thema: Fahrzeug-ID, was liefert die WB

Code Auswählen Erweitern

The RFID tag when you use RFID. On chargers with the so-called autocharge functionality, the vehicle MAC can be sent instead, but those are rare.

[dieter114]

Hallo Wolfdieter,

du hast sicherlich das Modul AI::FANN nicht geladen was völlig in Ordnung ist.
Wahrscheinlich habe ich bei dem Check etwas übersehen.

Im Logfile müsste ein entsprechender Perl Fehler zu sehen sein der den Absturz verursacht. Den kannst du mal bitte raussuchen und posten. Du findest ihn kurz vor den Neustarteinträgen.

Ich habe die fehlenden perl Module nachgeladen, der Fehler bleibt.
Solange ich den Config-Test nicht aufrufe, löuft alles.
Die Einträge in der Log Datei sind nicht anders als vorher - also m.E. Unauffällig

Nachtrag: set Forecast plantConfiguration check läuft Problemlos durch, Absturz nur wenn die "Zahnräder" betättigt werden.
                Allerdings zeigt dort

Code Auswählen Erweitern

AI FANN is not yet ready for use in consumption forecasting:
cause: the neural network for consumption forecasting is not activated was auch so erstmal gewollt ist.

LG WDS

[DS_Starter]

Ich sinniere schon eine ganze Weile über dieses Thema EV.
Es gibt aktuell für mich ein Spannungsbogen der sich auf die Architektur des Consumers "Wallbox" bzw. "BEV" bezieht.
Wenn es nur ein E-Auto im Haushalt gibt ist alles kein Thema und kann mit einem Haken versehen werden bis auf Probleme die ich noch nicht erkannt habe. 

Aber bei 2 oder mehr Fahrzeugen im Haushalt, die sich eine Wallbox teilen, wird es kompliziert.
Wenn die Wallbox als Consumer definiert wird, stimmen z.B. die Angaben zur Batteriekapazität nicht, sofern sie fest im Consumer hinterlegt werden müssen. Im Prinzip müssen dann alle! abgefragten Parameter dynamisch aus der Wallbox/Device gelesen werden damit die Werte bei wechselnden Fahrzeugen passen.

Möglich wäre auch die Variante (2) nicht die Wallbox als Consumer zu definieren, sondern die EV 1 bis X. Dabei würde das Wallboxdevice im Consumer als Bezugsdevice definiert. In dem Fall könnte problemlos auch mit konstanten Parametern gearbeitet werden die sich auf das entsprechende Fahrzeug beziehen und nicht über die WB gelesen werden können/müssen. Das gravierende Problem bei dieser Variante ist zu identifizieren welche der EV-ConsumerXX an der Wallbox gerade angeschlossen ist und in SF dann entsprechend behandelt wird. Eine solche Aktivierung könnte durch eine Vernüpfung des Status "EV angeschlossen" mit einer "Identifikation" per RFID / EV ID oder Name erfolgen. Es müsste aber jeder Nutzer in der Lage sein sowohl den Status "EV angeschlossen" + eine "Identifikation" zu liefern weil das dann Pflichtschlüssel sein werden.

In der Variante 2 würde es dann im ConsumerXX einen Key "Identifikation" geben, der wie gehabt eine Device:Reading Kombi mit einer Regex verlangt. Sobald dieser Regex "true" liefert ist dieser Consumer (im Prinzip ein bestimmter EV) aktiv. Damit wäre das Verfahren sehr flexibel, da jeder User entsprechend seiner Umgebung ein entsprechendes (user)Reading bereitstellen kann welches die möglichen Kennungen (ID/Name/MAC whatever) enthält.

Das ist meine Sichtweise. Wie denkt ihr darüber?

EDIT: Die Variante 2 hätte auch den Vorteil, dass sich zeitliche Nutzungsmuster besser abbilden wenn die Fahrzeuge personengebunden sind und sich dadurch Lademuster ausbilden.

[DS_Starter]

Solange ich den Config-Test nicht aufrufe, löuft alles.
Die Einträge in der Log Datei sind nicht anders als vorher - also e.E. Unauffällig

Wenn dein FHEM beim Aufruf des Config Checks abstürzt muß eine Fehlermeldung im Log zu finden sein. Ggf. müsstest du stacktrace im global mal anschalten.
Du könntest den Check mal aufrufen und dann einen Logauszug vom Zeitpunkt kurz vor dem Checkaufruf bis zum Neustart von FHEM posten.
Vllt. sehe ich dann schon etwas.
Es muß etwas spezifisches bei dir sein, denn der Check läuft ansonsten problemlos.

EDit: stürzt FHEM wirklich ab oder hast du es nur so betitelt?

[dieter114]

Siehe Nachtrag in #5149

[DS_Starter]

Nachtrag: set Forecast plantConfiguration check läuft Problemlos durch, Absturz nur wenn die "Zahnräder" betättigt werden.
                Allerdings zeigt dort
Code Auswählen
   AI FANN is not yet ready for use in consumption forecasting:
cause: the neural network for consumption forecasting is not activated
was auch so erstmal gewollt ist.

Dann ist der Check an sich ok, die Ausschrift ist in Ordnung.
Somit verdichtet sich das Problem bei dir auf die GUI. Deswegen nochmal die Bitte genau zu beschreiben was passiert wenn du die Zahnräder verwendest und einen Logauszug, ggf. mit stacktrace, zu posten.

[dieter114]

Siehe Nachtrag in #5149

Neuer Nachtrag: Es war ein Firefox Problem.
Lösung: Cache komplett leeren und gut is.
Nun läuft auch das "Zahnrad".
Aber frag nicht warum - verstehen kann ich das nicht.
fhem hat nicht mehr reagiert und so hab ich es als Absturz eingeordnet.
Danke für die schnelle Hilfe.

LG WDS

[300P]

Hallo Heiko,

ich habe zwar keine WB und kein EV.......  nur die eine WP als Großverbraucher, die ich mit deinem Programm als Consumer plane....

Schau mal hier wie evcc vorgeht:

Mehrere Fahrzeuge

-Standardfahrzeug
-Zuordnung über die UI
-Automatische Erkennung
-Erkennung via RFID
-Erkennung via Plug & Charge

oder direkt hier als Webseite EVCC

Es n.m.M. abhängig von der jeweiligen "Intelligenz / Alter" der WB UND zusätzlich von dem jeweils aktuell angeschlossenem EV was und wie die Erkennung sein "könnte". Das allein würde schon sehr komplex.

Ob du eventuell nicht einfach per API (z.B. evcc-API-Schnittstelle oder MQTT etc. zugreifst, damit du nicht das Rad neu komplett erfinden musst ?

[peterboeckmann]

Hallo Heiko,

Das ist meine Sichtweise. Wie denkt ihr darüber?

wäre es evtl. denkbar und vielleicht sogar nützlich, hier folgenden anderen alten Wunsch mit einzuarbeiten?
Ich denke, es gab schonmal den Wunsch nach "untergeordneten Verbrauchern" bzw. mehrstufigen Messungen.
Bei mir bspw. gibt es einen Verbraucher "Wohnzimmer". Im Wohnzimmer steht das Aquarium, das nochmal separat gemessen wird.
Abbildbar wäre das in der flow-Grafik als zweite Ebene unter den aktuell dargestellten Verbrauchern.

Vielleicht wäre das mit Wallbox und mehreren EVs eine Sonderform davon?

Nur so ein spontaner Gedanke - ohne die Auswirkungen davon auf das Modul auch nur ansatzweise absehen zu können.

Viele Grüße,
Peter

[grappa24]

Ob du eventuell nicht einfach per API (z.B. evcc-API-Schnittstelle oder MQTT etc. zugreifst, damit du nicht das Rad neu komplett erfinden musst ?

da simmer dabei 

[DS_Starter]

Ob du eventuell nicht einfach per API (z.B. evcc-API-Schnittstelle oder MQTT etc. zugreifst, damit du nicht das Rad neu komplett erfinden musst ?

Ja, das ist prinzipiell eine gute Idee.
Wenn ich aber die API integriere, schließe ich damit automatisch die EV-User aus die kein EVCC betreiben. Allerdings ist der Tipp Gold wert weil es ja eine MQTT Möglichkeit gibt wie ich in der Doku gelesen habe.
D.h. jeder User mit EVCC kann sich in FHEM ein MQTT Device erstellen welches die EVCC-Topics abonniert und ggf. darüber von FHEM/SF aus auch den Ladevorgang steuern.
Dann könnte ich bei der Einbindung bei Device:Reading Kombis als universelle Lösung bleiben und niemanden ausschließen.
Oder spricht etwas aus deiner/eurer Sicht dagegen?

Dann ist mir auch die Passage aufgefallen:

Code Auswählen Erweitern

Automatische Erkennung

Laden mehrere Fahrzeuge an einem Ladepunkt wird beim Anstecken die automatische Erkennung genutzt. Dafür wird der Ladezustand aller konfigurierten Fahrzeuge abgefragt und das plausibelste Fahrzeug ausgewählt. Hat die Erkennung ein falsches Fahrzeug ausgewählt (bspw. weil es an einem andern Ladepunkt geladen wird), kannst du die Zuordnung manuell korrigieren.
Die machen die Fahrzeugerkennung/Zuordnung über den Batterie Ladezustand und ordnen das Fahrzeug zu welches passen könnte. Man kann es zwar manuell ändern was für uns aber suboptimal wäre, weil die Folgeaktivitäten in SF sich auf diese Angaben verlassen müssen die wie es aussieht stimmen können oder auch nicht.

wäre es evtl. denkbar und vielleicht sogar nützlich, hier folgenden anderen alten Wunsch mit einzuarbeiten?
Ich denke, es gab schonmal den Wunsch nach "untergeordneten Verbrauchern" bzw. mehrstufigen Messungen.
Bei mir bspw. gibt es einen Verbraucher "Wohnzimmer". Im Wohnzimmer steht das Aquarium, das nochmal separat gemessen wird.
Abbildbar wäre das in der flow-Grafik als zweite Ebene unter den aktuell dargestellten Verbrauchern.

Vielleicht wäre das mit Wallbox und mehreren EVs eine Sonderform davon?

Naja, hier wird die logische und die Darstellungsschicht miteinander vermischt. Bei der eindeutigen EV-Identifikation geht es im Prinzip darum im Modul immer die richtigen Grundlagen für die Prognose von Ladezeiten, Ladezielen usw. für die KI als Trainingsgrundlage zu haben um eine darauf aufbauende Prognose zu rechnen. Wenn diese Daten zwischen mehreren Ev mit unterschiedlichen Eigenschaften und Nutzungsmustern gemischt werden, wird vermutlich kein optimales Ergebnis erzielbar sein. Es geht also in erster Linie um die Aufnahme und Speicherung (möglichst) sauberer Rohdaten.

[grappa24]

Ja, das ist prinzipiell eine gute Idee.
Wenn ich aber die API integriere, schließe ich damit automatisch die EV-User aus die kein EVCC betreiben. Allerdings ist der Tipp Gold wert weil es ja eine MQTT Möglichkeit gibt wie ich in der Doku gelesen habe.
D.h. jeder User mit EVCC kann sich in FHEM ein MQTT Device erstellen welches die EVCC-Topics abonniert und ggf. darüber von FHEM/SF aus auch den Ladevorgang steuern.
Dann könnte ich bei der Einbindung bei Device:Reading Kombis als universelle Lösung bleiben und niemanden ausschließen.
Oder spricht etwas aus deiner/eurer Sicht dagegen?

Als EVCC User wäre das für mich perfekt