core
core copied to clipboard
home-assistant
Set ping interval to 30 seconds instead of 5 minutes
Hello,
I use ping to check if the family mobiles are on the wifi. When I detect that they are not I activate camera recording and alarms.
Since the last change from 5 minutes to 30 seconds in 2023.12.1 (updates https://github.com/home-assistant/core/pull/105191 and https://github.com/home-assistant/core/pull/105199) it happens that in the iphone mobiles it detects small disconnections of 2 or 3 minutes. While on android phones this does not happen.
That is to say with the old configuration of a test every 5 minutes and I had configured the value of ping packets to 100 never happened to me. Does something similar happen to you?
Hey there @jpbede, mind taking a look at this issue as it has been labeled with an integration (ping) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of ping can trigger bot actions by commenting:
-
@home-assistant closeCloses the issue. -
@home-assistant rename Awesome new titleRenames the issue. -
@home-assistant reopenReopen the issue. -
@home-assistant unassign pingRemoves the current integration label and assignees on the issue, add the integration domain after the command. -
@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue. -
@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
ping documentation ping source (message by IssueLinks)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
That is to say with the old configuration of a test every 5 minutes and I had configured the value of ping packets to 100 never happened to me. Does something similar happen to you?
Your YAML configuration was scan_interval set to 300 and count to 100 (refer to the old docs for this)? Did you also have consider_home set? If not and that worked for you, you could try setting count to 100 in the Ping integration UI settings (default is 5) and then disable polling and define a custom polling interval of 5 minutes: this should put you back in the same situation you had when using YAML. If this doesn't work, then some further debug is needed.
If instead you used consider_home in your YAML configuration, that's not available in 2023.12.x unfortunately, there's a PR and it will be hopefully included in 2024.1.
I can deactivate the automatic scan interval (30 seconds) and make a manual one at 300 seconds as it was by default before. That is correct. Leaving the ping count at 100 everything should work as before.
But I understand that pinging an iphone is a quite common practice among home assistant users so I wanted to report my failure to see if there are more people in the same situation and want to make some kind of improvement in this module.
For example a new option under which a device is not reported as disconnected until it has not been reported 5 times out of network mode. Another option would be to implement that it does not report as disconnected until it has been out of network for 15min.
For example a new option under which a device is not reported as disconnected until it has not been reported 5 times out of network mode. Another option would be to implement that it does not report as disconnected until it has been out of network for 15min.
That option already existed, it's named consider_home and you can check on the Device tracker docs the way it works. In the passage of migrating Ping from YAML to Config Flow that wasn't implemented, but it's going to be.
From the Device tracker docs:
consider_homeSeconds to wait till marking someone as not home after not being seen. This parameter is most useful for households with Apple iOS devices that go into sleep mode while still at home to conserve battery life. iPhones will occasionally drop off the network and then re-appear.
In your case, when it's released, you could set it to 15 minutes and will have the effect you're talking about.
The thing is, if you didn't use it before and everything was fine, you should be ok with setting the polling interval to 5 minutes and count to 100.
I see what you mean about "consider_home":
Seconds to wait until marking someone as not at home after not being seen. This setting is very useful for homes with Apple iOS devices that go into sleep mode while at home to save battery life. iPhones occasionally disconnect from the network and then reappear. consider_home helps avoid false alarms in presence detection when using IP scanners such as Nmap. consider_home accepts several time representations, (for example, the following all represent 3 minutes: 180, 0:03, 0:03:00)
you say it's not available yet? when will it be available?
in my case setting the polling interval to 5 minutes and count to 100 works fine! :_) I can set it manually in the meantime.
ok, January is already next month. Between buying Christmas presents, drinking, and thinking about new year's resolutions, January 1st is already here! :-)
Hi there, I just would like to give a short answer to @javifly regarding this issue as I encountered the same problem with my android phone (yes it's not an apple ... beurk) I started to have this problem right after my tracker yaml configuration was automatically switched into Integration .. so nice to read you.
I have experienced similar behavior with 2 android devices recently. Thank you for the "workaround", ill update my config and see if it improves.
My wife got rather annoyed with the house announcing that she arrived home every few minutes.
that's what happened to me, for now i have deactivated the automations waiting for the new patch to be released in january, but the change has been quite annoying....
I managed to get past this stupid 2023.12 crap by changing to this yaml example:
command_line:
- binary_sensor: name: docker01-ping-status command: 'ping -W 2 -c 5 192.168.1.200 > /dev/null 2>&1 && echo success || echo fail' device_class: connectivity payload_on: "success" payload_off: "fail" scan_interval: 5
Sent from my iPhone
On 18 Dec 2023, at 5:04 pm, Javi Fly @.***> wrote:
that's what happened to me, for now i have deactivated the automations waiting for the new patch to be released in january, but the change has been quite annoying....
— Reply to this email directly, view it on GitHubhttps://github.com/home-assistant/core/issues/105452#issuecomment-1859847490, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMCDRZILC7SXXGEDBOJCSS3YKABJJAVCNFSM6AAAAABAOWCIXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJZHA2DONBZGA. You are receiving this because you were mentioned.Message ID: @.***>
I used ping to check the state of some home cinema devices controlled by IR. 30s is far too long. Dedicated automation generates an exorbitant code overhead and it pollutes the journal. Please bring the polling interval configuration back!!!
you can deactivate the 30 second poll yourself, and create a manual 5 minute poll similar to the one that was there before.
Yes, that's the workaround. Before: a clean 3 lines yaml ping config. After: a dirty 10 lines yaml automation. Where is the improvement? Even half of the ping doc page addresses this WA. At the end, the old school command_line binary_sensor shines like a diamond.
I have about 45 entities which have to be configured separately. That's a bit of a pain. A global override setting would be great or option to group them and set them up like that.
Every ping has diferent purposes, and in case of battery devices, any default value can kill the batteries FAST. The interval shoud be specified case by case, and not with an automation. Thats just stupid. Let's hope they restore it. Shoud we rename Automations to Scheduler?
It seems that they have already implemented the new option to define how many minutes to wait to mark a device as out of network.
Ping count: Number of echo requests to send to the target. The default is 5. Consider home: Number of seconds that must elapse before considering a disconnected device "not at home". The default is 180 seconds (3 minutes).
Now I can raise this value from 3 minutes to higher values to avoid false positives on apple devices.
What time value are you setting so that your iphone devices do not give false positives indicating network disconnections?
I have been trying with various values, 300, 600, 3600 but it keeps detecting small connections and disconnections. Does it work well for you?
It seems that very kindly fellow @PeteRager programmed the functionality to be able to choose the ping interval, so as not to have to use the default 30 seconds, but @jpbede has not accepted it.
I don't know if it would be viable to make an override of some part and to be able to use this functionality or to integrate it in some way, to my PeteRage's option seemed to me great.
I'm available to make whatever change is needed. I think there is some concern about people setting it to fast. For me I have alot of devices I ping, and the 30 seconds is to fast. My preference is 10 minutes. I don't think its possible to have a common preference of 30 seconds as the specific use case vary. We could certainly establish a minimum time that is configurable through the UI. Either way I thought I was doing a public service and spent a night and morning working on it.
Also in looking at the coordinator code that does the default schedule it injects a variable microsecond delay into the default schedules to prevent everything from hitting at once which is apparently important as its coded in the core; whereas the scripts we create don't do that. But we could put a millisecond delay in between each call - even more complexity.
I'd just like a simple user friendly way to manage this. Someone define that and I'll code it.
https://github.com/home-assistant/core/blob/b1b53ac893f0fbb43f6319e04470ba9f8649589f/homeassistant/helpers/update_coordinator.py#L100
The workaround is a bit painful as the first step is to go in and disable the polling for each device. So if you have 50 devices like me, that's 150 clicks of the mouse...and error prone...
Here's a command that I'm using to disable them all (you'll need to have HA shutdown) and jq installed.
cat ./temp/core.config_entries | jq '. | select(type == "object" and .domain == "ping").pref_disable_polling=true' > $TARGET/.storage/core.config_entries
Right now I use a windows script to monitor my computers. It monitors about 200 computers with a ping interval of 45 minutes. I was thinking of removing this script and move it to ha but seeing the problems I have not yet changed to ha and continue with my script.
It monitors the equipment in a sequential way. While one does not finish does not start the next, I've never had problems but being sequential the more teams there are the longer it takes to go through all and start again. Right now as I say 45 min
Right now I use a windows script to monitor my computers. It monitors about 200 computers with a ping interval of 45 minutes. I was thinking of removing this script and move it to ha but seeing the problems I have not yet changed to ha and continue with my script.
I have my list in a CSV file and have a shell script to auto generate the YAML configuration for ping and alerts. So it was pretty easy to add a new device, put its IP address, ping interval, etc. in the CSV file and run the script and generate a YAML package per device. Now with the UI you'd need to go in and type each one in one by one with all the errors that come from manual entry ... So I spent my morning redoing my shell script to automatically create the config entries (what the UI does) and autogenerate the automation to ping them on their configured intervals. Happy to put that up on GitHub if you want it.
Right now I use a windows script to monitor my computers. It monitors about 200 computers with a ping interval of 45 minutes. I was thinking of removing this script and move it to ha but seeing the problems I have not yet changed to ha and continue with my script.
The ping integration was never meant to monitor an entire network or something like that. There a better tools, which are designed for this use case, like Smokeping or Uptime Kuma.
However, this is not a decision we made for ping. It is a general decision not to have configurable scan intervals in the UI. If you think this is wrong, you can make a proposal in the architecture repository, which is meant for architectural discussions and decisions.
I will close this issue as the original problem has been solved, we lowered the interval 2 months ago.
