Any PING 'presence' that does NOT depend on the built-in method?

Are there any PING 'presence' apps (similar to 'Virtual IP presence sensor') that do not depend on the brain-dead PING implementation built into the firmware?

The built-in one doesn't allow you to set a timeout and has a ridiculously high default of 10 seconds, and when you have a device that is designed to be offline more than online, it will overburden the IP stack and eventually spam:
com.hubitat.app.exception.LimitExceededException: Device N generates excessive hub load on line 69 (method ping)

I worked around it with a NodeRED flow that sets a virtual presence sensor based on the ping status.

What exactly are you trying to assess the presence for, a mobile device or a typically static LAN device?

A static device that sleeps most of the time and has no HTTP interface (so I cannot use any of the URL testers)

Not an unreasonable request for @gopher.ny to add a timeout parameter if possible (I would have use for it myself).

Polling such devices to determine their status is not ideal. Tell us more about your use-case: is there anyway the device itself could hit an endpoint when it wakes ? Do so periodically? Assume it's offline if it hasn't called that endpoint on the hub in X time?

1 Like

Depending on the scale of what you are wanting to monitor, and while I haven't followed through on setting anything substantial up yet myself, I would prefer to offload this kind of network monitoring to something other than HE, like you have done with Node RED. I could accept a small level of monitoring on HE if the numbers of devices were small and they releatd directly to processes I was configuring on HE, but anything else I would prefer to manage outside of HE. Nothing against HE for this purpose, just I don't feel I want to overload it with more network or CPU traffic than is necessary for the automations I want to configure.

In this case, no, the device cannot hit an endpoint by itself, but I want to start a rule (that powers off a Zigbee Plug) as soon as it stops responding. It's just the single device, not a heap of devices...
(Although, now that I have this NodeRED solution, I can think of other ways to use it, like keeping track of how long and when my son is on his gaming PC, Switch or XBox... :smirk:)

The NodeRED solution works fine for me, so I am not going to pursue this any further unless a reliable ping health monitor app appears...

Whatever works for your setup.... That's not a cop-out or back-handed swipe at your choices, just an acknowledgement that everyone's setup is different.

1 Like

That's exactly my approach to home automation: pragmatism...

#1 factor: WAF
#2 factor: comfort/ease of use and reliability

The rest comes after that
(I have too many other things on my hands to spend more time on this side, so I try to find the quickest, easiest way to get things done, and in this case that was a simple NodeRED flow...)

1 Like

I hear you. Can do that :slight_smile:

5 Likes

Next build, just add the timeout as the 3rd parameters. Default if omitted is 3.

def pingResult = hubitat.helper.NetworkUtils.ping('192.168.0.108', 3, 1)
log.debug(pingResult)
4 Likes

Seconds? Milliseconds might be better...

1 Like

It's literally running ping behind the scenes, and all I got to work with is -W parameter that takes seconds. It's a very limited Linux implementation. I'm thinking a quick solution now vs. a nicer solution (probably much) later.

4 Likes

There aren't many things in which Linux compares poorly to BSD, but this is one of them. :worried:

2 Likes

fping is available as alternative on many OS-es, incl. Linux: fping -t [msec]
But it'd have to be included in the image, obviously...

1 Like

Interesting, my list in priority order is:

#1 factor: WAF
#2 factor: WAF
#3 factor: WAF
Etc.

:wink:

1 Like

Fair enough! I can definitely see that...

SWMBO will say nothing when all of it works seamlessly, but complain when the smallest thing doesn't...

2 Likes