This has been covered several times already. Read the thread. Search the forum.
You have that option. Use automations.
No, it isn’t. Read the thread. Hint: external websites might not like it.
Then what’s the issue?
HA is built to run automations. Take a guess.
Hmm…
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.
You can change it. It’s been stated multiple times that you disable polling and make an automation that does the polling.
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.
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…”).
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.
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.
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”).
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.
The post you replied to was in this thread. It had been moved, hours before.
because you moved it!
EDIT: And I have just read it
Feature Request: add the -f option to the ping integration so that the whole internet can get annoyed by HA.
This “joke” cannot be called a “humour” even remotely.
Although you will definitely collect “likes”.
Created this FR:
Everyone is welcome to participate.
I’m sorry, but you’re wrong. The original statement was one of entitlement. One’s decision to ping a service is only half of the argument. That is the rational way to look at it.
You’re just making an argument: They gave no indication that they’re using ping for internal purposes only.
And you’re simply wrong about not having a configurable interval: As has been mentioned so many times: Disable automatic polling and create an automation.
I hope this PR will fix that, and will be included in the next minor. Clearly review process missed this one as we established there’s no equivalent when updating to 2023.12 (unless we want to consider automation + duplicate binary sensors as the solution).
That for me is a showstopper, I can’t update to >= 2023.12 'till is fixed. Because of the way my home network is structured I rely heavily on a fine tuned ping, arp and other mechanism to fastly detect when devices are at home or not.
Again, I’m a bit confused to see how many replies miss the point and are “scan_interval was deprecated for a long time and was discussed as an architectural move”, while the docs suggested using it untill a week ago and no warning was given as per ADR 21 (The deprecation period for YAML configuration options is set to at least 6 months […] Using deprecated YAML integration configuration options must raise an issue in the users’ repairs dashboard. This issue should explain why this happens and what a user has to do to resolve the issue.). I think ADR#21 is as much as an archictural decision (hence the name) as the deprecation of the scan interval and the move to config flow, so I don’t understand why not adhering to that carries no weight in this conversation.
done: FR Time pattern trigger: Allow higher seconds/minutes than 59
btw this works too:
trigger:
platform: time_pattern
seconds: /30
condition:
- >
{{now() - this.attributes.last_triggered > timedelta(seconds=89)}}
but still requires we get crafty, while my hope is we can stay humans and the backend will provide for us…
Was thinking about this and I understand the developers concerns with frequent pings, but could a compromise be to allow the user to set a ping interval in the UI for anything the user chooses, that is at least 30 seconds and above? IE the UI doesn’t allow pings less then 30 seconds (input box is coded to accept only 30 seconds or more). For me, I’ve been doing ping at 90 seconds, and now I’d actually be pinging more often with the 30 seconds.
Then if the user wants more frequent pings with less then 30 second intervals, at that point they need to go through the extra steps of creating the automation to ping more often.
It’s not only about the value, but also the config option, which is being deprecated for all integrations that still uses it. It’s not specific to the ping integration. This was an architectural decision by die HA core team. I don’t think any debate on that point will change it.
I tend to agree that “scan_interval” could be / should be deprecated:
The first time the automation is triggered, the value of last_triggered is none and the subtraction will fail with an error message.
You can mitigate it with a default filter but the resulting template won’t be simpler than this:
{{ now().timestamp() | int(0) % 90 == 0 }}
Oh boy, do you mean these options?
If so, many integrations use that, and this could become a mess. I might not be understanding this right though and haven’t been able to find the discussions in github around this. Do you have any links you can share with discussions around deprecating the integration’s config options? Definitely curious to know more about this.