Assume we have integrations which:
– poll networks devices (like “ping”, “netdata”);
– poll internet services (like “weather”, dead “life360”).
By default, integrations are polling based on their own rules (could be like “poll every 30 sec”, “poll at 15:00”, “poll if …”).
A user may disable an automatic polling for some integration and update manually in an automation using “update_entity”.
I am using a manual polling for some integrations like ping, netdata.
For some integrations I left a default own polling - also because do not want to replace this own polling algorithm (which I do not know and which may be more complex than a simple “poll every 30 sec”).
Sometimes a polling (manual or automatic) causes errors - could happen if a device/service is unavailable.
To prevent these errors when doing a manual polling, some additional checks may be added in an automation - like:
– do not poll device_1 if switch_1 is down (i.e. this network segment is unavailable → no need to poll devices in it);
– do not poll network devices in 04:57 … 05:05 interval (routers & switches are periodically rebooted at 05:00 → network is down).
Since some integrations are using their own polling, I cannot add these checks in this polling process. Is it possible to prevent an automatic polling based on some conditions?
Like “if … → disable the integration, if … → enable the integration”.
A bit unrelated question:
Assume some integration provides a SET of entities.
Example: “ping” creates 2 entities - binary_sensor & device_tracker.
In an automation you can call “update_entity” for the device_tracker only - and the binary_sensor is then updated as well.
Another example - “netdata”: it creates many sensors. In an automation I have to call “update_entity” for EVERY entity. Is there any way to know for sure which entities are to be used with “update_entity” - one particular entity or all of them - to ensure that all entities are updated?
For your first question, there is no native way to disable an integration via a service call, but you can use the Spook integration to do just that: https://spook.boo/integrations
Thanks for the reply, read about Spook & was going to install it on a test setup.
The question is general. Wanted to hear about a “best practice” to update conditionally.
I don’t think you can, but nothing’s stopping you from disabling the automatic polling and setting a manual polling automation (using the same frequency) with the conditions you need to perform those checks.
I see.
Thanks for confirming my fears.
Probably, for some integrations whose polling I do not want to replace - I will try playing with Spook (it has services for enable/disable polling).
Btw, in my automations for “replacing polling” frequencies are not “abnormal”.
“Abnormal” = higher (more frequent) than default.
I am using less frequent update in most cases than default (like ping every 5 minutes instead of default 30 sec).
Simplest way is to just disable automatic polling wherever you need conditions, and poll at your own leisure using your preferences via an automation.
I get you, in my opinion this hardcoding of polling intervals is a bad idea, but at least it’s now possible to include certain conditions. I doubt the old yaml config for polling was flexible enough to include such conditions.
Netdata still has yaml config.
A default scan_interval was smth like 30 sec.
I defined a huge scan interval and update it every 5 minutes.
So, yaml config in this particular case was not a obstacle.
In general, I have no objections for new UI-based integrations - in part of polling.
It is really flexible: if you need to replace a default polling - juts switch it off and provide your own automation. The thing is that in many cases it is better to leave the default polling.
Here I meant that some entities may be like “paired”: updating one entity cause another entity to be updated too. But in other cases I need to call “update_entity” for every entity.
Granted, but that wasn’t the point I was trying to make. Could you set conditions based on device/entities being unavailable in this yaml config for Netdata?
Not sure if I understand you properly.
As I said, I can specify a huge scan_interval, and then manually update in an automation every 1 hour (or every 5 minutes, does not matter) using conditions like “do not try to update if the device is unavailable” (for example, if result of ping was negative).
Currently I manually update entities for:
– yaml-based integrations with huge scan-interval: netdata, smtp, open-hardware-monitor, some Xiaomi platforms;
– UI-based integrations with switched-off polling - ping.
Other integrations are with a default polling.
What I did is:
– call “update_entity” for ONE entity provided by the integration;
– if after this call only this particular entity is updated → then you have to call “update_entity” for other entities too,
i.e. “try & see” way.
Thanks for clarification.
Not sure if it’s a language barrier or just misunderstanding each other, but this is what I get from your request:
If integration has manual polling using a custom interval set up, use conditions (using automations).
If has automatic polling set up (because you’re comfortable with the update frequency), also use conditions (built in using some other logic).
The part I fail to understand is, nothing’s stopping you from disabling automatic polling for ALL integrations, then using the conditions in an automation using the same update frequency
I guess I’d rather have feature parity with yaml config (decide on the poll interval when setting up the integration), but that ship has sailed.
Yes, what you’re proposing makes sense, in a way that polling should realise that something is unavailable and stop until it’s available again. However, the current solution to add this check in an automation fixes this issue which plagues most integrations.
Your proposal would be the cherry on the cake - I wish we could have a configurable poll time + option to not spam on unavailability, but this is feature request territory, given that there’s a functional workaround for this.
I meant a bit different:
– for some integrations (configured in UI) I may just switch off polling and create an automation with a desired frequency (usually less frequent than a default) - and I can add conditions;
– for other integrations (configured in UI) I prefer to use a default polling (do not switch it off) - since this polling is complex & no need/ability to overwrite it; - THIS is a case for which I was interested to know is there any way to add conditions (enabling/disabling polling in Spook seems to be the only way).
As for yaml-configured integrations - I have only examples for netdata, OHM, SNMP - they can be “customized” as I described: define a huge scan_interval, then same as for “switch off polling” case described above.
Except cases (as I already said) when a default polling algorithm is complex & I do not want to reinvent it (can make it worse).
All my UI-based integrations do not allow to set a custom scan_interval - may be none of HA UI-based integrations does it.
As it was expressed in Community, a possibility to define scan_interval for users is officially considered to be harmful; experienced users may create automations with any scan_interval & conditions; inexperienced users may take a ready blueprint and poll smth every 1 second.
But some integrations may have a complex & tricky polling, no need to overwrite it - see above.
You lost me at complex polling. The most complex polling I’ve seen so far is ZigBee, where you can set different intervals based on whether it’s an end device or not. I’m not even sure that’s actual polling tbh.
In short, I’m out, sorry. May you find the answer you’re looking for
FYI it’s not really complex. It’ll always be a time_pattern trigger. The integrations should specify the polling frequency, if omitted, it’s 30 seconds.
Imho in some cases it could be more difficult - like “poll at a particular time”, just a guess.
Another case:
Take a life360-like integration: assume the integration creates a “device_tracker” entity with attributes like “last_seen”, “battery_level” etc.
And you call “update_entity” for this “device_tracker” manually.
Assume a corr. device is offline - it was last_seen yesterday.
Question: will you get the same object after every call? Or it will have an updated “last_updated” after every call? If none of attributes changed - the object is not supposed to be considered as updated.
But this is what I get with Traccar integration: if “update_entity” called by a user - the same object has a new “last_updated” (and tons of SAME records in DB as a result - same state/attribute, only different last_updated); if a default polling=ON → the object has same “last_updated” (as expected).
And who is a culprit here?