Yes i got the tip from you before to use gps location, that way i could use “Schiphol” which does have precipitation forecasts (the one closest to me does not) i’ll try and remove the gps coordinates and see what it does.
@mjj4791: i started from scratch, just to be sure and i actually copy pasted the example from https://home-assistant.io/components/sensor.buienradar/ which fails with config errors. When i look at the explanation text above it, some items are explained in the monitored section as “windspeed” but in the example you type it out as “wind_speed” so which one is correct? That might confuse people (at least it does with me, since the config says its broken now)
My bad!
I had the same issue earlier today and made a PR with some corrections.
See: https://github.com/home-assistant/home-assistant.github.io/pull/3036
Only I forgot to change the explanation text…
The correct naming convention should be as below (like the examples, which are now correct and working for me).
monitored_conditions:
- stationname
- symbol
- humidity
- temperature
- ground_temperature
- wind_speed
- wind_force
- wind_direction
- wind_direction_azimuth
- pressure
- visibility
- windgust
- precipitation
- irradiance
- precipitation_forecast_average
- precipitation_forecast_total
/edit
To correct the text in the description as well, I have made PR #3040.
@IoTmessenger @riemers
OK; I see where the confusion comes from… examples were indeed wrong in the docu
However the proposed changes above for the docu are incorrect as well…
The correct names should be as shown here: https://github.com/home-assistant/home-assistant/blob/master/homeassistant/components/sensor/buienradar.py#L38
so:
- no: ‘wind_speed’, but ‘windspeed’
- no: ‘wind_force’, but ‘windforce’
- no ‘wind_direction’, but ‘winddirection’
- no ‘wind_direction_azimuth’, but ‘windazimuth’
- no ‘ground_temperature’, but ‘groundtemperature’
I have it running at the moment (HA 0.49.0) with an unmodified buienradar code, with this config:
and all values are updating…:
i have the exact same monitored conditions now (next time, paste it as text, is easier copying) 
And i get this:
I am missing a few… i did change my gps coordinates to Schiphol, which i am sure has all the right readings…
There is some strange behavior then, as the sensors created have a different naming convention than the monitored conditions would suggest.
I was missing those sensors and started investigating.
monitored_conditions:
- stationname
- symbol
- humidity
- temperature
- groundtemperature
- windspeed
- windforce
- winddirection
- windazimuth
- pressure
- visibility
- windgust
- precipitation
- irradiance
- precipitation_forecast_average
- precipitation_forecast_total
Gave these sensors:
entities:
- sensor.br_stationname
- sensor.br_symbol
- sensor.br_temperature
- sensor.br_ground_temperature
- sensor.br_humidity
- sensor.br_pressure
- sensor.br_wind_speed
- sensor.br_wind_gust
- sensor.br_wind_force
- sensor.br_wind_direction
- sensor.br_wind_direction_azimuth
- sensor.br_precipitation
- sensor.br_precipitation_forecast_average
- sensor.br_precipitation_forecast_total
- sensor.br_visibility
- sensor.br_irradiance
I did close my last PR #3040 and will request to withdraw the #3036 PR.
My apologies for causing the confusion, I thought I was ‘helping’ the community.
Strangely, with those settings, I do have a working buienradar…
/edit:
I have requested to revert the #3036 PR (new PR: #3042).
Which coordinates have you set
- in HA config
- in the buienradar sensor
I will try to see if I get the same behavior as you see; maybe something is off…
@IoTmessenger @riemers
No problem; you were helping indeed! I now see where your confusion came from…
to explain:
If you enable, for example, the monitored condition ‘windforce’, as you did in your example, a new sensor will be added to HA which will get the name ‘sensor.br_wind_force’; this is, because I use the displayname of the monitored condition to build the sensor’s name (‘Wind Force’ in your screenshot, thus resulting in a name of ‘br Wind Force’).
HA is replacing the spaces in this name and setting it to lower case, thus resulting in the sensors name of ‘sensor.br_wind_force’. If you have set a name of your sensor, you could end up with a sensor name of ‘sensor.thuis_wind_force’ or ‘sensor.weather_wind_force’…
I now see this is confusing, and also not in line with the documentation… (it states ‘sensor.br_[monitored_condition]’)
I will fix the docu to match the current situation, so the examples actually work…
1 Like
Thanks for the explanation, I do understand now how the sensors are created.
I think I have added all sensors in the configuration of the card, before checking the names of the created sensors after a reboot.
You know what they say about assumptions.
Something else, I did not specify my long/lat in the config of the sensor so it uses the ones already defined in HASS config.
That results in a station quite far from me. On the buienradar website you can choose your location by naming the city; is there by any chance an option to accomplish the same in the sensor config?
Or does that still use the same (perhaps nearest) station?
The sensor selects the weather station closest to you by default; this is using the coordinates specified in the sensor itself or the coordinates in hass, if you did not add them to the sensor (you don’t have to).
For this, it calculates the distance between your coordinates and the coordinates of the weather station. Since via the buienradar xml api only data from 49 weather stations are available for the whole country, it might be some distance away from you actual location.
If you want to force the sensor to select a different station, you can add coordinates to the sensor’s config, which are different from your real/actual location. In my case ‘Voorschoten’ is closest, but ‘Lopik’ is more reliable/accurate for my location, probably due to the influence of the sea on the temperature…
1 Like
just added more clarification on the ‘name’, ‘monitored_condition’ and resulting ‘entity id’ to the documentation of the sensor: https://github.com/home-assistant/home-assistant.github.io/pull/3044
1 Like
For me it also came up with Voorschoten station, but that is way too inland for me. I will play with some locations by manually adding their long/lat to the sensor.
Thanks!
And in my case, the missing sensors… i was looking at my “group” which didn’t have those sensors in.
I see the changed document, it tells about the spaces. I would suggest just adding something like this text after the monitored_conditions (because you have it now in the name section, which might be confusing too)
— snip —
Please note that for any given condition you can find a similar “sensor.br_” with the exception of the following items (because they have spaces from grabbing the information)
sensor.br_wind_gust
sensor.br_wind_direction
sensor.br_wind_force
sensor.br_ground_temperature
sensor.br_wind_speed
sensor.br_wind_direction_azimuth
Just a thought, i don’t know if possible. Would it not be easier to just name the conditions the same as the sensors?
I thought about that as well; I now updated the documentation to reflect the current way it works; so the docs reflect the current working.
What I could do, is to update the code of the sensor to name the sensors/entity id’s using the monitored_condition name and not the display name; in that case, the name of the sensor (the entity id) will be easily linked to the configured monitored_condition (and thus prevent the confusion about the condition/sensor names).
@riemers @IoTmessenger: Does that make sense to you as well?
In that case we would get sensors called:
- sensor.br_groundtemperature for the condition groundtemperature (and not sensor.br_ground_temperature)
- sensor.thuis_windforce for condition windforce (and not sensor.thuis_wind_force)
- sensor.weather_windspeed for condition windspeed (and not sensor.weather_wind_speed)
- etc.
Please note that, if we go this way, the names/entity-id’s of the sensors will change when this update gets approved committed into homeassistant…
Let me know what you think about this change…
I don’t mind anymore since i know it, but i would say its a big plus to approve the new changes you just said for people just starting to use it. Also don’t mind changing my entities if it will make life easier for future home assistant users with buienradar. Your doing great work and one of the things that grabs new users is that they can install new components without too much hassle.
Weather forecast is doing just fine 
p.s. what is the best timeframe? default was 60, i thought 30 would get quicker response, but that might be different?
@mjj4791 @riemers
Breaking changes with the next update will get a lot of current users ‘in trouble’ and should be avoided.
You could also clearly list the names of the monitored conditions and the resulting sensor names in complete examples of the configuration? Using the lists I posted above..
That way, someone starting to use this platform can easily copy/paste the example config (and just delete unwanted conditions/sensors).
Nothing wrong with a breaking change, as long as it is a good improvement. But like i said, i don’t mind but i do think it is better for new users. Even with a complete example, if items have different names it will still look strange to people that examine it.
Just like when they changed “After” to “At”, breaking change, but in the end it was a logical change. That is just my 2 cents. Fine with any choice @mjj4791 makes.
@mjj4791
I would like some adjustments on the Buienradar weather component;
Get the state to be more standardized, other platforms use:
'cloudy'
'fog'
'hail'
'lightning'
'lightning-rainy'
'partlycloudy'
'pouring'
'rainy'
'snowy'
'snowy-rainy'
'sunny'
'windy'
'windy-variant'
'exceptional'
You are using the description from Buienradar, we could map the status code (a double status code means night: aa) from buienrader to these (or more):
'a': 'clear', Vrijwel onbewolkt (zonnig/helder)
'j': 'partly-cloudy', Mix van opklaringen en hoge bewolking
'b': 'mostly-cloudy', Mix van opklaringen en middelbare of lage bewolking
'c': 'cloudy', Zwaar bewolkt
'd': 'fog-cloudy', Afwisselend bewolkt met lokaal mist(banken)
'f': 'partly-cloudy-drizzle', Afwisselend bewolkt met (mogelijk) wat lichte regen
'g': 'partly-cloudy-thunder', Opklaringen en kans op enkele pittige (onweers)buien
's': 'thunder', Bewolkt en kans op enkele pittige (onweers)buien
't': 'heavy-snow', Zware sneeuwval
'm': 'drizzle', Zwaar bewolkt met wat lichte regen
'n': 'foggy', Opklaring en lokaal nevel of mist
'g': 'pouring', Zwaar bewolkt en regen
'u': 'partly-cloudy-snow', Afwisselend bewolkt met lichte sneeuwval
'v': 'light-snow', Zwaar bewolkt met lichte sneeuwval
'w': 'snow-sleet', Zwaar bewolkt met regen en winterse neerslag
'sunny': ['a'],
'partly-cloudy': ['j'],
'mostly-cloudy': ['b'],
'cloudy': ['c'],
'fog-cloudy': ['d'],
'fog': ['n'],
'drizzle': ['m'],
'rainy': ['g'],
'lightning-rainy': [],
'lightning': ['s'],
'hail': [],
'snowy': ['v', 'u'],
'heavy-snowy': ['t'],
'snowy-rainy': ['w'],
'windy': [],
'windy-variant': [],
'exceptional': [],
This would allow easier automation and the symbols for the new front end weather panel (or my customized one).
We could still keep the description we have now, but in a different property. We could then also add it to the forecast.
Secondly, could we add a second forecast array: percipation_forecast. This would give an array of the text document you are getting from buienradar with a DateTime. This would allow rendering it better in the front end and allows for more precise automation with templates.
What do you think about these additions? I think it wouldn’t be to much work to add, I could look into it if you like it.
Bram
Interestingly, I just happened to look into this last week; I think these are 2 useful additions to do…
Do you know where to find the dutch meanings of all weather codes, that would make mapping a lot easier?
You found many more than I did last week…
I still miss the meaning of some icons (do you know where to find their meaning):
