Python plugin: Domoticz Pollen Forecast

[pfloryann]

A lightweight multilingual Domoticz plugin for monitoring airborne pollen levels in Europe.
It can be useful for people who are allergic to pollen. It allows users to view pollen levels for today as well as tomorrow for allergenic pollen types.

The plugin provides pollen alerts for today and tomorrow, together with detailed pollen information for each supported pollen type.

Features:
No API key required
No external Python dependencies
Configurable latitude and longitude
Configurable update interval
Separate pollen forecast for today and tomorrow
Domoticz Alert sensors suitable for automations and notifications
Detailed pollen information using Text sensors


https://github.com/blooesky/Domoticz-Pollen-Forecast/

[pfloryann]

v.1.1.0 Supported languages

English
Română
Deutsch
Français
Italiano
Español
Português
Nederlands
Polski

The selected language controls device names when devices are first created, pollen names, alert texts and detailed Text sensor values.

[JayDotR]

v.1.1.0 Supported languages

English
Română
Deutsch
Français
Italiano
Español
Português
Nederlands
Polski

The selected language controls device names when devices are first created, pollen names, alert texts and detailed Text sensor values.

Hi pfloryann,

A good data source where I was long time looking for. As you perhaps saw, i forked your repo and made some reflections about making it easier to integrate in automations. If you want, feel free to check mine https://github.com/janreimen/Domoticz-Pollen-Forecast. If it's OK for you, I will try to adjust your changes back into the fork, and we could merge back the fork to your repo.

Greetings,

Jan

[pfloryann]

Hi JayDotR,
I'm glad the plugin is proving useful, and thanks for your interest.
The idea you implemented in the fork is great for automation, but it requires a large number of sensors (12); I tried to simplify the plugin to the essentials: one general alert sensor each for today and tomorrow, and one sensor providing details for each of those days.
The logic was that if a user receives a high pollen level alert, they can check the text sensor to see which specific allergen is at a high level. Airborne pollen usually comes from multiple plants, so creating a separate alert sensor for each plant would result in receiving multiple simultaneous notifications at once.

[JayDotR]

Hi JayDotR,
I'm glad the plugin is proving useful, and thanks for your interest.
The idea you implemented in the fork is great for automation, but it requires a large number of sensors (12); I tried to simplify the plugin to the essentials: one general alert sensor each for today and tomorrow, and one sensor providing details for each of those days.
The logic was that if a user receives a high pollen level alert, they can check the text sensor to see which specific allergen is at a high level. Airborne pollen usually comes from multiple plants, so creating a separate alert sensor for each plant would result in receiving multiple simultaneous notifications at once.

I'm understanding your concern of the number of sensors, but on the other hand a text sensor is quite unhandy to keep track over time due to the global setting to define retention duration of those fields. That's why I chose to switch over to Custom Sensor Types which target the Percentage Table, and give a year-to-year overview in their stats.

Your're right with the 12 sensors are perhaps too much. My next version will therefore contain an additional parameter field where you can either blank (choose all allergens), or (with verification) define which pain points you're interested in. Nevertheless, your idea of having a global score could be integrated in mine. The code will be kept modular, what simplifies maintenance over time. I'm not so a fan of large monolith python scripts

[JayDotR]

NB : could you add a Luxemburgish translation please

Code: Select all

"lb": {
    "today": "Haut",
    "tomorrow": "Muer",
    "unknown_pollen": "Onbekannte Pollen",
    "no_data": "Keng Donnéeën",
    "levels": {
        0: "Keng Donnéeën",
        1: "Keng",
        2: "Niddereg",
        3: "Mëttel",
        4: "Héich",
    },
    "pollen": {
        "alder_pollen": "Erle",
        "birch_pollen": "Birk",
        "grass_pollen": "Gras",
        "mugwort_pollen": "Beifouss",
        "olive_pollen": "Oliven",
        "ragweed_pollen": "Ambrosia",
    },
}

[pfloryann]

Yes, allowing the user to select what interests them could be a good option and a step in the right direction; however, the plugin's current form should also include an option for general information, should the user desire it.

[pfloryann]

v.1.2.1 added languages:

Lëtzebuergesch
Čeština
Български
Magyar
Svenska

[JayDotR]

Thanks for the point of view, so therefore mine advanced also in version number . Pushed v0.2.1-alpha to github.

Jan

[manjh]

Latitude/longitude donot have a default version.
Suggestion: pull the lat/long values from the Domoticz settings, use those as default after installation.

[JayDotR]

Latitude/longitude donot have a default version.
Suggestion: pull the lat/long values from the Domoticz settings, use those as default after installation.

I'm permitting to reply on this topic, and from the architectural point of view of the plugin, it makes sense to use the system coordinates if no input is given. As I cant reply for pfloryann, I will consider this thought in my plugin I'm writing

[pfloryann]

Thank you for the suggestion. It will be implemented in the next update.

LE: v1.2.3 is out

Now If the coordinate fields are left blank, the coordinates will now be retrieved from the Domoticz settings.
However, if you wish to use different coordinates, you can still configure them within the plugin.

[JayDotR]

Thank you for the suggestion. It will be implemented in the next update.

LE: v1.2.3 is out

Now If the coordinate fields are left blank, the coordinates will now be retrieved from the Domoticz settings.
However, if you wish to use different coordinates, you can still configure them within the plugin.

You're right. But an issue I ran into when testing is that if for a reason the system coordinates cant be ready you can stitch back to a classic .env file fallback (I implemented it that way, btw)