2023.12 Ping integration changes & scan_interval

[rossk]

@HeyImAlex

Probably because of the nice web UI.

It’s all about the Ui

[Ildar_Gabdullin]

@PedroKTFC

highly highly

“highly likely” (c)

[allard77 (Allard K)]

This is my question too. Device tracker is my only use for ping atm.

[jbhorner]

Agree 100% that it is a step backwards. Having to create 15 new automations (which in themselves have had issues over the past two releases) to get a new interval is hardly a user benefit.

If I have a critical device that is down, I do not want to wait 5 minutes to know about it. This will be yet another piece of functionality I have to move to another solution from Home Assistant.

The logic of making it easy for the user is deeply flawed. How hard can it be to leave one field that defaults to 5 minutes but is editable (with the ability to change from minutes to seconds)?

[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.