2023.12 Ping integration changes & scan_interval

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

[Ildar_Gabdullin]

@Mariusthvdb

might be even less yaml than before. O wait, some people want more yaml

This sarcasm is meaningless for users how wants to use user-controllable packages instead of plenty of UI-made settings (not mutually related).

[allard77 (Allard K)]

@Mesmo

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.

I think it would be very useful to get a device_tracker integration that is configurable from the UI, which lets you choose a platform (or multiple platforms per device) and includes a setting for a polling interval. AFAICT there isn’t a feature request for this yet.

[Mariusthvdb (Marius)]

@allard77

device_tracker integration that is configurable from the UI, which lets you choose a platform (or multiple platforms per device)

the best (imho) is still Composite.
its not fully UI, but allows for those multiple platforms, and has lots of useful settings.

You can even throw them all in a single composite tracker and use that for your Person entity.

[allard77 (Allard K)]

Looks good, I will try it out. But I think something like this is very useful in the default HA, without HACS. I first started out with presence detection using the mobile app, without realizing it would never be set to ‘away’ on my locally-connected-only instance. From the forum I learned I wasn’t the only one making that mistake. A composite device tracker configurable from the UI would be a big step forward IMO.

[parautenbach (Pieter Rautenbach)]

@quaqo

Here I disagree: if it is about hammering the default shouldn’t have been reverted.

I personally actually agree with this. I just meant this is the more debatable part of the issues raised (not that I necessarily agreed with it, hence the maybe).

@quaqo

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

That’s definitely a communication faux pas.

[quaqo]

@parautenbach

That’s definitely a communication faux pas.

For me, personally, the unsolvable issue ATM is the lack of a consider_home alternative (apart from what Ildar Gabdullin suggested here, which is too much I’m afraid).

[Mariusthvdb (Marius)]

nope, you misread, and misconcluded.

there is (and has been for some time now) 100% user-controllability, and that was what I was referring to. (via the one beautiful automation).