Since last night the API at polleninformation.at seems to have stopped working. The service just returns an 404 not found error. The website and app still work so I presume the URL, parameters or its values have changed.
Can anyone provide an updated version of the correct URL?
Update:
During research I found the integration “Pollen Information EU” (GitHub - krissen/polleninformation: Integration for homeassistant, creating sensors based on polleninformation.eu) that I wasn’t aware of until now. Initially, they had the same problem with the dead API, but the developer updated the URL parameters and it’s working again.
A valid request that I built with the help of the new source code is for example:
https://www.polleninformation.at/index.php?id=0&type=15976824&lang_code=de&lang_id=0&L=0&tx_scapp_appapi%5Baction%5D=getFullContaminationData&locationType=gps&show_polls=1,3,294,296,2,298,297,5,7&C=1&personal_contamination=false&sensitivity=0&country=AT&sessionid=&pasyfo=0&value%5Blatitude%5D=46.628&value%5Blongitude%5D=14.309
As you can see the returned JSON structure changed. I’m quite happy with the integration mentioned above, so I think I will stick with it and not bother adjusting the sensors in this thread.
Edit: The URL mentioned above currently does not return anything anymore on my end. Either there is some rate-limiting in place or something else is broken again.
Hi Guys!
The github project looks cool but I face problems to get all allergens with this one. Anyhow - I recognized that not only the URL changed but also it’s important to have the “User-agent” in the header available otherwise it’ll return an 403 access-denied.
I’m working on it too - hold on guys 
I checked the code on the github - the reason why you’re not getting “all” of the allergens is that the developer has put constant allergen ids into the code. Simply removing the option just pull all of them again. I’ll create a request to change that.
Cheers
edit: PULL-Request
Hi!
I’m one of the developers of the polleninformation.at platform. I’m very sorry, but for various reasons, we had to close public access to the API. As you probably know, the interface is actually intended for internal use only—it was never intended for public use. Since the API is now used by many external applications, these additional calls create an enormous load on the server. Furthermore, this data represents the main business model of the Austrian Pollen Information Service.
Here’s the suggestion: We offer an official, public API on a fair-use basis that delivers the most important forecast data while placing as little load on the web server as possible. The Austrian Pollen Information Service (www.polleninformation.at) must be specifically cited as the data source in every application.
In return, the currently used API (https://www.polleninformation.at/index.php?id=0&type=15976824 or https://www.polleninformation.at/index.php?eID=appinterface) may no longer be used.
What do you think?
Hey Christian! 
A very warm welcome to the community! Your suggestion sounds absolutely reasonable and well thought out. The idea of having an API interface that can be used directly while also reducing the load on your web servers is fantastic! 
I can only speak for myself, but I think this sounds absolutely brilliant! 
cheers mate
I’m glad to hear that! Please give me some more time (probably Monday) to finalize the API and to clarify everything with our customer, the Austrian Pollen Information Service.
To be honest: Nobody wants to play an endless game of cat and mouse like we’ve had for the past two days =)
Awesome, thank you so much, guys, for putting effort into this! In the past few months I’ve come to appreciate to have an overview about the current pollen situation on my dashboard and I’m glad, a solution that everybody is content with is on the way.
I’m looking forward to a public API and was a bit surprised to learn that the Österreichischer Polleninformationsdienst is an association somehow linked to AZ Pollen Research GmbH, a privately held company. I had assumed this service was run by Geosphere Austria or a public authority.
As for the implementation:
Instead of showing 13 “unavailable” messages in the stack card, it would be great if all mushroom-template-cards were hidden and replaced with a single notice that the API is currently down.
Also — and this might just be personal preference — I’d rather have numeric states (e.g. 0 to 3) instead of text labels. I always mix up “gering” and “mäßig” and have trouble remembering which one is stronger, so the text version doesn’t give me much usable information. With numeric states and state_class: measurement, it would also be possible to show a proper graph in the history, which I’d find more helpful.
Thanks again to all the people contributing!
Thank you! 
Pre-release v0.3.1-beta1 includes the merged PR.
… Now I need to update the card, so that it gets the new entity names. It was on the todo -list, to allow different locales. Had hardcoded it the previous way to make it easier for the card, but this will be better long-term.
EDIT:
I’ve reverted the locale-commit, and applied it in a separate branch (localised-sensors), as well as opened an issue (#6) for tracking development towards having localised sensors. This enables me to push a release with your other changes (generalised fetching of allergen-information) whilst keeping the integration compatible with the card. Once the feature of localising sensors has been fleshed out more, supporting not only de and en, but also other supported languages, it will be merged into master. Of course, v0.3.1-beta1 will remain available as a downloadable release with both the localisation commit and the generalised fetch -commits applied. I’ll shortly release v0.3.1 which will not have the localisation commit applied, only the fetching related ones — thank you for your contributions!
I’ll be sure to update the integration accordingly.
EDIT:
For what it is worth, in the integration I purposefully set rather conservative polling intervals; 8 hours. But I could set it to still less frequently; open to suggestions!
Hi everyone. Please feel free to co-develop the integration! I initially made it specifically to be used by pollenprognos-card at the request of some users of the card.
Several design choices were made with that in mind — get data into HA but access it by way of the card. Other use cases would warrant different designs.
For example, something that is on the todo-list, is to make a weather sensor for proper HA forecasts, but haven’t had reason enough to actually do it yet.
Anyway, just wanted to say 
and to welcome all interested to develop the integration further together, should you want!
EDIT:
Check out pre-release v0.4.0-beta1 with support for localisation. Autodetect HA-language and by default configure allergens localised to the same language; however, the user is offered options to override, and manually set another language.
The sensor entity names are still generated in English, making sure that entity names are the same regardless of localisation. This means that despite localisation, the integration maintains compatibility with pollenprognos-card as-is.
Hi Guys,
The new, official polleninformation.at API is now ready!
German: https://www.polleninformation.at/datenschnittstelle
English: https://www.polleninformation.at/en/data-interface
I would like to ask you all to use only this new API in future. I have tried to keep the changes to a minimum so that you don’t have to redevelop everything.
I hope that this is now a good solution for everyone.
Pre-release v0.4.0-beta2 of the integration is out, using the new API.
Haven’t quite tested it well enough to feel confident in releasing just right now, but will late Tuesday or early Wednesday! If you have the time, please do test and let me know if there are issues.
(Still have to update the README as well.)
Oh, as far as I could tell, some air quality indicators have been removed, compared to the previous endpoint(s). This is the server response when fetching data for Vienna:
{'contamination': [{'poll_id': 23, 'poll_title': 'fungal spores (Alternaria)', 'contamination_1': 3, 'contamination_2': 3, 'contamination_3': 2, 'contamination_4': 2}, {'poll_id': 5, 'poll_title': 'grasses (Poaceae)', 'contamination_1': 2, 'contamination_2': 2, 'contamination_3': 1, 'contamination_4': 1}, {'poll_id': 17, 'poll_title': 'cypress family (Cupressaceae)', 'contamination_1': 1, 'contamination_2': 1, 'contamination_3': 1, 'contamination_4': 1}, {'poll_id': 15, 'poll_title': 'nettle family (Urticaceae)', 'contamination_1': 1, 'contamination_2': 1, 'contamination_3': 1, 'contamination_4': 1}, {'poll_id': 7, 'poll_title': 'mugwort (Artemisia)', 'contamination_1': 1, 'contamination_2': 1, 'contamination_3': 1, 'contamination_4': 1}, {'poll_id': 1, 'poll_title': 'alder (Alnus)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}, {'poll_id': 3, 'poll_title': 'hazel (Corylus)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}, {'poll_id': 2, 'poll_title': 'birch (Betula)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}, {'poll_id': 16, 'poll_title': 'plane tree (Platanus)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}, {'poll_id': 291, 'poll_title': 'rye (Secale)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}, {'poll_id': 18, 'poll_title': 'olive (Olea)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}, {'poll_id': 6, 'poll_title': 'ragweed (Ambrosia)', 'contamination_1': 0, 'contamination_2': 0, 'contamination_3': 0, 'contamination_4': 0}], 'allergyrisk': {'allergyrisk_1': 8, 'allergyrisk_2': 8, 'allergyrisk_3': 5, 'allergyrisk_4': 5}, 'allergyrisk_hourly': {'allergyrisk_hourly_1': [5, 5, 5, 5, 5, 5, 7, 8, 8, 7, 6, 5, 5, 4, 5, 5, 5, 4, 3, 3, 3, 3, 3, 3], 'allergyrisk_hourly_2': [4, 4, 4, 4, 4, 4, 5, 6, 6, 7, 7, 7, 8, 7, 7, 7, 8, 7, 7, 6, 6, 6, 6, 6], 'allergyrisk_hourly_3': [2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 1, 4, 5, 5, 5, 4, 4, 4, 3, 2, 2, 1], 'allergyrisk_hourly_4': [2, 2, 2, 1, 1, 2, 3, 4, 5, 5, 4, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 2]}}
If I’m not mistaken, and some indicators aren’t available, all things considered, I think it’s quite generous that the most essential forecast data is being made publicly available—especially given that this is a core part of the Austrian Pollen Information Service’s business model. It’s understandable that not every detail or data point can be shared freely, both for technical and commercial reasons.
Thank you for the endpoint @_GC !
And everyone else, if you’re interested and have the time, do test and let me know what your results are, before a proper release late Tuesday or early Wednesday!
EDIT: This is a breaking change. If you had an earlier version of the integration installed, you need to remove those config entries* and re-add them, having updated.
* It doesn’t matter if you update first, or remove existing config entries prior to updating; but the ones configured with older versions of the integration won’t work with >=0.4.0-beta2; you have to configure new ones. With an API-key.
Great - thank you!
And you’re right - some data has been removed for performance and commercial reasons.
Maybe there will be a paid subscription in the future for additional data, but for now this is all we can offer.
New pre-release out, v0.4.0-beta3. I think this might be a keeper.
If anyone has time, do test! I’ll make it run through some hoops myself tomorrow (Wednesday) and release v0.4.0 during the day.