Thanks for this, great work! In terms of the recent change to create sensors, for me thatâs a better approach. However, Dark sky currently creates sensors for each attribute and each day i.e. precipitation0d, precipitation1d, windspeed0d, windspeed1d whereas your implementation creates a âdayâ sensor with each of the items as attributes. Personally I prefer the Dark Sky approach as they I just refer to the sensors, but interested to hear thoughts?
@briis Thanks so much for including the current day forecast. Unfortunately, I think there is still something wrong about the way this is implemented with the dates. This is my stock weather card after the update:
Today is Monday. The card doesnât show the current day high/low under the temperature because it doesnât know what it is. I shouldnât see Sunday in the forecast, itâs past. Sunday has the Monday - ie current - data in it; Monday is showing Tuesdayâs data, etc.
I also have bramkragtenâs custom weather card installed, and it shows the data incorrectly in the same way.
@rsachoc I made a pile of template sensors to pull the forecast highs and lows out when I was trying to make this work with the custom Dark Sky weather card, so it is possible to make the sensors you want yourself. I agree it would be easier if the sensors were already created in this way by the custom component. There just needs to be some sanity on how many sensors - 16 days of forecast data sensors would be unnecessary in my opinion. But I donât know how much work this would be for @briis, and what his philosophy is on how he created the component.
Thank you for creating this integration. Just installed it for the first time today and I have the same problem as @Anwen in that today is Monday and itâs starting with Sunday.
Hi all,
I belive I found the error. All text based dates in the raw data are UTC time, and I need to get those converted to Local Timezone, which then will fix the wrong weekday issue. I hope to have this done some time tomorrow.
With regards to the sensor, and one sensor per value per forecast day. It is doable, but will of course create a lot of sensors in your system. Honestly I donât use the sensors, as I have a personal Weatherstation, that I read through another Integration I wrote - so I am happy to do one or the other.
I will work on correcting the dates and let you all know when done.
Before sensors were created inside this integration, I created set of sensors for forecast to be able to feed data to weather card build from individual components. Below is code for one day set (as it is right now it will retrieve forecast for today). It can be easity adjusted to following days just by changing index (so all â0â to â1â and so onâŚ) and adjusting sensor name. These sensors also include icons for overal condition (also considering partly cloudy night). I did not created sensors for wind, as I do not use it, but this should be easy to create from other one by analogy:
sensor:
- platform: template
sensors:
temp_max_0:
friendly_name: 'Temerature Forecast max 0'
value_template: "{{ state_attr('weather.weatherbit_zielonka', 'forecast')[0].temperature }}"
unit_of_measurement: '°C'
temp_min_0:
friendly_name: 'Temerature Forecast min 0'
value_template: "{{ state_attr('weather.weatherbit_zielonka', 'forecast')[0].templow }}"
unit_of_measurement: '°C'
condition_0:
friendly_name: 'Condition Forecast 0'
value_template: "{{ state_attr('weather.weatherbit_zielonka', 'forecast')[0].condition }}"
icon_template: >
{% set stat = state_attr('weather.weatherbit_zielonka', 'forecast')[0].condition %}
{% if stat == 'clear-night' %} mdi:weather-night
{% elif stat == 'cloudy' %} mdi:weather-cloudy
{% elif stat == 'exceptional' %} mdi:weather-sunny-alert
{% elif stat == 'fog' %} mdi:weather-fog
{% elif stat == 'hail' %} mdi:weather-hail
{% elif stat == 'lightning' %} mdi:weather-lightning
{% elif stat == 'lightning-rainy' %} mdi:weather-lightning-rainy
{% elif stat == 'partlycloudy' %} mdi:weather-partly-cloudy
{% elif stat == 'pouring' %} mdi:weather-pouring
{% elif stat == 'rainy' %} mdi:weather-rainy
{% elif stat == 'snowy' %} mdi:weather-snowy
{% elif stat == 'snowy-rainy' %} mdi:weather-snowy-rainy
{% elif stat == 'sunny' %} mdi:weather-sunny
{% elif stat == 'windy' %} mdi:weather-windy
{% elif stat == 'windy-variant' %} mdi:weather-windy-variant
{% else %} mdi:cloud-question
{% endif %}
precip_0:
friendly_name: 'Precipitation Forecast 0'
value_template: "{{ state_attr('weather.weatherbit_zielonka', 'forecast')[0].precipitation }}"
unit_of_measurement: 'mm'
Finally at the moment my weather looks like on the screenshot below. For current conditions I do use data from Netatmo Weather Station:
Thank you for your great work! I think for now itâs probably better if you leave the single sensor per day and if people want they can create their own forecast sensors. More flexible, but a little more upfront work! Thanks again!
Hi All,
This took a bit longer than I expected, but handling dates and timezones, is more complicated than I thought. In the end I had to actually read the Developer Docs and this Integration now conforms to the way HA expects it to. The Weather Entity always expects a DateTime entry in UTC, where as I had to convert the time for the Sensor to be Location Aware as this is not handled by Home Assistant.
I have done numerous tests, and in the end it boils down to the Timezone you have set on your Computer, if the Days are displayed correctly. So if you add a Weather Entity for the same Timezone as your Computer is set to, it should display correct, but if it is a location in a different Timezone, the days might not be correct for parts of the day.
Let me know how this goes.
Release 0.12
Weather Entity now reports datetime as UTC Date time in RFC 3339 format, which is what the Lovelace Weathercard expects.
Sensor Entity now reports datetime as Location aware Date time in RFC 3339 format.
I just tested 8 different locations spread across the Globe, and unfortunately they all report 3mi or 5km. So I must conclude that the raw data we get from weatherbit always include that number. Maybe it would help if this was reported to weatherbit?
@briis Dates are working now! Thanks for figuring all that out! I agree with your decision on the sensors, but could I ask you to make just one more? There is a text description field in the current API:
and it would be great to have that text string (e.g.âFew cloudsâ) for a custom weather card.
My current visibility is 5 if I look at the API data as well.
@ffeingol If you want to see the raw weather data, you can look at the API data yourself. The documentation for the API is here: https://www.weatherbit.io/api. Scroll down and click on the green Documentation button for whichever data you are interested in. For example, if you choose Current Weather, and scroll down the page a bit, it gives an example API call:
Replace Raleigh,NC with your city and API_KEY with your API key, and paste that link into a browser. It will return the data is JSON format. If your city doesnât work, you could also use latitude and longitude with
Iâll be happy to do that. I know itâs really outside the scope of this, but if you can give me an example of how to call the API via curl I could report it a lot easier. If not, I totally understand. Just read the next post and that was all I needed.
Thank you. But I need to know the exact wording of what appears in the sensors. For instance, in the link you supplied, although there are âfew cloudsâ, âbroken cloudsâ etc there is no âcloudyâ, which is what appears in the sensors.