Closed umrath closed 7 months ago
Das bräuchte Api Credentials.
Ist das ein Problem? Als Entwickler kann man die relativ problemlos anfragen (der Ostrom-Support ist üblicherweise ziemlich responsiv). Und bei Tibber geht das ja ziemlich ähnlich.
Als Nutzer brauche ich für andere Dienste ja teilweise auch Zugangsdaten, die ich mir auch relativ problemlos über die App holen kann.
Kein Problem- muss nur jemand machen und zur Verfügung stellen.
Hi, ich bin neu hier. Hoffe es entspricht der Etiquette, wenn ich schreibe, dass auch ich mich freuen würde Ostrom integriert zu wissen im evcc. In dem Blogbeitrag „Feature Highlights 10/2023“ hat der Michael beim Punkt -Smartes Netzladen- dazu aufgefordert ein issue zu eröffnen, sofern ein dynamischer Stromtarif noch nicht unterstützt ist, wenn dieser aber eine Schnittstelle bietet. Wie eingangs erwähnt, ich bin neu hier und weiß nun nicht ob die von „umrath“ genannte API Doku jene Schnittstelle darstellt, welche das evcc-Team benötigt. Bin aufjedenfall sehr dankbar für das starke evcc-Tool!!
Danke. Am letzen Zustand bzgl. Anforderungen hat sich allerdings nichts geändert, s.o.
Ich verstehe allerdings nicht ganz, was an den Voraussetzungen nicht erfüllt ist. Eine offene Schnittstelle ist doch vorhanden.
Genau das verstehe ich nicht. Eine Mail an partner@ostrom.de sollte doch völlig genügen.
Alles klar. Habe da mal ganz freundlich eine Nachricht hinterlassen. Vielleicht melden die sich ja. Sobald die es tun, gebe ich hier ein Zeichen.
@habz0c haben sie es getan?
Nein
Noch immer nicht? Sonst würde ich mal nachhaken. Bisher war der Support immer sehr auf zack.
Leider noch immer keine Antwort von denen.
Ich habe mir die API (https://docs.ostrom-api.io/reference/introduction) mal angeschaut.
Ich bin mir garnicht sicher, ob wir hier mit den "partner" api credentials richtig fahren. Die persönlichen credentials für jeden Nutzer wären ja richtiger, da ja jede evcc Instanz selbständig die Tarife abruft. Der partner Zugriff hat hier ja eher eine andere Zielgruppe.
Dazu kommt das die API bzgl. Tarife sehr wenig kann. Ich weiß nicht was die anderen Anbieter hier liefern, aber ostrom liefert hier scheinbar einfach nur die spot Preise, welche ja eher generisch sind. Zumindest mit einem call gegen die Sandbox https://sandbox.ostrom-api.io ist das so. Ich müsste mir mein persönliches Netzentgeld/Steuern etc. sowieso dazu addieren. In der Hinsicht macht es ja kaum Sinn x APIs von x Stromanbietern zu integrieren die alle nur die spot Preise liefern.
Ich kann leider noch nicht gegen die produktive API testen, da mein Lieferbeginn erst am 1.4. ist. Zur Zeit sagt die produktive Umgebung nur: "kein aktiver Vertrag"
Btw. könnte ich credentials für die sandbox zur Verfügung stellen.
Ich bin auch sehr an einer Integration interessiert und werde mir die API auch mal ansehen. Ab Mai bin ich auch Kunde von Ostrom. Wer an einem Referral Code interessiert ist, kann mich gerne über Telegram unter @arend_boehmer oder per Mail kontaktieren.
Ich werde Anfang April, wenn mein Vertrag dann läuft, einen PR dafür machen können. Im Grunde ist das aktuell etwas sinnfrei, weil die API relativ exakt das liefert, was auch die awattar API liefert. Man könnte also auch einfach die awattar API für eine Strompreisindikation verwenden (die benötigt keinen Authentifizierung). Es sind eben einfach nur die EPEX SPOT Preise für MWh bzgl. Tageszeit gemittelt über alle Strombörsen in Europa.
Ich denke der Strommarkt muss sich aber hier weiter entwickeln und es müssen die Regionen wo der Strom erzeugt und abgenommen wird mit in den Preis einfließen. So könnten die APIs pro Stromanbieter irgendwann dann wieder Sinn machen.
Im Grunde muss hier aber evcc sagen wo die Reise hingehen soll. Es müssen in Deutschland ab 2025 alle Energieanbieter gesetzlich verpflichtend dynamische Stromtarife anbieten. Es ist unrealistisch für alle eine API zu implementieren.
Okay, Evtl. könnte man die verschiedenen dynamischen Tarife aus den Anbieter-APIs zukünftig als Plugins einbinden, aber das wird @andig besser beurteilen können.
Nabend, Wenn ich da so lese stellt sich mir die Frage ob es möglich ist die Werte von EPEX direkt abzurufen.
Die APIs von netztransparenz.de könnte hier eine sinnvolle Anlaufstelle sein. Das scheint ein Projekt der Übertragungsnetzbetreiber zu sein.
Nabend, Wenn ich da so lese stellt sich mir die Frage ob es möglich ist die Werte von EPEX direkt abzurufen.
Die Idee hatte ich auch schon. Es gibt für Home Assistant schon eine fertige Integration: https://github.com/mampfes/ha_epex_spot
Ich verstehe die Diskusssion nicht. Reicht Entso-E nicht?
Ich denke schon, dass das reicht. Leider war das für mich nicht offensichtlich und damit scheine ich ja nicht alleine zu sein.
Wir sind noch nicht gut darin, die verfügbaren Tarife zu vermarkten.
/cc @naltatis
Dann ist ja vorerst alles geklärt. Danke euch. :)
Ich denke schon, dass das reicht. Leider war das für mich nicht offensichtlich und damit scheine ich ja nicht alleine zu sein.
Ebenso... 😂
Zwischenzeitlich können „custom“ Tarife auch selbst per Template implementiert werden.
Huhu Leute, ich bin auch Ostrom Kunde und baue eventuell selbst noch eine Integration für HASIO. Aber ich hab nun auch mal EVCC angeschaut und finde das recht nett. Vielleicht kann man ja auch hier eine Preisabfrage für Ostrom mit einbauen? Die API ist recht einfach. Rest API mit Bearer Token und dann muss man die Preise abfragen. Dann muss man nicht zwei Werte aus dem Preisarray addieren. Und hat bereits den Endkundenpreis inkl. Netzgebühr.... hab das mit dem Ostrom Support validiert.
Ja, kann man 👍🏻
Zwischenzeitlich können „custom“ Tarife auch selbst per Template implementiert werden.
Ja, das funktioniert.
Statischer Tarif (monatlich):
tariffs:
currency: EUR
grid:
type: custom
price:
source: http
uri: https://api.ostrom.de/v1/tariffs/city-id?cityId=11111&usage=1000
jq: .ostrom[0].workingPriceBrutto
scale: 0.01
Dynamischer Tarif (stündlich):
tariffs:
currency: EUR
grid:
type: custom
forecast:
source: http
uri: https://api.ostrom.de/v1/spot-prices/ostrom-product-tariff?cityId=11111&postalCode=55555
jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
@naltatis @andig Lohnt es (schon) dafür ggf. Aufwand in Tariff-Templates zu stecken?
Ja, sollten wir nutzen. Die werden inzwischen ja auch automatisch in der Doku angezeigt. Das macht's für neue Nutzer viel einfacher. Und wir haben dann gleich die Grundlage für die UI.
Hab mal einen groben Entwurf erstellt: #14206
Zwischenzeitlich können „custom“ Tarife auch selbst per Template implementiert werden.
Ja, das funktioniert.
Statischer Tarif (monatlich):
tariffs: currency: EUR grid: type: custom price: source: http uri: https://api.ostrom.de/v1/tariffs/city-id?cityId=11111&usage=1000 jq: .ostrom[0].workingPriceBrutto scale: 0.01
Dynamischer Tarif (stündlich):
tariffs: currency: EUR grid: type: custom forecast: source: http uri: https://api.ostrom.de/v1/spot-prices/ostrom-product-tariff?cityId=11111&postalCode=55555 jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
Zwischenzeitlich können „custom“ Tarife auch selbst per Template implementiert werden.
Ja, das funktioniert.
Statischer Tarif (monatlich):
tariffs: currency: EUR grid: type: custom price: source: http uri: https://api.ostrom.de/v1/tariffs/city-id?cityId=11111&usage=1000 jq: .ostrom[0].workingPriceBrutto scale: 0.01
Dynamischer Tarif (stündlich):
tariffs: currency: EUR grid: type: custom forecast: source: http uri: https://api.ostrom.de/v1/spot-prices/ostrom-product-tariff?cityId=11111&postalCode=55555 jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
Bei mir will der Server mit den Anpassungen in der Config einfach nicht mehr starten
Error during startup. Check your configuration and restart. cannot create tariff type 'custom': jq: query failed: cannot iterate over: null
Es darf nur ein "type: custom" eingebunden werden. "forecast" ODER "price", also entweder "statischer Tarif" ODER "dynamischer Tarif". Die URL-Parameter "cityId" und "postalCode" müssen individuell angepasst werden.
Ich bekomme im Moment beim Abruf des dynamischen Tarifs aber auch einen Fehler:
cannot create tariff type 'custom': jq: too many results
Das müsste ich mir genauer angucken.
Es darf nur ein "type: custom" eingebunden werden. "forecast" ODER "price", also entweder "statischer Tarif" ODER "dynamischer Tarif". Die URL-Parameter "cityId" und "postalCode" müssen individuell angepasst werden. Ich bekomme im Moment beim Abruf des dynamischen Tarifs aber auch einen Fehler:
cannot create tariff type 'custom': jq: too many results
Das müsste ich mir genauer angucken.
Vielen Dank für dein Feedback.....
ich habe im Grunde nur die 2. Konfiguration genutzt, die sich auf den dynamischen Tarif bezieht...die Fehlermeldung bezieht sich auch auf diese Zeile: jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
P.S. was ist mit CityID gemeint ?
Gruß
Es darf nur ein "type: custom" eingebunden werden. "forecast" ODER "price", also entweder "statischer Tarif" ODER "dynamischer Tarif". Die URL-Parameter "cityId" und "postalCode" müssen individuell angepasst werden. Ich bekomme im Moment beim Abruf des dynamischen Tarifs aber auch einen Fehler:
cannot create tariff type 'custom': jq: too many results
Das müsste ich mir genauer angucken.Vielen Dank für dein Feedback.....
ich habe im Grunde nur die 2. Konfiguration genutzt, die sich auf den dynamischen Tarif bezieht...die Fehlermeldung bezieht sich auch auf diese Zeile: jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
P.S. was ist mit CityID gemeint ?
Gruß
Guck mal auf https://www.ostrom.de/ und gib deine Daten für die Berechnung deines Tarifs ein. Wenn man dann auf "Tarif berechnen" klickt, wird man auf eine Seite weitergeleitet und in der Adresszeile steht dann etwas wie:
https://join.ostrom.de/tariff-plan?usage=1000&cityId=11111&postalCode=55555&cityName=Musterstadt&language=de_DE
Da siehst du dann deine cityId.
Es darf nur ein "type: custom" eingebunden werden. "forecast" ODER "price", also entweder "statischer Tarif" ODER "dynamischer Tarif". Die URL-Parameter "cityId" und "postalCode" müssen individuell angepasst werden. Ich bekomme im Moment beim Abruf des dynamischen Tarifs aber auch einen Fehler:
cannot create tariff type 'custom': jq: too many results
Das müsste ich mir genauer angucken.Vielen Dank für dein Feedback..... ich habe im Grunde nur die 2. Konfiguration genutzt, die sich auf den dynamischen Tarif bezieht...die Fehlermeldung bezieht sich auch auf diese Zeile: jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}' P.S. was ist mit CityID gemeint ? Gruß
Guck mal auf https://www.ostrom.de/ und gib deine Daten für die Berechnung deines Tarifs ein. Wenn man dann auf "Tarif berechnen" klickt, wird man auf eine Seite weitergeleitet und in der Adresszeile steht dann etwas wie:
https://join.ostrom.de/tariff-plan?usage=1000&cityId=11111&postalCode=55555&cityName=Musterstadt&language=de_DE
Da siehst du dann deine cityId.
Oh ja....da muss man erstmal drauf kommen ;-))
An der Fehlermeldung ändert sich allerdings dadurch nichts ;-(
Es darf nur ein "type: custom" eingebunden werden. "forecast" ODER "price", also entweder "statischer Tarif" ODER "dynamischer Tarif". Die URL-Parameter "cityId" und "postalCode" müssen individuell angepasst werden. Ich bekomme im Moment beim Abruf des dynamischen Tarifs aber auch einen Fehler:
cannot create tariff type 'custom': jq: too many results
Das müsste ich mir genauer angucken.Vielen Dank für dein Feedback..... ich habe im Grunde nur die 2. Konfiguration genutzt, die sich auf den dynamischen Tarif bezieht...die Fehlermeldung bezieht sich auch auf diese Zeile: jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}' P.S. was ist mit CityID gemeint ? Gruß
Guck mal auf https://www.ostrom.de/ und gib deine Daten für die Berechnung deines Tarifs ein. Wenn man dann auf "Tarif berechnen" klickt, wird man auf eine Seite weitergeleitet und in der Adresszeile steht dann etwas wie:
https://join.ostrom.de/tariff-plan?usage=1000&cityId=11111&postalCode=55555&cityName=Musterstadt&language=de_DE
Da siehst du dann deine cityId.Oh ja....da muss man erstmal drauf kommen ;-))
An der Fehlermeldung ändert sich allerdings dadurch nichts ;-(
I tried it in https://jqkungfu.com/ and it works. Error using this in evcc is
jq: too many results
Resultset is an array with 24 entries, but "too many" is relative :-)
Sounds like a peoblem with the query, not the amount of data.
This gives back valid data format in online jq tester, but doesn't work in evcc:
'[.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}]'
-> invalid character 'm' looking for beginning of value
Thats a different error? What's the data? As usual, log files are king.
Data is:
{
"day": {
"averagePrice": 30.38,
"prices": [
{
"date": "2024-06-17T00:00:00.000Z",
"dateUTC": "2024-06-16T22:00:00.000Z",
"price": 7.67,
"grossKwhPrice": 9.12,
"mWhPriceInEuros": 76.62,
"hour": "00",
"taxesAndLevies": 20.59,
"priceWithTaxesAndLevies": 28.26
},
{
"date": "2024-06-17T01:00:00.000Z",
"dateUTC": "2024-06-16T23:00:00.000Z",
"price": 6.68,
"grossKwhPrice": 7.95,
"mWhPriceInEuros": 66.73,
"hour": "01",
"taxesAndLevies": 20.41,
"priceWithTaxesAndLevies": 27.09
},
{
"date": "2024-06-17T02:00:00.000Z",
"dateUTC": "2024-06-17T00:00:00.000Z",
"price": 6.89,
"grossKwhPrice": 8.19,
"mWhPriceInEuros": 68.81,
"hour": "02",
"taxesAndLevies": 20.45,
"priceWithTaxesAndLevies": 27.34
},
{
"date": "2024-06-17T03:00:00.000Z",
"dateUTC": "2024-06-17T01:00:00.000Z",
"price": 7.19,
"grossKwhPrice": 8.55,
"mWhPriceInEuros": 71.81,
"hour": "03",
"taxesAndLevies": 20.5,
"priceWithTaxesAndLevies": 27.69
},
{
"date": "2024-06-17T04:00:00.000Z",
"dateUTC": "2024-06-17T02:00:00.000Z",
"price": 7.36,
"grossKwhPrice": 8.76,
"mWhPriceInEuros": 73.56,
"hour": "04",
"taxesAndLevies": 20.54,
"priceWithTaxesAndLevies": 27.9
},
{
"date": "2024-06-17T05:00:00.000Z",
"dateUTC": "2024-06-17T03:00:00.000Z",
"price": 9.01,
"grossKwhPrice": 10.72,
"mWhPriceInEuros": 90.02,
"hour": "05",
"taxesAndLevies": 20.85,
"priceWithTaxesAndLevies": 29.86
},
{
"date": "2024-06-17T06:00:00.000Z",
"dateUTC": "2024-06-17T04:00:00.000Z",
"price": 11.92,
"grossKwhPrice": 14.18,
"mWhPriceInEuros": 119.13,
"hour": "06",
"taxesAndLevies": 21.4,
"priceWithTaxesAndLevies": 33.32
},
{
"date": "2024-06-17T07:00:00.000Z",
"dateUTC": "2024-06-17T05:00:00.000Z",
"price": 13.27,
"grossKwhPrice": 15.79,
"mWhPriceInEuros": 132.68,
"hour": "07",
"taxesAndLevies": 21.66,
"priceWithTaxesAndLevies": 34.93
},
{
"date": "2024-06-17T08:00:00.000Z",
"dateUTC": "2024-06-17T06:00:00.000Z",
"price": 11.63,
"grossKwhPrice": 13.84,
"mWhPriceInEuros": 116.23,
"hour": "08",
"taxesAndLevies": 21.35,
"priceWithTaxesAndLevies": 32.98
},
{
"date": "2024-06-17T09:00:00.000Z",
"dateUTC": "2024-06-17T07:00:00.000Z",
"price": 8.48,
"grossKwhPrice": 10.09,
"mWhPriceInEuros": 84.73,
"hour": "09",
"taxesAndLevies": 20.75,
"priceWithTaxesAndLevies": 29.23
},
{
"date": "2024-06-17T10:00:00.000Z",
"dateUTC": "2024-06-17T08:00:00.000Z",
"price": 6.22,
"grossKwhPrice": 7.4,
"mWhPriceInEuros": 62.11,
"hour": "10",
"taxesAndLevies": 20.32,
"priceWithTaxesAndLevies": 26.54
},
{
"date": "2024-06-17T11:00:00.000Z",
"dateUTC": "2024-06-17T09:00:00.000Z",
"price": 5.51,
"grossKwhPrice": 6.55,
"mWhPriceInEuros": 55.01,
"hour": "11",
"taxesAndLevies": 20.18,
"priceWithTaxesAndLevies": 25.69
},
{
"date": "2024-06-17T12:00:00.000Z",
"dateUTC": "2024-06-17T10:00:00.000Z",
"price": 4.19,
"grossKwhPrice": 4.99,
"mWhPriceInEuros": 41.86,
"hour": "12",
"taxesAndLevies": 19.93,
"priceWithTaxesAndLevies": 24.12
},
{
"date": "2024-06-17T13:00:00.000Z",
"dateUTC": "2024-06-17T11:00:00.000Z",
"price": 3.95,
"grossKwhPrice": 4.7,
"mWhPriceInEuros": 39.45,
"hour": "13",
"taxesAndLevies": 19.89,
"priceWithTaxesAndLevies": 23.84
},
{
"date": "2024-06-17T14:00:00.000Z",
"dateUTC": "2024-06-17T12:00:00.000Z",
"price": 4.67,
"grossKwhPrice": 5.55,
"mWhPriceInEuros": 46.62,
"hour": "14",
"taxesAndLevies": 20.02,
"priceWithTaxesAndLevies": 24.69
},
{
"date": "2024-06-17T15:00:00.000Z",
"dateUTC": "2024-06-17T13:00:00.000Z",
"price": 5.46,
"grossKwhPrice": 6.5,
"mWhPriceInEuros": 54.54,
"hour": "15",
"taxesAndLevies": 20.18,
"priceWithTaxesAndLevies": 25.64
},
{
"date": "2024-06-17T16:00:00.000Z",
"dateUTC": "2024-06-17T14:00:00.000Z",
"price": 6.43,
"grossKwhPrice": 7.65,
"mWhPriceInEuros": 64.21,
"hour": "16",
"taxesAndLevies": 20.36,
"priceWithTaxesAndLevies": 26.79
},
{
"date": "2024-06-17T17:00:00.000Z",
"dateUTC": "2024-06-17T15:00:00.000Z",
"price": 8.86,
"grossKwhPrice": 10.55,
"mWhPriceInEuros": 88.58,
"hour": "17",
"taxesAndLevies": 20.82,
"priceWithTaxesAndLevies": 29.68
},
{
"date": "2024-06-17T18:00:00.000Z",
"dateUTC": "2024-06-17T16:00:00.000Z",
"price": 11.42,
"grossKwhPrice": 13.59,
"mWhPriceInEuros": 114.16,
"hour": "18",
"taxesAndLevies": 21.31,
"priceWithTaxesAndLevies": 32.73
},
{
"date": "2024-06-17T19:00:00.000Z",
"dateUTC": "2024-06-17T17:00:00.000Z",
"price": 15.74,
"grossKwhPrice": 18.73,
"mWhPriceInEuros": 157.37,
"hour": "19",
"taxesAndLevies": 22.13,
"priceWithTaxesAndLevies": 37.87
},
{
"date": "2024-06-17T20:00:00.000Z",
"dateUTC": "2024-06-17T18:00:00.000Z",
"price": 21.02,
"grossKwhPrice": 25.01,
"mWhPriceInEuros": 210.16,
"hour": "20",
"taxesAndLevies": 23.13,
"priceWithTaxesAndLevies": 44.15
},
{
"date": "2024-06-17T21:00:00.000Z",
"dateUTC": "2024-06-17T19:00:00.000Z",
"price": 20.01,
"grossKwhPrice": 23.81,
"mWhPriceInEuros": 200.01,
"hour": "21",
"taxesAndLevies": 22.94,
"priceWithTaxesAndLevies": 42.95
},
{
"date": "2024-06-17T22:00:00.000Z",
"dateUTC": "2024-06-17T20:00:00.000Z",
"price": 12.82,
"grossKwhPrice": 15.25,
"mWhPriceInEuros": 128.15,
"hour": "22",
"taxesAndLevies": 21.57,
"priceWithTaxesAndLevies": 34.39
},
{
"date": "2024-06-17T23:00:00.000Z",
"dateUTC": "2024-06-17T21:00:00.000Z",
"price": 10.16,
"grossKwhPrice": 12.09,
"mWhPriceInEuros": 101.55,
"hour": "23",
"taxesAndLevies": 21.07,
"priceWithTaxesAndLevies": 31.23
}
]
},
"year": {
"averagePrice": 28.53,
"prices": [
{
"price": 5.62,
"month": "2024-05",
"taxesAndLevies": 20.21,
"priceWithTaxesAndLevies": 25.83
},
{
"price": 6.24,
"month": "2024-04",
"taxesAndLevies": 20.32,
"priceWithTaxesAndLevies": 26.56
},
{
"price": 6.46,
"month": "2024-03",
"taxesAndLevies": 20.37,
"priceWithTaxesAndLevies": 26.83
},
{
"price": 6.13,
"month": "2024-02",
"taxesAndLevies": 20.3,
"priceWithTaxesAndLevies": 26.43
},
{
"price": 7.66,
"month": "2024-01",
"taxesAndLevies": 20.59,
"priceWithTaxesAndLevies": 28.25
},
{
"price": 6.85,
"month": "2023-12",
"taxesAndLevies": 20.44,
"priceWithTaxesAndLevies": 27.29
},
{
"price": 9.11,
"month": "2023-11",
"taxesAndLevies": 20.87,
"priceWithTaxesAndLevies": 29.98
},
{
"price": 8.75,
"month": "2023-10",
"taxesAndLevies": 20.8,
"priceWithTaxesAndLevies": 29.55
},
{
"price": 10.07,
"month": "2023-09",
"taxesAndLevies": 21.05,
"priceWithTaxesAndLevies": 31.12
},
{
"price": 9.43,
"month": "2023-08",
"taxesAndLevies": 20.93,
"priceWithTaxesAndLevies": 30.36
},
{
"price": 7.76,
"month": "2023-07",
"taxesAndLevies": 20.61,
"priceWithTaxesAndLevies": 28.37
},
{
"price": 10.63,
"month": "2023-06",
"taxesAndLevies": 21.16,
"priceWithTaxesAndLevies": 31.79
}
]
}
}
Log:
[tariff] ERROR 2024/06/17 16:42:50 invalid character 'm' looking for beginning of value
[main ] FATAL 2024/06/17 16:42:50 cannot create tariff type 'custom': invalid character 'm' looking for beginning of value
[main ] FATAL 2024/06/17 16:42:50 will attempt restart in: 15m0s
Please provide full log, showing data.
Seems this needs the debugger. Can I test this in any way? Which config/credentials?
Seems this needs the debugger. Can I test this in any way? Which config/credentials?
What do you need to debug it? I could send you my "cleaned" config (home assistant addon) without IPs, user names and passwords.
Alle Parameter um den Aufruf zu machen. Ich kann nicht hellsehen :)
Zwischenzeitlich können „custom“ Tarife auch selbst per Template implementiert werden.
Ja, das funktioniert. Statischer Tarif (monatlich):
tariffs: currency: EUR grid: type: custom price: source: http uri: https://api.ostrom.de/v1/tariffs/city-id?cityId=11111&usage=1000 jq: .ostrom[0].workingPriceBrutto scale: 0.01
Dynamischer Tarif (stündlich):
tariffs: currency: EUR grid: type: custom forecast: source: http uri: https://api.ostrom.de/v1/spot-prices/ostrom-product-tariff?cityId=11111&postalCode=55555 jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
Zwischenzeitlich können „custom“ Tarife auch selbst per Template implementiert werden.
Ja, das funktioniert. Statischer Tarif (monatlich):
tariffs: currency: EUR grid: type: custom price: source: http uri: https://api.ostrom.de/v1/tariffs/city-id?cityId=11111&usage=1000 jq: .ostrom[0].workingPriceBrutto scale: 0.01
Dynamischer Tarif (stündlich):
tariffs: currency: EUR grid: type: custom forecast: source: http uri: https://api.ostrom.de/v1/spot-prices/ostrom-product-tariff?cityId=11111&postalCode=55555 jq: '.day.prices[ ] | {start: .date, price: .priceWithTaxesAndLevies}'
Bei mir will der Server mit den Anpassungen in der Config einfach nicht mehr starten
Error during startup. Check your configuration and restart. cannot create tariff type 'custom': jq: query failed: cannot iterate over: null
Ich habe eine Frage zu den Daten. ich nutze aktuell Tibber und schaue mit gerade ostrom an. Bei Tibber habe ich ja über die API eine Vorschau bis morgen. So wie ich das in dieser Abfrage sehe, ist das ja immer nur der aktuelle Tag und nicht bis morgen. Wie läuft das mit dem Ladeplanung ab wenn man nicht genügend Vorschau hat. Hast du da schon Erfahrungen? Oder bekommt man als Kunde eine andere API Schnittstelle mit mehr Informationen?
Much like Tibber, Ostrom provides hourly tariffs with variable prices. I would very much like to see this getting integrated into evcc, if possible.
Link to the API: https://docs.ostrom-api.io/reference/introduction