Implement options to get best/worst hours per day

hombach commented 1 year ago

for best and worst pricing hours today have a config for the amount of searched hour (s, each)
have a boolean state reflecting if these are the actual hour/price - to be used to switch some kind of load (eg. EV charger, or ESS batteries)
??? amount of hours as config or also as state to be more dynamic ???

weindler commented 1 year ago

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.

hombach commented 1 year ago

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. Bitte Ideen und Anforderungen als Issue einlasten... ;)

Marty56 commented 1 year ago

Sortierung nach Preis ist relativ einfach. Im Prinzip eine Zeile Javascript Code. Im Beispiel Preise von Heute sortieren.

var path_tibber = "tibberlink.0.Homes.xxxxxxx." 
var sorted_tibber_price_today = JSON.parse(get(path_tibber + "PricesToday.json")).sort(function(a,b) { return a.total - b.total })
log(sorted_tibber_price_today)

hombach commented 1 year ago

@Marty56: Willkommen beim TibberLink Adapter - Programmiertechnische Umsetzung ist das eine (Danke für das Beispiel!) - Spezifikation was für möglichst viele Nutzer gebraucht wird das andere....

Einfach nur sortieren wäre eine Variante - sprich es gäbe dann noch einen State "tibberlink.0.Homes.xxxxxxx.PricesToday.jsonsorted" zusätzich ..... (für prices tomorrow macht das IMHO keinen Sinn)
Oder NUR den vorhandenen "tibberlink.0.Homes.xxxxxxx.PricesToday.json" sortieren?
Zusätzlich schwebt mir ein Schalter vor (boolean-state) der von anderen Adaptern bzw. Script dann direkt genutzt werden kann zum Schalten von z.B. Großverbrauchern. Für den State definiert man dann nur "gib mir die x billigsten Stunden des Tages" oder "immer an wenn Preis unter 0,xx EUR"
Statt einem state als "Ausgang" im TibberLink könnte man auch direkt einen State eines anderen Adapters ansteuern.... sprich den Großverbraucher. Wenn hier dann ein state in "0_userdata.xyz" verwendet würde wäre Punkt 3 hinfällig.

Meinungen?

weindler commented 1 year ago

@Marty56: Willkommen beim TibberLink Adapter - Programmiertechnische Umsetzung ist das eine (Danke für das Beispiel!) - Spezifikation was für möglichst viele Nutzer gebraucht wird das andere....

1. Einfach nur sortieren wäre eine Variante - sprich es gäbe dann noch einen State "tibberlink.0.Homes.xxxxxxx.PricesToday.jsonsorted" zusätzich ..... (für prices tomorrow macht das IMHO keinen Sinn)

2. Oder NUR den vorhandenen "tibberlink.0.Homes.xxxxxxx.PricesToday.json" sortieren?

3. Zusätzlich schwebt mir ein Schalter vor (boolean-state) der von anderen Adaptern bzw. Script dann direkt genutzt werden kann zum Schalten von z.B. Großverbrauchern. Für den State definiert man dann nur "gib mir die x billigsten Stunden des Tages" oder "immer an wenn Preis unter 0,xx EUR"

4. Statt einem state als "Ausgang" im TibberLink könnte man auch direkt einen State eines anderen Adapters ansteuern.... sprich den Großverbraucher. Wenn hier dann ein state in "0_userdata.xyz" verwendet würde wäre Punkt 3 hinfällig.

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.

Marty56 commented 1 year ago

Hallo Josef,

Danke für Deine Rückmeldung. Was ich noch praktischer fände, ist ein Json File mit Preisen für 48h Für den Fall, dass noch keine Preise für den nächsten Tag vorliegen, sollten die Felder, z.b. total vorhanden sein und mit null belegt sein. Und dieses Json File sollte einmal sortiert und unsortiert vorliegen.

Use Case. Ich schalte meine Spülmaschine ein und will den niedrigsten Preis der nächsten 12 h ermitteln. Das wäre mit einem 24h sortierten Json nur eine Abfrage auf index 0 und ich muss keine Unterscheidung mehr treffen, ob es vormittag oder abends ist.

Gruß Martin

reneschuster commented 1 year ago

3. Zusätzlich schwebt mir ein Schalter vor (boolean-state) der von anderen Adaptern bzw. Script dann direkt genutzt werden kann zum Schalten von z.B. Großverbrauchern. Für den State definiert man dann nur "gib mir die x billigsten Stunden des Tages" oder "immer an wenn Preis unter 0,xx EUR"

Das gleiche für die teuersten Stunden des Tages wäre auch hilfreich um z.B. die Wärmepumpe zu diesen Zeiten zu sperren.

hombach commented 1 year ago

Ok... ich versuche einmal eine Spezifikation zusammenzufassen:

Es gibt potentiell mehrere Schaltkanäle (Usecase z.B. E-Auto, Wärmepumpe, Spülmaschine)
Für jeden Kanal gibt es eine "fixe" Adapter-Konfiguration für Stundenbasis oder Preisbasis
Für jeden Kanal gibt es eine "fixe" Adapter-Konfiguration für den Einzustellenden Wert "An" (Usecase "True" für das E-Auto oder "False" für das deaktivieren der Wärmepumpe) und natürlich auch einen für "Aus" (das Gegenteil.... die Werte können Bool, Number, oder String sein.
Für einen Kanal mit Stundenbasis gibt es einen State zu dynamischen definieren der Anzahl Stunden (über 3 kann dann der "Kehrwert" erzeugt werden)
Für einen Kanal mit Preisbasis gibt es einen State zu dynamischen definieren der Preisgrenze (über 3 kann dann der "Kehrwert" erzeugt werden)
Je Kanal gibt es einen State der definiert werden kann als Ziel der Schaltoperation. Per Default im Bereich des TibberLink Adapters, dieser wird dann zur Laufzeit neu erzeugt. Hier kann dann aber auch ein Fremd-State ausgewählt werden. (Use-Case z.B. Wallbox für das E-Auto direkt einschalten)

Eine komplexere Frage sehe ich noch im "Planungszeitraum".

Sprich das E-Auto sollte z.B. grob zwischen 14:00 und 7:00 geladen werden und in der Zeit 3h laden.... das heißt wir bräuchten immer ein Zeit-Fenster. Das sollte immer nach 13:00 starten, wenn die Werte des nächsten Tages vorhanden sind (?)
Für Kanäle nur auf Preisbasis wäre das IMHO irrelevant - Usecase: das Splitklima-Gerät soll die Gas-Heizung unterstützen wenn der Strom unter 13ct kostet.... da sind Zeitfenster eher unwichtig - könnte man aber auch einbauen um ein Heizen bei Nacht zu verhindern
Denkbar wäre auch ein Eingangsstate zum Aktivieren eines Zyklus. UseCase Waschmaschine.... da kommt es nicht so auf die Uhrzeit an, eher darauf dass es irgendwann mal fertig sein sollte. Umsetzung dann: Von Aussen ein True in den Trigger des TibberLink (Kanal-)Eingangs schreiben. Der Adapter sucht dann nach gegebenen Regeln eine Schaltzeit und setzt danach den Trigger wieder auf False. Damit wäscht die Maschine nur einmal, nicht täglich...

:-) 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

Marty56 commented 1 year ago

Hallo Josef,

Ich würde in Deiner Stelle vorher überlegen, wie Du den Adapter positionieren möchtest. Aus meiner Sicht dient er primär als Quelle um Preise, Stromverbrauch (Leistung und Energie) ioBroker zur Verfügung zu stellen.

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. Außerdem habe ich in ioBroker ein paar wenige kleinere Funktionen implementiert, die (noch) nicht in EVCC nicht drin sind, wie z.B. ein elektronisches Fahrtenbuch für mein E-Auto.

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

2023-08-07 13:05:53.124 - error: tibberlink.0 (612251) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
--
2023-08-07 13:05:53.132 - error: tibberlink.0 (612251) unhandled promise rejection: Request imeout for uri [object Object]
2023-08-07 13:05:53.132 - error: tibberlink.0 (612251) Error: Request imeout for uri [object Object]
at ClientRequest. (/opt/iobroker/node_modules/tibber-api/src/nodes/TibberQueryBase.ts:130:33)
at Object.onceWrapper (node:events:628:28)
at ClientRequest.emit (node:events:514:28)
at ClientRequest.emit (node:domain:489:12)
at TLSSocket.emitRequestTimeout (node:_http_client:847:9)
at Object.onceWrapper (node:events:628:28)
at TLSSocket.emit (node:events:526:35)
at TLSSocket.emit (node:domain:489:12)
at TLSSocket.Socket._onTimeout (node:net:571:8)
at listOnTimeout (node:internal/timers:569:17)
2023-08-07 13:05:53.133 - error: tibberlink.0 (612251) Request imeout for uri [object Object]
2023-08-07 13:05:53.149 - warn: tibberlink.0 (612251) Terminated (UNCAUGHT_EXCEPTION): Without reason
2023-08-07 13:05:53.749 - error: host.iobrokerstable Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
2023-08-07 13:05:53.757 - error: host.iobrokerstable Caught by controller[1]: Error: Request imeout for uri [object Object]
2023-08-07 13:05:53.757 - error: host.iobrokerstable Caught by controller[1]: at ClientRequest. (/opt/iobroker/node_modules/tibber-api/src/nodes/TibberQueryBase.ts:130:33)
2023-08-07 13:05:53.757 - error: host.iobrokerstable Caught by controller[1]: at Object.onceWrapper (node:events:628:28)
2023-08-07 13:05:53.757 - error: host.iobrokerstable Caught by controller[1]: at ClientRequest.emit (node:events:514:28)
2023-08-07 13:05:53.758 - error: host.iobrokerstable Caught by controller[1]: at ClientRequest.emit (node:domain:489:12)
2023-08-07 13:05:53.758 - error: host.iobrokerstable Caught by controller[1]: at TLSSocket.emitRequestTimeout (node:_http_client:847:9)
2023-08-07 13:05:53.758 - error: host.iobrokerstable Caught by controller[1]: at Object.onceWrapper (node:events:628:28)
2023-08-07 13:05:53.758 - error: host.iobrokerstable Caught by controller[1]: at TLSSocket.emit (node:events:526:35)
2023-08-07 13:05:53.758 - error: host.iobrokerstable Caught by controller[1]: at TLSSocket.emit (node:domain:489:12)
2023-08-07 13:05:53.758 - error: host.iobrokerstable Caught by controller[1]: at TLSSocket.Socket._onTimeout (node:net:571:8)
2023-08-07 13:05:53.759 - error: host.iobrokerstable Caught by controller[1]: at listOnTimeout (node:internal/timers:569:17)
2023-08-07 13:05:53.759 - error: host.iobrokerstable instance system.adapter.tibberlink.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2023-08-07 13:06:56.286 - warn: tibberlink.0 (740234) Error (undefined) during: pull of homes:

weindler commented 1 year ago

Ich würde in Deiner Stelle vorher überlegen, wie Du den Adapter positionieren möchtest. Aus meiner Sicht dient er primär als Quelle um Preise, Stromverbrauch (Leistung und Energie) ioBroker zur Verfügung zu stellen.

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. Außerdem habe ich in ioBroker ein paar wenige kleinere Funktionen implementiert, die (noch) nicht in EVCC nicht drin sind, wie z.B. ein elektronisches Fahrtenbuch für mein E-Auto.

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.

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.

Schimi1983 commented 1 year ago

Ich würde in Deiner Stelle vorher überlegen, wie Du den Adapter positionieren möchtest. Aus meiner Sicht dient er primär als Quelle um Preise, Stromverbrauch (Leistung und Energie) ioBroker zur Verfügung zu stellen.

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. Außerdem habe ich in ioBroker ein paar wenige kleinere Funktionen implementiert, die (noch) nicht in EVCC nicht drin sind, wie z.B. ein elektronisches Fahrtenbuch für mein E-Auto.

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.

sehe ich auch so... dann vielleicht lieber einen seperaten Adapter der diese funktionen hat und auf tibberlink aufbaut.....

hombach commented 1 year ago

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

Hallo Martin, Das Verbindungsproblem hatte ich auch. Der issue #32 behandelt auch dieses Problem - ich bin dran ;) Gruß, Christian

hombach commented 1 year ago

Sortierte JSON nach Preis sind jetzt in Version 0.2.0 enthalten

volkerrichert commented 12 months ago

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

Marty56 commented 12 months ago

Du befindest dich in GitHub von Tibber link, Ok? Es gibt es ein nach Preis sortiertes Array. Sehe keine Notwendigkeit für irgendwelche Erweiterungen.

hombach commented 12 months ago

Wenn ich "getBestTime" von ioBroker.tibber richtig verstanden habe, dann bestimmt es die x idealen, aber zusammenhängenden(!) Stunden des Tages... das fände ich recht spannend - habe ich schon vorgesehen

volkerrichert commented 11 months ago

gibt es dazu denn schon was? ggf. kann man da was zuliefern

hombach commented 11 months ago

Angefangen habe ich schon - ich hänge momentan an einer Entscheidung: A: Der Adapter kann mehrere Homes und damit auch Pulse(s) .... das macht die Sache mit dem Calculator etwas komplexer - Abhilfe wäre hier je Calculator "Kanal" das entsprechende Home heraus zu suchen... kleine Prüfung ob überhaupt ein Pulse vorhanden, und fertig. Problem: es gibt noch Probleme mit dem Abfragen der Pulse wenn mehrere Homes vorhanden sind. B: Der Adapter wird geändert und kann nur noch ein Home - dann ist die Zuordnung des Calculator kein Thema mehr...

Akut tendiere ich zu "A"

weindler commented 11 months ago

Angefangen habe ich schon - ich hänge momentan an einer Entscheidung: A: Der Adapter kann mehrere Homes und damit auch Pulse(s) .... das macht die Sache mit dem Calculator etwas komplexer - Abhilfe wäre hier je Calculator "Kanal" das entsprechende Home heraus zu suchen... kleine Prüfung ob überhaupt ein Pulse vorhanden, und fertig. Problem: es gibt noch Probleme mit dem Abfragen der Pulse wenn mehrere Homes vorhanden sind. B: Der Adapter wird geändert und kann nur noch ein Home - dann ist die Zuordnung des Calculator kein Thema mehr...

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.

hombach commented 11 months ago

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.

volkerrichert commented 11 months ago

Angefangen habe ich schon - ich hänge momentan an einer Entscheidung: A: Der Adapter kann mehrere Homes und damit auch Pulse(s) .... das macht die Sache mit dem Calculator etwas komplexer - Abhilfe wäre hier je Calculator "Kanal" das entsprechende Home heraus zu suchen... kleine Prüfung ob überhaupt ein Pulse vorhanden, und fertig. Problem: es gibt noch Probleme mit dem Abfragen der Pulse wenn mehrere Homes vorhanden sind. B: Der Adapter wird geändert und kann nur noch ein Home - dann ist die Zuordnung des Calculator kein Thema mehr...

Akut tendiere ich zu "A"

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.

hombach commented 11 months ago

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.... Bei dem entsprechenden Home als Unterordner zur besseren Zuordnung... oder zentral um alle Calculator "Eingänge" an einem Fleck zu halten... (?)

volkerrichert commented 11 months ago

Aus meiner Sicht ganz klar als Unterordner beim entsprechenden Homes. So findet man super easy z.b. den passenden Current oder sonst was.

weindler commented 11 months ago

Unterordner

hombach commented 10 months ago

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. Tests sehr willkommen! Auch Kontrollen ob die Doku so verständlich ist ;)

spoeh-man commented 10 months ago

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.

hombach commented 10 months ago

Ich habe den Usecase auch - das Wetter (bzw. Solarertrag) drängt mich derzeit an der Sache weiter zu machen.... ;) Die "Billigsten xx Stunden" sind in der Umsetzung. Die "Teuersten xx Stunden" sind dann nur der Kehrwert, der sich damit schon abbilden lässt -> 3 teuerste bedeutet auf 21 billigste Stunden einstellen und statt true false ansteuern zu lassen und umgekehrt.

hombach commented 10 months ago

FYI: in der 1.1.1 ist noch ein Fehler im Timing, dadurch keine korrekte Aktualisierung bei "Stundenwechsel" = Preiswechsel. 1.1.2 fixed das - eben noch kurz in der Testschleife, kommt aber heute noch

spoeh-man commented 10 months ago

Ich habe den Usecase auch - das Wetter (bzw. Solarertrag) drängt mich derzeit an der Sache weiter zu machen.... ;) Die "Billigsten xx Stunden" sind in der Umsetzung. Die "Teuersten xx Stunden" sind dann nur der Kehrwert, der sich damit schon abbilden lässt -> 3 teuerste bedeutet auf 21 billigste Stunden einstellen und statt true false ansteuern zu lassen und umgekehrt.

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

weindler commented 10 months ago

Natürlich wird das getestet, warte schon sehnsüchtlich drauf @hombach

weindler commented 10 months ago

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

hombach commented 10 months ago

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.

weindler commented 10 months ago

@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ß.

hombach commented 10 months ago

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.

Kein Problem, man kann mehrere Calculator-Channels pro Home einsetzen

Ich hoffe es ist verständlich was ich meine auch wäre dass preisdelta intresant

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

hombach commented 10 months ago

Die 1.1.2 ist auf NPM - bei mir funktioniert so jetzt alles für "Best Price"

spoeh-man commented 10 months ago

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

hombach commented 10 months ago

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 ... ??

hombach commented 10 months ago

@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ß.

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:

spoeh-man commented 10 months ago

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 ... ??

ja oder ein wort laden entladen pause

bvwulfen commented 10 months ago

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). Zum Eingriff interessiert mich das Preisniveau, um aus vier Möglichkeiten zu entscheiden: ob ich besser den billigen Strom aus dem Netz beziehe und den vollen Ertrag der PV einspeicher bis die Akkus voll sind; ob ich Standard-Nulleinspeisung mache mit PV den Eigenverbrauch decke und nur den Überfluss einspeichere; ob ich Standard-Nulleinspeisung mache aber erlaube mit Batterie zur Nulleinspeisung zu stützen. last not least: ob ich die Wechselrichter stoppe, um die Akkus zu schonen, um bei teurerem Preis diese nutzen zu können.

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.) Die Verluste der Akkus durch das Einspeichern und Zyklen habe ich bei 9ct. pro kWH abgeschätzt. Bevor nicht der Preisunterschied erreicht wird lohnt sich keine Zwischenspeicherung (oder gar Aufladung aus dem Netz). Dazu vergleiche ich in IOBrooker nur den aktuellen Preis mit ner Mischung aus heutigem und morgigem Durchschnittspreis. Liegt die Differenz bei über 9ct stoppe ich die WR. (Beides Infos dazu in Tibberlink schon vorhanden).

Besser wird es wohl indem ich mein eigenes Lastprofil auf die Folgestunden und Preise integriere, aber ich hadere noch. EIGENTLICH müsste hier erst abgeschätzt werden welchen Ladezustand die Akkus erreichen werden bis das höhere Preisniveau erreicht ist, dann müsste man abschätzen welchen wie langen Zeitraum sie bei höchstem Preisniveau abdecken können. Der Zeitraum hier legt aber fest, in welchen Zeiträumen ich mit min. 9ct. drunter liege… Das ist bestimmt stabil bestimmbar, aber ich hab noch keine pragmatische Lösung…

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. Das ausbremsen der Wechelrichter mit dem Wissen der später teureren Tarif kommt als nächstes auf dei ToDo, geht aber über die angedachten „teuersten“ Zeitbereiche und Abschätzung der verbleibenden Akkukapazität. Für beides gibt mit die aktuelle Version schon alles was ich brauche.

In der Hoffnung mit den Überlegungen geholfen zu haben, mir haben sie gerade zum besseren Verständnis geholfen :) Cheers

spoeh-man commented 10 months ago

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.

hombach commented 10 months ago

@spoeh-man:

Denke du brauchst zwei Ausgaben=Datenpunkte für deine Akku Ansteuerung? Sprich Laden ja/nein und Entladen ja/nein ... ??

ja oder ein wort laden entladen pause

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". Im nächsten Channel nimmst du die 2 Stunden wo du laden willst - ValueOff = "pause" On="laden". Beide Channel lässt du auf den gleichen Datenpunkt schreiben.... sollte eigentlich funktionieren !!! War aber nie so gedacht ;) Version 1.2.0 von GIT installiert sollte das eigentlich schon hinbekommen -- wäre ein spannender Test :)

hombach commented 10 months ago

Besser wird es wohl indem ich mein eigenes Lastprofil auf die Folgestunden und Preise integriere, aber ich hadere noch. EIGENTLICH müsste hier erst abgeschätzt werden welchen Ladezustand die Akkus erreichen werden bis das höhere Preisniveau erreicht ist, dann müsste man abschätzen welchen wie langen Zeitraum sie bei höchstem Preisniveau abdecken können. Der Zeitraum hier legt aber fest, in welchen Zeiträumen ich mit min. 9ct. drunter liege… Das ist bestimmt stabil bestimmbar, aber ich hab noch keine pragmatische Lösung…

... 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.... Kommen wir da dem Ziel schon näher?

spoeh-man commented 10 months ago

@spoeh-man:

Denke du brauchst zwei Ausgaben=Datenpunkte für deine Akku Ansteuerung? Sprich Laden ja/nein und Entladen ja/nein ... ??

ja oder ein wort laden entladen pause

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". Im nächsten Channel nimmst du die 2 Stunden wo du laden willst - ValueOff = "pause" On="laden". Beide Channel lässt du auf den gleichen Datenpunkt schreiben.... sollte eigentlich funktionieren !!! War aber nie so gedacht ;) Version 1.2.0 von GIT installiert sollte das eigentlich schon hinbekommen -- wäre ein spannender Test :)

in 1.2.0 ist leider beste einzelstunden noch nicht implementiert

hombach commented 10 months ago

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.

spoeh-man commented 10 months ago

ich hatte die 1.2.0 von GIT

hombach commented 10 months ago

Die 1.2.0 sollte nicht älter wie 4h sein. Und nicht am "not implemented" stören lassen - da funktioniert was nicht. Habe dazu aber noch keinen Ansatz.

spoeh-man commented 10 months ago

aktuell kommt immer pause als Ergebnis muss ich morgen mal dran wenn ich zeit finde aber immerhin ein Ansatz

bvwulfen commented 10 months ago

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. Kein Hausakku macht aber keine 700 Zyklen im Jahr, sondern eher weniger als 350, die Chemie kann also etwas geschont werden. Zum Vergleich also: angenommene 4500 Zyklen auf 12,5 Jahre

Ab jetzt nicht weiterlesen wer nicht mitrechnen möchte und gleich zum Fazit springen ..:) _ Die 25% mehr Laufdauer bedeuten, dass im Doppelzyklus pro Tag es auf 12.5 Jahre 625€ statt 500€ sind (Früher neue Batterien) Dies aber bei nun 9000 Zyklen. (12,53502) Es ist also ein Mehrpreis pro Zyklus von 2,8 Cent! (625-500)%(9000-4500) Ein Zyklus heißt hier aber 2,5kWh, also ein Einspeichermehrpreis von 1Cent! pro kWh im zweiten Zyklus am Tag. Bei 500€ pro 2,5kWh (Batteriepreis) kostet die Normalnutzung mit 4500 Zyklen aber nach wie vor 4,5Cent.

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: Das Speichern aus PV in LiFePo kostet im Normalfall 4,5Ct pro kWh für die Batterie alleine. Der zusätzliche Ladezyklus pro Tag kostet die zusätzliche kWh trotz Verlusten nur 3ct. (1ct. Material, 2ct. Lade-/Entladeverluste)

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.

bvwulfen commented 10 months ago

... 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.... Kommen wir da dem Ziel schon näher?

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. Wie viele teure Stunden ich überbrücken kann, liegt an meinem Speicher, also Abschätzung des Individuums. Von den teuren Stunden benötigt man den mittleren Preis und kann dann überlegen welche günstigen Stunden darunter liegen. Dann die folgt die Optimierung welche der "Billigstunden" man nimmt. Optimierung, da ich den Aufladeprozess durch den PV-Überschuss schlechter abschätzen kann.

Ich lass es mal gären und schau was dort als Minimal/Optimal stehen bleiben kann.

hombach / ioBroker.tibberlink

Implement options to get best/worst hours per day #16