As of 0.107, weather alerts will no longer have a detail attribute, as I have to use web scraping to populate it. If you would still like to have this functionality, you can use the code from the previous version as a custom component:
Let me know if you have any trouble.
It is possible to reveice tomorow weather in sensor?
Could you please be more specifc (en français si c’est plus simple)? Are you looking for something like the “Forecast” sensor, but for the next day instead of the next forecast period (i.e. today / tonight)?
Est ce que je peux avoir un sensor pour la Meteo de demain?pour avoir un tts avec alexa. Le summary detail donne juste ce soir et la nuit comme exemple le soir
Je te donne l’exemple de ce matin, je trouve la météo de aujourd’hui présentement mais j’aimerais avoir pour demain
Merci
Une idée? Merci
Hi, Thanks for a useful integration. This is to report two non-critical issues.
I run the current latest version of HA 108.2 on a P4 4G on hassio (docker) on Raspbian Buster.
- Platform error weather.environment_canada - No module named 'bs4'
- Platform error camera.environment_canada - No module named 'bs4'
- Platform error sensor.environment_canada - No module named 'bs4'
Top Permitted Domains
Domain Hits
dd.weather.gc.ca 5126
pool.ntp.org 2936
api.myqdevice.com 2817
Wes
Anyone else experiencing problems with the camera component lately?
If I don’t specify a camera station, lat or long it shows me east coast and Newfoundland now (I’m in Ontario).
If I specify lat/long or station it show’s nothing.
Sorry for the radio silence. I’m working on an update of the radar component to address the bs4 issue. It’s going to leverage Environment Canada’s web map service, which will dynamically generate radar imagery for an arbitrary location. One thing I’m stuck on at the moment is finding a background map that can be used without authentication, which leads to a question:
How important is it for this component to “just work”, i.e. how much of a pain would it be for users to need to acquire an API key from a service like MapBox first?
Other integrations require that the user get an API key, so this wouldn’t set a precedent. However, the subtle difference here is the API key isn’t needed to acquire the bulk of the weather data, just for a basemap for the radar portion of it.
If someone doesn’t need or want to display the radar map, then obliging the user to acquire an API key would seem like an imposition. Ideally, the API key would be optional. If the user later attempted to use the radar map without an API key, the integration would gracefully inform them it can’t work that way (or simply show the radar data without a basemap).
I’ve submitted a pull request to switch to the new version. I’m using Mapbox with an access token for now, the usage should hopefully stay under their free tier.
https://github.com/home-assistant/core/pull/34729
This is a breaking change as the station IDs are no longer supported, only lat/lon. The advantage is that everyone gets a custom map centred on the location they want.
If I understood their free tier correctly, you get 50000 “map loads” per month.
A map load is counted every time Mapbox GL JS initializes on a webpage or in a web app.
So if the sum of all instances of this integration making “map load” requests remains under 50K/month, it’s free. I guess the question is when does the integration perform a “map load”? If it’s only when it first renders the page containing the basemap (for the Radar map) then I think there’s a lot of headroom before we reach the 50K ceiling.
On the other hand, if the basemap is refreshed every time the Radar map is updated periodically (conjecture; I don’t know if that even happens) then it may chew through the 50K allotment faster than expected. I guess you’ll know soon enough. 
Worst case, you may need to allow users to supply their own key/token.
It only pulls the base map when the component is loaded, so basically when Home Assistant starts or restarts. I’m still working to use a map from Natural Resources, but this should hopefully work for a while.
Oh! In that case, 50K is effectively “infinity”.
michel: do you look for my demand?
I don’t think the sensor.chance_of_precip has ever worked and always showed “Unknown”. Is this expected?
No, it’s expected to work. Mine is currently working for Ottawa, but maybe this value isn’t populated for the station you’re using?
It seems that I need to do some fairly substantial rework to how my integrations get configured in order to get this PR merged. Frankly, I don’t know how long that’s going to take as it seems a bit involved.
In the meantime, I would suggest loading the files from the PR branch as a custom component:
Hi, I just started using this. Thanks for the effort you put in.
From a cleanliness perspective, is it possible to remove the default location from the list of sensors? For example, my nearest station doesn’t have previous days precipitation which is the main reason I wanted to use this so I simply added the next closest station using
- platform: environment_canada
station: AB/s0000510
But when I look at my sensors in Developer Tools - States I have
sensor.precipitation_yesterday
sensor.precipitation_yesterday_2
sensor.precipitation_yesterday is the default nearest station and is greyed out but I can still see the value. I have duplicate values for every sensor even though I’ll never use the default one.
Thanks
I believe that this is a result of the entity database retaining an entry for every entity that it’s ever seen. If you go into Configuration --> Entities, you should be able to remove the ones that you don’t want.
Let me know if that works or if you have any trouble.