2023.12 Ping integration changes & scan_interval

[tom_l]

@jbhorner

Having to create 15 new automations

One automation.

[parautenbach (Pieter Rautenbach)]

If they use the same scan interval a simple, single automation covering multiple entities will do the job, which should be the case for those that used the defaults.

That said, I remembered these two smart options by @CentralCommand from a year ago which truly allows you to have only one, regardless of varying scan intervals (as long as its constant per entity).

2022.12: Scrape and scan interval

Or just have one automation: trigger: platform: time_pattern minutes: '*' variables: entities: sensor.entity_1: 5 sensor.entity_2: 10 sensor.entity_3: 100 sensor.entity_4: 2880 ... total_mins: "{{ (now().timestamp() / 60) | int }}" action: repeat: for_each: "{{ entities | dictsort }}" sequence: if: "{{ total_mins % repeat.item[1] == 0 }}" then: service: homeassistant.update_entity data: entity_id: "{{ repeat.item[0] }}"…

So, please, can everybody still complaining about this just pause for a moment and think about this.

If you don’t get this by now:

1. scan_interval is being deprecated. This has been going on for years. None of this is specific to the ping integration. It’s just another one on the list. I simply don’t get how this can still be a surprise if you’ve made any attempt at regularly reading blog posts and release notes.
2. This is a home automation platform. Automations: Use them. There are so many complaints about using the UI vs YAML, or not having flexibility and control. Here you have it all.

[jbhorner]

With 15 (minimum) separate steps.

[tom_l]

Yet you have no issue with setting up 15 sensors.

[jbhorner]

Presuming you’re talking about my pinged devices, the sensors were already set up. And working. And it could be done in one place. Now it is in two places, and even with that it is more complex as in the second place it requires several additions. Your original assertion that it’s one automation is a bit flawed in my situation. As someone else has stated for their use case, I have varying poll times based on the type of device. That means different triggers, and different automations.

Why is this better than simply having a polling frequency in the place where the monitored devices are set up to begin with? It’s among the worst UX experiences (outside of manually editing YAML) I can imagine in this case.

To be sure, the way the migration went was mostly spot-on. It’s great that the existing devices were automatically imported into the new (visible) integration. It’s also great that I was given a warning that the YAML should be edited to remove the prior ping definitions.

With all of this said, I’ll just be disabling this part of my Home Asisstant implementation and move it to UptimeKuma. My only use case for this integration was for the purpose of notifications and one dashboard showing the status of said devices. I suppose I’d be sad if I had an automation that flashed my lights if my garage door opener didn’t respond to a ping. But that’s not the situation here. It’s just a shame that I’m having to move more things away.

[Mariusthvdb (Marius)]

these I remember (even found them in my templating toolbook now … had forgotten all about them because no need.

they are not ging to work for those Pingers that use the seconds scan_interval? wonder if it will take long before we see those being updated with that detail. Probably a nice challenge for the next few days (hours…)

never underestimate the power of customize and set custom attributes!

homeassistant:

  customize_glob:

    device_tracker.ping_*:
      scan_interval: 5

nor the power of modern templates

{{integration_entities('ping')}}

[Xitee (Mato)]

Why do we have to move everything to UI? Why can’t we support both like some integrations do? Sometimes, especially for advanced users, YAML is far better than doing everything in the UI.
You can copy paste stuff and also create extra files if you want to group everything together. I for example have a specific yaml file for each room in a ‘rooms’ folder. If you understand how YAML works this is far better organized than having everything somewhere hidden in the settings between other unrelated devices.

And what I can’t understand at all is why when we move, we can’t even keep existing features! And even less if it is for aesthetical reasons - in the settings!!

[tom_l]

@Xitee

Why do we have to move everything to UI?

We’re not. See: https://www.home-assistant.io/blog/2020/04/14/the-future-of-yaml/#the-future-of-yaml

[Xitee (Mato)]

Ok, we don’t move everything. But we do remove yaml support for everything that is related to services/devices which is still pretty bad.
What is the reason why we remove existing things? Why can’t we keep both?

[tom_l]

Dude that ship sailed years ago. Search the forum, this is not related to the release topic.

[Mesmo (David)]

Also agree with this being a step back for ping - in addition to the convoluted approach to replicate interval_seconds, I cannot see a way to replicate consider_home which was essential for me for phones that like to drop their WiFi periodically.

[Ildar_Gabdullin]

@Mesmo

in addition to the convoluted approach to replicate interval_seconds, I cannot see a way to replicate consider_home which was essential for me for phones that like to drop their WiFi periodically.

Although I am not a fan of “move yaml to UI” approach - I think there is a way to achieve same results with automations.
Btw, all my PING entities were already updated in automations before 2023.12 (for only 2 entities I still used “scan_interval”).

I also wondered how the Docs for device_tracker relate to the changed PING platform - particularly regarding “interval_seconds” & “consider_home” params (even created a thread for this).

1. Seems that Docs for “device_tracker” became irrelevant to the PING integration.
2. The “interval_seconds” parameter seems to be same as deprecated “scan_interval”. I was using 10-15 ping “device_trackers” - and concluded that it is same. Means - the “interval_seconds” param may be implemented in automations the same way as “scan_interval” - by using “time_pattern” in a trigger.
3. The “consider_home” parameter may be implemented by using an additional automation like “if device_tracker = not_home for XXX minutes → set binary_sensor to OFF”; then use this “binary_sensor” instead of “device_tracker” (or in addition to) to see if a person home/not_home. Quite cumbersome.

[quaqo]

@Mesmo

I cannot see a way to replicate consider_home which was essential for me for phones that like to drop their WiFi periodically.

This. I asked this again, again, again, and again.

I also fail to see how this YAML to automations breaking change is compliant with this ADR. I would have expected a grace period for scan_interval, but the big problem I have is with consider_home.

[quaqo]

@Ildar_Gabdullin

The “consider_home” parameter may be implemented by using an additional automation like “if device_tracker = not_home for XXX minutes → set binary_sensor to OFF”; then use this “binary_sensor” instead of “device_tracker” (or in addition to) to see if a person home/not_home. Quite cumbersome.

Thanks for this, but I feel this is too much for an undocumented removed functionality that breaks things. The replacement for one line of YAML can’t be to create an additional sensor on top of 2 automations.

[quaqo]

@parautenbach

scan_interval is being deprecated. This has been going on for years. None of this is specific to the ping integration. It’s just another one on the list. I simply don’t get how this can still be a surprise if you’ve made any attempt at regularly reading blog posts and release notes.

I agree but using deprecated YAML integration configuration options must raise an issue in the users’ repairs dashboard. I understand and I agree in principle with the changes, but I don’t feel the issues raised here are without merit.

[Mesmo (David)]

Thanks for suggestion #3 - I had been using device_tracker/ping and then assigning the tracker to the relevant person. I was then using the zone count for home (to/from zero) to turn on/off an alarm. So I can see how I’d do it but it’ll be reams of trigger logic to replace something that was really simple and elegant IMHO.

As a general comment, I’m really pleased to see things move from yaml config to the UI, but it’d be great if they didn’t drop capability in the process.

[parautenbach (Pieter Rautenbach)]

@quaqo

I agree but using deprecated YAML integration configuration options must raise an issue in the users’ repairs dashboard. I understand and I agree in principle with the changes, but I don’t feel the issues raised here are without merit.

That’s not actually what’s happening here. Marius’ message is in response to mine that says you can set a custom attribute and use that in an automation (based on Mike’s link I posted). You can call that my_custom_scan_interval or x. It won’t have any relation to the deprecated setting. You’re simply setting some attribute and you will still need to implement an automation to use that.

(Of course, if you’re running a version of HA what still supports it, you would indeed be overriding the configured value. We’re talking about the way forward here.)

[parautenbach (Pieter Rautenbach)]

@quaqo

the issues raised here are without merit

What is without merit is the discussion about the removal of a long-time architectural decision to deprecate scan_interval.

What maybe had some merit was the change from the default 30 sec to 5 min, but that point was answered: It’s about hammering external servers. Regardless, the 2023.12.1 release will revert to a default of 30 sec.

[Mariusthvdb (Marius)]

100%

I did think of that and figured it would be easiest if people simply used their known verbiage, going from pre 2023.12 to 2023.12 +

least breaking backwards-incompatible changes, and taken care of in the backend…
(only add 1 beautiful automation)
might be even less yaml than before. O wait, some people want more yaml

[quaqo]

@parautenbach

What is without merit is the discussion about the removal of a long-time architectural decision to deprecate scan_interval.

I somehow agree, but still I feel like users should have been given a warning in previous releases with a set target deprecation date in 6 releases. I fail to see how this is in compliance with the ADR I posted.

@parautenbach

What maybe had some merit was the change from the default 30 sec to 5 min, but that point was answered: It’s about hammering external servers. Regardless, the 2023.12.1 release will revert to a default of 30 sec.

Here I disagree: if it is about hammering the default shouldn’t have been reverted. The fact that it is shows that’s not about that for the ping integration. It’s a global architectural move and that has its own pros that I understand and agree with.

Still, consider_home was removed from ping device tracker without any hints, documentation or path to move forward and scan_interval (even thou it is deprecated across HA) was removed without raising error messages in previous releases. In fact it was advised in the official documentation, without implementing any warning starting from 2023.6 (e.g. “warning: scan_interval will be deprecated in 2023.12, move to automations update_entity, etc.”).