2023.12 Ping integration changes & scan_interval

This change has been in the making for 3 years in every other UI integration and scan_interval has been deprecated for a few years before that. Automations give you full control over the frequency that you update the sensor. E.g. If you want it to update it only when you are home, for example.

An abnormal scan interval, or scan intervals for integrations that do not have them is one of the most asked feature requests. Sorry that this is harder than before, but the benefits outweigh the ease of use. The default scan interval should be good enough, if it’s not, you have to make an automation to alter it.

As you said yourself

We give you the most flexibility. I.e. you can dream anything up with the automation engine.

trigger:
- platform: time_pattern
  seconds: "/1"
condition:
- condition: state
  entity_id: person.petro
  state: home
action:
- service: homeassistant.update_entity
  target:
    entity_id: sensor.petros_phones_ping
3 Likes

30s v 5 minutes is frankly irrelevant as it won’t satisfy everybody. What if I want more? What if I want less? And by changing it, doesn’t it suggest it should be configurable?!

Auto T I also have many things on my network monitored at sensible specified intervals dpeending on the type of device.

Having to edit a database rather than a simple’ish YAML file is a major backward step for me. I suspect some of my devices will fail badly if pinged too often and others will go offline if ot ping’d at the correct frequency to keep them alve. Automations - horrible solution to a minor specification item no longer being provided. You did not have to specify this as the default does suit many devices and systems.

1 Like

It is configurable with an automation and the homeassistant.update_entity service. This is the path forward, it’s set in stone. It’s something that isn’t going to change. The decision was made years ago at this point. Sorry. All UI integrations are this way and any YAML integration that moves to the UI will adopt this functionality. And before you get upset with me, I did not make this decision, it was a group decision from many volunteer & core developers.

6 Likes

Yes. That’s why I’m confused. I do understand the reasoning, but I still don’t get why then change the defaults just after the relase.

Also the deprecation occured so long ago, but was still advised in the documentation without any hint this would be removed (as it is now for the YAML config).

Anyways I do appreciate that it can be done with automations, for me the issue is what are we supposed to do with the device tracker consider_home option.

This release breaks functionality of the device tracker ping platform without a clear documented path to remedy. Again, if I’m not mistaken.

2 Likes

I’ve had to roll back to 2023.11.3 as my ping stopped working also the RPi 4 CPU Temperature. Ping is used to auto reboot my Router after 16S is the connection cuts and CPU Cooling Fan Control.

I completely agree. I do also think it is a step back.
We remove 5 lines of code to add an intergration AND an automation for the interval time.

4 Likes

I think you may agree with me that this is not 2023.12-related.
This is probably worth to be discussed in another place.

As for “yaml->UI” trend - totally agree with you.

As for PING:
I had 10-15 ping sensors (mainly device_trackers, 2 binary_sensors) in yaml.
After update I got these (they seemed as “these”) entities added in “Integrations” UI. Then I commented lines for these entities in a code.
And none of these device_trackers were working.
Rebooted - did not help, all tracker not_home.
Removed all PING integrations for device_trackers from UI, only 2 PING binary_sensors remained .
Rebooted.
Quest continues.

1 Like

Well, my attempts to add ping device_trackers from yaml failed.

  1. Lines in yaml are commented.
  2. Some “device_tracker.some_device_ping_device_tracker” line deleted from “known_devices.yaml”.
  3. Ping integrations in UI (automatically created on HA updated) removed.
  4. HA rebooted several times.
  5. But still I see this “device_tracker.some_device_ping_device_tracker” in Entities list. And because of this I cannot add a PING integration with entities with a same name… (same for ALL my old entities - they are stuck and cannot be replaced).

Observe that this “move ping entities from yaml → UI” functionality is not working in my case. Not mature.


My working plan turned to be:

  1. Roll back to 2023.11.x.
  2. Remove all PING entities from yaml.
  3. Update to 2023.12.
  4. Add PING entities in UI.
    …
  5. PROFIT !
1 Like

Then please give the flexibility to declutter the Automations list as well! Which has been asked multiple times already… as it is just a long list without able to hide these fake Automations made as a stop gap solution…

3 Likes

That is being worked on.

3 Likes

I’m going to stick my oar in again as, in my irritation with the impact on ping, I hadn’t appreciated the impact on my device tracker configuration. Here is my highly highly (irony for those of you in America!) complex yaml:

# Use ping at home to detect presence
device_tracker:
  - platform: ping
    hosts:
      my_phone: 172.16.0.116
      wife_phone: 172.16.0.118
      car: 172.16.0.121
    interval_seconds: 1
    count: 2

Sorry but where in the whole wide world of sport is what’s been removed helpful to anyone? How do I replace this with anything “simple”?! I use this to switch on lights at night when we get home. I suppose I could wait 5 minutes, or 30 seconds in the next release, for the lights to come on (again, for those of you in America, irony!).

4 Likes

It’s all about the Ui :+1:t2:

“highly likely” (c)

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

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)?

One automation.

2 Likes

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

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.
8 Likes

With 15 (minimum) separate steps.

Yet you have no issue with setting up 15 sensors. :man_shrugging:

1 Like