Depends which certs are included in the browsers or operating systems CA cert chain.
Chrome includes the intermediate CA certs of https://www.pki.dfn.de/ueberblick-dfn-pki/ which have been used to issue the cert āwww.dwd.deā, which enabled Chrome to fully validate the cert, but Mozilla is lacking those CA certs.
I have added the two missing CA certs into my RasPis /etc/ssl/certs, now wget works, but home-assistant still doesnāt.
After adding the missing CA certs to lib/python3.5/site-packages/certifi/cacert.pem the DWD weather warnings are working!
Is it possible to do this in hassio?
I would think so, if you know how. You have to find out how to ssh to your RasPi (AFAIR port 222, instead of the hass.io-container which listens on default ssh-port 22) and find out where the files are. (in my case: /srv/homeassistant, then see above)
Or wait until the certs are updated in one of the next versions, which would be the correct solution.
where exactly did you get the two CA certs? here? https://www.pki.dfn.de/wurzelzertifikate/globalroot2/
I had the exact same thing in my head. Maybe exported the cert from the homepage?
I googled the names of the intermediate certs that I saw in the āwww.dwd.deā-cert, payed attention that what Iāve found was from DFN-websites, compared the cert-fingerprints and downloaded them:
https://www.pki.dfn.de/fileadmin/PKI/zertifikate/DFN-Verein_Certification_Authority_2.pem
http://cdp.pca.dfn.de/dfn-ca-global-g2/pub/cacert/cacert.pem
that worked. thanks!
After sending an email to dwd about the cert, i got an answer today that they made some modifications.
Everything works now as before, no need to copy the certs.
THX to DWD!
Wow, thank you for your effort
Thanks for the plugin!
Occasionally, I see some āsensor xxx is taking over 10 secondsā log entries. Thatās why I started changing the component so it uses the new WFS API instead of the JSON file. While the JSON file contains all regions, WFS allows filtering.
I looked at the data and realised that no warning level in terms of integer is provided. Nevertheless, there is a key ādwd:SEVERITYā containing a string rating.
Does any of you know how to map e.g. āModerateā to an integer value?
My current progress and an example API response (attached at the end) can be found here:
Thanks!
Hi everyone,
Iāve found a mapping between serverity and int rating and continued working on the plugin
In case anyone wants to test: Please feel free (see github)
Working fine for me until now
Feel free to create a pull request with your solution. I think it is better to use the filtered API for low power devicesā¦
I want to reopen the discussion on this topic because i lately realized that there is something wrong with the warning level of the current implementation.
For example: For my region āLandkreisā currently a āFROSTā warning is issued as level 1 (yellow) on the DWD homepage. The warning level of the HA sensor is 2 for the same region. This is not a HA sensor bug because the level 2 is issued by dwd in their json (https://www.dwd.de/DWD/warnungen/warnapp/json/warnings.json).
So i think it is time to switch to their new format like @Hummel95 did it already.
After i read this thread i did some further investigations and found out that we could improve this sensor much more because the DWD offers more and more detailed informations with their new API. With their new API not only āLandkreiseā can be queried by also āGemeindenā or āStadtteileā of bigger cities. The following file contains a list of all available so called warncells witch can be queried.
https://www.dwd.de/DE/leistungen/opendata/help/warnungen/cap_warncellids_csv.html
Cell starting with ā1ā represent āLandkreiseā. Cells starting with ā2ā represent āBinnenseenā. Cells starting with ā4ā represent āNord- und Ostseeā. Cells starting with ā5ā represent āKĆ¼steā. Cells starting with ā7ā or ā8ā represent āGemeindenā or āStadtteileā.
With the following query one can check if the warncellid is correct
https://maps.dwd.de/geoserver/dwd/ows?service=WFS&version=2.0.0&request=GetFeature&typeName={region_type}&CQL_FILTER=WARNCELLID=%27{warncellid}%27&OutputFormat=application/json
{region_type} must be the right one of the following
dwd:Warngebiete_Kreise
dwd:Warngebiete_Binnenseen
dwd:Warngebiete_See
dwd:Warngebiete_Kueste
dwd:Warngebiete_Gemeinden
{warncellid} your desired warncellid
The query to get the warnings for your cell is
https://maps.dwd.de/geoserver/dwd/ows?service=WFS&version=2.0.0&request=GetFeature&typeName={region_type}&CQL_FILTER={cql_filter_property}=%27{warncellid}%27&OutputFormat=application/json
{region_type} must be the right one of the following
dwd:Warnungen_Kreise
dwd:Warnungen_Binnenseen
dwd:Warnungen_See
dwd:Warnungen_Kueste
dwd:Warnungen_Gemeinden
{cql_filter_proerty} must be
GC_WARNCELLID for dwd:Warnungen_Kreise
WARNCELLID for all other types
{warncellid} your desired warncellid
I already started working on an improvement of Hummel95ās solution and itās working fine so far but a found one problem i want to start a discussion about. In the current sensors configuration one has to enter the regionās name to configure the sensor. This is fine for āLandkreiseā. The problem is that the regionās name is not unique for āGemeindenā e.g. āGemeinde Oberhausenā exists two times in the warncell list.
Is it therefore ok to change the required configuration from āregion_nameā to āwarncellidā in configurations.yaml?
After an update of the sensor all users would have to update their configurations.yaml to get the sensor working again. Otherwise it cannot be guaranteed that the right cell is selected.
Hi Stephan,
Thanks for working on this! I stopped running home-assistant last year but Iām planning on installing it again soon.
In my opinion changing the configuration parameter to warncellid makes sense especially since itās justified by an increased prediction accuracy.
If you havenāt checked out my pull request please do so. The HA team requested some changes in the code to comply with their rules. https://github.com/home-assistant/core/pull/23234
Thanks!
After reading the pull request i realize that there is more work to do than i initially thought.
First step: Splitting sensor and API
Check if one of the on PyPI available DWD APIs fits our needs, or if not program a new one.
After a quick check it seems that there is no DWD API on PyPI which uses there OWS service.
I think i will start trying, never did this before, to develop a dwdows
PyPI package which than can be used for the āWarnwetterā and maybe a āPollenflugā or āBiowetterā sensor.
I just finished my first version of the API, i called it dwdwfsapi
because the DWD calls its underlying service Web Feature Service (WFS).
For those who are interested:
Link to PyPI
Link to GitHub
The next days i will start with step two: embedding the API in home-assistant
Feel free to replace my current codeā¦
I know this is slightly off topic, but seen as darksky (which most people were using for forecasts) has been bought by apple is there any chance to upgrade the dwd integration to also pull weather data and forecasts?
Using the warnwetter app gives me the best forecasts for my area anyway and I would love to have that level of exactness in home assistant.
Of course this would be only interesting for us Germans but then I guess the warning levels currently supported are also of not much use for someone in Australia
Sadly I know nothing about coding and using the api but it looks like you are quite well versed in thisā¦
So maybe someone is up for the task of integrating the weather data as well! Thanks!
Try to use Yr.NO. Itās very accurate in Dus and uses the same weather forecast model like DWD.