Make Tibber priceInfo available as attributes of current price #69364
Conversation
Added already downloaded priceInfo for today with timestamp and price level as list in attribute raw_today
Added already downloaded priceInfo for tomorrow with timestamp and price level as list in attribute raw_tomorrow
Added only prices as list for today and tomorrow as new attribute
Added tomorrow_valid as attribute if array of tomorrows prices are valid
This is the same format as the Nordpool integration, only with Tibber's api keys ("startsAt" and "total")
Adjusted valid update interval by changing hours until last timestamp from 5 to 8 and spread_load_constant from 5000 to 3600 (to reduce refresh window)
This should move update interval from 16:20-18:00 to 13:30-14:30 to make sure tomorrows prices are downloaded a bit earlier in the day
|
Hey there @Danielhiversen, mind taking a look at this pull request as it has been labeled with an integration ( |
Knodd
changed the title
Changed returing [] to None for empty attributes to make it consistent with initial state for sensor
fix check errors
|
I do not think these are allowed as attributes. |
Has this been implemented? If not, would it not make sense to add data as attributes now and move it to forecast later when possible? I made the format exactly like the Nordpool integration (except for the API-keys) to make it clear what data is returned) so it would be an easy swap out for Tibber customers since Nordpool API is deprecated |
No, but independent of that I do not think these are allowed as attributes. |
|
Since it's the same data being used for current price sensor and it already has attributes for min/max/avg, price_level etc I thought it would be ok. How should we add them then? Can we reuse the data for a separate sensor entity called price_forecast or something? The way I read the link above that's not the optimal way either |
Always return null/None for empty price data Check that todays prices is valid array before iterating
MartinHjelmare
changed the title
|
Who makes the decision if future prices are allowed as attributes of the current price sensor or not? |
|
We should wait for the architecture discussion to be resolved before we expose this information. |
Returning None for empty data makes it necessary to check for datatype i Apexcharts etc. Returning empty list keeps graph from crashing if data is not valid list and returns no data points as expected
|
OK, guess we'll just have to be patient then. Any estimate on the timeline for this discussion? There has been no comments for 4 months on the discussion and it focuses mostly on the problem with existing integrations spreading forecast values over separate entities making automations based on forecast cumbersome. This is not the case for listed data in attributes where we easily can use {% if states('sensor.electricity_price') > average(state_attr('sensor.electricity_price', 'today')) %} to check if the current price is above todays average price etc Weather forecast integrations generally (met.no as an example) also exposes forecast data as lists in attributes so I don't see whats worse with forecasting electricity prices as attributes. I understand the need to keep it organized and in common form, but my opinion is that it would be a better solution to expose the data as attributes now (seems to be the general way integrations solve forecasting data today) and move it to a forcasted values model for sensor data when (and if) such a function is added at some point later, along with all other integrations providing forecasted data |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
|
I hope to keep this PR alive. Adding the pricing info would make this integration much more useful for automation purposes. |
|
Let's close here until the architecture discussion is resolved. |
Added priceInfo for today with timestamp and price level as list in attribute raw_today
Added priceInfo for tomorrow with timestamp and price level as list in attribute raw_tomorrow
Added only prices as list for today and tomorrow as new attributes
Added tomorrow_valid as attribute if array of tomorrows prices are valid
This is the same format as the Nordpool integration, only with Tibber's api keys ("startsAt" and "total")
Adjusted valid update interval by changing hours until last timestamp from 5 to 8 and spread_load_constant from 5000 to 3600 (to reduce refresh window)
This should move update interval from 16:20-18:00 to 13:30-14:30 to make sure tomorrows prices are downloaded a bit earlier in the day
Proposed change
add extra attributes for priceInfo and update them when current price is updated.
The price info is already included in downloaded data
Type of change
Additional information
Checklist
black --fast homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: