Some weeks ago I already created a custom component for DWD pollen information. You might want to check it out at https://github.com/marcschumacher/dwd_pollen. Let me know if you like it and feel free to open issues!
[jackeroo_marc] I tried your platform. It works great. Had the fear that it would not work without the requirements under Hass.io in Docker. Fortunately, that’s not the case. Great!
As far as I can see in your sensor.py there will just be the values from 0-6 as return? Currently I’m using a template sensor in addition to the REST sensor to give me a readable output instead of the dwd index:
- platform: template
scan_interval: 1800
sensors:
pollen_92_graeser_today:
friendly_name: 'Gräser'
value_template: >
{% if (states('sensor.pollen_92_graeser')|regex_findall_index("'today': '[-0-9]+'")|regex_findall_index("[-0-9]+") == "0-1") %} Keine bis geringe Belastung
{% elif (states('sensor.pollen_92_graeser')|regex_findall_index("'today': '[-0-9]+'")|regex_findall_index("[-0-9]+") == "1") %} Geringe Belastung
{% elif (states('sensor.pollen_92_graeser')|regex_findall_index("'today': '[-0-9]+'")|regex_findall_index("[-0-9]+") == "1-2") %} Geringe bis mittlere Belastung
{% elif (states('sensor.pollen_92_graeser')|regex_findall_index("'today': '[-0-9]+'")|regex_findall_index("[-0-9]+") == "2") %} Mittlere Belastung
{% elif (states('sensor.pollen_92_graeser')|regex_findall_index("'today': '[-0-9]+'")|regex_findall_index("[-0-9]+") == "2-3") %} Mittlere bis hohe Belastung
{% elif (states('sensor.pollen_92_graeser')|regex_findall_index("'today': '[-0-9]+'")|regex_findall_index("[-0-9]+") == "3") %} Hohe Belastung
{% else %} Keine Belastung {% endif %}
But maybe I can also get this now in manipulation the sensor.py. I will see Else I will do it the same way as with the REST sensor.
Edit: RTFM to myself I saw in the documentation that there will be this readable format in the description attribute. This will help.
This is awesome. Exactly what i was looking for. However, where did you select the region? I’m trying to find where you put that but i cant find it… Unless im blind
When you go on the opendata link, you got a JSON String. I used the content number for the different region, not like the other variant of this sensor here in this thread, which is using the partregion_id into the content path.
I extract from JSON String, for my region, into a sensor attribute for a template sensor. Like above.
As an example for my region “Westl. Niedersachsen/Bremen” it is the content number “3”:
It may work for some time, but it will fail over time. The data is sorted by the number you choose, but the content may change, if other data will get available.
Right now you have 26 or 27 “content numbers”, if more info from other or new weather stations comes available, they will be added to this file, so the numbering will change.
Tbh I don’t see any advantage at all to simply use a number over an id, that is unique and therefore lasting much longer. And you already got where you needed to be to find out the correct partregion_id.
I am using this, to extract the pollution for my region into the attributes of my dwd_pollen REST-Sensor. And with this sensor I go into a template for the state and icon for each pollen typ.
The problem is, what you described, is when the content number change. So I need a way to extract the JSON Path for my region with region_id and not with the content number. It would be nice, when the pollen path is into the sensor attributes of my dwd_pollen sensor. Like now
I tried to extract this over the region_id, but my knowledge about JSON isn’t that big
What I still don’t get, 2nd screenshot.
If I blow this into a new yaml sitting in a sensors directory (using sensor: !include_dir_list sensors/)
why the heck does it moan about:
a) 2 lines in a yaml starting " platform: rest" <== editor moans about that one
b) having a line " platform: rest" and somewhere later " platform template" <== editor moans aswell
HA is something a real lottery, especially if being new with it collection interesting stuff from within this community. Since even if things are marked “solved” this doesn’t mean it’ll work at all.
The worst one was the one mention at pt. a) since the HA editor flagged this RED while the settings>server>check configuration validated it green. Means nice to have such checks but as long as these tend to act as a lottery either the whole configuration is sort of rolling dice.
Just besode the fact that I got everything running by now and simply want to thank for the detailed explanation incl. the one with the content number some lines below. Works like a dream.
Even though the topic is quite old, I wanted to share my slightly improved sensor since I managed to solve the issue of dealing with the array and only picking the item for the partregion_id I’m interested in (by using JSONPath) and not using an unreliable array index which can change.
You have to replace the 111 in the json_attributes_path of the first REST sensor with your partregion_id. This REST sensor then has one attribute for each pollen type. The second sensor (template type) is just an example, you have to repeat this for every pollen type, it’s sadly quite repetitive. Its value is a number between 0 and 6 (indicating the intensity today) and the attributes contain todays’ and tomorrows’ intensity. So you’re quite flexible with using it in a Lovelace card.
But as far as I can see, this doesn’t work, does it? Either you call the rest sensor “DWD Pollenbelastung” or you change the template sensors from {% set dwd_state = state_attr('sensor.dwd_pollenbelastung', 'Erle')['today'] %}
to {% set dwd_state = state_attr('sensor.dwd_pollen', 'Erle')['today'] %}
Either way great contribution!
@dyfcom
I am very sorry, I totally missed your reply and didn’t answer. Sorry for that! Fortunately @rkallensee did a great job with his snippet.
Else I will do it the same way as with the REST sensor.
I saw in the documentation that there will be this readable format in the description attribute. This will help.
I fixed my example.