Ah well that explains it then. If HACS isn’t working then the ‘endpoint’ folder /hacsfiles doesn’t exist… and then lovelace can’t find the card which is in /hacsfiles/bom-weather-card… hence the error. I wonder if this is @autumnleaf and @alex.hart645 problem as well? There seems to be a few people with weird issues lately…
I found the hacs folder and all looks fine, and it is loading into the sidebar okay. In saying that, I cannot update custom header, so there could be an error somewhere. If I continually press F5 with hard resets within console the card does display but just for a undefined period of time. So weird!
Definitely. If it displays then that indicates it is configured correctly. Do entities disappear at all? that could cause the card to disappear. Do any other custom cards do anything weird at all? Custom Header is now deprecated so maybe that is why that won’t update as the repo is also archived. have too many other ideas.
You could move the bom directory into www and then edit the resources to point to that instead which will eliminate any hacs issue… I could also remote into your system (teamviewer) and have a poke around to check everything if you would like me to…
Apologies if this has been covered before, 559 posts on this topic, but I did use search and couldn’t find what I needed. I keeps getting the following in my logs;
Maybe not the right channel, please let me know. I keep getting the following in my logs for some filter sensors I’ve set up
2020-10-20 05:52:17 WARNING (MainThread) [homeassistant.components.template.sensor] The 'entity_id' option is deprecated, please remove it from your configuration
The issue is from the template sensors in my BOm package. Anyone know is ‘entity_id’ has been replaced or do I just get rid of it all?
I believe it was removed in 0.115.0. You can just remove it. Template sensors no longer need to be told which entities to track… they can work that out themselves. The docs for the card and sample templates have been updated to reflect this.
So if it’s not one thing, it’s another. The Core BOM integration is now removed in Home Assistant because it uses web scraping.
For now, I’m going to make it a custom component and I’ll put it in HACS as well but probably not make it a default repo. I think part of the ‘objections’ apart from it violating ADR-14 is that it’s the radar component that is causing the issue. Not sure why the observations also include the radar but there you have it and we have @theRat for radar now anyway.
I am just going to do some testing that I haven’t broken anything… then I will give you the repo to add to HACS etc…
Add this custom repo in hacs with this URL
https://github.com/DavidFW1960/bom_core_replacement
I’ve been running dev or 0.117 for a while and saw the card wasn’t working again but at least this is a simpler fix this time…
1 Like
The BOM core component is being removed in 0.117 due to the use of web scraping. In the spirit of Hacktoberfest I am going to work on rebuilding the BoM integration without the use of web scraping with the short term goal of having it released on HACS and then long term hopefully home assistant core.
3 Likes
That is awesome Brendan… I thought eventually someone would do that. Excellent.
FYI: working well for me.
1 Like
Are you aware that there is a new way to get weather data from the BoM that returns data as JSON? For example to get the observations from the closest weather station to a location use:
https://api.weather.bom.gov.au/v1/locations/r3dnb6/observations
The weird number is a geohash of Lat/Lon. This website will calculate it for you. Make sure to set the precision to 6.
Unfortunately the observations don’t include any air pressure data. 
There are other endpoints for warnings, daily forecast, 3 hourly forecast. To see all there have a look at
Unfortunately you still have to poll regularly for the data as the BoM still hasn’t caught up with modern technology. I am not sure if this is still considered web-scarping or not, but it is more efficient that what is currently being done.
1 Like
I suggested that to Brendan on his Repo yesterday… I think we chatted about this recently didn’t we?
Regarding AirPressure I think it does publish them for SOME stations but not all.
I think it got mentioned in some emails.
The Air Pressure data is not included in the this json data. They normally only have it for stations based at airports. But I just double checked the data provided for Canberra Airport (station 070351) and it is not included.
I just checked Sydney too and you’re right. Brendan said he’s going to use FTP anyway.
The JSON API seems pretty awesome, and it’s much better to only download the data for your specific station rather than a 300kB file each time. I’m just hesitant because it’s an undocumented API, which could change without consultation or warning. I’m leaning towards using this API for ease of use.
I doubt the json will change any time soon. It was implemented for the new version of the BoM mobile app. I have checked it uses the same thing as I rooted my phone and mitm decoded the https. But it does lack pressure info.
I will keep using my mqtt version of the sensors most likely anyway for observations. I have been tempted to ask the BoM why they don’t publish data on mqtt so that everyone wasn’t constantly polling. The desktop and mobilie versions of the new website download warning data every minute and everything else ever 5 minutes. For data that doesn’t change that often this is crazy.
2 Likes
Another thing to consider is the difference between observations and forecasts.
Forecasts exist for every location in Australia by coordinates. They are generated by a super computer running multiple models. So you can get a forecast for your suburb which will differ from that of the nearest observations station.
Observations are only available for fixed locations where the BoM has hardware to measure. Interestingly not all of these are in the ftp data. For example there is a weather station at Mangrove Mountain (id: 061375) that is not included in the ftp data.
2 Likes
the current BOM integration actually uses the JSON content for some of the calls:
def _build_url(self):
"""Build the URL for the requests."""
url = (
f"http://www.bom.gov.au/fwo/{self._zone_id}"
f"/{self._zone_id}.{self._wmo_id}.json"
and ftp:
def _get_bom_stations():
"""Return {CONF_STATION: (lat, lon)} for all stations, for auto-config.
This function does several MB of internet requests, so please use the
caching version to minimize latency and hit-count.
"""
latlon = {}
with io.BytesIO() as file_obj:
with ftplib.FTP("ftp.bom.gov.au") as ftp:
ftp.login()
ftp.cwd("anon2/home/ncc/metadata/sitelists")
ftp.retrbinary("RETR stations.zip", file_obj.write)
and scraping:
for state in ("nsw", "vic", "qld", "wa", "tas", "nt"):
url = f"http://www.bom.gov.au/{state}/observations/{state}all.shtml"
for zone_id, wmo_id in re.findall(pattern, requests.get(url).text):
zones[wmo_id] = zone_id
Hey all, I have created a custom component which pulls data from the new API, work in progress but I would love for you guys to test it. Works for me so far 
2 Likes
Well I didn’t see that coming… lol… this won’t co-exist with the current BOM Sensor at all… But otherwise working ok.
You know you could add the forecast information as well and that would then mean we don’t need the old FTP component either… That would be really cool as the old FTP component doesn’t support a lot of places but the new API does and it would also mean a lot of the issues people have with the card would go away as well…
I assume the dewpt and delta_t are not available? (I didn’t check) Otherwise same info as old core component.
Love this anyway…
Need to make some edits to my package and entities passing to the card…
Yes, I used the integration name “bom” which will overwrite the existing one, which is being removed anyway, but I guess that makes it hard to test.
I am planning to expand it to include all information offered by the new API, seems like it even does radar.
So far I haven’t seen dewpt and delta_t on the new API, not sure who would use these anyway.
1 Like