Jeder Entwickler arbeitet in seinem eigenen Branch und entwickelt dort seine Funktion. Üblicherweise heißt so ein Branch dann “feature/funktionXY”
Der Entwickler erstellt in Github einen Pull-Request
Andere Entwickler “reviewen” den Code. Dabei schauen wir auf…
3.1 die Umsetzung der Funktion an sich und wie sich diese in die Architektur von OpenEMS einfügt
3.2 Dokumentation (insb. readme.adoc und bnd.bnd)
3.3 Code-Qualität (Best Practices, Einhaltung der Java Coding Conventions, unnötige system.out.println, Fehler/Warnungen in Eclipse, Checkstyle - wir haben geplant das mal zu dokumentieren, aktueller Stand ist hier: https://github.com/OpenEMS/openems/pull/1006/files)
Je nach Größe des Pull-Requests kann dieser Vorgang mehr oder weniger lang dauern. Empfehlenswert ist in jedem Fall, einzelne Funktionen in einzelne Pull-Requests zu trennen - also einen Pull-Request für Wettervorhersage, einen für Sonnenauf/untergang, einen für Ladestation, usw.
Am besten starten wir mal mit der einfachsten Entwicklung und exerzieren daran mal den Prozess durch, ok?
Wenn eine Funktion nocht nicht fertig ist, kann ein Pull-Request auch als “Draft” (Entwurf) gestartet werden. Dann wissen zumindest die anderen Mitglieder in der Community schon einmal, dass eine bestimmte Funktion entwickelt wird und können vielleicht auch schon einen ersten Blick auf den Code werfen und Rückmeldungen geben.
das ist sehr interessant, ich arbeite ebenfalls an ähnlichen Controllern.
Vorallem würde mich interessieren, mit welchen Anbieter du die Wettervorhersage holst und wie du mit den Daten auf die Anlagenleistung umrechnest.
Leider kann ich noch keine Aussage zur Genauigkeit, da meine Anlage erst in den nächsten Wochen in Betrieb geht.
Konntest du bei dir schon Erfahrungen damit sammeln?
@stefan.feilmeier Ich habe gesehen, dass im Pullrequest https://github.com/OpenEMS/openems/pull/1327 eine neue Prediction-Architektur erstellt wird.
Ist auch eine Implementierung in die UI vorgesehen? Das wäre perfekt für meine Bedürfnisse, die oben dargestellten Verläufe waren sehr spezifisch und nicht allgemein Verwendbar. Schade, dass ich hier zu langsam war.
Mein Trost ist, dass ich in der Zeit doch tiefer in die OpenEMS-Struktur einsteigen konnte.
Genau, daran arbeite ich im Rahmen des Forschungsprojekts EMSIG. Hier eine kurze Präsentation, mit der ich das vor kurzem erst im Konsortium vorgestellt habe (und daraufhin noch ein paar Anpassungen gemacht habe)
Meine Idee für eine Zweitverwendung der Vorhersage wäre auch - genau wie in deinem Screenshot oben - die “weiße Fläche” in der historischen Ansicht zu befüllen. Ein bisschen Quellcode dazu gibt es auch bereits im Pull-Request. Bisher allerdings nur einen console.log und keine Charts.
“Unable to get Response: JSON [componentId] is not a member of [{"componentID":"_predictorManager","payload":{"method":"get24HoursPrediction","params":{"channel"…]”
Als Predictor habe ich das Persistence-Model eingerichtet
Dein Fehler scheint bei componentId zu liegen: componentId != componentID
“Unable to get Response: JSON [componentId] is not a member of [{“componentID”:”_predictorManager",“payload”:{“method”:“get24HoursPrediction”,“params”:{“channel”…]"
Hallo Stefan,
herzlichen Dank für deine Hilfe! Der Fehler lag am Parameter “channel” statt richtig “channels”.
Der Predictor funktioniert nun einwandfrei.
Besteht Interesse daran, den Predictor für den Anbieter Solcast https://solcast.com (10 API Anfragen am Tag kostenlos) zu implementieren?
Den Code dafür habe ich geschrieben und verwende ihn auch schon einige Monate. Ich habe etwas Verschattung und daher weichen die Werte bei niedrigen Sonnenstand etwas ab, dennoch bin recht zufrieden mit den Vorhersagewerten.
super, dass wir es lösen könnten. Sorry für die Verwirrung, aber ich glaube die Last-Minute-Änderung, dass mehrere Channels gleichzeitig abgerufen werden können, war es wert. Das ist ein sehr häufiger Use-Case.
Solcast beobachte ich schon länger, bin aber bisher nicht dazu gekommen, mir das Angebot genauer anzusehen. Es wäre toll, wenn du den Predictor als Pull-Request bereitstellen könntest. Wir sind zur Zeit leider etwas hinterher mit den Reviews, aber dieser Beiträg wäre wirklich sehr interessant.
First thanks for your sharing.
I’m using your predictor and it’s seems working in my output debugLog !
But I’m interested to get a curve for my prediction on my dashboard in the UI EMS.
Can you help me to do this ?
I tried some things with the dashboard and this is working good for me. But the code is not generally useable (e.g. fix channeladdresses). So i didn’t add this to the pull-request.
as i mentioned it is a little bit complicated to describe. You can look to my personal branch where the predictor is fully integrated in the UI.
It’s not good coded but it works fine for me. The go-e Charger is although integrated but not fully functional and buggy. I’m still working on it and when it works fine, then i will make a pull-request.
I am very interested in your controll, too. Unfortunately I could not get it to work. I´ve created my site on solcast.com, configured your controller - but the debug-log only shows “predictorSolcast0[Prediction: UNDEFINED]”.
The log-file /usr/lib/openems/forecasts.json ist still empty. I´ve created it by my own and set all rights on it.
Do you have any advice for me?
EDIT: There seems to be a problem with the debug-mode while parsing the JSON-object. If debug-mode is disabled then prediction works!
Hi Klinki,
in this controller there is a function named debug-mode. But this is not the same as in the other controllers with a detailed debug log.
Here is a simple test function implemented to read a local json-file defined in “Debug File”. When debug mode is on and no file is found then no prediction can be done.
Best regards
Christian
Yes, if no debug file can be accessed the normal debug log shows an error of the missing file. But the module does not work even if the file is there. The problem seems to be in parsing data. Eclipse then shows a java error.
I´ve tried to get the widget “Vorhersage” to work but the actual structure in energy.components.ts seems to be different from your example. Do you plan to adapt your module?
I am no java programmer and my javascript is not really good. But I really do like your module and I am very interested to get it to work with ui. I’ll keep trying…
Thanks a lot for your work!
regards
klinki
EDIT: I was able to add the Solcast-predictor to the history ui. The predicts are pretty close to reality!