That’s interesting as I recently setup a page to compare 3 different weather integrations side by side and so far there does not appear to be much of a difference except that tomorrow.io also provides pollen levels:
I was not aware that the Met Office one was being discontinued.
It’s mentioned here under Backward Incompatible changes:
Hopefully temporary… I have a lot of links into this so will hold off upgrading until it is fixed or it becomes clear that’s not going to happen.
Thanks. I’ll be doing the same. Although there seem to be other issues as well…
I still intend to continue to scrape the Met office for weather alerts, but I have been testing met.no (same as @Jonah1970’s first comparison). Seems to work well.
Thanks for all the comments.
Having seen the upstream issue (Python 3.12, versioneer build failure · Issue #183 · EJEP/datapoint-python · GitHub) has been open for just over a year without progress and the code owner does not seem to be active, I wasn’t overly optimistic of getting a good outcome, especially not in the next couple of days (when 2024.2 is released).
I’ll have a look at the two @Jonah1970 has compared and hope that Met Office will return soon!
Regards,
Gordon
Hi,
After re-factoring several TTS automations to speak forecasts using the new 2023.12 service, I just went with the default source (Norwegian Meteorological Institute).
I think some other forecast sources (e.g Gnome desktop) use the nearest airport METAR (e.g. lookup METAR EGNT for Newcastle).
So far, the morning wake-up message based on forecast_daily feels to have been relatively accurate for NE England, but then again, I’m not explicitly monitoring quality against other sources. My automation reads out the forecast time as a ‘freshness’ test and it’s always been current.
Across all providers, hourly slot forecasts seem to give great precision but terrible accuracy!
The only thing I’d like to add is a trigger for National Severe Weather Warning Service warnings for my area. After quick look, the data seems available via email and RSS so likely not hard to achieve.
Back in the day, ISTR Mycroft used to get UK Meto data but haven’t checked the code for years. Must rework my Mycroft One as a Wyoming Satellite!
Thanks for the link - my search foo didn’t find that thread! 
There’s some seriously nice template functions parsing out the data in that thread - digesting the contents might take several cups of tea! 
If I’ve got the gist of the thread, I might have a tinker and read up on custom feedparser and feedreader. Didn’t find them earlier today when looking for integrations as they seem general purpose, rather than RSS-specific.
If you look at the extract post I linked, you’ll see I shared the complete package to do it. You only need to set your region and add the feedparser integration. Happy to help you if you need it.
That post also contains the card to display the info.
Thanks again - I’m only so far down the thread (and rabbit hole), but the help is definitely appreciated!
Ironically, this is probably an indoor project ideal for the upcoming snow severe warning… 
Just because the metoffice add-on is going away doesn’t mean you have to stop using the metoffice. You can do the same using the RESTfull sensor.
Something like this in the rest: domain
- resource: http://datapoint.metoffice.gov.uk/public/data/txt/wxfcs/regionalforecast/json/511?key=<your api key>
verify_ssl: false
timeout: 30
scan_interval: 3600
sensor:
- name: metoffice.RegionalForecast
value_template: "{{ value_json['RegionalFcst']['FcstPeriods']['Period'][0]['Paragraph'][1]['$'] }}"
You will need to get your metoffice location ID from the following list (I’m using 511 because that’s where I am:
{
"Locations": {
"Location": [
{
"@id": "500",
"@name": "os"
},
{
"@id": "501",
"@name": "he"
},
{
"@id": "502",
"@name": "gr"
},
{
"@id": "503",
"@name": "st"
},
{
"@id": "504",
"@name": "ta"
},
{
"@id": "505",
"@name": "dg"
},
{
"@id": "506",
"@name": "ni"
},
{
"@id": "507",
"@name": "nw"
},
{
"@id": "508",
"@name": "ne"
},
{
"@id": "509",
"@name": "yh"
},
{
"@id": "510",
"@name": "wm"
},
{
"@id": "511",
"@name": "em"
},
{
"@id": "512",
"@name": "ee"
},
{
"@id": "513",
"@name": "sw"
},
{
"@id": "514",
"@name": "se"
},
{
"@id": "515",
"@name": "uk"
},
{
"@id": "516",
"@name": "wl"
}
]
}
}
Then you can use the data in a template like
{{ states('sensor.metoffice_regionalforecast') }}
Result type: string
Outbreaks of rain and snow for much of the day. Snow likely over modest high ground, heavy at times, but a rain and snow mix at low levels in the north, and mostly rain in the south. Becoming windy. Cold. Maximum Temperature 4C.
This is just what I use to get the daily forecast to announce to me when it takes me up, just to brighten my day, but the metoffice api provides a vast wealth of information that can be queried in the same way using REST, and then re-used for whatever you need.
Yet.
DataPoint is an unsupported service with a planned retirement date of March 2025. Further details will be provided in due course.
I hope / assume a suitable alternative will be arranged.
The replacement service is already available, its called Data Hub and is at
Its more complex to use, but there is a free plan up to 1GB of data per month, more than sufficient for most HA users I suspect.
Personally, I’ll upgrade when the current service ends and I’m forced to do it, but for now its working fine.
For anyone adventurous enough to try datahub, and have come up against the tragic documentation, here’s a quick start:
https://data.hub.api.metoffice.gov.uk/sitespecific/v0/point/hourly?datasource=BD1&includeLocationName=true&latitude=52.9646&longitude=-1.1506&excludeParameterMetadata=true
set long/lat to the middle of your city (in my case middle of Nottingham)
and put your API key in the header, as a value of ‘apikey’. This will then return a slab of JSON, and an excerpt of which is
"requestPointDistance": 1190.8376,
"modelRunDate": "2024-02-08T17:00Z",
"timeSeries": [
{
"time": "2024-02-08T17:00Z",
"screenTemperature": 2.63,
"maxScreenAirTemp": 2.66,
"minScreenAirTemp": 2.51,
"screenDewPointTemperature": 2.39,
"feelsLikeTemperature": -1.77,
"windSpeed10m": 5.25,
"windDirectionFrom10m": 71,
"windGustSpeed10m": 9.77,
"max10mWindGust": 10.66,
"visibility": 4000,
"screenRelativeHumidity": 97.76,
"mslp": 98600,
"uvIndex": 0,
"significantWeatherCode": 8,
"precipitationRate": 0.0,
"totalPrecipAmount": 0.0,
"totalSnowAmount": 0,
"probOfPrecipitation": 22
},
You’ll then have to dig into that to pull whatever you need out of it. There’s a hourly (above), daily, and 3 hourly available.
If anyone has the enthusiasm to code a rest sensor (probably with
json_attributes_path and then a series of json_attributes, then please share.
You’ll then need to construct your own forecast using a template, etc. You know the deal.
- resource: https://data.hub.api.metoffice.gov.uk/sitespecific/v0/point/hourly?datasource=BD1&includeLocationName=true&latitude=[LATITUDE]&longitude=[LONGITUDE]&excludeParameterMetadata=true
headers:
apikey: "YOUR_LONG_API_KEY"
scan_interval: 3600
sensor:
- name: Datahub Hourly
value_template: "{{ value_json['features'][0]['properties']['modelRunDate'] }}"
json_attributes_path: $.features.0.properties
json_attributes:
- timeSeries
Then you can pull out the nearest “forecast” as the current weather into attributes of a sensor, and one example of pulling out one of those attributes into a sensor state:
template:
- sensor:
- name: Current weather
state: >
{% set tsl = state_attr('sensor.datahub_hourly','timeSeries')|map(attribute='time')|map('as_timestamp')|list %}
{% set ts = tsl|select('>=',(now()-timedelta(minutes=30))|as_timestamp())|first %}
{{ tsl.index(ts) }}
attributes:
status: "{{ state_attr('sensor.datahub_hourly','timeSeries')[this.state|int(0)] }}"
- sensor:
- name: Wind speed
state: "{{ state_attr('sensor.current_weather','status')['windSpeed10m'] }}"
unit_of_measurement: 'm/s'
device_class: wind_speed
attributes:
timestamp: "{{ state_attr('sensor.current_weather','status')['time'] }}"
The state of sensor.current_weather is the index of the forecast block in the hourly Datahub sensor timeSeries list that is closest to the current time.
Use this macro to return a description for the significantWeatherCode:
{% macro weather_code(x) -%}
{{ {
0: "Clear night",
1: "Sunny day",
2: "Partly cloudy",
3: "Partly cloudy",
4: "Not used",
5: "Mist",
6: "Fog",
7: "Cloudy",
8: "Overcast",
9: "Light rain shower",
10: "Light rain shower",
11: "Drizzle",
12: "Light rain",
13: "Heavy rain shower",
14: "Heavy rain shower",
15: "Heavy rain",
16: "Sleet shower",
17: "Sleet shower",
18: "Sleet",
19: "Hail shower",
20: "Hail shower",
21: "Hail",
22: "Light snow shower",
23: "Light snow shower",
24: "Light snow",
25: "Heavy snow shower",
26: "Heavy snow shower",
27: "Heavy snow",
28: "Thunder shower",
29: "Thunder shower",
30: "Thunder"}.get(x, "n/a") -}}
{% endmacro %}
This doesn’t provide a weather object, though. Perhaps I need to learn how to create an integration.
@Troon So much better than what I came up with!
I created a sensor for the 1st in the array for each of hourly, 3-hourly, and daily and @Gen helped me make that more sensible with json_attributes_path: "$['features'][0]['properties']['timeSeries'][1]" but a long list of json_attributes.
I haven’t had time to do anything since, so here is one of the daily ones anyway and special thanks to @GEN who got me there…
rest:
- resource: !secret met_office_datahub_daily
scan_interval: 3600 #max
headers:
apikey: !secret met_office_datahub_apikey
verify_ssl: false
sensor:
# timeSeries[x] x={0-7} selects day
# note starting with [1] as this is consistent ([0] seems to lose entities as the day progresses)
- name: MetOffice d1
device_class: timestamp
value_template: "{{ (value_json.features[0].properties.timeSeries[1].time |as_datetime )| as_local }}"
json_attributes_path: "$['features'][0]['properties']['timeSeries'][1]"
json_attributes:
- time
- midday10MWindSpeed
- midnight10MWindSpeed
- midday10MWindDirection
- midnight10MWindDirection
- midday10MWindGust
- midnight10MWindGust
- middayVisibility
- midnightVisibility
- middayRelativeHumidity
- midnightRelativeHumidity
- middayMslp
- midnightMslp
- maxUvIndex
- daySignificantWeatherCode
- nightSignificantWeatherCode
- dayMaxScreenTemperature
- nightMinScreenTemperature
- dayUpperBoundMaxTemp
- nightUpperBoundMinTemp
- dayLowerBoundMaxTemp
- nightLowerBoundMinTemp
- dayMaxFeelsLikeTemp
- nightMinFeelsLikeTemp
- dayUpperBoundMaxFeelsLikeTemp
- nightUpperBoundMinFeelsLikeTemp
- dayLowerBoundMaxFeelsLikeTemp
- nightLowerBoundMinFeelsLikeTemp
- dayProbabilityOfPrecipitation
- nightProbabilityOfPrecipitation
- dayProbabilityOfSnow
- nightProbabilityOfSnow
- dayProbabilityOfHeavySnow
- nightProbabilityOfHeavySnow
- dayProbabilityOfRain
- nightProbabilityOfRain
- dayProbabilityOfHeavyRain
- nightProbabilityOfHeavyRain
- dayProbabilityOfHail
- nightProbabilityOfHail
- dayProbabilityOfSferics
- nightProbabilityOfSferics
2024.2.2 released today brings back the Met office integration (haven’t upgraded to it yet though):
2024.2.2
- Bump datapoint to 0.9.9 + re-enable Met Office Integration (@DustyArmstrong - #110206) (metoffice docs) (dependency)
Met office now working for me. But remind didn’t Met Office have a full 3 hourly weather entity? I now only have daily weather entity.
This is missing for me too
It did. A 3-hourly and a daily.