goecharger / go-eCharger-API-v2

New API specification for V3 and V4 go-eCharger
86 stars 21 forks source link

Request re-fetch of awattar prices #152

Open UdoKrie opened 1 year ago

UdoKrie commented 1 year ago

Since Wifi from home to go-echarger is sometimes impacted, e.g. by a closed garage door, it happens from time to time that the go-echarger doesn't know about the current awattar price: http://go-echarger.familie-kriebel.net/api/status?filter=awcp =>"awcp": null (Maybe there are other reasons beside Wifi that current prices are not available) In consequence a planned low price charging is omitted.

After rebooting with stable Wifi typically the go-echarger retrieves the data successfully from the provide ( in my case tibber germany).

However, rebooting after detecting awcp == null should not be the method of choice, so here some questions / requests:

  1. Is there a method to trigger awattar price fetch/ update via REST API besides reboot ?
  2. If not, please provide an API method to tigger a price fetch
  3. Could you please document the triggers when the go-echarger updates the awattar prices ? Once a day ? Each hour ?

That would help to understand and maybe work-around the issue.

BTW, I' currently investigate options to implement a price based charging plan (utilizing openHAB or HomeAssitant)

br, Udo

UdoKrie commented 1 year ago

I did some more investigations:

awc seems to do the trick: the description is not correct, it seems to be a kind of tarif identifier, in my case either 222 or 1377 ( both tibber tarifs). Setting the awc as config triggers a fetch of the current price, awcp gets updated, in case of null -> valid values.

Could you please confirm the behavior and maybe update the documentation accordingly ? Thx in advance, Udo

povlhp commented 7 months ago

It is fine that setting awc will force refetch of pricing, still needs to be added to docs. Currently I often have awcp = null, and thus smart charging does not work. Neither planned, nor low price charging.

I am located in Denmark, awc = 230, and often prices are missing, often Denmark is completely missing in the list of countries to pick prices from, thus it is very unstable.

Could we please get a supported way to write awpl (aWattar Price List) - it seems to contain hourly prices up to x hours into the future. I can see in in "Debug API Viewer" in the iPhone App. I can sometime see awcp = null, and values in awpl.

right now, my best bet is to change awcp to 1 after a few failed attempts with awc = 230, and then use German prices as a rough guideline for when smart charging should pick its hours.

That said, being able to have say awc = 999 = manual awpl upload would be great. In Denmark prices consists of: Nordpool spot + fixed governement fee + fixed fee (electricity seller - we have roaming among there) + Transport fee (fixed, but 3 different time windows, set by electricity cable owner (about 30 of these in Denamrk)) + VAT on top of everything. Thus to pick the best time, I would need at least spot + Transport fee - as transport fee between 1700-2100 is often way more than electricity price. But I have blocked in that timespan. Low fee 0000-0600 thus if I could write awpl and have it use that for planning, I could do all calculations in Home Assistant.

UdoKrie commented 7 months ago

Currently I often have awcp = null, and thus smart charging does not work. Neither planned, nor low price charging.

Thank you for rising this topic. In my case I observe that awcp always null, even writing to awc (FW 055.7), regardless which trariff provider I select (tibber, awattar and so on). So it seems more a problem of the box. BTW, awpl looks also valid in my scenario.

Could we please get a supported way to write awpl (aWattar Price List) - it seems to contain hourly prices up to x hours into the future. I can see in in "Debug API Viewer" in the iPhone App.

How can this field be retrieved ? It's not part of the official http status api.

I'm starting with an hourly tariff@tibber in january and also highly interesseted in a stable awcp field

povlhp commented 7 months ago

Field is only visible from the debug API in the app. But it shows that there is an internal value it would make sense to make writeable (if not readable - but that might not be possible depending on licensing of price data).

kalaws commented 2 weeks ago

Bump. Would still be great to be able to write prices manually.

erxbout commented 1 week ago

I had a look at this.. If awc is set to the max value of uint16_t (65535) the awpl will not refresh over the pushed prices.. It should work to push price data with:

curl --request GET \
  --url 'http://192.168.3.235/api/set?awpl=%5B%7B%22start%22%3A1620634400%2C%22end%22%3A1620638000%2C%22marketprice%22%3A1.705999851226807%7D%2C%7B%22start%22%3A1720634400%2C%22end%22%3A1720638000%2C%22marketprice%22%3A1.705999851226807%7D%5D' 

Yes this is a get request and due to to url length beeing limited there is only the possibility to push data from two hours.. It is totally not best practice but this would work for the moment..

kalaws commented 1 week ago

Thanks for looking into it! Perhaps it would be possible to include in the pushed url another url where prices are fetched? Far fetched, I suppose :)

erxbout commented 1 week ago

hahaha yea far fetched indeed xD

Problem is we do not fetch with http requests and if we would do that the server would need to respond in the correct format ect.. Would also be a bit of hassle to get it setup right..