2023.12 Ping integration changes & scan_interval

Have responded to the wrong post?
My post was in response to an original post in the 2023.12 Welcome home blog (which you moved along with mine to this), on how to trigger an automation every 90secs. I didn’t mention ping at all.
As others have mentioned my suggestion doesn’t work, however that is irrelevant to your remark if indeed, it was aimed at me.

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

because you moved it!

EDIT: And I have just read it

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

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

1 Like

Feature Request?

1 Like

Created this FR:

Everyone is welcome to participate.

2 Likes

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.

1 Like

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.

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.

1 Like

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…

1 Like

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.

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.

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”.
1 Like

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 }}

Oh boy, do you mean these options?

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.

Config options are not being deprecated.

2 Likes

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
    
11 Likes

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?

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?

1 Like

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.

1 Like