2023.12 Ping integration changes & scan_interval

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

[Ildar_Gabdullin]

@Mariusthvdb

there is (and has been for some time now) 100% user-controllability

Then my comment is still valid.
Packages in yaml may be managed.
UI settings cannot be united to packages; but this is not related to “2023.12 release” thread directly.

[mwav3 (Tim)]

I like the new climate card

Not a huge fan of the changes around the Ping sensor - was trying to change it to do every 90 seconds (5 minutes is too long) and then saw the formula/math needed in this post to do the automation

Time pattern trigger for every 90 seconds

trigger: - platform: time_pattern seconds: '/15' condition: '{{ (now().hour * 3600 + now().minute * 60 + now().second) % 75 == 0 }}' If you want every 90 seconds (like it says in the topic’s title), change '/15' to '/30' and change 75 to 90.

It appears from comments higher in the thread this difficulty was implemented on purpose, so I just gave up on using Home Assistant for ping all together and just do it through the ping node in Node Red now

[123 (Taras)]

@mwav3

then saw the formula/math needed in this post to do the automation

What I see is simple arithmetic but if anyone finds it daunting then it can be reduced to this:

{{ now().timestamp() | int(0) % 90 == 0 }}

Use it as a condition with a 30-second Time Pattern Trigger (as explained in the linked example) or simply as a Template Trigger.

Or if you’re already using Node-Red, use mwav3’s suggestion; it’s more convenient. Otherwise, installing Node-Red (and learning how to use it) merely for the use of ping seems like a lot of overhead. Nevertheless, it’s an easy first step into a new world of possibilities with Node-Red.

[Duke_box]

Or

trigger:
    - platform: time_pattern
      minutes: "/1.5"

should work.

[petro]

Really? Post in the other thread.

[mwav3 (Tim)]

Thank you, appreciate the updated formula. I will be the first to admit I am not an expert with Home Assistant automatons, and your posts and expertise has definitely helped me many times when putting them together. I definitely like the visual aspect of automations in node red so have been running it for awhile, but definitely agree would not be worth the overhead of installing node red just for ping.

Will give the automation using your trigger another try and see which way ultimately works best now. My use case for background is I just want to have a sensor that determines if internet is online, and then when it goes offline for over 5 minutes my GSM modem texts me there is an internet outage at the house.

[123 (Taras)]

@Duke_box

minutes: "/1.5"

should work.

It’s not supported. The Automation Editor flags it as an error when you attempt to save the automation.

[petro]

Then there’s really no reason to alter the poling rate. It will have a 30 second polling rate in 2023.12.1

[mwav3 (Tim)]

Oh perfect, thanks Petro. Glad they are going with the 30 seconds over 5 minutes

[Mariusthvdb (Marius)]

though I love the beauty of that, and also the optimal flexibility we get with service homeassistant.update_entity I must confess it would be nice if we could just jot in

automation:
  trigger:
    - platform: time_pattern
      seconds: /90

why would it be too difficult to have the backend take care of that? I suppose many more triggers than only for replacing scan_interval could use that.

[poudenes]

What is the main reason that this whole scan_interval is removed?
Isn’t a free will of the user to set this on whatever they want…

If I want a scan_interval of 1 seconds then this is my decision. I can have a good reason for.

Now I have an automation to update some device_trackers with a 5 seconds interval.
If this is the reason, people have to build a automation to make this happen, that’s ok.

But is the resource impact the same when you used scan_interval vs a automation that update entities?

Just some questions that pops up after reading all those scan_interval stuff

[parautenbach (Pieter Rautenbach)]

@poudenes

What is the main reason that this whole scan_interval is removed?

This has been covered several times already. Read the thread. Search the forum.

@poudenes

Isn’t a free will of the user to set this on whatever they want…

You have that option. Use automations.

@poudenes

If I want a scan_interval of 1 seconds then this is my decision. I can have a good reason for.

No, it isn’t. Read the thread. Hint: external websites might not like it.

@poudenes

Now I have an automation to update some device_trackers with a 5 seconds interval.
If this is the reason, people have to build a automation to make this happen, that’s ok.

Then what’s the issue?

@poudenes

But is the resource impact the same when you used scan_interval vs a automation that update entities?

HA is built to run automations. Take a guess.

@poudenes

Just some questions that pops up after reading all those scan_interval stuff

Hmm…

[allard77 (Allard K)]

@parautenbach

@poudenes

If I want a scan_interval of 1 seconds then this is my decision. I can have a good reason for.

No, it isn’t. Read the thread. Hint: external websites might not like it.

Actually, it is his decision. Whether or not external websites like it has nothing to do with that. Especially if he is not even pinging external websites. And not being able to configure the interval also means I can’t make it longer, so as of 12.1 I will be pinging every 30 seconds even though I only really need every 5 minutes, unless I make the extra effort to create an additional automation. How many people will bother to do that, if their own system isn’t really affected by that higher frequency?

I understand that giving people the power to create short ping intervals comes with some risks. Those risks are mainly for the users themselves, they might get excluded from reaching certain websites. That will probably teach them something, but it is not my favorite way users should be educated about these risks. I would prefer doing that by making short intervals part of ‘advanced options’ or something like that, and by giving them a dialog before this option is activated.

I really don’t agree with creating a UI that does not give you the option to change the interval in any way, and instead directing people to a different UI to change the parameters of what the first UI is doing.

[petro]

You can change it. It’s been stated multiple times that you disable polling and make an automation that does the polling.

[allard77 (Allard K)]

Was that a reply to this?

I really don’t agree with creating a UI that does not give you the option to change the interval in any way, and instead directing people to a different UI to change the parameters of what the first UI is doing.

Because in that case you did not understand what I was saying. I know this is possible. Read the line again. What I mean is that the workaround with the automation is, to me, a weird and unncessarily complex way to achieve this, sweeps all uses of ping including local network applications under the same denominator, doesn’t educate clueless users about the problems they might cause and doesn’t really solve the problem in the first place.

[Ildar_Gabdullin]

1. Have nothing against about deprecation of “scan_interval”. This may be anyway replaced by an automation. Moreover, for most integrations I already update entities in automations since it allows me to update them conditionally (“do not update if…”).

2. Things about recent changes of PING that worries me are:
   – docs became inconsistent in part of “device_tracker”;
   – these changes for many users became sudden; users should be just warned “yaml ping config will be deprecated in 2023.x; scan_interval will be deprecated in 2023.x”.
   What happened in fact was rather hasty. Repeat, these changes did not touch me personally.

3. In general even this “switch off polling & use automations” way (very smart) is still not giving people 100% control “when the entity is updated”: entities are still automatically updated on HA startup. I keep asking questions about “how to disable updating on HA startup” - and usually this is unanswered or ignored.

4. These next “move yaml → UI” changes touches more & more integrations. Although it was said (ADR) that only integrations of some kind will be moved to UI - I am afraid that this list will grow. Usually I see a reaction from same people (liked by same people) - same “ship is sailed and so on”, also about “this approach was discussed and agreed by majority”. Can I see a thread where it was “discussed & approved”? (I hope it will not be same story as happened recently with the latest primitive HA logo which was also “discussed & approved”).

[Duke_box]

@petro

Really? Post in the other thread

Have responded to the wrong post?
My post was in response to an original post in the 2023.12 Welcome home blog (which you moved along with mine to this), on how to trigger an automation every 90secs. I didn’t mention ping at all.
As others have mentioned my suggestion doesn’t work, however that is irrelevant to your remark if indeed, it was aimed at me.