component throws error at midnight #277
Labels
bug
Something isn't working
Comments
|
Did it affect the actual charging? |
|
Not sure, as our dynamic tariffs are lower during the day in this season, we're charging during the day instead of nights |
|
I have made a v1.11.0-dev3 with the following changes:
Can you install this version, and see if you get the error next midnight? |
|
Sure, I'll let you know tomorrow! (FYI, the dev2 version threw the error again at midnight) |
|
Jupz, the error is still there but with a lot more detail now indeed: 2024-07-05 00:00:00.436 ERROR (MainThread) [custom_components.ev_smart_charging.helpers.coordinator] Is not able to calculate charging schedule!
2024-07-05 00:00:00.436 ERROR (MainThread) [custom_components.ev_smart_charging.helpers.coordinator] start_hour = 2024-07-02 22:00:00+00:00
2024-07-05 00:00:00.438 ERROR (MainThread) [custom_components.ev_smart_charging.helpers.coordinator] ready_hour = 2024-07-05 06:00:00+00:00
2024-07-05 00:00:00.438 ERROR (MainThread) [custom_components.ev_smart_charging.helpers.coordinator] hours = 3
2024-07-05 00:00:00.438 ERROR (MainThread) [custom_components.ev_smart_charging.helpers.coordinator] raw_two_days.data = [{'value': 0.2224329, 'start': datetime.datetime(2024, 7, 3, 22, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 3, 23, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1939979, 'start': datetime.datetime(2024, 7, 3, 23, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 0, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1714314, 'start': datetime.datetime(2024, 7, 4, 0, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 1, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1637479, 'start': datetime.datetime(2024, 7, 4, 1, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 2, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1606382, 'start': datetime.datetime(2024, 7, 4, 2, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 3, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1605414, 'start': datetime.datetime(2024, 7, 4, 3, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 4, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1894604, 'start': datetime.datetime(2024, 7, 4, 4, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 5, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1938889, 'start': datetime.datetime(2024, 7, 4, 5, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 6, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1914085, 'start': datetime.datetime(2024, 7, 4, 6, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 7, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1785462, 'start': datetime.datetime(2024, 7, 4, 7, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 8, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1395479, 'start': datetime.datetime(2024, 7, 4, 8, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 9, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.108463, 'start': datetime.datetime(2024, 7, 4, 9, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 10, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.0669479, 'start': datetime.datetime(2024, 7, 4, 10, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 11, 0, tzinfo=datetime.timezone.utc)}, {'value': -0.01509, 'start': datetime.datetime(2024, 7, 4, 11, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 12, 0, tzinfo=datetime.timezone.utc)}, {'value': -0.028642, 'start': datetime.datetime(2024, 7, 4, 12, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 13, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.0548479, 'start': datetime.datetime(2024, 7, 4, 13, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 14, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.0895265, 'start': datetime.datetime(2024, 7, 4, 14, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 15, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1139201, 'start': datetime.datetime(2024, 7, 4, 15, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 16, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.1455979, 'start': datetime.datetime(2024, 7, 4, 16, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 17, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.2009796, 'start': datetime.datetime(2024, 7, 4, 17, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 18, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.2506985, 'start': datetime.datetime(2024, 7, 4, 18, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 19, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.2823037, 'start': datetime.datetime(2024, 7, 4, 19, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 20, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.2518359, 'start': datetime.datetime(2024, 7, 4, 20, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 21, 0, tzinfo=datetime.timezone.utc)}, {'value': 0.2257846, 'start': datetime.datetime(2024, 7, 4, 21, 0, tzinfo=datetime.timezone.utc), 'end': datetime.datetime(2024, 7, 4, 22, 0, tzinfo=datetime.timezone.utc)}]And the config:
|
|
Thanks fore the error log. I think I know what the problem is. The integration is recalculating it's state based on changes in input information (such as the price sensor) and once per hour. If the "once per hour" update happens a few milliseconds before the price sensor is updated at midnight, it might be reason why there are problems. But if this is the case, it also means that a few milliseconds after the error, the price sensor will be updated, and then everything will work as normal. If you have the possibilty to "Enable debug logging" for the integration around midnight, it could help confirming this theory. I will try to recreate the problem and investigate what is exactly happening. |
|
I'll see what this yields: - id: ev_enable_debug_logging
alias: "Enable debug logging for ev_smart_charging component around midnight"
description: "Enable debug logging for ev_smart_charging component around midnight"
mode: single
trigger:
- platform: time
at: "23:55:00"
id: start_debug_logging
- platform: time
at: "00:05:00"
id: stop_debug_logging
action:
- alias: "Choose to start or stop debug logging"
choose:
- conditions:
- condition: trigger
id: start_debug_logging
sequence:
- alias: "Start debug logging for ev_smart_charging"
service: logger.set_level
data:
custom_components.ev_smart_charging: debug
# not sure if this also covers the next logger, so setting it explicitly
custom_components.ev_smart_charging.helpers.coordinator: debug
- conditions:
- condition: trigger
id: stop_debug_logging
sequence:
- alias: "Stop debug logging for ev_smart_charging"
service: logger.set_level
data:
custom_components.ev_smart_charging: warning
custom_components.ev_smart_charging.helpers.coordinator: warning |
|
I might have been able to recreate the problem. The following template: template:
- sensor:
- name: "Nordpool template price sensor"
unique_id: nordpool_template_price_sensor
unit_of_measurement: "öre/kWh"
state: "{{ states('sensor.nordpool_kwh_se3_sek_2_095_0') }}"
availability: "{{ 'sensor.nordpool_kwh_se3_sek_2_095_0' | has_value }}"
attributes:
prices_today: >
{%- set forecast_data = state_attr('sensor.nordpool_kwh_se3_sek_2_095_0', 'raw_today') %}
{%- set forecast_data2 = state_attr('sensor.nordpool_kwh_se3_sek_2_095_0', 'raw_tomorrow') %}
{%- set time_key = 'start' %}
{%- set price_key = 'value' %}
{%- set ns = namespace(data=[]) %}
{%- for i in forecast_data | default([], true) if i[time_key].date() == now().date() %}
{%- set ns.data = ns.data + [dict(time = i[time_key].strftime('%Y-%m-%d %H:%M:%S%z'), price = i[price_key])] %}
{%- endfor %}
{%- for i in forecast_data2 | default([], true) if i[time_key].date() == now().date() %}
{%- set ns.data = ns.data + [dict(time = i[time_key].strftime('%Y-%m-%d %H:%M:%S%z'), price = i[price_key])] %}
{%- endfor %}
{{ ns.data }}
prices_tomorrow: >
{%- set forecast_data = state_attr('sensor.nordpool_kwh_se3_sek_2_095_0', 'raw_today') %}
{%- set forecast_data2 = state_attr('sensor.nordpool_kwh_se3_sek_2_095_0', 'raw_tomorrow') %}
{%- set time_key = 'start' %}
{%- set price_key = 'value' %}
{%- set ns = namespace(data=[]) %}
{%- for i in forecast_data | default([], true) if i[time_key].date() == (now()+timedelta(days=1)).date() %}
{%- set ns.data = ns.data + [dict(time = i[time_key].strftime('%Y-%m-%d %H:%M:%S%z'), price = i[price_key])] %}
{%- endfor %}
{%- for i in forecast_data2 | default([], true) if i[time_key].date() == (now()+timedelta(days=1)).date() %}
{%- set ns.data = ns.data + [dict(time = i[time_key].strftime('%Y-%m-%d %H:%M:%S%z'), price = i[price_key])] %}
{%- endfor %}
{{ ns.data }}
Gave this log: There is something wrong/unexpected with the template sensor state at "2024-07-07 00:00:00.079". And then the template sensor state is updated again at "2024-07-07 00:00:00.117", and now it is correct! |
|
My logs for two nights: |
|
So the error didn't happen the last two nights for you. It seems a little odd that your price is updated 00:01:40 and 00:01:48, but it's not a problem for my integration. So no need to do anything about that. Anyhow, with your logs from three nights ago, and with my own logs, I now know what to do in order to fix this. There will be an update coming soon. |
|
Should be fixed in v1.11.0-dev4. Please check. |
|
Installed, will report back tomorrow |
|
here you are (-dev4): |
|
That looks good! Thanks for providing the logs! There will be an offical release towards the end of the week. |
|
Fixed in v1.11.0. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version of the custom_component
Version 1.11.0-dev2
Configuration
Standard setup, and using the template price sensor for Zonneplan (see wiki)
Describe the bug
I've seen the below error for a few days now, always at midnight
Debug log
The text was updated successfully, but these errors were encountered: