-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Support of Epex Spot prices from ha_epex_spot #231
Comments
@jonasbkarlsson seems like there will be more requests like this.
Or would you share examples of the data format used by currently supported sources and a way how to configure your integration to read an entity with compatible format even when the supported source is not present/detected? |
The three currently supported price sources as well as EPEX Spot mentioned by @andreasd all have very similar formats. When I added the second (and the third) price source I was thinking about providing a more general solution. But since it was so easy to add a slightly different price source, I did that instead. Basically they provide the price information in one (or two) attributes as an array of dictionary. And the dictionary use a certain key for the start time and another key for the price.
So one way to make the integration more generic would be to add a forth "generic" price source, where the user can provide strings for "price_list", "start_of_hour", "price" and optionally "price_list_tomorrow". How about that? For the EPEX spot case,
|
thanks for the quick response! i think it's just important to not limit this awesome extension by the price sources. so providing a generic price source that can either be configured via variables (like you showed in your example) or by reformatting other source data to a fixed input data, sound like a good way. i tried to find out if there is a somehow common data structure for hourly prices in home assistant, but it seems there is no standard so every extension follows a different approach. |
@jonasbkarlsson adding the generic/configurable price source would be great. |
@johny-mnemonic I made a template sensor to try out how the integration would react to that, but in one of the validation steps, the integration checks that there exist in entry with the supplied entity name in the To make your own integration that will fake one of the three supported price integration would work. Is that something you are considering to do? |
@jonasbkarlsson no, I was hoping the template sensor would be enough 😞 |
@johny-mnemonic How would you make the templete sensor? I have experimented with the following templete sensor. It mimics the format of the Entsoe price integration. But it has one inconvenient problem. The attribute In the below example,
|
is there anything i could do to help adding support for a broader range of price data sources? it seems like a defined structure for a sensor and then using some templates to gather this data from various sources seems like the most flexible option. |
@andreasd Can you contruct a template sensor that takes the output from your price data source and provies the state and attributes price_today and price_tomorrow? |
hi! thanks for the quick response. yes, I'm confident that I can construct such a sensor. I'm not entirely sure about the price_today and price_tomorrow attributes. the epex spot integration updates daily at around noon and will provide data until midnight the next day. so e.g. today i already have data until tomorrow 24:00 but tomorrow morning I will have only data until midnight. so there will be a period where there is no "price_tomorrow". is this separation of the hours needed or can we simply supply a list of hours and prices no matter how long in the future they are available? i could integrate a split of the data in today and tomorrow, but think it would offer more flexibility in the data sources if the integration handles this. |
something like this could be used to make the split in today and tomorrow and would output start_of_hour and price for each element from the epex spot sensor. state would be the current price |
@andreasd , Hi, should we perhaps coordinate these interfaces in the ha_epex_spot & hass_entsoe_dayahead-components, since we're both active we could be make the same nice interface for Jonas (and his clients) in both components. |
@andreas-berg i have no play in ha_epex_spot and think a better approach for this integration would be to offer a standardized interface to read in price data, like in the format proposed here. this way every user can build a template sensor (like the one from me above) that will provide data in the desired format. maybe those template sensors can be directly packaged with ev_smart_charging or collected in the documentation. with a standardized interface in ev_smart_charging for price data, it does not matter where the data is coming from. users won't have to hope that their price source provides it in the correct format, but they can reformat it themselves. this would in theory already work, it ev_smart_charging would not also check for other variables to determine if one of the supported data provider addons is installed. so it would also require minimal changes in ev_smart_charging. |
@andreasd, finally I got some time to test your template sensor above. For me it seems like it will not select today's and tomorrow's prices in the local time zone, but in UTC time. Was that your intention? The first price I get is the following:
But the first price for today in local time is at the time Also note that I changed your But otherwise, the template sensor seems to work. |
thanks for taking time to work on this! my template sensor was a quick proof of concept that it is possible to integrate different sources via templating to a format that ev_smart_charging defines. so things like "use utc/local time", names of the attributes, etc. should all be defined in ev_smart_charging and then we can start making template sensors from different sources that work with that standard. we could collect them in the wiki here so others have something to start of to integrate other sources or simply copy&paste them, if their source is already present. you for sure have the best insight how the sensor should be structured, so if you give me/us the requirements, I'm sure we can make use of it :) |
yeah, we need definition of what generic format ev_smart_charging expects and also the way to tell ev_smart_charging we are giving it a generic source so it should not check for the presence of the currently supported sources. |
I will make a proposed definition, and ask for comments. Also, I have noticed that some electricty price integration use Is it possible to make a template sensor that gives a |
Here is one definition of a price sensor. I added an OPEN ISSUE in the end. Should the format require the "today" and "tomorrow" data to only contain price data for today and tomorrow? The integration will work even if this is not the case, and I think I have seen price integrations that does not fulfill such a requirement. |
i'll take a look and will adapt the template sensor to fit this description! thank you! |
i have modified the template sensor and it should now fit the format.
generated sensor attributes:
I'm not sure if the integration i use (epex spot) can fulfill the requirement of "An array with 12 or fewer elements is considered to be invalid.". Is there an issue if the "tomorrow" element is empty because there is no data available yet? I only get data for the next day at 1-2pm each day, so until then, there simply is no data available. i'm also unsure about the datetime format. i guess calling as_datetime should provide it in the required format? otherwise I can change it back to the str representation. please let me know if there is anything else I can help with. |
Having problems with the development environment. Have not got the debugger to work with Python 3.12 of HA yet... Temportairly switching back to 3.11 to test the template sensor. So, the "price_today" and "price_tomorrow" in you example are not arrays of dict, they are strings. For example this:
Note the Is it possible to change something in the template sensor code to not make it a string? |
The I have now made a pre-release v1.11.0-dev1. I have not spent a lot a of time to verify the code... but please check if it works! I updated the price template definition and added an example for EPEX Spot. And the documentation page is not updated. |
i'll take a close look next week when I'm back home! thank you! |
had a chance to test it out now and no issues so far :) i'm seeing the prices and times in the extension (i included the dashboards from the readme.md) and calculcations of charging time also seems to work. so if everything goes well, the extension should trigger the first charge of my car tonight. I'll let you know if I took the car or the bike tomorrow morning :P |
I've tried using the extension but realized that the price information has to come from a supported source extension. I'm using https://github.com/mampfes/ha_epex_spot to get current and next day hourly prices. The extension provides a sensor with the prices in attributes and hourly intervals like this:
there are various other sensors (with options to add tax, surcharges, etc.) but all have in common that they provide prices (price_ct_per_kwh) and interval data (start_time, end_time) as attributes as seen in the screenshot above.
i have no experience with home_assistant addon development, but can help out debugging and testing, if this would increase the chance to support this data source ;)
thanks in advance!
The text was updated successfully, but these errors were encountered: