In yaml based setup, consider_home was always required or else defaulted a value.
Ping will always fail for many possible reasons (router, wifi, phone, raspberry pi) so consider_home allows you to set how many seconds later mark as not_home if first ping fails.
In the current version, ping integration automatically setting the device away if it fails only once.
Well, actually its about to be 4 different ways ping works in Home Assistant across the last few versions, unless I am missing something with my math:
1- Ping configurable from yaml in 2023.11, user configurable interval, with consider home
2- Ping configurable from UI with 5 minute interval in 2023.12 - no consider home option
3- Ping configurable from UI with 30 second interval in 2023.12.1 - no consider home option
4- Future release of 2024.1- configurable from UI with 30 second interval with consider home option.
So, i consider that unstable with all those changes. However, looking at this in another way to be more positive, being forced to change can sometimes lead to using something else that makes the system better. Iâve seen some posts above with alternatives suggested that donât use ping at all. I would be interested if anyone had other ideas on alternatives to check if an external internet connection is up and working, without relying on ping.
@parautenbach is correct. You are confusing terminology.
REMOTE means you can connect to your Home Assistant server from another network. For example, in a restaurant on their WiFi you want to check if you turned off the garage light.
LOCAL means everything on your home network whether itâs connected by WiFi or Ethernet. Itâs the first letter in the acronym LAN.
The only way to get remote access is to expose your Home Assistant server to the Internet. Some people use port forwarding through their Firewall and DuckDNS for DNS resolution. Others subscribe to Nabu Casa which, I believe, tunnels into your server like a VPN. Iâve done both and much prefer the Nabu Casa route. Itâs much easier to set up and the monthly subscription supports Home Assistant development.
You can use netcat to probe a specific port on a host, like for example:
nc -z -w 3 192.168.1.123 80
Will check if http port 80 is open on 192.168.1.123 without actually establishing a connection (with a timeout of 3 seconds in case the server is down). I do this for my IP cameras that are NATâed by my NVR onto virtual ports and donât respond to ICMP pings.
Thatâs just default behavior changing except for consider home. My automation which I setup during the beta has continued to work exactly the same despite these âdifferent ways it worksâ
Glad these tweaks/changes/improvements/default behavior/backwards compatible changes/breaking changes or whatever semantics one wants to use to describe them are not impacting you, but based on 225 posts on this thread, thatâs not the case for everyone.
225 posts mostly from the same 10 people who have continued to beat this horse to death even after changes were made directly based on theirs and others comments.
Ok point taken petro. I think Iâve chimed in enough on this topic so will definitely move on with more important contributions
Interesting. How would you actually use this as a HA sensor? thanks
You make no sense 
Kidding 
I am confused though, The see service adds the device_tracker. itself.
The see service?
Thanks mate 
Sorry but I think youâve missed the point of what I was saying. Originally, someone questioned why I had my HA on my WiFi. I explained I coudnât use Ethernet so it had to be WiFi and it has to be on my local network as it can then be exposed remotely (I know full well the difference between local and remote, I worked on TCP/IP routing for networked operating systems in the 1980s). I use the Clouflare tunnel approach to expose my HA for remote access.
Somehow a simple explanation of why I was using WiFi got dragged into a line-by-line, almost word-by-word, disection for accuracy.
If you go into Developer Tools>SERVICES, you can call Device Tracker: See. Iâve copied in a screenshot below. If I called the service with the data below, HA would create an entity called device_tracker.pick_a_name.
Right! Thank you, I see what youâre doing now.
Delete the old entity, call the service to create a new one with the value of away ect ect.
Thanks again, ill test it, see how it gets on
Respectfully, I think the confusion stemmed from your interpretation of Mariusthvdbâs statement:
personally, I turn off wifi an BT when away from home⌠dont want to be tracked
To which you replied:
Thatâs an interesting approach. I need WiFi on as I want to access HA remotely
Now I might be wrong, but I understood Marius to be saying that they turn off wifi on the phone, not on the HA server. With wifi and bluetooth off on the phone, they reduce the 3rd party tracking potential (while acknowledging the cellular signal still allows the provider that capability) while out and about (commercial and government entities have been known to record this information).
Since wifi would be turned off, when they return home, unless they remembered to turn it back on, ping wouldnât be useful for them for presence, so they were sharing that other detectors might be used instead of, or alongside of, ping.
Ah! OK, wouldnât be the first time Iâve misunderstood a post. Probably best to draw a line under this side issue.
you understood correctly ;-}
Ahh soon enough we will need to summon the devil to make ping work as simply as it did!
The devs really go from one extreme to the next dont they? there is no middle ground with them. Just slowly start killing all yaml config options and moving everything to UI.
lol @ hammering.
I really dont understand the logic behind all this.
And no, âjust make an automationâ is not a solution, it just pisses everyone off.
Ever heard of the saying IF IT AINT BROKE, DONT FIX IT ?
Today break this, tomorrow fix it, by the time you fix it you make everyone angry. Is it a one time thing? no. because it happens all the time. instead of a stable system, we must sit and sweep up the havoc thatâs being created.
My point is⌠Please return Ping back to how it was operating with the scan_interval.
Some will reply to this and say:
Nevertheless i will moan because im just another pissed off user, because today its Ping, tomorrow its something more vital.
I agree and but i just accepted it becauseâŚ
It was weird when i check the commits.
Someone made it to 30 minutes, it is approved and merged. Someone thought that it is too long, made it 5, approved and merged. Someone checked with some other people and thought it is too short and agreed to make it 15 minutes.
