[Feature Request] Real ping (ICMP)

[mirekmal]

Description

May we have a real ping widget/sensor implemented?
The reason is, that frequently this is the only way to check specific device availability, while any http(s) communication is done via cloud. Some examples:

• some IoT sensors are using WiFi and are not accessible directly from LAN (via web service) though it is possible to ping them. All configuration/interaction is done via dedicated application (using frequently undocummented API) or via cloud (when pinging cloud server does not indicate status of device).
• monitoring of any VMs (like Windows OS runnin on VMware ESXi). It is possible to launch ESXi web console of such machine (and use such link in href), but pinging this link gives status of ESXi host rather, that VM. It would be good to be able to ping the real IP address of VM in such scenario. On the other hand if no http(s) service is configured on such VM it is not possible to use this IP for ping sensor/widget.

Other

No response

[shamoon]

See #2215

[mirekmal]

WOW, did not expected, that this might create breaking change, though as you mentioned in change description it makes a lot of sense. Thanks a lot for taking time to get this implemented!

[mgrimace]

I use (old) ping to see at a glance if my local non-docker containers are up. I also have check the status of a few websites. Under what circumstances would a non-technical person choose ping or site monitor (i.e., how do you decide which one to use?)

[mirekmal]

Well, not sure if this answer is 'non technical'...

• site monitor would be checkingspecific service (web page response, API calls, etc). This would be like functionall check if specific service is alive.
• new ping would just check if machine on which these services reside (or is source of data for service) is alive.
  So the first one is no change in functionality, it would work as ping works today.
  Another example of second case is Netatmo weather station. It is configured on your local network and is assigned with IP address, but you can't communicate with it locally by any mean. You can just ping it to check if it is present on the LAN. All communication is done using undisclosed API with the cloud service and you can pull weather data from this service only from the cloud. Even public API available for Netatmo in reality communicates with web services. So it is cloud API rather than local API. So, if you want to check status of service, you can distinguish between using ping to local device (as source of data), but the use href to point to publicly available web page of service to pull down weather information from your device...
  This might not be easy to distinguish, but many services works in this model.

[mgrimace]

That's super helpful thank you! So if I'm understanding this correctly:

• siteMonitor a specific service itself, which sometimes aren't directly accessible
• ping source/location/device of a service, which is useful tell you indirectly if a serice is 'up' (e.g., if you can't access it directly, or you want to check a device, etc.)
  (? more or less ?)

[shamoon]

Yep, above seems accurate.

I would think of it like:

• ping = ping (like bash)
  • server received a packet yes / no and how long. Just like bash, no protocol (https), no port, not using http, etc.
• siteMonitor = curl
  • server responded to an http(s) request, even on a specific port

Its a little tricky because we will maintain backwards compatibility by allowing ping: https://domain:port but actually all that will do will be a ping to domain (which is the new proper syntax for the setting). As noted above, there are many instances where users dont care about http response, just a real ping

[shamoon]

it just really depends. Sometimes a server will be up but http still not working, in that case maybe ping is not what you want.

Agree, a little hard to answer 'non-technical' =)

See eg https://stackoverflow.com/questions/4607684/curl-and-ping-how-to-check-whether-a-website-is-either-up-or-down

Also https://unix.stackexchange.com/a/332502

[shamoon]

Sorry for the barrage of comments but also wanted to note this is already in the main image if folks want to test it out to get a sense for how it works

[mgrimace]

Thanks so much, this is all great info. This is an entirely new concept to me, and it's good to have some rationale for which option to choose. I'm not sure if others would benefit from some kind of 'use case' for each in th documentation, but I found this helpful. Thank you both for the info!

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns.