Is it? I get the feeling, that DWD weather stations are a little rare. In my case it is more than 20km away, and has a different elevation (around 150m lower). So the weather data is not very accurate. Other weather providers like accu_weather or dark_sky are calculating the weather data, so it seems more accurate.
Nonetheless, it is great to see a DWD weather component! If they bring up a weather station near my town, I’ll use it for sure.
Thanks @VDRainer, powered up the Laptop to investigate the matter and the numbers were there… Checked the mobile app again and no precipitation. Just cleared cache and it started working.
@paddy0174 Bad for you 
The station here is just around the corner - I didnt know that until 2 days ago. In my hass time I had yr, darksky, openweather, met and never was happy with any of those.
@DonTomato Don’t underestimate my nagging towards the DWD. 
I’m living in the area south of Munich, with a lot of tourist spots. I very much see the need for a DWD weather station around here, all the tourists need to know the temperature.
If the DWD doesn’t know it yet, they will soon! 
I tried a few weather providers as well, the best I could find for now is AccuWeather. They seem to be pretty good in calculating, but if a DWD station is set up near my home, I’ll def use this component. If not for anything else, than just for the great idea to use OpenData and get back at all the weather guys, who want a buckload of money for anything and trying to block DWD. Love it!
Hello @FL550,
thanks for adding all available information as sensor values.
Unfortunately, these look a bit strange to me at the moment.
With the temperature sensor of my closest DWD station, I only get an “Ok” as state and the actual temperature values are in the attribute values:
But shouldn’t it look more like the Darksky temperature sensor, for example? So with the current temperature as state and only additional information in the attribute values:
Hello @CM000n,
no, this is intended as these values should provide especially the data for every hour, in case someone need this.
For normal usage all sensor values are included in the weather entity (see under “Developer settings”). If you really need the specific value as a sensor, have a look at HAs template sensors. With a template sensor you can extract exactly the data you need as a single sensor.
Thanks for clarification
you beautiful person! thanks a lot for making this integration. after darksky decided to shut down dwd was my great hope as the next station is only about 5km away.
So thanks a lot!
@FL550: maybe i still may need some coffee this morning, but can’t find any integration as stated on the GitHub site:
In the HA UI go to "Configuration" -> "Integrations" click "+" and search for "Deutscher Wetterdienst".
Do i need to add some repository or similar or what i am missing?
P.S.: thanks a lot for making this integration!
/ Ralf
You need to install it via HACS first.
Hello,
thanks, that was the needed hint for me.
@FL550: maybe a small change in your github would help others who struggle like me:
Nevertheless, again thanks a lot for this integration whioch allows me to get accurate weather data forecast for my region and replace DarkSky finally.
/ Ralf
Thanks for the hint, I will include this for clarification!
Thanks for the integration, I installed via HACS and it works fine for me!
temperature: 30
humidity: 36
pressure: 1019.1
wind_bearing: 224
wind_speed: 9.3
visibility: 42.9
attribution: Data provided by Deutscher Wetterdienst (DWD)
forecast:
- datetime: '2020-09-15'
condition: sunny
temperature: 30.3
templow: 17
precipitation: 0
precipitation_probability: 2
I have some troubles finding the right code for a template sensor to read the probabilty and precipitation from the foreast and can find any documentation for HAss to read from a nested sensor with a dynamic date as the identifier to match. Can someone point me in the right direction? Thanks!
Sorry for the late reply. You can access the values with this template
{{state_attr('weather.dwd_weather_bad_nauheim', 'forecast')[0]['temperature']}}
The number is the index of the array, so 0 is today, 1 is tomorrow and so forth. Hope this helps!
I already got this feedback in a different thread regarding templating - nevertheless many thanks for your reply!
great component … I’ve also added a rain preview map to my config which is rather simple
sensor:
- platform: mqtt
state_topic: "weather_reload_trigger"
name: "weather_reload_trigger"
camera:
- platform: generic
still_image_url: https://www.dwd.de/DWD/wetter/radar/radfilm_brd_akt.gif?{{states('sensor.weather_reload_trigger')}}
name: cam_weather1
limit_refetch_to_url_change: true
- platform: generic
still_image_url: https://www.dwd.de/DWD/wetter/radar/radfilm_nib_akt.gif?{{states('sensor.weather_reload_trigger')}}
name: cam_weather2
limit_refetch_to_url_change: true
I change the status of the weather_reload_trigger once per hour or so (with a simple appdaemon script) to get an updated map that shows the rain radar animation
JKW
PS: does anyone see a way to graph the forecast data ?
Good idea! Why are you using the camera platform instead of just integrating the .gif into Lovelace as a Picture entity so it gets reloaded every time you open the dashbaord?
honestly … no idea … maybe to reduce traffic because the gif is quite big ?
no idea 
Fair Point 5-6 MB for every call is quite something. Then again, the load is on the client and the network, but not HA - so I take it…
Unfortunately, I have no idea how to graph this data, but I can give a direction to look for:
You would need to combine the forecast sensors, some templating and a way to show all in a graph. Hope this helps!
My hope was that I could reuse that feature in a clean way for this:
It works as is with a highly modified version of mini-graph … I guess one could also create a version that works with your data …