-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement options to get best/worst hours per day #16
Comments
Wäre super, wenn es einen Adapter gibt, der den tibber0 adapter und den tibberconnect adapter ersetzt und die beiden zusammenführt. Bis jetzt habe ich noch nichts lesen können welche Vorteile und Neuigkeiten dieser Adapter besitzen soll und ob das möglich ist die beiden anderen in den zu vereinen. |
Hier sind primär in tibberconnect vorhandene Fehler beseitigt und der Adapter auf einen offiziellen, in ioBroker gelisteten Stand gebracht. Nächster Schritt ist die Implementierung von weitergehenden Funktionen, wie auch im alten tibber adapter vorhanden. |
Sortierung nach Preis ist relativ einfach. Im Prinzip eine Zeile Javascript Code.
|
@Marty56:
Meinungen? |
@hombach, in meinen Augen sind deine Vorschläge punkt 3 und 4 genau goldrichtig, doch es gilt zum Überlegen, dass z.B. das Laden der E-Autos ja nicht in 1er Stunde rum ist sondern ja länger dauert, daher hat z.b. der Tibber.0 Adapter die Möglichkeit die gesamtzahl der Stunden anzugeben wo die günstigsten Preise sind, z.B. man braucht 4 Stunden um das Auto voll zu laden also gibt man hier 4 ein und dann sucht er sich die zusammenhängendsten 4 Stunden aus. Ebenfalls sollte vielleicht bedacht werden, daß man dies entweder in % oder im Gesamtpreis auswählen sollte unter dem das laden beginnt, da ja für jeden Tibber Nutzer andere Konditionen herrschen, für den einen ist 15Cent (incl. Steuer) interessant für den anderen 20 Cent. Aber mit dem Punkt 3 wäre ich bei dir, so könnten sich die verbraucher danach richten und einschalten wenn die obengenannten Kriterien erfüllt sind. Gruß Josef P.S: Danke für deine tolle Arbeit und deine Zeit die du für uns opferst. |
Hallo Josef, Danke für Deine Rückmeldung. Use Case. Ich schalte meine Spülmaschine ein und will den niedrigsten Preis der nächsten 12 h ermitteln. Gruß Martin |
Das gleiche für die teuersten Stunden des Tages wäre auch hilfreich um z.B. die Wärmepumpe zu diesen Zeiten zu sperren. |
Ok... ich versuche einmal eine Spezifikation zusammenzufassen:
Eine komplexere Frage sehe ich noch im "Planungszeitraum".
:-) das ist jetzt etwas mehr geworden - Brainstorming - dabei fällt mir auf: es gibt noch einen Unterschied in den Usecases: Das e-Auto muss im Zeitraum die z.B. 3h mit dem besten Preis nutzen - Lage egal.... bei der Waschmaschine sollten die 3h tendenziell am Stück sein - LOL |
Hallo Josef, Ich würde in Deiner Stelle vorher überlegen, wie Du den Adapter positionieren möchtest. Ein Energiemanagement ist ein ganz andere Kaliber und von der Komplexität gewaltig. Allein schon die Unterstützung der diversen Wallboxen und die Unterstützung von den unterschiedlichen Hausspeichern ist eine Mammutaufgabe. Ich würde den Adapter damit nicht überfrachten, außerdem gibt es für Energiemanagement auch schon ziemlich gute Open Source Lösungen. Deshalb würde ich an Deiner Stelle das Thema nicht (vermutlich halbgar) in den Adapter hineinnehmen. Derzeit benutze ich für mein E-Auto Evcc (https://evcc.io) als Energiemanagement. Das Programm kann über Rest Api mit iobroker sehr einfach verbunden werden. ioBroker dient in meinem Fall als Schnittstelle zum Messgerät für meine PV Produktion. Tibber Link hilft mir ein paar Bedienungs- Workarounds für meine (noch) unintelligente Wasch- und Spülmaschine zu implementieren. U.a. die Ansage mit Alexa, um wieviele Stunden die Geräte jeweils (manuell) zeitversetzt eingeschaltet werden sollen. Und ich benutze Tibber Link als Datenquelle für ein paar Grafana Diagramme. Aus meiner Sicht ist Tibber Link vom Funktionsumfang vollständig. Vielleicht sollten die relativ seltenen Server Problem auf Seiten von Tibber noch etwas eleganter abgefangen werden. Gestern gab es ein Verbindungsproblem und der Adapter hat sich danach nicht mehr allein neu gestartet. Gruß Martin Update: Log File
|
Ja, ich gebe dir da auch recht, mit dem überfrachten des adapters, doch man muss auch bedenken, dass evcc (habe ich auch) für die meisten wallboxen mittlerweile geld verlangt. Die Ausführungen von @hombach haben schon was für sich. Natürlich ist es eine Frage der Zeit des Adapter Erstellers und wie weit er sich hier hineinfuchsen will. Als Mindest würde ich bis jetzt zumindestens hoffen daß die beiden adapter tibber.0 und tibber connect mit diesem hier ersetzt werden können, das heißt die sortierfunktion von tibber.0 würde ich nur ungerne vermissen. Aber wie gesagt das hier sind nur Vorschläge, es richtet sich alles nach @hombach, er ist der der seine Zeit opfert. |
sehe ich auch so... dann vielleicht lieber einen seperaten Adapter der diese funktionen hat und auf tibberlink aufbaut..... |
Hallo Martin, Das Verbindungsproblem hatte ich auch. Der issue #32 behandelt auch dieses Problem - ich bin dran ;) |
Sortierte JSON nach Preis sind jetzt in Version 0.2.0 enthalten |
Ich habe die "getBestTime" Funktion aus iobroker.tibber nach iobroker.tibberconnect portiert. Das könnte ich auch hier noch mal wiederholen. Leider ist der tibberconnect recht instabil und bedarf zu viel Kontrolle. Wenn Interesse besteht, dann kann ich bestimmt einen PR machen. Aktuell laufen beide parallel und das macht keinen Sinn |
Du befindest dich in GitHub von Tibber link, Ok? |
gibt es dazu denn schon was? ggf. kann man da was zuliefern |
Angefangen habe ich schon - ich hänge momentan an einer Entscheidung: Akut tendiere ich zu "A" |
Ich würde auch zu A tendieren, sehe aber mittlerweile mehrere Probleme ich sitze gerade an einem Ladescript um den Batteriespeicher automatisch in Abhängigkeit der PV Forecast und der Ladedauer (Batteriespeicher um auf 100% zu kommen) ebenso der Grundlast, nun ist mir aufgefallen, daß (habe die besten 3 Preise vom Adapter genommen), hier kann es natürlich passieren, daß der beste Preis die Zeit nach dem 2.besten Preis ist. Ebenso kann es passieren daß 2. bester Preis 0 Uhr ist und 1. bester Preis 23 Uhr. Wie wirst du das regeln? Eventuell sollte man hier noch die Ladedauer mit berücksichtigen, so könnte man das ganze auch fürs e-Auto laden verwenden (wenn keine andere Software vorhanden). Das ist alles nicht einfach. Was ist wenn die Batterie zum Beladen länger als 1 Stunde braucht, und der beste Preis als letzte Zeit ist. Beispiel: 0Uhr= 3.bester Preis, 1 Uhr = 2.bester Preis, 2Uhr bester Preis. Dann bin ich mit meinem Script schon wieder am Ende. Irgendwie müßte da genau die Ladedauer mit berücksichtig werden beim Calculator. Meinetwegen Ladedauer als Datenpunkt. |
Die benötigte Dauer wird die Variable für den TibberLink.... wie lange das ist, sprich Ladezeit in deinem Beispiel ist ein "externes" Problem. Das kann ich nicht in den Adapter rein holen. Sprich es gibt einen State mit der Anzahl n der Stunden und durch dessen Aktualisierung werden die nächsten n guten Stunden ausgegeben. |
Ich denke auch, dass in einem MultiPulse Fall ein Calculator pro homes sinnvoll ist. Dann hat mal die betreffenden Werte "in der Nähe". Außerdem umgeht man Issues mit Zeitzonen. |
Hat für und wieder.... habe den Calculator jetzt so umgebaut, dass jeder Kanal einem Home zugeordnet wird. Wo die States des Calculator gespeichert werden ist jetzt noch offen.... |
Aus meiner Sicht ganz klar als Unterordner beim entsprechenden Homes. So findet man super easy z.b. den passenden Current oder sonst was. |
Unterordner |
In der 1.1.0 sind jetzt mal die Grundlagen der ganzen Calculator Behandlung gelegt und der einfachste Fall "Best Price" sprich AN wenn günstiger wie Grenzwert implementiert. Der nächste Fall wird "Beste x Stunden über den Tag verteilt" werden. |
Ich wäre echt glücklich wenn es irgendwann beste und schlechteste stunden gibt. Mein Usecase ein Speicher der aus dem Netz oder PV geladen werden kann an Tagen mit wenig Sonnenstunden würde ich gerne in den Billigsten xx stunden Laden und in den Teuersten xx stunden entladen bzw. den Hausverbrauch abpuffern. |
Ich habe den Usecase auch - das Wetter (bzw. Solarertrag) drängt mich derzeit an der Sache weiter zu machen.... ;) |
FYI: in der 1.1.1 ist noch ein Fehler im Timing, dadurch keine korrekte Aktualisierung bei "Stundenwechsel" = Preiswechsel. |
Gennerel richtig aber es ist ja auch möglich 2 mal zu laden bzw. entladen also zum Beispiel von 0-4 uhr billig also laden dann von 7-10 uhr teuer also entladen und 13-17 uhr billig wieder laden und 18-21 Teuer Entladen. Ich hoffe es ist verständlich was ich meine auch wäre dass preisdelta intresant |
Natürlich wird das getestet, warte schon sehnsüchtlich drauf @hombach |
so, habe nun mal die calculation aktiviert und die version 1.1.2 geladen, wann wird hier berechnet, jede stunde oder wenn man einen wert eingibt in den datenpunkt trigger price oder wie genau sollte das nun ablaufen? @hombach |
Eigentlich jede Stunde sobald die neuen Preise eingepflegt sind und wenn man etwas am datenpunkt ändert. akut ändert er bei mir aber gar nichts mehr... keine Ahnung warum. Die 1.1.2 ist buggy. |
@hombach, also beste Kosten steht der eigene Datenpunkt auf true mit Zeitstempel von 13Uhr, im adapter unter calculations steht er zwar auf false aber hier weiß ich auch noch nicht so genau was man hier einstellen muß. |
Kein Problem, man kann mehrere Calculator-Channels pro Home einsetzen
JA - und den Preis noch zusätzlich zu berücksichten hatte ich mir auch schon gedacht: D.h. gib mir die besten max. n Stunden deren Preis gleichzeitig unter Trigger liegen muss |
Die 1.1.2 ist auf NPM - bei mir funktioniert so jetzt alles für "Best Price" |
oder gib mir auf einen Datenpunkt laden ruhen oder entladen und als input die Lade und entladedauer sowie das mindestpreißdelta wegen 2 cent delta brauch ich den Akku nicht zu stressen denn eigentlich ist es egal was der Strom kostet solange dass delta zwischen min und max groß ist |
Denke du brauchst zwei Ausgaben=Datenpunkte für deine Akku Ansteuerung? Sprich Laden ja/nein und Entladen ja/nein ... ?? |
z.B. sowas sollte zu erzeugen sein: wenn der in Calculations.0.Active auf false steht sollte die Ausgabe auch auf false gehen - bzw. auf das was in den Grundeinstellungen für "ValueYES" vorgesehen war: |
ja oder ein wort laden entladen pause |
Hi, ich verstehe den PV Usecase von Euch noch nicht und würde gerne mit meinem vergleichen. Die Kombination aus PV und Akku setzt ja erstmal einen zusätzlichen Regler mit Nulleinspeisung voraus. Der produzierte Strom geht also nur soweit in die Ladung, wie er nicht im Eigenverbrach ist. (Ich nutze den Hoymiles-Zero-Export). Den Fahrzeugakku würde ich gedanklich noch einreihen können als planbare Ladezeit die am Ende vollständig abgeschlossen sein soll, aber das ist noch nicht mein eigener Anwendungsfall. Dies ist für mich ein verschiebbares Lastprofil. Hab ich PV über, lade ich immer das Auto zuerst und dann den Hausakku. (Für die Restladung sind die billigsten Zeitfenster ja andiskutiert und sinnig, nur in der Länge nicht 100% abschätzbar). Meine aktuelle Umsetzung zum 1. „ob“ ist es, dass ich den Wechselrichtern/der Steuerung die Obergrenze auf 0Watt reduziere, also die Freigabe entziehe, wenn Sparpotential vorhanden ist. In Folge wird ausschließlich der Akku geladen und kein Wechselstrom erzeugt. (Es setzen sich die WR aber darüber hinweg, wenn die Akkus voll sind damit weiterer PV-Strom dann genutzt und die Laderegler nicht ins Leere steuern.) Besser wird es wohl indem ich mein eigenes Lastprofil auf die Folgestunden und Preise integriere, aber ich hadere noch. Ich tendiere dazu das erste „ob“ tatsächlich an das laufende Mittel zu koppeln und stumpf bei very_cheap oder cheap erst zu laden und nur bei vollen Akkus wieder auf Nulleinspeisung zu gehen. In der Hoffnung mit den Überlegungen geholfen zu haben, mir haben sie gerade zum besseren Verständnis geholfen :) |
Nun ich habe leider nur ein Balkonkraftwerk mit 0,9 kWP und einen Selbstgebauten Speicher mit ca 1 kWh die PV geht erstmal mit voller Leistung über die Steckdose ins Netz an einer anderen Stelle ist der Akku der über ein Meanwell Netzteil geladen wird. Dass Netzteil wird über Tasmota mit pwm angesteuert, regeln tut dass ganze ein Script im Iobroker bis jetzt nur Überschuss den ich nicht selbst verbrauche. sobald die PV Leistung zu klein ist um auf 0 zu regeln wird wird der Akku entladen. Bis jetzt war das Konzept prima da ich noch keinen stundenbasierten Tarif hatte. Aber jetzt würde ich (mehr aus Neugierde )gerne zu den Teuersten Stunden entladen und zusätzlich wenn wenig oder kein PV ertrag zu erwarten ist den Akku in den billigen Stunden laden. Und ja ich weis dass das in der Größenordnung nicht wirklich sinnig ist aber die Komponenten haben mich kaum was gekostet. |
Das wird schon speziell, aber versuch mal einen Channel "best hours single" alle z.B. 22 Stunden raus zu nehmen wo du nicht Entladen willst - ValueOff = "entladen" On="pause". |
... Wenn wir ein Verhältnis der Lade zur Entlade-Leistung eines Hausakkus haben... mit diesem und den 9ct minimalen Delta beim Preis die vorhendenen Stundenpreise im Tibber in zwei Gruppen trennen.... |
in 1.2.0 ist leider beste einzelstunden noch nicht implementiert |
doch, in der aktuell auf GIT ladbaren Version ist es vorhanden.... einfach mal einschalten, es gibt anscheinend aktualisiert iOBroker bei Dir die Übersetzungen auch nicht? Das verstehe ich hier nämlich auch nicht so recht. |
ich hatte die 1.2.0 von GIT |
aktuell kommt immer pause als Ergebnis muss ich morgen mal dran wenn ich zeit finde aber immerhin ein Ansatz |
Ich hab mal die Mehrkostenrechnung überschlagen, um an realistischere Werte zu kommen und lege 500€ pro 2,5kWh LiFePo Speicher zugrunde. (Redodopower aktuell). LiFePo hält in etwa 10 Jahre bei 7000 Zyklen. Ab jetzt nicht weiterlesen wer nicht mitrechnen möchte und gleich zum Fazit springen ..:) Wesentliche Verluste sind also in Wärme/Innenwiderstand der Batterie. LiFePo (als Aktueller Standart) hat bei großzügiger Auslegung 95% Ausbeute, also 5% Verlust. Wir wollen knapper auslegen, damit die vorherigen 4,5Cent nicht relevant steigen -> 10% Verluste. Beim Einspeichern der kWh gehen wir von einen unterdurchschnittlichem Preis aus, also ca.20ct. durch die 10% unterm Strich dann aber 22Ct. —> Folglich zusätzliche 2ct. Kosten pro kWh… __ Zusammengefasst: Ich korrigier also mal meine Annahmen und setze das minimal Delta auf 3ct. anstelle von 9 Cent :) Gut für @spoeh-man … schlecht für meine gedanklichen Knoten in der Optimierung. Jetzt muss ich neu denken, da es damit wesentlich relevanter wird abzuschätzen, wie groß der PV Ertrag sein wird und ob ich den Speicher zur nächsten Aufladung (Sonne oder Niedrigpreis) überhaupt leer bekomme. Ich habe realistische 1500WP auf dem Dach, 300-500W nicht steuerbaren Basisverbrauch in Hochpreiszeiten, 800W Wechselrichter und 5kWh LiFePo. |
Nein, ich glaube nicht. Ich glaub es bleibt bei der Abfrage "teuersten x-Stunden bis nächstem Sonnenertrag" zur Lösung. Für das Aufladen via Netz dann "teuersten x-Stunden bis ???" da sind es immer Wechselintervalle abhängig davon wie schnell ich laden kann und entladen muss. Ich lass es mal gären und schau was dort als Minimal/Optimal stehen bleiben kann. |
Gefixed, Timingfehler gefunden und gefixt. Startup-Fehler Calculator gefixt.... |
Version 1.3.0 und jetzt auch 1.3.1 im Beta-Repo - damit ist das Ziel dieses Issues erldigt - Erweiterungen können gern in neuen Issues gefordert, oder in den Discussions erst mal besprochen werden |
Implement options to get best/worst hours per day
The text was updated successfully, but these errors were encountered: