Yes, but that does not matter. You can even make it output similar to the solcast sensor by modifying {% set output_item = {time:sum_value} %} to {% set output_item = {'period_start': time, 'pv_wh_estimate':sum_value} %} i.e.
I don’t have multiple PV arrays so I can’t test but does something like this work? I’m a beginner at Jinja/templating (obviously adapt for wh_period, etc; this is an example for watts):
{% set sensor1 = state_attr('sensor.energy_production_today_2', 'watts') %}
{% set sensor2 = state_attr('sensor.energy_production_today_3', 'watts') %}
{% set ns = namespace(output={}) %}
{% for time, value in sensor1.items() %}
{% set ns.output = dict({time: value}, **ns.output) %}
{% endfor %}
{% for time, value in sensor2.items() %}
{% if time in ns.output %}
{% set ns.output = dict({time: ns.output[time] + value}, **ns.output) %}
{% else %}
{% set ns.output = dict({time: value}, **ns.output) %}
{% endif %}
{% endfor %}
{{ ns.output }}
This error originated from a custom integration.
Logger: custom_components.open_meteo_solar_forecast
Source: helpers/update_coordinator.py:312
integration: Open-Meteo Solar Forecast (documentation, issues)
First occurred: June 10, 2024 at 20:01:00 (1138 occurrences)
Last logged: 02:00:00
Unexpected error fetching open_meteo_solar_forecast data
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/open_meteo_solar_forecast/coordinator.py", line 63, in _async_update_data
return await self.forecast.estimate()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/open_meteo_solar_forecast/open_meteo_solar_forecast.py", line 155, in estimate
data = await self._request(
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/open_meteo_solar_forecast/open_meteo_solar_forecast.py", line 122, in _request
raise OpenMeteoSolarForecastRatelimitError("Rate limit exceeded")
open_meteo_solar_forecast.exceptions.OpenMeteoSolarForecastRatelimitError: Rate limit exceeded
1138 occurrences, it means there are 1138 api calls in 6 hours?
No it just retries until the rate limit is lifted, after it succeeds it polls the API every 30mins. I could make my personal Open-Meteo instance available to others for use if needed.
It’s caused by your IP being shared with others, Open-Meteo is popular outside of HA (apps like Breezy Weather use it) so you probably have a neighbor that’s into FOSS services.
What does it mean that my IP is being shared with others? Could it be because I am using cloudflared for remote access to home assistant? I would be glad if you could help me find a solution for this issue.
It’s really unrelated to this integration but I’ll explain in simple terms. Basically because there are only ~4B public IPv4 addresses available (and >8B people, servers, devices, etc) ISPs are forced to basically use something like NAT44 so that all their users could access the IPv4 internet. One of the many issues with technologies like NAT44 is that it means that a large chunk of the ISP’s users (sometimes even an entire city) would share the same IPv4 address. That is why your Open-Meteo quota is exhausted so quickly, there are other people also using Open-Meteo with the same public IPv4 address.
I’ve opened a discussion on GitHub to ask if API keys could be made available for free users, this way the quota is per-API key not IP address: API keys for the free Open-Meteo API · open-meteo/open-meteo · Discussion #843 · GitHub. If it doesn’t work (I’m 99% sure it’ll be rejected) I could just make my own personal instance available, I feel like I would probably be able to cope with the load.
Thank you for your explanation. I thought there could only be one public ip-address at the same time. I think there is no way for me to solve this problem, is it? It would be great if you could offer a solution. I tink 10 daily calls per instance (I have got four) should be enough at it was with solcast either.
I tried to use 4 Sensors to sum up but I get the following errors, perhaps you can help me out:
TemplateError('TypeError: unsupported operand type(s) for +: 'int' and 'dict'') while processing template 'Template<template=({% set sensor1 = state_attr('sensor.energy_production_today_8', 'watts') %} {% set sensor2 = state_attr('sensor.energy_production_today_9', 'watts') %} {% set sensor3 = state_attr('sensor.energy_production_today_10', 'watts') %} {% set sensor4 = state_attr('sensor.energy_production_today_11', 'watts') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% set sum_value = value + sensor2 + sensor3 + sensor4[time] %} {% set ns.output = dict({time: sum_value}, **ns.output) %} {% endfor %} {{ ns.output }}) renders=4>' for attribute 'watts' in entity 'sensor.energy_production_today_all'
TemplateError('TypeError: unsupported operand type(s) for +: 'float' and 'dict'') while processing template 'Template<template=({% set sensor1 = state_attr('sensor.energy_production_today_8', 'wh_period') %} {% set sensor2 = state_attr('sensor.energy_production_today_9', 'wh_period') %} {% set sensor3 = state_attr('sensor.energy_production_today_10', 'wh_period') %} {% set sensor4 = state_attr('sensor.energy_production_today_11', 'wh_period') %} {% set ns = namespace(output={}) %} {% for time, value in sensor1.items() %} {% set sum_value = value + sensor2 + sensor3 + sensor4[time] %} {% set ns.output = dict({time: sum_value}, **ns.output) %} {% endfor %} {{ ns.output }}) renders=4>' for attribute 'wh_period' in entity 'sensor.energy_production_today_all'
I’ve decided to make my Open-Meteo instance public, you could use https://om.4gggg.com if you like. All you would need to do is set it as the Base URL, there is no API key required.