2023.12 Ping integration changes & scan_interval

[Mariusthvdb (Marius)]

@quaqo

I don’t see a way to implement consider_home at this point.

yes, Ive raised that and still looking for a definitive conclusion.
really fine with the new update on Ping (I just learned its going to be 30secs by default with the next update) and if that would prove to be too taxing, its easy enough to lower that further with an automation.

the consider_home though is a generic device_tracker setting, and as the ping tracker was the last one I had in yaml, I can no longer set that anywhere…

how to proceed on that (especially thinking of trying to fix/mitigate the modern phones toggling wifi to save batteries, but also triggering ‘false’ device_tracking because of that)

O and before I forget (just did): its been an amazingly smooth Beta, really nice, and no more errors in the startup log

[adekloet (Alex de Kloet)]

Just another way to do it via YAML;

Use a commandline sensor (up/down sensor using ping):

command_line:
  - binary_sensor:
      name: Google-URL-Online-commandline-ping
      command: "ping -W 1 -c 5 www.google.com > /dev/null 2>&1 && echo success || echo fail"
      # If errors occur, make sure configuration file is encoded as UTF-8
      device_class: connectivity
      payload_on: "success"
      payload_off: "fail"

[Mariusthvdb (Marius)]

talking about disabling polling, it would be useful to learn which integrations do update on startup (even when polling is disabled and which dont)

currently I have an issue with a rest sensor exceeding the api limit, and I’ve even set it to scan_interval: 86400 (can up that with a *7…) and automate the updating with a condition to not pass when ha has just restarted or some integration were reloaded:

    condition:
      condition: state
      entity_id:
        - binary_sensor.ha_restarted
        - binary_sensor.automation_integration_reloaded
        - binary_sensor.template_integration_reloaded
      state: 'off'

apparently it still updates on restart.
I am all for the system setting of not polling, but please make that 100%

[quaqo]

@petro

Also 2023.12.1 will bring back the 30 second scan interval for ping.

Thanks for confirming this! Also while I can see other benefits (code wise) to not have every integration have a scan_interval and just use automations, I’m confused by this statement by balloob

@balloob

This is correct. We got a lot of complaints in the past of people who used scan interval on any integration to hammer devices and services until they got Home Assistant blocked. The scan_interval option has been deprecated for a long time and is not allowed to be set via the UI. It is still possible for people, but you got to put in effort and hopefully know better what you’re doing to prevent abuse.

If this is the rationale for the change (and I get it), why lower the default from 300 to 30 seconds now? Also scan_interval has been deprecated for years (at least 4), but without any clear roadmap on when so I think is normal many people were still using it and are a bit surprised by the breaking change. Unless I missed some very important info on the ping integration that 2023.12 was going to be the end of scan_interval.

Also what about consider_home? See my post here:

@quaqo

Also what about device tracker’s ping? I don’t see a way to implement consider_home at this point. I see there’s a PR for this, but it’s not clear to me what’s the official advice on ping scan_interval and consider_home with the new UI for this release.

Thanks again to everyone.

[incar]

Ping settings for custom interval is a bit too complicated and way too long for default now…

Default 5min is definitely not reasonable.

I’m using it for automation to reboot device and send notification if device is not responding for longer than 30sec. Now with default way minimum time to reliably reboot device is 10min…

[petro]

@incar

I’m using it for automation to reboot device and send notification if device is not responding for longer than 30sec. Now with default way minimum time is 10min…

@petro

Also 2023.12.1 will bring back the 30 second scan interval for ping.

[PedroKTFC]

I am pinging MY device in MY local network. Pinging once a second is a trivial load these days. Why couldn’t “fast” ping be limited to local networks? There must be a huge set of use cases where people are pinging local devices relatively frequently!

[PedroKTFC]

This is why breaking changes need very very careful consideration. This will break something I use just about every day and until now I had a very simple and reasonably elegant solution. I will now have to use a kludge!

[PedroKTFC]

You don’t know people’s use cases. Give them the option, never assume. I’ve spent my life in IT and providing flexibility is always the best option.

[PedroKTFC]

I think given it’s a breaking change in a new release, the feeling of the community needs to be clear and that should be in the thread for the new release (sorry)!

[petro]

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

@PedroKTFC

I’ve spent my life in IT and providing flexibility is always the best option.

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

[PedroKTFC]

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

[nicktheradiovosht (Dr Nicholas P Filer)]

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.

[petro]

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.

[quaqo]

@PedroKTFC

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

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.

[hh93 (Howie Davison)]

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.

[Fotis_Kanellopoulos]

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.

[Ildar_Gabdullin]

@erik3

But it really should

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.

[Ildar_Gabdullin]

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 !

[GSzabados (Gábor Szabados)]

@petro

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

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…