That’s what the start/end times are. All the information is there.
Yes but Brendan isn’t passing them through t the created sensor. I get that the info is there but it’s not available to use unless it gets through to the sensor.
So when I use the coordinates where I live (Pearce ACT) it find the nearest observations station is Tuggeranong and returns the correct data for observations. The forecast being returned is for my location (Pearce), but the forecast sensors are all named as Tuggeranong… I believe the forecast sensors should be named with the correct location.
I don’t really mind but wouldn’t it be best if the observations and forecast have the same naming? They are for the same location after all… Then if you added a second integration for a different location it’s easier to know which go together… Anyway I don’t much care either way.
But they aren’t for the same location. This is why I personally think Observations and Forecast integrations should be separate.
For where I live I want to configure 2 locations for observations and a different location for the forecast. So 3 different locations. For the observation stations I don’t want/need sensors for forecasts. And for the forecast location I don’t want any observations (they would be a duplicate of one of the others anyway).
You can disable any you don’t want I think Brendan said…
I see what @theRat is saying, for my location, observations would be, sensor.melbourne_olympic_park_* but a forecast is for a region, not a specific location, so it could be more like sensor.melbourne_*
For Pearce, ACT, observations would look like sensor.tuggeranong_* and forecast could be sensor.canberra_*. If two weather stations happened to be within the same forecast region, yes it would unfortunately create duplicate forecast sensors, the workaround would be disable the duplicate sensors through the UI.
As per simon quoted above I think you have it backwards.
Forecasts can be at the suburb level while observations are for a specific station… (unless I am reading him wrong)
OK! I understand now! The location name for forecasts comes from:
https://api.weather.bom.gov.au/v1/locations/r3dnb6x
{
"metadata":{
"response_timestamp":"2020-10-28T00:48:35Z"
},
"data":{
"geohash":"r3dnb6x",
"timezone":"Australia/Canberra",
"latitude":-35.36155700683594,
"longitude":149.0837860107422,
"id":"Pearce-r3dnb6x",
"name":"Pearce",
"state":"ACT"
}
}
Yep. That’s the way it works. The forecasts numbers (min/max rain etc) can vary from suburb to suburb. The text parts don’t change as they are more regional.
Nice work on 0.3 Brendan. I think I can work with that. Looking good. Seems BOM don’t make _0 min and max unavailable anymore either…
I might add an actual min/max as sensors that can be parsed through and if they exist show on the card like:
Showing the actual with (Forecast 12°C) after it… Open to thoughts on this.
It is low-moderate today not very high (according to the API)
https://api.weather.bom.gov.au/v1/locations/r659dx/forecasts/daily
How do you know it’s low-moderate today? Where does it say that?
I went to the link you posted and it says veryhigh.
“uv”:{“category”:“veryhigh”,“end_time”:“2020-10-28T05:10:00Z”
Yeah… I think I got it mixed up with fire danger. Doh!
Heres the value_template for UV
{% set uv = states('sensor.kariong_uv_category_0') %}
{% if uv == 'extreme' %} {% set uv = 'Extreme' %}
{% elif uv == 'veryhigh' %} {% set uv = 'Very High' %}
{% elif uv == 'high' %} {% set uv = 'High' %}
{% elif uv == 'moderate' %} {% set uv = 'Moderate' %}
{% elif uv == 'low' %} {% set uv = 'Low' %}
{% endif %}
Sun Protection {{ as_timestamp(states('sensor.kariong_uv_start_time_0')) | timestamp_custom(' %I:%M%p') | lower | replace(" 0", "") }} to {{ as_timestamp(states('sensor.kariong_uv_end_time_0')) | timestamp_custom(' %I:%M%p') | lower | replace(" 0", "") }}, UV Index predicted to reach {{ states('sensor.kariong_uv_max_index_0') }} [{{ uv }}]
Replicates current one. I wonder if they delete the UV value at some point?? (So I would then need to get tomorrows value?)
After sunset would be the time to check.
I think after 4:10 which is the end time…
Anyway just getting the templates sorted now
Thank God I can reload templates… without restarting HA…
1 Like
So it seems some of the conditions have been renamed… like partly-cloudy is now partly_cloudy etc…
This may take a bit longer and I will need to update the card as well…
grrrrrrrrr
But the forecast contains 60+ sensors, disabling all of those would be a massive pain.
Just an idea, when configuring the integration would it be possible to select whether you want forecast/observations/both along with the coordinates?