Automatically deactivate the ping sensor if the host is unavailable. Where is the logic? - Githubissues

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.

https://www.home-assistant.io

Apache License 2.0

69.03k stars 28.28k forks source link

Automatically deactivate the ping sensor if the host is unavailable. Where is the logic? #116751

Open garry0garry opened 2 weeks ago

garry0garry commented 2 weeks ago

The problem

Automatically deactivate the ping sensor if the host is unavailable. Where is the logic?

What version of Home Assistant Core has the issue?

2024.5.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Ping (ICMP)

Link to integration documentation on our website

https://www.home-assistant.io/integrations/ping

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 2 weeks ago

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 close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign ping` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove 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)}}

jpbede commented 2 weeks ago

What are you looking for? Could you please describe a bit further what you want

garry0garry commented 2 weeks ago

Starting from version Home Assistant 2024.5.0, I periodically observe a short-term disconnection of Ethernet on my mini PC. About once a day.

In the integration "Ping (ICMP)" I have more than 10 ping sensors to check the availability of my devices. Now I discovered that almost all integrations are deactivated.

jpbede commented 2 weeks ago

The ping integration does not deactivate any integration. Besides, the ping integration also does not deactivate it self. The sensor went into unavailable state as we can’t get the rtt for example.

Any integration is responsible to handle unavailable devices on their own. So when a device is not reachable, an integration may went into the reauth stage.

garry0garry commented 2 weeks ago

The sensor went into unavailable state as we can’t get the rtt for example.

So I can no longer hope that binary_sensor.ping_xxx will always be available to check the availability of devices? Diagnostics are automatically disabled because there is no round-trip time (RTT) response?

garry0garry commented 2 weeks ago

I don't understand the logic. Why automatically deactivate the accessibility sensor when it appears to be unavailable? It's just a ping. The user added this sensor to the integration himself. Can you give a situation where automatic ping deactivation is correct?

jpbede commented 2 weeks ago

I don't actually get what your problem is. Could you add some screenshots?

So I can no longer hope that binary_sensor.ping_xxx will always be available to check the availability of devices?

The binary sensor is still available when the device is not reachable. Only then sensor entities are not available.

Diagnostics are automatically disabled because there is no round-trip time (RTT) response?

Diagnostics are not available, if you refer to the diagnostics section.

jpbede commented 2 weeks ago

A unavailable device should look like this:

jpbede commented 2 weeks ago

The diagnostics entities are disabled as there is nothing we can display. If we don't get a ICMP reply we can't display any round-trip-time. As soon the device is available the sensors are active again.

garry0garry commented 2 weeks ago

Today I saw this picture on almost all my pings: Who turned them off?

jpbede commented 2 weeks ago

Ahh now it is a bit more clear. Did you add them manually or did you had them in YAML before?

If you added them manually, then some other integration (or someone) must have disabled them. The integration itself does not deactivate the entity. The only case where the entity is disabled is after it has been imported from YAML to mimic the old behavior.

If you still have them in YAML, please make sure to remove them

garry0garry commented 2 weeks ago

After transferring to GUI, I deleted everything from YAML. And it worked without problems before updating to HA 2024.5.0 (possibly problems with interface overload). Afterwards, Ethernet failures began to appear and in the integration I saw disabled sensors.

user@MyHomeAssistant:~$ grep -i ping *.yaml
automations.yaml:    entity_id: device_tracker.ping_router_trash
automations.yaml:    entity_id: device_tracker.ping_cam18
automations.yaml:      entity_id: device_tracker.ping_switch_4
automations.yaml:      entity_id: device_tracker.ping_switch_2
automations.yaml:      entity_id: device_tracker.ping_switch_1
automations.yaml:      entity_id: device_tracker.ping_router_banya

jpbede commented 2 weeks ago

Ah okay, now I get it.

I see you're using the device_tracker in your automations, I guess you've had them before in your YAML before. When importing the ping configuration from YAML, we only enable the configured platform by default. So you've the device_tracker platform configure, we enable this by default and binary_sensor is disabled by default.

The device_tracker is still available but isn't displayed on the device page. If you want to use the binary_sensor you can enable it, it wont get disabled by default.

garry0garry commented 2 weeks ago

Question: Why were all the ping sensors in the GUI turned on before version 2024.5.0, but are turned off today?

jpbede commented 2 weeks ago

Did you have enabled the binary_sensors before?

jpbede commented 2 weeks ago

There haven’t changed anything in 2024.5 in the ping integration.

From which version did you updated?

garry0garry commented 2 weeks ago

Did you have enabled the binary_sensors before?

Yes. After deleting the settings from YAML, I checked the settings in the GUI.

There haven’t changed anything in 2024.5 in the ping integration.

2024.5.0, subjectively, affected the operation of the network, which caused problems with Ethernet. For example, today the interface was Down/Up all night. In the morning I went into the integration settings and found that the sensors were turned off. There was no information in the log about turning off the sensors.

From which version did you updated?

... 2024.4.4 -> 2024.5.0 -> 2024.5.1

jpbede commented 2 weeks ago

Yes. After deleting the settings from YAML, I checked the settings in the GUI.

Tbh I've the feeling you're mixing binary_sensor and device_tracker. If you come from YAML, there just could be one entity active after import. And based on that you're using device_tracker in your automations, I'm guessing that the binary_sensor was disabled all the time.

How did you configured ping in YAML? Was it as a device_tracker like:

device_tracker:
  - platform: ping
    hosts:
      device_name_1: 192.168.2.10

or as a binary_sensor:

binary_sensor:
  - platform: ping
    host: 192.168.0.1

2024.5.0, subjectively, affected the operation of the network, which caused problems with Ethernet. For example, today the interface was Down/Up all night. In the morning I went into the integration settings and found that the sensors were turned off. There was no information in the log about turning off the sensors.

But there was no change in the ping integration, which could disable a entity. There was literally nothing in this release related to ping :)

With 2024.4 we added some new sensors.

jpbede commented 2 weeks ago

You could open the core.config_entries, this file is stored in your configuration folder in a sub-folder called .storage, search there for entries for ping and send them.

garry0garry commented 2 weeks ago

OK. Now I only have suspicions without facts.

Now I have checked that all sensors are turned On in the GUI.
Now I have corrected everything in automation on binary_sensor.

If the situation happens again, I will write here.

But... I can't understand. If I don’t have a device_tracker in the settings, then where does it come from in entities?

You could open the core.config_entries, this file is stored in your configuration folder in a sub-folder called .storage, search there for entries for ping and send them.


$ grep ping .storage/core.config_entries
"domain": "ping",
"title": "ping_switch_1 der-saray",
"domain": "ping",
"title": "ping_switch_2 kamenniy-saray",
"domain": "ping",
"title": "ping_switch_3 Summer House",
"domain": "ping",
"title": "ping_switch_4 banya1",
"domain": "ping",
"title": "ping_switch_5 Catalyst 2940",
"domain": "ping",
"title": "ping_switch_6 banya2",
"domain": "ping",
"title": "ping_pzem_1",
"domain": "ping",
"title": "ping_pzem_2",
"domain": "ping",
"title": "ping_pzem_3",
"domain": "ping",
"title": "ping_pzem_4",
"domain": "ping",
"title": "ping_well_1",
"domain": "ping",
"title": "ping_router_rp_ax58",
"domain": "ping",
"title": "ping_router_msk",
"domain": "ping",
"title": "ping_router_trash",
"domain": "ping",
"title": "ping_router_banya",
"domain": "ping",
"title": "ping_cam18",
"domain": "ping",
"title": "ping_pzem_5",
"domain": "ping",
"title": "ping_router_summer_house",
"domain": "ping",
"title": "ping_router_der_saray",

jpbede commented 2 weeks ago

OK. Now I only have suspicions without facts.

Now I have checked that all sensors are included in the GUI. Now I have corrected everything in automation on binary_sensor. If the situation happens again, I will write here.

But... I can't understand. If I don’t have a device_tracker in the settings, then where does it come from in entities?

Again, the ping integration always creates a binary_sensor and device_tracker. If you come from YAML, we only enable the entity that was used in YAML before. e.g. when you configured device_tracker in your YAML, than device_tracker gets enabled upon import and binary_sensor disabled.

The device tracker isn't shown on the device page (I think you called it settings) but it is there.

$ grep ping .storage/core.config_entries

I need the whole JSON object :)

garry0garry commented 2 weeks ago

I need the whole JSON object :)

Sent to github@bnck.me

jpbede commented 2 weeks ago

Sent to github@bnck.me

Thx, but I just needed the ping object in the JSON file, not the whole :D But the content confirmed it:

"data": {
  "imported_by": "device_tracker"
},

This indicates, that this was imported from device_tracker config and thus the device_tracker is enabled by default and the binary_sensor is disabled by default. So this behavior is intended and works as expected.

The device_tracker isn't visible on the device page (when you click on the config page on device), so you just saw the binary_sensor, but the device_tracker is still there and enabled and can be used.