2023.12 Ping integration changes & scan_interval

[petro]

The post you replied to was in this thread. It had been moved, hours before.

[Duke_box]

because you moved it!

EDIT: And I have just read it

[nickrout]

Feature Request: add the -f option to the ping integration so that the whole internet can get annoyed by HA.

[Ildar_Gabdullin]

@nickrout

whole internet can get annoyed by HA.

This “joke” cannot be called a “humour” even remotely.
Although you will definitely collect “likes”.

[123 (Taras)]

@Mariusthvdb

why would it be too difficult to have the backend take care of that?

Feature Request?

[Ildar_Gabdullin]

@Ildar_Gabdullin

In general even this “switch off polling & use automations” way (very smart) is still not giving people 100% control “when the entity is updated”: entities are still automatically updated on HA startup. I keep asking questions about “how to disable updating on HA startup” - and usually this is unanswered or ignored.

Created this FR:

Allow not to update entities on HA startup

Assume we have an integration which updates some entities periodically. A user may need to control a frequency of these updates. If the integration has “scan_interval” supported, a user may set it to a huge number and then update entities manually by calling a “homeassistant.update_entity” service. If the integration has no “scan_interval” supported and is controlled in UI -a user may switch off a periodical polling: [изображение] and then update entities by that “homeassistant.update_entit…

Everyone is welcome to participate.

[parautenbach (Pieter Rautenbach)]

@allard77

Actually, it is his decision. Whether or not external websites like it has nothing to do with that. Especially if he is not even pinging external websites. And not being able to configure the interval also means I can’t make it longer, so as of 12.1 I will be pinging every 30 seconds even though I only really need every 5 minutes, unless I make the extra effort to create an additional automation. How many people will bother to do that, if their own system isn’t really affected by that higher frequency?

I’m sorry, but you’re wrong. The original statement was one of entitlement. One’s decision to ping a service is only half of the argument. That is the rational way to look at it.

You’re just making an argument: They gave no indication that they’re using ping for internal purposes only.

And you’re simply wrong about not having a configurable interval: As has been mentioned so many times: Disable automatic polling and create an automation.

[quaqo]

@Ildar_Gabdullin

Things about recent changes of PING that worries me are:
– docs became inconsistent in part of “device_tracker”;

I hope this PR will fix that, and will be included in the next minor. Clearly review process missed this one as we established there’s no equivalent when updating to 2023.12 (unless we want to consider automation + duplicate binary sensors as the solution).

That for me is a showstopper, I can’t update to >= 2023.12 'till is fixed. Because of the way my home network is structured I rely heavily on a fine tuned ping, arp and other mechanism to fastly detect when devices are at home or not.

@Ildar_Gabdullin

– these changes for many users became sudden; users should be just warned “yaml ping config will be deprecated in 2023.x; scan_interval will be deprecated in 2023.x”.
What happened in fact was rather hasty. Repeat, these changes did not touch me personally.

Again, I’m a bit confused to see how many replies miss the point and are “scan_interval was deprecated for a long time and was discussed as an architectural move”, while the docs suggested using it untill a week ago and no warning was given as per ADR 21 (The deprecation period for YAML configuration options is set to at least 6 months […] Using deprecated YAML integration configuration options must raise an issue in the users’ repairs dashboard. This issue should explain why this happens and what a user has to do to resolve the issue.). I think ADR#21 is as much as an archictural decision (hence the name) as the deprecation of the scan interval and the move to config flow, so I don’t understand why not adhering to that carries no weight in this conversation.

[Mariusthvdb (Marius)]

done: FR Time pattern trigger: Allow higher seconds/minutes than 59

btw this works too:

    trigger:
      platform: time_pattern
      seconds: /30
    condition:
      - >
       {{now() - this.attributes.last_triggered > timedelta(seconds=89)}}

but still requires we get crafty, while my hope is we can stay humans and the backend will provide for us…

[mwav3 (Tim)]

Was thinking about this and I understand the developers concerns with frequent pings, but could a compromise be to allow the user to set a ping interval in the UI for anything the user chooses, that is at least 30 seconds and above? IE the UI doesn’t allow pings less then 30 seconds (input box is coded to accept only 30 seconds or more). For me, I’ve been doing ping at 90 seconds, and now I’d actually be pinging more often with the 30 seconds.

Then if the user wants more frequent pings with less then 30 second intervals, at that point they need to go through the extra steps of creating the automation to ping more often.

[parautenbach (Pieter Rautenbach)]

It’s not only about the value, but also the config option, which is being deprecated for all integrations that still uses it. It’s not specific to the ping integration. This was an architectural decision by die HA core team. I don’t think any debate on that point will change it.

[Ildar_Gabdullin]

I tend to agree that “scan_interval” could be / should be deprecated:

1. Less experienced users will use a default freq.
2. More experienced users will use an automation - it is MUCH BETTER: you may update conditionally, you may stop updating. These things were not possible (if I am right) with “scan_interval”.

[123 (Taras)]

@Mariusthvdb

{{now() - this.attributes.last_triggered > timedelta(seconds=89)}}

The first time the automation is triggered, the value of last_triggered is none and the subtraction will fail with an error message.

You can mitigate it with a default filter but the resulting template won’t be simpler than this:

{{ now().timestamp() | int(0) % 90 == 0 }}

[mwav3 (Tim)]

@parautenbach

the config option, which is being deprecated for all integrations that still uses it

Oh boy, do you mean these options?

Options Flow | Home Assistant Developer Docs

If so, many integrations use that, and this could become a mess. I might not be understanding this right though and haven’t been able to find the discussions in github around this. Do you have any links you can share with discussions around deprecating the integration’s config options? Definitely curious to know more about this.

[petro]

Config options are not being deprecated.

[petro]

Standard Polling Frequency

The standard Ping polling frequency in 2023.12.0 is 5 minutes. This has been updated in 2023.12.1 to a polling frequency of 30 seconds.

Consider Home

Consider home will be available in 2024.1.x. If you join the beta, you can have it as early as December 28th 2023.

Altering Default Polling Frequency

To alter the default polling rate:

1. Disable polling (Note this does not disable a single poll that occurs at startup)
   • 3 vertical dots → System Options → Turn off Enable polling for updates.
2. Create an automation with any polling rate you desire using any number of available triggers.
   Heres a typical automation with a 15 second polling rate for multiple ping entities

   trigger:
   - platform: time_pattern
     seconds: "/15"
   action:
   - service: homeassistant.update_entity
     target:
       entity_id:
       - sensor.ping_device1
       - sensor.ping_device2
   

[quaqo]

@petro

Consider home will be available in 2024.1.x. If you join the beta, you can have it as early as December 28th 2023.

The comeback is great news! Thanks! Do you happen to know why it wasn’t documented in 2023.12 release notes as a breaking change?

[quaqo]

@parautenbach

It’s not only about the value, but also the config option, which is being deprecated for all integrations that still uses it. It’s not specific to the ping integration. This was an architectural decision by die HA core team. I don’t think any debate on that point will change it.

Just curious, as I already explained how I feel (I agree with the change but not with the timing): do you know why the Nmap Tracker scan_interval wasn’t removed when it was moved to config flow/UI?

[parautenbach (Pieter Rautenbach)]

I have unfortunately no idea. I can only speculate. It could’ve been an oversight. I only used the nmap tracker for a short while when I started using HA ~5 years ago, but I dropped it so haven’t followed its updates too closely. Perhaps one of the core devs see your comment and can chime in.

[quaqo]

Thanks anyways!