Closed Celphor closed 7 months ago
Went back to 1.3.1 (where I came from when upgrading to 2.2.0) and everything is fine again
Timestamps are given in UTC time in the developers view (as indicated by "+00:00"). If you use e.g. ApexCharts, they will be printed using your local time zone setting.
I can confirm the implementation in v2.2 is wrong. If the hours are in Utc timezone then the first hour for delivery date 4 Jan should start on 3 Jan 23:00 like it is in v1.4. Because Belgium is currently on Utc +1. You can see this time shift at https://www.timeanddate.com/worldclock/converter.html?iso=20240103T230000&p1=48&p2=1440
This is what I see if a configure an EPEX Spot Web Scraper for BE:
My timezone is set to (but this shouldn't make a difference at all):
Is this what you would expect? Do you see different values? If yes, there must be a difference in your system configuration. Please share more information about your configuration.
Hi @mampfes , I freshly installed HACS around 26/12 and then the v2.2.0 version of epex spot. I displayed the prices via the apex charts and had the issue that when clicking on the first block that it was showing in the popup 02:00 as time. Afterwards I saw this issue and had the same data format as Celphor. The first timing started at midnight with the timezone indicator also on +00:00. So something like: start_time: '2023-12-19T00:00:00+00:00' end_time: '2023-12-19T01:00:00+00:00'
Downgrading to v1.4 changed it in start_time: '2023-12-18T23:00:00+00:00' end_time: '2023-12-19T00:00:00+00:00' The charts were fine then.
Today I did see the v2.3.1 version and upgraded to that one and now I have it as format: start_time: '2023-12-19T00:00:00+01:00' end_time: '2023-12-19T01:00:00+01:00'
For me this is also a correct representation. For my concern this bug can be closed. :) @Celphor Can you upgrade to v2.3.1 and confirm it is fine for you too ?
@Celphor, @stevenboeckmans Did 2.3.1 fix the issue for you?
@mampfes For me it looks fine with 2.3.1 Thank you.
Tried 2.3.2 - the problem persists
@Celphor Hm, as the problem persists only for you, my guess that this has s.th. with your setup and/or operating system. Which HA installation type are you using? (HA OS, Container, Core, Supervised). Which timezone is configured in HA and - if you don't use HA OS - which timezone is configured in your operating system?
You mentioned that 1.3.1 worked and 2.2.0 doesn't work anymore. There were 3 releases in between (1.4.0, 2.0.0, 2.1.0.). Could you please find out which release exactly causes the problem? Because so far I don't an idea what causes this issue.
Sure. 1.4.0 is ok, 2.0.0 breaks it
@Celphor Are you using Awattar as source? If yes, could you please test the new beta version 2.3.3.2? I think I found the root case of this issue, but I'm not sure whether this fix is working. One problem is, that version 1.4.0 didn't use the Awattar API correctly. Therefore a change is definitely needed.
I'm using Awattar (at). In 2.3.3.2 the hours and prices match now, but now you pull the wrong days. Today shows yesterday prices and tomorrow is today. Miscount by 1 is developers best friend ;-)
the hours and prices match now, ok, good!
today shows yesterday prices and tomorrow is today Could you please check this again? I don't see this on my machine and I don't think that this has s.th. to do with the latest changes.
Ah, the problem is a little bit different. You pull 3 days of data now, so the first set is yesterday. Before there was only today and tomorrow (if available). As I reuse the data on an external display assuming the data starts on the current day, i went into the trap ;-) Do you keep it like this or wasn't this intended?
As of now:
So in the future, can I rely on this code to work? I just changed the indices to the second and third split as follows on my sensors returning a string of pipe separated daily prices:
name: Strompreise heute
unique_id: strompreise_heute
icon: mdi:currency-eur
state: "
{% set s = states.sensor['epex_spot_at_price'].attributes.data | map(attribute='price_ct_per_kwh') %}
{% if (s | batch(24) | list | length) < 2 %}
{{ '' }}
{% else %}
{% set s = states.sensor['epex_spot_at_price'].attributes.data | map(attribute='price_ct_per_kwh') %}
{% for price in (s | batch(24) | list)[1] %}
{{- price | round(2) -}}
{%- if not loop.last %}|{% endif -%}
{% endfor %}
{% endif %}
"
Yes, I will keep this behaviour, because I need the day from yesterday for epex_spot_sensor in certain situations.
I am happy with it. Thanks for fixing the bug!
Version 2.2.0
I am in timezone GMT+1
In attributes the first value is the value for 1 o'clock and the last value for 23pm is missing, so the list only covers 23 hours. The total list is shifted by one hour.
Example for today: