Not sure what you are seeing here; looks like the HA code/buienradar component and the version of the buienradar library you have are incompatible (the API has changed from 0.5->0.7)
Can you try with HA 0.49.0; that will update the buienradar components and install the external library version 0.7; then all should work as intended (and no manual code chnages needed any more)
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:
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
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ā¦
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ā¦
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
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:
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):
